Agentic Dev
The agent fleet, in practice
The principles are easy to write down. This is what running a fleet of coding agents actually looks like day to day - the handoffs, the gates I stop at, and the failure mode that taught me to never trust a single agent's finding.
A while back I wrote that the productivity jump from coding agents isn't a smarter single model, it's an architecture: many narrow agents, typed handoffs, human gates, adversarial verification. That post was the theory. People asked the fair follow-up question - what does that actually look like when you sit down and work? So here is the practice, including the parts that broke.
The unit of work is a narrow agent, not a chat
I almost never ask one agent to "review this change." I fan out. One agent looks only at security. One checks architecture fit against the design we already agreed on. One runs the style and test checklist and nothing else. Each comes back with a short, specific, checkable answer instead of a long plausible one. The narrowness is the whole point: a finding scoped to one concern is a finding I can actually verify or throw away. A general review is just vibes with paragraphs.
Typed handoffs are what turn agents into a pipeline
The difference between a neat demo and something I rely on is whether the agents hand each other data or prose. When an agent returns a structured result against a schema - a list of findings, each with a file, a severity, a claim - the next stage can filter it, route it, and act on it without me in the middle reading every line. Prose makes me the bottleneck. A schema makes the fleet composable. The moment I started forcing structured output instead of free text, the whole thing stopped feeling like babysitting.
I gate on anything hard to undo
Not every step gets to run on its own. The rule I settled on is simple: let agents loose on the cheap, reversible work - searching, drafting, finding, enumerating - and put a human gate in front of anything I can't easily take back. Spawning twenty agents to read the codebase costs me nothing and I don't need to approve it. Merging, deleting, pushing, sending - those stop and wait for me. The agents do the breadth. I keep the judgment for the steps where judgment is expensive.
The failure mode that changed how I work
Here's the part the theory undersells. The characteristic failure of these systems is not that they're wrong in an obvious way. It's that they're confidently, specifically, plausibly wrong. An agent will hand me a finding with a file path, a line number, and a clean explanation, and it will be fiction. Early on I shipped a couple of those because they read like truth.
The fix wasn't a better prompt. It was a second agent whose only job is to try to refute the first one, told to assume the finding is wrong until it can prove otherwise. Real findings survive that. Hallucinated ones fall apart immediately, because there's nothing underneath them to defend. Now nothing acts on a single agent's word. A finding is a hypothesis until something adversarial has failed to kill it.
What it adds up to
None of this is exotic. Narrow the scope, type the handoffs, gate the irreversible steps, and verify by refutation instead of trust. The reason it works isn't that the agents are brilliant. It's that the architecture assumes they aren't, and stays useful anyway. That assumption is the whole trick.