Roles, Not Just Seats
The first mistake is treating "AI-optimized" as a per-person upgrade. Give everyone an agent, tell them to go faster, and you have simply distributed a powerful tool to people whose incentives, review load, and definition of "finished" have not moved. What you get is more code produced by the same number of people who can meaningfully review it—which is to say, a widening review debt.
We prefer to think in roles that can be held by a human, an agent, or a human directing an agent, depending on the risk. A planner owns the problem: what are we actually building, what are the constraints, what does acceptance look like. A builder produces the change against that plan. An independent verifier confirms the work against the acceptance criteria—and critically, is never the same actor that built it. These are not three job titles you must hire. They are three responsibilities you must not collapse into one enthusiastic loop.
Coding agents are genuinely good at the builder role and increasingly useful in planning and verification, which is exactly why the boundaries matter. Tools like Cursor's coding agents and Claude Code will happily plan, implement, and declare victory in a single conversation. They are optimized to be helpful, and "I have completed the task" is a helpful-sounding sentence whether or not it is true. The organizational discipline has to come from you.
The Planner → Builder → Verifier Split
The reason we insist on separating these responsibilities is not bureaucratic. It is that a builder—human or model—cannot be a credible judge of its own work. Anyone who has written code knows the feeling of re-reading your own change and seeing what you meant instead of what you wrote. Models have a sharper version of the same problem: they are strongly inclined to agree that the thing they just produced satisfies the thing they were just asked to do.
So we route work through a directed sequence. The planner produces a small, explicit contract: the change to make, the files likely involved, the acceptance criteria, and any risks. The builder implements only that, and reports what it changed and how it tested it. Then a separate verifier—a different model, a different agent session, or a human—checks the result against the original criteria, not against the builder's account of itself.
The value here is asymmetric. A planner who over-invests costs you some time up front. A verifier who under-invests costs you an incident. So we spend deliberately on independent verification, and we prefer the verifier to run in a fresh context, ideally on a different model provider than the builder, so that shared blind spots do not quietly get rubber-stamped. This is also where evaluation discipline earns its keep; the pattern behind structured agent evaluations is the same instinct applied to the software itself—judge the output against a defined standard, repeatably.
Rituals That Produce Evidence
Teams run on rituals: standups, planning, review, retro. AI-optimized teams need rituals that produce evidence, because chat transcripts and self-reports are the least trustworthy artifacts in the building. An agent saying "tests pass" is a claim. A recorded command, its exit code, the changed files, and a verifier's verdict are evidence.
In practice this means our rituals attach receipts to work rather than opinions. A change does not advance because someone feels good about it; it advances because there is a tested commit, a runnable acceptance check, and an independent sign-off. We keep the lifecycle explicit—planned, building, verifying, reviewing, accepted—and we only move a task forward when there is proof for the transition. When a task fails the same way twice, we stop and escalate to a human rather than letting an agent grind through a third identical repair.
This sounds heavy. It is lighter than the alternative, which is discovering three weeks later that a confident agent quietly stubbed out the hard part. Standards like the Model Context Protocol help here by giving agents structured, auditable access to tools and context instead of improvised guesses—more surface area for evidence, less for hallucination.
Routing Work to the Right Capability
Not every task deserves the frontier. We route ambiguous, security-sensitive, or architecture-shaping work to stronger reasoning and to senior humans, and we route bounded, well-specified changes to fast daily-driver models. Scouting, triage, and documentation can run on cheaper tiers. The point is to optimize verified progress per dollar, not to prove you own the biggest model. Vendor documentation—Anthropic's and OpenAI's alike—describes wildly different capabilities per tier; treat those as inputs to a routing decision you make from your own measured outcomes.
What This Looks Like in Practice
On a recent engagement, a team of six was drowning in a pull request backlog that grew every time they adopted a new agent. We changed almost nothing about their tooling. We changed who was allowed to accept work.
We made the builder responsible only for producing a change plus a self-test report, and we stood up an independent verification step—a separate agent session on a different model—whose only job was to run the acceptance checks and either accept or send it back with a reason. We introduced a one-page "run card" per task: the goal, the acceptance criteria, and the files in scope. And we added a hard rule that no change merged on a self-report; it merged on a tested commit and a verifier verdict.
The backlog stopped growing within a week. Not because they wrote less code, but because the code that reached review already carried evidence, and the reviewers stopped re-deriving whether it worked. The senior engineers moved off line-by-line babysitting and onto planning and architecture—the work only they could do. Throughput went up because the judgment was finally spent where it mattered.
Common Mistakes
- Treating AI as a headcount multiplier. More generated code without more verification capacity just relocates the bottleneck to review.
- Letting the builder grade its own homework. Self-reported success is the single most expensive habit we see. Verification must be independent.
- Rituals that collect opinions instead of evidence. If your process advances work on vibes and transcripts, it will eventually advance a confident mistake.
- Running everything on the most expensive model. Capability is not free; route deliberately and measure outcomes.
- No stop condition. Without a rule to halt after repeated identical failures, agents will cheerfully burn budget looping on the same wall.
- Ignoring senior time. The scarce resource is human judgment. Design the team to spend it on ambiguity and architecture, not on re-checking whether tests ran.
Designing the team is the foundation. But roles and rituals only pay off when they are wired into a repeatable path from idea to running software. In the next article we walk that path end to end—spec, plan, build, verify, review, ship—and show where the receipts attach at each gate.
