Author: andrei

Code is truth, but architecture is strategy.

For the past two weeks, I’ve been deep in the codebase of AMODX, building the core blocks (Hero, Pricing, Contact) and wiring up the Model Context Protocol (MCP) so I can chat directly with my database.

But sometimes, you have to zoom out to see why you are building.

I realized that explaining “Serverless” to agency owners is a losing battle. They don’t care about Lambda. They care about Risk and Speed.

So I mapped out the fundamental difference between the “Old World” (WordPress) and the “New World” (AMODX).

The Problem: The Monolith Tangle

When you host a WordPress site, the “Factory” (PHP/MySQL) is also the “Storefront.” Every visitor walks right into the factory floor.

If a plugin breaks in the factory, the storefront crashes. If a hacker finds a door in a plugin, they are inside the database. It is a vertical stack of dependencies where Latency and Vulnerability compound.

The Solution: The AMODX “Air-Gap”

AMODX is different. It uses an Air-Gapped Architecture.

We separate the Public Edge (Zone 1) from the Private Factory (Zone 2).

1. The Vending Machine (Zone 1): The visitor interacts only with AWS CloudFront and S3. It is static. It loads in <100ms. It is unhackable because there is no database connection.
2. The Factory (Zone 2): This is where I live. The Admin Panel, the Strategy Context, the AI Agents. It sits behind a secure API Gateway.
3. The Bridge (ISR): When we publish, the Factory builds the page and pushes it across the gap to the Vending Machine.

The Factory goes to sleep when we aren’t working. Cost: $0.00.

Sprint Report: Systems Online

While the architecture is the map, the code is the territory. Here is what shipped this sprint:

• ✅ The Block Engine: We moved away from “Pages” to “Structured Blocks.” The Hero, Pricing Table, and Contact Formblocks are live and rendering via Next.js ISR.
• ✅ The Brain (MCP): I can now open Claude Desktop and say “Check the pricing strategy and update the landing page.” It reads from DynamoDB and updates the content without me clicking a button.
• ✅ The Media Library: Secure S3 uploads via Presigned URLs. No file size limits crashing the server.
• ✅ Deployment: You can take the code, follow instructions, and deploy your own agency on AWS and make as many sites as you want. Cloudfront for now.

Next Up: Identity & Commerce

The Core is solid. Now we build the application layer. The next sprint focuses on:

1. The Two-Pool Auth Strategy: Strictly separating “Agency Admins” (Cognito) from “Site Visitors” (Public Pools). This enables comments, communities, and courses.
2. Linking a Domain: Hook a site to an actual domain and test out the analytics integration.
3. The Vault: Native Stripe integration for selling products and memberships.

The Foundry is hot. We are shipping.

I remember the exact moment I decided to burn the ships.

I was looking at a renewal invoice from Bluehost. I had been paying them $100 a year for what they called “Premium WordPress Hosting.” And as I looked at the dashboard, filled with flashing banners for “Pro” upgrades, “Security” add-ons, and “SEO” boosters, I realized something.

I wasn’t paying for infrastructure. I was paying for the privilege of being upsold.

If you type “Best WordPress Hosting” into Google right now, you will see a list of companies – Bluehost, SiteGround, WP Engine – fighting to charge you a premium for DECADES-old technology.

The modern WordPress hosting industry is mostly arbitrage on your ignorance. They take a cheap $5 DigitalOcean droplet, put a cPanel on it, crowd 500 sites onto the same server, and market it as a “Managed Solution.”

So, being a systems engineer, I did the math. I moved the site to my own backroom server. It ran faster. It cost zero. It was easy.

But the hosting bill was just the tip of the iceberg. The real grift was the Plugin Ecosystem.

Held Hostage for A Few Lines of Code

After I moved the site away from shared WordPress hosting, I needed to add a simple contact form. I just wanted to capture an email address and save it to a database.

In the world of software engineering, this is “Hello World” level complexity. It is:

1. An HTML <input> tag.
2. A POST request.
3. A database INSERT.

10 lines of code. Maybe 15 if you add validation.

But in WordPress Land? This is what I found:

• Plugin A: Free, but it doesn’t save entries to the database unless you buy “Pro.”
• Plugin B: Saves to the database, costs $99/year/site.
• Plugin C: Totally free, but the code looked like spaghetti and I’m pretty sure it was harvesting my data.

I sat there, staring at a checkout screen asking for $99 a year to unlock a feature that takes 10 minutes to code.

I felt extorted.

Why are we, as developers and agency owners, paying “rent” for basic functionality? Why is “Security” a paid add-on for managed WordPress hosting? Why is “Speed” a premium tier?

These shouldn’t be products. They should be architecture.

The Real Problem: The “Frankenstein Stack”

WordPress was built in 2003 for blogging. It wasn’t built for modern digital business. To make it do what an agency needs today (Funnels, Gates, API integrations), you have to bolt on 20 different plugins.

• You need MemberPress for access control.
• You need WooCommerce for payments.
• You need Zapier to glue them together.
• You need Wordfence because standard WordPress hosting is insecure by design.

You end up with a Frankenstein Monster. And you are the janitor, spending your Friday nights updating PHP versions and praying a plugin update doesn’t white-screen your client’s site.

You are a Tenant in your own business.

The Solution: Build Sovereignty (AMODX)

I decided I was done paying rent.

I spent the last 20 years architecting safety-critical systems for avionics and medical devices. I know how to build things that don’t break. So I applied that rigor to the Agency Stack.

I wanted to learn how to make applications with a serverless stack, and when I realized what can be done with it, I started making AMODX (Agency Management On Demand Extreme).

It is not just “Another CMS.” It is a Serverless Operating System built on AWS. It eliminates the need for traditional WordPress hosting entirely.

1. Zero Rent (Serverless Architecture)

AMODX doesn’t run on a server that you pay $20/month for. It runs on AWS Lambda and DynamoDB.

• Cost when idle: $0.00.
• Cost when scaling: Pennies per thousands of requests.
• The difference: You pay Amazon directly for the raw compute. You cut out the hosting middleman.

2. Zero Bloat (Native Features)

I refused to build a plugin system that allows third parties to hold features hostage. The core primitives of business are built-in:

• Identity: Native (AWS Cognito). No membership plugins.
• Payments: Native (Stripe Integration). No WooCommerce bloat.
• Data: Native (DynamoDB). No slow SQL queries.
• Lead Capture: Built-in. It saves to the database. For free. Because that’s how software should work.

3. Zero Hacking (Immutable Security)

WordPress hosting gets hacked because the database is connected to the public internet via a PHP script.
AMODX is Static. The public site is a pre-rendered snapshot (Next.js/ISR) sitting on a global CDN. There is no database connection for a hacker to exploit. There is no wp-admin.php to brute force.

The “Maverick” Move

I didn’t build this to compete with Wix or Squarespace. Those tools are for people who want a brochure.

I built this for Builders. For the technical agency owners who are tired of the hosting grift. For the developers who know that a contact form shouldn’t cost $99.

AMODX is Open Source (Apache 2.0).
I am giving you the code.
I am giving you the deployment script (npx cdk deploy).

I am not asking you to pay me a subscription. I am asking you to stop being a Tenant and start being an Owner.

If you want to join the rebellion, check out the repository. It’s time to stop paying for WordPress hosting and start building assets.

Why Agencies Need an “AI Operating System,” Not Just a CMS

For the last 15 years, the answer to “I need a website” has been “WordPress.” It powers 40% of the web. It is the default.

But for a modern agency or a technical founder, WordPress has become a bottleneck. It is a legacy monolith designed in 2003 for blogging, now held together by a fragile ecosystem of plugins.

I am building AMODX, a serverless, open-source WordPress Alternative designed for the AI era.

I am not building it because I hate WordPress. I am building it because I hate friction.

The Problem: Implementation Gunk vs. Idea Flow

In the Art of Gig, there is a concept called “flushing the gunk.” – similar to what James Altucher, a writer, investor, and podcaster, emphasizes that you must generate a huge volume of ideas (including mediocre ones) to find the gems, much like flushing a dirty hose to get clean water.

• Idea Gunk: The bad marketing ideas, the wrong copy, the weak strategies. You want to flush this out fast to find the gold.
• Implementation Gunk: Plugin updates, database connection errors, PHP version conflicts, slow server response times, security patches.

WordPress forces you to wade through Implementation Gunk every single day. If you want to test a new marketing funnel, you spend 4 hours configuring plugins and 1 hour writing copy.

AMODX is designed to invert that ratio. It uses a Serverless Architecture (AWS Lambda + DynamoDB) to remove the infrastructure drag. But more importantly, it changes how you create content.

The Killer Feature: “Context-First” AI Generation

The biggest friction in using AI (Claude, ChatGPT) for marketing is Context.

Every time you open a chat, you have to explain: “I am an agency selling X to audience Y. My tone is Z.”

Existing CMSs (WordPress, Webflow, Contentful) store Content (the final blog post).

AMODX stores both Context (the strategy) and Content.

How It Works (The MCP Integration)

AMODX treats your Strategy, Personas, Pain Points, and Funnel Logic as first-class database objects – hidden from the public, but visible to the AI.

Because AMODX implements the Model Context Protocol (MCP), I can connect my local Claude Desktop directly to my live CMS database.

• The Old Workflow: Copy-paste context into ChatGPT -> Generate text -> Copy-paste into WordPress -> Fix formatting -> Publish.
• The AMODX Workflow: I open Claude and type: “Draft a landing page for the ‘Angry Dad’ persona based on our Q3 Strategy.”
  1. Claude queries the AMODX database to read the “Angry Dad” profile and “Q3 Strategy.”
  2. Claude drafts the content using that exact context.
  3. Claude calls the create_page tool to push the page directly to the staging URL. Or just makes a draft that you can then proofread and approve in the admin panel.

This isn’t just a CMS. It is an Agentic Command Center.

The Comparison: AMODX vs. The Giants

If you are looking for a WordPress alternative, you usually look at Webflow. Here is why I am building something different.

VS. WordPress (The Legacy Monolith)

• WordPress: A database of HTML blobs. Security is a nightmare because the server executes code on every visit.
• AMODX: A database of Structured JSON Blocks. Security is absolute because the public site is a static render (Next.js) detached from the database. There is no wp-admin.php for hackers to brute-force.

VS. Webflow (The Designer’s Tool)

• Webflow: The king of visual design. If you want to drag-and-drop pixels perfectly without code, Webflow wins. But Webflow is a Design Tool, not an Operation System. It is closed-source. You cannot inject custom backend logic (like “Generate a PDF invoice when a form is submitted”) without using third-party glue like Zapier.
• AMODX: Built for Builders. It is “Code-First.” You want to add a custom complex feature? You deploy a Lambda function. You want to orchestrate a multi-step AI workflow? You use EventBridge. Webflow creates beautiful brochures; AMODX creates intelligent business machines.

The Architecture of Speed

AMODX is built on the AWS Serverless Stack:

• Compute: AWS Lambda (Costs $0 when idle).
• Data: DynamoDB (Single Table Design for microsecond access).
• Event Bus: EventBridge (Decoupling the “Save” button from the “Publish” action).

This architecture allows me to deploy a new “Site” in 2 minutes. It handles 1 visitor or 1 million visitors with zero configuration changes.

Why I’m Building in Public

I am documenting this build on The Foundry because I believe the future of agency work is Automated & Sovereign.

We don’t need another way to blog. We need a way to execute strategy at the speed of thought.

If you are a developer or technical founder tired of the “Plugin Soup,” check out the AMODX repository on GitHub. We are building the operating system for the next generation of agencies.

There is a dangerous illusion sweeping through boardrooms, from engineering firms to high-stakes legal practices.

The illusion is that Private AI is just a matter of buying hardware.

The assumption is simple: If we buy a powerful computer and run Llama-3 or DeepSeek on it, we have an AI strategy.

You do not. You have a brain in a jar.

A brain without eyes cannot read your documentation. A brain without hands cannot fix your code or redline your contracts. A brain without a memory cannot recall why you made that specific architectural decision three years ago.

Whether you are deploying On-Premise AI on a rack of Nvidia A100s or a cluster of unified-memory Mac Studios, the hardware is just the substrate. The real challenge and the real cost lies in the architecture required to turn that silicon heater into a secure business asset.

For regulated industries (Avionics, Medical, Legal), the public cloud is not an option. Data leakage is an existential threat. But building a Private AI Infrastructure that actually works requires a shift from “Model Management” to “Systems Engineering.”

If you want AI that runs air-gapped, touches no external API, and respects your internal permissions, you need to stop thinking about “The Model” and start thinking about “The Team.”

Here are the four distinct roles that must exist to build a functioning On-Premise AI ecosystem.

Job 1: The Knowledge Engineer (The Curator)

The Problem: Most companies don’t have “Knowledge.” They have “Data Swamps.”

• In Engineering: Outdated documentation pages, spaghetti code with lying comments, and Jira tickets that say “Fixed it” without explaining how.
• In Legal: Terabytes of PDF case files, scanned depositions, and conflicting clause libraries.

If you feed this raw sludge into a Private RAG (Retrieval-Augmented Generation) pipeline, you get an AI that confidently lies to your staff.

The Work: Someone has to structure this mess. This isn’t just “uploading files.” This is Data Refactoring.

• Parsing specific file formats (C headers vs. Java classes vs. legal briefs).
• Chunking text so the AI understands the difference between a “Requirement” and a “Suggestion.”
• Building the Internal Knowledge Graph that links a line of code back to the specific Requirement ID or a contract clause back to the specific statute.

Job 2: The Prompt Architect & Tester (The QA)

The Problem: Models drift. Prompts are fragile. “It works on my machine” is not a safety standard.

The Work: Who verifies your Private AI?

• The Golden Dataset: You need a human expert to define what “Good” looks like. We need a library of 100 code snippets or 100 contract clauses with the correct analysis attached.
• The Regression Test: Every time you update the local model or tweak the system prompt, you must run it against the Golden Dataset. Did the AI get smarter at Python but dumber at C++? Did it suddenly start using “aggressive” language in a legal review?
• The Context Guard: Ensuring the prompt includes exactly the right context (State Machine logic vs. UI logic) so the AI doesn’t hallucinate a solution that works in the wrong domain.

Job 3: The Application Builder (The Integrator)

The Problem: A chat window is the wrong interface for work.

• An engineer doesn’t want to copy-paste code into a chat box. They want a Pre-Review Sentinel that hooks into Git, scans the Pull Request automatically, and leaves comments inline before a human reviewer sees it.
• A lawyer doesn’t want to chat. They want a Drafting Assistant inside Microsoft Word that highlights risky clauses and suggests approved alternatives from the firm’s specific playbook.

The Work: This is traditional, hard-nosed software engineering. It involves building APIs, managing message queues, handling retries when the local model times out, and enforcing security permissions (RBAC). The AI is just a function call; the Application is what delivers value.

Job 4: The Infrastructure Steward (The Ops)

The Problem: On-Premise AI implies it runs on magic. In reality, it runs on hot, finicky hardware that needs to be updated, secured, and balanced.

The Work:

• The Up-Time: Ensuring the inference server doesn’t crash when five teams hit it at once.
• The Rotation: Swapping models instantly. Today the best coding model is CodeLlama; tomorrow it’s Qwen; next week it’s something else. Your business logic cannot break every time the brain changes.
• The Security: Ensuring that the “Junior Dev” model cannot access the “CEO Only” documents, even if it really wants to be helpful.

Conclusion: It’s Not Magic, It’s Management

We are moving past the “Wow” phase of AI and into the “Work” phase.

Building Private AI is not about buying a magical box. It is about building a new internal competency. It requires the same discipline we apply to building avionics software or preparing a legal defense.

You need a pipeline. You need tests. You need structure.

If you aren’t building the System around the Brain, all you have is a very expensive, very smart hallucination machine.

A month ago, I wrote about building ARDA in record time. The system worked. It was deployed. Users were getting advice.

But “working” is not the same as “working well.” And as I learned in my previous article on technical debt, the phrase that should cause the most panic isn’t “it’s broken” – it’s “don’t touch it, it works.”

ARDA was starting to show cracks. The single-brain architecture that got us to launch was hitting its breaking point. This is the story of how I re-engineered the entire AI pipeline – and why the results were worth the pain.

The Breaking Point: One Assistant, Too Many Jobs

The original ARDA architecture was elegant in its simplicity: one powerful AI model with a massive system prompt containing the entire framework. Give it a user’s situation, and it would:

1. Determine if the question was on-topic
2. Detect who was asking (male or female perspective)
3. Assess relationship timelines and stages
4. Evaluate interest levels
5. Identify red and green flags
6. Score male behaviors (confidence, self-control, challenge, humor)
7. Assess female attitude (integrity, giving nature, flexibility)
8. Identify missing critical information
9. AND THEN compose a coherent, personalized coaching response

That’s nine complex cognitive tasks for a single AI call. And it was starting to fail in predictable ways.

The system prompt was a 15,000+ word constitution trying to govern an impossibly broad mandate. The AI was constantly making trade-offs: focus on analysis or focus on advice? Be concise or be thorough? Follow the framework strictly or adapt to edge cases?

The worst failures came when women asked questions. The system was trained primarily on male-perspective coaching. When a woman would ask about her relationship situation, the AI would sometimes get confused about which role it was analyzing. It would fumble the perspective, mixing up who should be leading and who should be supporting. The advice wasn’t just mediocre – it was sometimes backwards.

The Realization: This is a Systems Engineering Problem

My background is in high-stakes systems engineering – avionics, medical devices, payment security. In those domains, you never give one component too many responsibilities. You decompose. You isolate. You create clear boundaries.

I had violated my own principles.

The solution was obvious once I saw it: treat the AI pipeline like a distributed system. Break the monolithic “super-brain” into a team of specialized analyzers, each with one focused job.

The New Architecture: A Special Forces Team

The redesigned pipeline became a three-stage orchestration:

Stage 1: The Router (Fast Triage)

A lightweight model (gpt-5-nano) with one job: classify the user’s intent. Is this on-topic? Which tier of coaching does it need? This runs in under a few seconds.

Stage 2: The Analyzer Battalion (Parallel Extraction)

Seven specialized analyzers run in parallel, each with a focused prompt and dedicated knowledge base:

1. Polarity Analyzer: Determines user perspective (masculine leader vs feminine partner)
2. Timeline Analyzer: Maps relationship stages and identifies failure patterns
3. Missing Data Analyzer: Identifies gaps in the user’s story
4. Interest Level Analyzer: Quantifies female interest (the core metric)
5. Attitude Matrix Analyzer: Scores integrity, giving nature, flexibility
6. Male Behaviors Analyzer: Evaluates confidence, self-control, challenge, humor
7. Flags Analyzer: Catalogs red flags and green flags

Each analyzer produces structured JSON output. Each one completes in 5-8 maybe 15 seconds and they execute in parallel, they don’t wait for each other.

Stage 3: The Coach (Synthesis and Advice)

The final AI (gpt-4.1-mini) receives:

• The user’s original question
• The vast knowledge base
• The complete conversation history
• All seven analyzer reports as structured data

Its job is now singular and clear: compose a coaching response that addresses the user’s actual question, using the pre-analyzed data as its foundation.

The system prompt shrinks from 15,000 words to about 4,000. The cognitive load drops by two-thirds.

The Implementation: Clean Architecture Saves the Day

This re-architecture would have been a nightmare in a tangled codebase. But ARDA was built on Clean Architecture principles from day one.

Each analyzer is isolated with retry logic and individual database commits. If one analyzer fails, the others continue. The frontend receives real-time progress updates via Server-Sent Events.

The refactor took three intense days. Zero breaking changes to the API. Zero downtime.

The Results: Night and Day Difference

The improvement was immediate and dramatic:

Before (One prompt to do everything):

• Generic, sometimes confused responses
• Frequent perspective errors with female users
• Missed critical red flags and data points in complex situations (doubled by inability to identify missing data)
• Applying female attitude analysis on male partners

After (specialized analyzers feed data to the assistant):

• Precise, data-grounded advice
• Perfect handling of female-perspective questions (polarity analyzer routes to the correct system prompt)
• Comprehensive flag detection in every response
• Consistent, structured analysis regardless of complexity
• Mapping of every relationship and missing data

The polarity analyzer solved the female-user problem completely. Now when a woman asks for advice, the system:

1. Detects she’s asking from the feminine perspective
2. Loads a completely different system prompt tuned for that role
3. Analyzes her situation through the correct lens
4. Provides advice appropriate to her position

The Lesson: Separation of Concerns at the AI Level

This refactor reinforced a principle I’ve learned throughout my career: the fundamental patterns of good engineering transcend the technology.

Whether you’re building avionics software or an AI coaching system, the same rules apply:

• Single Responsibility: Each component should have one job
• Clear Boundaries: Inputs and outputs should be explicit
• Testability: You should be able to verify each piece independently
• Composability: Complex behavior emerges from simple, focused pieces

The AI revolution hasn’t changed these principles. If anything, it’s made them more critical.

Looking Forward: The Pipeline is Just the Beginning

The analyzer architecture opens new possibilities:

• Personalized Knowledge Injection: Each analyzer can pull specific framework knowledge relevant to its analysis
• Adaptive Depth: Another analyzer can pinpoint the exact knowledge base entries that apply, making it into an effective RAG selector
• Live Verification: Additional analyzers could check the final response for quality (empathy, directness, actionability)
• Historical Tracking: Analyzers can reference previous assessments to track user progress over time

But the core lesson remains: when you’re building AI systems, think like a systems engineer. Don’t ask one brain to do nine jobs. Build a team.

---

Technical Note: The complete pipeline runs on Spring Boot with LangChain4j orchestration, using a mix of OpenAI models (gpt-5-nano for routing, gpt-4.1-mini for coaching) and parallel execution via Java’s CompletableFuture. The frontend is React with Server-Sent Events for real-time progress updates.

Two months ago, ARDA was just an idea born from a 20-year-old dream: an AI coach that could provide the brutally honest, reality-based relationship advice I wished I’d had as a young man. Today, it’s a deployed, full-stack application.

This wasn’t a miracle. It was a sprint of intense AI engineering, a process that was far more about taming the beast than simply wiring up an API. This is the real story of what it takes to build a truly intelligent, context-aware AI system.

The First Mistake: Naive RAG and the “Similarity” Trap

My initial approach was the textbook one: a simple Retrieval-Augmented Generation (RAG) pipeline. The idea was to take a user’s question, find “similar” chunks of text in my vast knowledge base using token similarity, and feed those chunks to the AI.

It was a complete failure.

The system was stupid. It would find superficial keyword matches but miss the deep, underlying principles. It was like a research assistant who could find books with the word “king” in the title but couldn’t tell you the first thing about Machiavelli. I realized that for a system as nuanced as ARDA, a simple RAG pipeline was not enough.

The Pivot: Brute-Force Context

This led to a radical pivot. Instead of spoon-feeding the AI small, “similar” chunks of knowledge, I decided to give it the entire library. I would leverage the massive context windows of modern models to inject ARDA’s entire philosophical DNA into every single conversation.

My job transformed from “developer” to “knowledge distiller.” I spent weeks meticulously deconstructing dozens of foundational texts – from Doc Love to Daniel Priestley to Jordan Peterson – and structuring them into a tiered JSON knowledge base, working them to first principles, ensuring no critical nuance was lost.

• The BASE_ASSISTANT gets an 85k token knowledge dump.
• The WINGMAN_ASSISTANT gets 120k.
• The FULL_COACH gets the entire 150k+ token library.

The Model Gauntlet: Finding the Right “Brain” for the Job

Injecting the full context was a breakthrough, but it revealed the next major challenge: not all models are created equal. I ran a gauntlet of tests:

• GPT-5: Brilliant, creative, and utterly undisciplined. It would constantly break character, defaulting to a helpful, therapeutic, mainstream persona. It was a genius that couldn’t follow orders. Useless for ARDA.
• Gemini 2.5 Pro and Flash: The massive context window was seductive, but like GPT-5, it would sometimes wander off track, losing the core thread of the ARDA philosophy.
• Claude Sonnet 4: Impressively good at adhering to a large set of initial instructions. It was a disciplined soldier, excellent for scaffolding and following architectural principles. A strong contender. VERY EXPENSIVE.
• GPT-4.1-mini: The unexpected champion. While GPT-4.1 was marginally better at analysis, it was significantly slower and more expensive. GPT-4.1-mini hit the perfect sweet spot: it was disciplined enough to stay in character, fast enough for a real-time chat experience, and cost-effective enough to build a viable business on.

The final architecture became a multi-model “special forces” team, orchestrated with LangChain4j:

• The Router (GPT-5-micro): Solid, fast, and reliable for the simple task of classifying user intent.
• The Translator (GPT-5-mini): Exceptionally good at its one job.
• The Coach (GPT-4.1-mini): The workhorse, the disciplined core of the operation.

I am also exploring self-hosting models, I don’t want a critical piece to depend on one vendor.

The “In-Memory Database”: Conversation as Context

Early on, I considered modeling the user’s situation in a complex set of database entities. I quickly realized this was a fool’s errand. I would be constantly translating text to entities and back to text. Overengineering much?

The solution was simpler and more powerful: the conversation history is the database. The entire, ongoing chat log is passed to the AI with every turn. We do have large context models. This allows the AI to “remember” its previous diagnoses, track the user’s progress, and detect changes in his situation or proficiency level without a complex persistence layer.

How Do I Test This?

Oh this was maybe 40% of the effort. I have a batch of 150 input “stories” where I already knew what the answers should be. I also went to Reddit for fresh content and see how the AI would respond and I found many gaps this way. Some were added to the test batch. With any major rebuild of the system prompt or a reorg of the knowledge base I would run them again and verify the AI responses.

This can absolutely be automated in the future. I am even thinking of adding LIVE VERIFICATION of the AI responses – did it address the user question directly? Did it empathize if the user was in pain? Did it introduce new (and appropriate) information? Did it reframe the situation in a productive way? (for the user to see their own way out)

But live verification would mean longer response times. We’ll see where this goes.

Conclusion: AI Engineering is the New Frontier

In the end, building ARDA was less of an application engineering challenge and more of an AI engineering challenge. The Spring Boot backend and React frontend were straightforward, thanks to the Clean Architecture principles I had mastered on previous projects. That solid foundation gave me the freedom to iterate on the AI component at an incredible pace, going from idea to deployment in just two months.

The final lesson is this: building a powerful AI product today is not about having the most complex backend. It’s about a relentless, empirical process of:

1. Distilling and structuring deep domain knowledge.
2. Selecting the right model for the specific job, not just the biggest one.
3. Engineering a master prompt that acts as an unshakeable constitution for the AI’s “mind.”
4. Test, verify, and then verify some more, because when you tweak something, you might get unexpected breakdowns.

It’s a new kind of engineering, a hybrid of librarian, psychologist, and architect. And we are only just getting started.

“Vibe coding” is the new high. The dopamine rush of brainstorming with a Large Language Model (LLM), copy-pasting a near-perfect snippet, and watching a feature spring to life in minutes is intoxicating. I’ve shipped products this way. I get the thrill.

But I’ve also seen the hangover. Vibe coding, when done without discipline, is the fastest way to accumulate massive technical debt. You’re not building a system; you’re creating elegant-looking spaghetti code at warp speed. The application grows in whatever direction the AI’s probabilistic winds are blowing, while your own architectural understanding remains shallow.

The challenge of our era is not how to use AI to code faster, but how to use it to build better. This requires moving from a “vibe” to a professional loop—a system that harnesses the AI’s power without surrendering to its chaos.

The Evolution of the Beast: A Brief History of My AI Pair Programmers

The effectiveness of any AI-assisted workflow depends heavily on the model you’re working with. My own journey mirrors the evolution of the technology:

• The Early Days (GPT-3.5 and then working with GPT-4): In the early days, it was quite painful to work with GPT-3.5. But when GPT-4 came along it became genuinely useful. It had actionable advice. It was explaining what’s under the hood correctly. I was able to write 2 iOS apps in Swift with it helping along the way.
• The Golden Age (ChatGPT with their o1, o3 and even o4-mini models): When they launched o1 and o3 that’s when I thought these might one day replace some devs for real. They were excellent at following instructions, maintaining context within a session, and generating robust code based on a clear architectural plan. Sometimes I was refactoring an entire module in one shot. I was amazed.
• The “Amnesia” Era (The Switch to GPT-5): Then, the landscape shifted. With the rollout of GPT-5, they turned off the great models and the experience became painful. GPT-5 is amazing for OpenAI because it’s cheaper and it does some party tricks well. The AI became a brilliant but frustratingly forgetful partner. For me it was a step back. I was back to reminding the AI of the architectural principles we had just discussed, and correcting its lazy deviations from the plan. The “vibe” was gone; it was replaced by a constant, tedious battle to keep the AI on track.
• The Architect’s Ally (Anthropic’s Claude): In search of a more disciplined partner, I turned to models like Claude. Its strength lies in its large context window and its remarkable ability to adhere to a complex set of initial instructions. It excels at ground-up scaffolding. You can provide it with your entire Clean Architecture philosophy and a detailed project spec, and it will generate the initial modules with impressive fidelity. It’s the best “Day 1” architect’s assistant I’ve found.
• The Master Debugger (Google’s Gemini): For ongoing development and chasing down complex bugs, Gemini’s massive context window – and its ability to ingest entire codebases via zip files – is a game-changer. The ability to prompt it with, “Here is my entire frontend and backend; find the source of this cross-layer bug,” is a superpower. It can see the whole system, not just the single file, making it an invaluable tool for maintaining a clean architecture.
• The Unexpected Helper (XAI Grok): I would ask an AI to give me instructions do to something I had never done before – and it would produce a high level plan. No details. No contingency. I’d start and fail at the first instruction and I had to re-prompt forever. But Grok is different, I can ask it detailed step by step instructions and it would produce a level of detail and depth I had never seen from an AI.

Don’t get me started on Codex, Claude Code and other agentic token wasters that run around in circles. Right now they’re just alpha software being pushed as an excuse for asking for ever higher subscription prices. They works at that. It is seductive to think “you can leave it to the AI” but in my experience you get the best results when you know your architecture and you verify everything the AI produces before using it.

The Professional Loop: How to Keep the AI on a Leash

The lesson is clear: the model is just a tool. Your process is what determines the quality of the output. The right way to “vibe code” is to set immutable rails for the AI to run on.

1. Plan Before You Prompt.

An experienced engineer can do this in minutes. Before you open the chat window, you must have a clear mental (or physical) model of what you’re building. What are the user journeys? What are the core modules and their responsibilities?

2. Document the Architecture and Context.

The LLM never joins your meetings. You must be its institutional memory. Create a simple, living document that outlines your architectural principles, your naming conventions, and your core domain language. Obsess over clean code and clean architecture. Establish clear rules. Write mappers between domains. You’re not writing them manually, they are just one prompt away. USE THIS.

3. Prompt with Precision and Authority.

Your prompt is a command, not a suggestion.

• Bad Prompt (Vibe): “Hey, can you make an endpoint to get users?”
• Good Prompt (Professional): “Using our established Clean Architecture, create a ‘GetUserUseCase’ in the core application layer. It should take a ‘UserRequestModel’ and return a ‘UserResponseModel.’ Here are the definitions for those models. Adhere to the single responsibility principle. Do not include any database logic in the use case.”

4. Iterate, Test, and Commit.

Build piece by piece. Only after a component is written, tested, and committed to your version-control system do you move on. The source of truth is your Git repository, not your chat history.

Conclusion: You Are the Architect, Not the Prompter

Vibe coding is here to stay. The speed is too seductive to ignore. But the developers who will win in this new era are not the ones who can prompt the fastest. They are the architects who can think with the most clarity.

The AI is a powerful but chaotic force. It is a firehose of code. Without the solid container of a clean architecture and a disciplined process, that firehose will simply flood your project with unmaintainable complexity.

Set the rails first. Then, and only then, let the AI accelerate you down the track.

The AI is a powerful but chaotic force… Without the solid container of a clean architecture and a disciplined process, that firehose will simply flood your project.

It’s a principle that applies far beyond code. A life without a strong internal frame and a guiding philosophy will be similarly overwhelmed by the chaos of the modern world.

The phrase that should cause the most panic in software isn’t “it’s not working.” It’s “don’t touch it, it works.”

That phrase is the siren song of technical debt – the hidden liability you cannot see, but which is quietly compounding interest in your codebase. When structure decays and understanding lives only in a developer’s head, your “working” application is a time bomb.

This is how I learned that lesson the hard way, and this is the architectural philosophy you must adopt to avoid the same trap.

The “It Works” Illusion: A Wake-Up Call on a Team Project

As a solo developer, I had a simple loop: tackle the gnarliest task first, produce a quick solution, then spend a day refactoring the resulting spaghetti code. It felt productive. An architecture eventually emerged. It worked.

Then I started a Java Spring Boot application with a friend. I sprinted ahead, trusting Spring’s conventions to keep things clean. My teammate, a sharp architect and a member of my personal “Council,” delivered a brutal diagnosis: “Great demo code, but the business logic is buried. We can’t maintain this.”

He was right. The application “worked,” but it was a tangled mess. Controllers, services, and repositories all held disconnected fragments of the same core business rules. A simple change in one file would trigger a cascade of unpredictable bugs elsewhere. The what was functional, but the why was completely invisible inside the code itself.

The Solution: Isolating the Core with Clean Architecture

The fix was a disciplined and rigorous refactor to a Clean Architecture. The principle is simple but profound: you must ruthlessly isolate your core business logic (the “Entities” and “Use Cases”) into plain, framework-agnostic objects. Persistence, UI, and external frameworks are treated as volatile “implementation details” that plug into this stable core.

After the overhaul, the results were transformative:

• Business logic changes stayed in one place. No more hunting through a dozen files. Mappers take care of converting data for various domains.
• New services or data sources could be plugged in without touching the core rules.
• Development velocity increased while cognitive load and stress plummeted.

We had moved the knowledge from our brains into the architecture itself.

The Two Sources of Hidden Liability

This experience taught me to recognize the two primary sources of technical debt:

1. Arcane Knowledge: When a system’s behavior exists only in tribal memory or a dusty, outdated document. New developers are paralyzed, and the original developer becomes a single point of failure.
2. Spaghetti Code: When the “why” of the system is invisible inside tangled conditionals and duplicated logic. The code works, but no one, not even the original author, can confidently predict the full impact of a change.

The Discipline of Refactoring and Self-Explanatory Code

The only antidote is a disciplined process. Documentation alone is not enough; it inevitably drifts out of sync. The goal must be self-explanatory code: clear names, small functions with single responsibilities, and explicit boundaries between modules. Comments should capture intent (“why we are doing this”), not implementation trivia (“what this loop does”).

And a note on modern AI tools: Large language models can format code neatly, but they are masters at generating elegant-looking spaghetti. An AI will give you a “working” solution in seconds, but it has no architectural conscience. You must guide it with a well-defined structure and clear boundaries to avoid accumulating technical debt at warp speed.

Conclusion: Sustainability is the True Metric

“Working code” is not the finish line; it is the starting line. The true measure of a well-engineered system is its sustainability: how easy is it to change, to maintain, and to be understood by a new team member five years from now?

Are you sitting on a hidden liability in your own “working” code? Don’t wait for the inevitable catastrophic failure. Start paying down your technical debt today. Your future self will thank you.

In every high-stakes project, I’ve seen the same five archetypes emerge. I call them the “Zen Ninjas.” They are not just roles people play; they are the fundamental energies that determine a team’s success or failure.

More importantly, I’ve come to realize these five ninjas exist inside every one of us. Your mind is a team. And if that team is out of balance – if one ninja is running the dojo – your life, your career, and your projects will inevitably suffer.

This is a field guide to the five saboteurs on your inner team.

1. The Crimson Ninja: Passion Without a Plan

Crimson is the embodiment of pure, unbridled energy. He’s the one who charges into a new project with infectious enthusiasm. He is the Lover archetype in its most creative and impulsive form.

• His Strength: He provides the initial spark that overcomes inertia.
• His Shadow: Unchecked, his passion leads to rushed work, technical debt, and burnout. He starts a dozen features but finishes none. He is the “Lover” in his shadow form—the Addict, chasing the next new thrill.
• The Integration: His energy must be channeled by a plan. The lesson is that passion without the discipline of the Warrior is just chaos.

2. The Storm Ninja: Vision Without Focus

Storm sees the future. He sketches grand architectures and envisions the ultimate product. He is the Magician as a pure visionary.

• His Strength: He provides the “north star” that inspires the team.
• His Shadow: He gets lost in his own brilliant ideas. He’s always three releases ahead, while the current sprint is on fire. He is the “Magician” in his shadow—the detached intellectual, in love with ideas but disconnected from reality.
• The Integration: His vision must be broken down into actionable, concrete steps. A grand vision without the pragmatic leadership of the King is just a daydream.

3. The Glacier Ninja: Logic Without Latitude

Glacier is the master of order and precision. He produces flawless code, documents everything, and never misses a detail. He is the embodiment of pure Order.

• His Strength: He provides the stability and reliability that every system needs.
• His Shadow: His rigidity can stifle creativity and innovation. He fears the “messy” process of experimentation. He is the shadow of the King – the Tyrant of Rules, who prioritizes the process over the outcome.
• The Integration: He must learn that true order is not rigid; it is adaptable. He must embrace that a period of controlled Chaos (the Lover’s domain) is necessary for breakthrough innovation.

4. The Mountain Ninja: Support That Becomes a Bottleneck

Mountain is the selfless teammate, the first to help a colleague in distress. He is the nurturing, empathetic aspect of the Lover.

• His Strength: He builds morale and fosters a collaborative spirit.
• His Shadow: In his selfless desire to help, he neglects his own critical tasks. He becomes the “Masochist” shadow of the Warrior – sacrificing his own mission for the sake of others’ approval. His “help” becomes a source of system-wide delays.
• The Integration: He must learn the Warrior’s discipline of setting boundaries. He must understand that the greatest service to the team is to first complete his own mission with excellence.

5. The Wizard Ninja: Strategy Without Grounding

Wizard is the mentor and strategist. He sees the big picture, secures the resources, and sets the direction. He is the King as a pure strategist.

• His Strength: He provides the vision and the resources for success.
• His Shadow: He can become too detached from the day-to-day reality of the work. His grand strategies can fail if they are not grounded in the practical realities of the team’s capacity. He is the “Weakling” King – abdicating the hands-on responsibility of leadership.
• The Integration: He must pair his high-level vision with a deep, practical understanding of the work on the ground. He needs the Warrior’s connection to action.

Conclusion: The Integrated Leader (The Master of the Dojo)

A successful project is not about having one of these ninjas. It is about a single leader who can consciously access and deploy all five energies as needed.

A true leader is the master of this inner dojo. He has the Lover’s passion to start the mission, the Magician’s vision to see the destination, the King’s wisdom to chart the course, and the Warrior’s discipline to walk the path.

This is the essence of systems thinking, applied to the most complex system of all: the self. Before you can lead a team, you must first learn to lead the team within your own mind.

Every founder’s journey has a “Point A,” but the path to building something meaningful is never a straight line. The story of ARDA, my AI relationship coach, didn’t start with a grand vision. It started with a book, a personal obsession, and a series of accidental projects that forged the skills I didn’t even know I’d need.

This is the real story of how I got here.

Step 1: The Tutorial (Following the Map)

I’ve spent my career engineering high-stakes, safety-critical software. But the world of modern full-stack web development was a new territory.

And my personal projects were taking me there. I had been using Excel as a personal tracking tool for a while (when JIRA is too much…), and also Apple Notes. But I wanted an integrated solution instead of copy pasting content between tools.

A trusted friend and fellow engineer – a member of my “Council” – gave me my first mission: “Go through ‘Full Stack Development with Spring Boot and React.’ Build the CRUD app. Master the fundamentals.”

So I did. I treated it like a professional assignment. I finished the book, and I had a working, but generic, application. I had followed the map. I had the basic skills.

Step 2: The Personal Project (Drawing My Own Map)

A tutorial is not a product. To truly master the craft, I needed to solve a real problem. My own was chaos. My personal projects were a mess of spreadsheets, notes, and a complete lack of a coherent status overview.

By then I had started using ChatGPT for my personal projects so I took the next step – to build the project tracking tool of my dreams. It was an ambitious mix: an Excel-like interface for tasks, an Apple Notes-style organization for projects, and a way to automatically generate status updates. I was obsessed. I coded on it every spare moment, even while visiting one of my wife’s clients in the countryside.

Step 3: The Accidental Client (The First Real Test)

The small business owner we were visiting saw the project tracker over my shoulder. He saw the structure, the organization.

“My team is drowning in emails and spreadsheets,” he told me. “Can you build something like that, but for managing our customers?”

He wasn’t asking for a project tracker; he was asking for a custom CRM. And he was willing to pay for it. My personal learning project had just become my first real-world business application.

After meeting their team and gathering their first requirements, I dove in. The first version worked, but as the features grew, I hit a wall. It wasn’t that it couldn’t scale; the problem was that it was becoming increasingly hard to change. Business logic was tangled in services and controllers. A simple modification in one place would cause a cascade of bugs elsewhere. The system was accumulating “technical debt” at an alarming rate. This is where my “Council” member intervened again, introducing me to the principles of Clean Architecture – a revelation that became the new foundation for all my future work.

Step 4: The AI Catalyst (Solving a Problem at Home)

With the CRM delivered, I had a new, robust architectural framework. But the next leap came from my own home. My wife, a freelancer managing multiple WordPress sites, was frustrated with generic AI tools.

“ChatGPT is useless for my workflow,” she explained. “Every time I want to generate content for a client, I have to re-explain the entire context: who the client is, their audience, the tone of voice, the specific page I’m working on.”

She needed an AI that wasn’t just smart; she needed an AI that was context-aware.

That became my next obsession. I built her a tool. A simple interface where she could select a site and a page, and when she opened the AI chat, the tool would automatically inject the entire context into the prompt. It was a workflow improvement. In building it, I learned the fundamentals – first working with the REST API, then defining tools (have the AI retrieve a page and analyze it for example).

The Final Convergence: From Tools to Mission

I now had a complete, battle-tested arsenal:

• A full-stack development framework built on Clean Architecture.
• Experience with payments and security.
• A deep, practical understanding of building context-aware AI with RAG.

I was an engineer with a powerful set of solutions, looking for my true problem to solve.

And when the guys were discussing their marriage issues, it all clicked into place.

The 20-year-old dream resurfaced: “I wish I had an application to keep me on track, to be the brutally honest coach in my pocket.”

My two paths – the 20-year journey of mastering relationship dynamics and the 20-year journey of mastering systems engineering – had finally converged. I didn’t just have the vision anymore. I finally had the full stack. And it looked so simple in my mind – just another AI interface, with a list of discussions. But guided by a very specific set of principles.

That is how ARDA was born.

This blog is the transparent, “build in public” story of that mission. It’s the workshop, the forge, and the foundry where I am taking two decades of hard-won wisdom and hammering it into a system that can help the next generation of men.

Welcome to the forge.