How I ship production code with a team of AI agents

AI can write code faster than any person. That stopped being the hard part a while ago. The hard part is trust: knowing that what the agent wrote is correct, secure, and still correct after the next ten changes.

On a production trading terminal, "it looks right" isn't good enough. So I don't use one AI assistant. I run a small pipeline of specialised agents, each with one job, a written rulebook, and no permission to grade its own homework. This is how it works.

The pipeline at a glance

A ticket is scoped against the API contract.
Implementer agents build it in parallel, each in its own git worktree.
Hard gates run before anything is pushed.
An adversarial reviewer agent tries to break the change.
An AI review loop runs until there are zero findings.
I review and sign off.

Each step exists because something went wrong without it.

1. The contract is the oracle

Tickets are written by humans, and humans are vague. An OpenAPI contract is not. Every agent reads the contract at the exact branch it's working on, not whatever happens to be checked out locally. When the ticket and the contract disagree, the contract wins.

This one rule removes a whole category of bugs: validators that drift from the real API, enums that are almost right, fields that are optional in one place and required in another.

2. Implementers work in isolated worktrees

I run two implementer agents at once, and each gets its own git worktree. They never share a working directory, so they can't step on each other's files, and I can review two tickets in parallel without any merge chaos.

Parallelism is where agents really pay off. One engineer can keep several streams of work moving, as long as each stream is isolated.

3. Nothing ships red

Before any push, the full set of gates must pass:

lint across the whole repo
unit tests in every workspace, not just the one you touched
a production build
end-to-end tests in a real browser

"Lint passed" is one step, not the gate. Agents are very good at declaring victory early, so the gates are scripted and non-negotiable.

4. A reviewer whose job is to break it

The reviewer agent works in its own worktree, checked out at the exact commit being reviewed. Its job isn't to confirm the change works. Its job is to find what the implementer missed, and it attacks five classes of defects every time:

Untrusted input read before it's validated
Data bound to the wrong owner, such as a result landing after the user switched account
Validators drifting from the contract
Boundaries and precision: testing both sides of every limit, and stopping exactly on it
UI that misstates or leaks state

5. A finding needs a failing repro

This is the rule that makes the whole system work. A reviewer can't just say "this looks wrong". Every finding has to come with a failing test that reproduces it, plus a control that proves the test fixture itself is valid.

Without that, AI review turns into noise: plausible-sounding concerns that waste hours. With it, every finding is either real and provable, or it doesn't exist. I wrote more about this in why every AI code reviewer needs a failing repro.

6. Approval is per commit

An approval applies to one commit and nothing else. If the branch moves, even by a one-line docs change, it gets reviewed again. It sounds strict, but it's the only way an approval actually means something.

7. Knowing when to stop

An AI review loop can run forever if you let it. The trend tells you when to stop: three findings, then two, then one, then a nitpick. When a round's only finding exists because of the previous round's fix, the loop is reviewing itself, and that's the signal to ship.

What this buys you

Agents do the volume: the typing, the test writing, the first pass of review. I do the judgement: what to build, which findings are real, and when it's ready. The result is that one engineer can ship like a small team, with more review than most teams actually get.

If you want a workflow like this set up for your own team, let's talk.