My AI coder is not allowed to choose the database. It doesn’t decide whether to use event sourcing or CRUD. It doesn’t pick the deployment strategy. And it absolutely doesn’t get to skip the security scan because “the code looks fine.”
I designed it that way — for the same reason professional engineering teams separate these responsibilities.
One Agent, One Responsibility
When most people talk about “AI coding,” they imagine a single agent that does everything: understands the requirement, designs the solution, writes the code, tests it, and ships it. That’s like hiring one person to be the architect, developer, QA engineer, and security analyst simultaneously.
It works for small things. It fails for anything that matters.
Instead, I use a pipeline of specialized agents, each with a clear responsibility:
-
Interviewer — Extracts requirements and domain knowledge through structured conversation. Produces a transcript of decisions, constraints, and business rules.
-
Ubiquitous Language — Distills the interview into a domain glossary, bounded context definitions, and a context map. This becomes the shared vocabulary for everything downstream.
-
Change Planner — Decides what needs to change based on the requirements and current codebase. Produces a detailed plan: which files to modify, which new components to create, which tests to write.
-
Architect — Makes structural decisions. Chooses patterns, evaluates trade-offs, and documents decisions as Architecture Decision Records (ADRs). No new architectural pattern enters the codebase without a recorded rationale.
-
Coder — Implements the plan. Writes the code and tests, following the architecture the architect defined and the vocabulary the UL agent established. This is the only agent that touches production code.
-
Quality Check — Runs static analysis, enforces 100% line and mutation coverage, verifies architecture boundary compliance. Accepts or rejects the change.
-
Security — Scans for vulnerabilities, checks dependencies, validates against OWASP guidelines. Accepts or rejects.
-
Delivery — Handles CI/CD, infrastructure-as-code, and deployment.
Why Separation Matters
The temptation with AI is to collapse this pipeline into a single prompt: “Build me a feature that does X.” The AI will happily comply. It will make architectural choices implicitly, skip quality checks it doesn’t know about, and produce code that works but isn’t governed.
Separation of concerns in the agent pipeline catches problems that a single-agent approach misses:
The architect prevents accidental complexity. When the coder agent needs a new data access pattern, it doesn’t invent one. The architect evaluates whether the existing patterns suffice or whether a new one is justified — and if so, documents why. This is how you prevent a codebase from accumulating five different ways to query a database.
The quality agent catches what the coder doesn’t know to test. The coder writes tests for the code it generated. The quality agent runs mutation testing to find behaviors the coder’s tests don’t actually verify. These are different perspectives, and they catch different things.
The security agent doesn’t trust the coder’s judgment. The coder might generate code that passes all functional tests but introduces a SQL injection vector or logs sensitive data. The security agent treats every change as potentially hostile — the same way a security team reviews a pull request from any developer, no matter how senior.
Architecture Decisions Need Records
One of the most valuable practices in this pipeline is the Architecture Decision Record. Every significant structural decision gets documented:
- What was decided
- Why this option was chosen over alternatives
- What trade-offs were accepted
- When this decision should be revisited
When the coder agent works within a well-documented architecture, it produces code that’s consistent with the system’s design principles. When it encounters a situation where the existing architecture doesn’t have a clear answer, it escalates to the architect agent rather than improvising.
This mirrors how mature engineering organizations work. Junior developers don’t make infrastructure decisions. Senior developers don’t skip code review. Security reviews aren’t optional because the developer is confident. The pipeline enforces the same discipline — regardless of whether the “developer” is human or AI.
The Pipeline in Action
This week I was working on a system that needed a new observability feature — hierarchical trace trees that span multiple Lambda invocations. In a single-agent approach, the AI would have jumped straight to code. Instead:
The interviewer clarified what “trace” means in this specific domain (not generic logging — structured hierarchical trees built from domain events).
The UL agent updated the glossary with precise definitions for Trace Tree, Span, and Projection.
The architect decided to build traces as a read-model projection from the event store, rather than as a write-time concern. This kept the domain model clean and made traces eventually consistent rather than requiring synchronous instrumentation.
The coder implemented the projection, repository, and API endpoints — following the architecture decision, using the glossary terms, and writing tests at every layer.
The quality agent ran mutation testing and found gaps in the projection tests. The coder wrote additional tests until every mutant was killed.
The security agent verified that trace data didn’t leak sensitive information from the events it projected.
Each agent did one thing well. The result was a feature that was architecturally sound, well-tested, secure, and used consistent domain language. No single agent could have produced that outcome alone.
The Takeaway
The power of AI-assisted development comes from building a pipeline where different concerns are handled by different agents — the same way professional teams separate architecture from implementation, quality assurance from development, and security from everyone.
Don’t let your AI coder make architecture decisions. Don’t let your AI architect skip the quality gate. And don’t let any single agent be the judge of its own output.
Separation of concerns applies to AI workflows just as much as it applies to code.