Four steps, three models: how our AI dev loop ships code

In August we counted the last ten pull requests our AI dev loop had opened. Not one passed review on the first try. Between them they took 43 rounds of review before they were clean.

That sounds bad, but it is the point. The loop is built so the AI finds its own mistakes before a person ever looks at the change. This post explains how it works, what went wrong along the way, and what we changed.

The loop is part of Miko Assistant, our desktop assistant that drives Claude Code by voice. When you ask Miko to work on a task, she starts a session that runs /miko-dev: a plan, a grade, the code, then a review, each done by a different AI model. We use it every day, including to build Miko herself.

How the loop works

Each step runs as its own agent with its own model. The plan goes back for revision until it earns an A+. The code goes back for fixes until a review comes up clean. Each of those loops stops after three rounds.

Why use different models

It started simply: Fable planned, Fable graded the plan, and Opus wrote the code. Then we noticed that most of what we paid for went into writing the code. The writer only needed a strong model because the plan left design decisions open for it to make.

So in August we moved the design work into the plan:

• The plan has to scaffold the work, not outline it. It names every file to change, the full signature of every function, every test and what it checks, the edge cases and how each is handled, and the order of the changes.
• The critic grades against one main rule: could a cheaper model carry out this plan without making a single design decision? If not, it isn't an A+.
• Sonnet writes the code. With the decisions already made, the job is careful typing, not invention.
• Opus reviews it. A model reviewing its own code shares its own blind spots. The review is where a stronger model earns its price, because its job is to catch what the cheaper one missed.

In short: pay for judgement where judgement happens, and nowhere else.

What broke, and what we changed

The first version ran in July. The template behind it has been changed more than 30 times since. Each change came from something going wrong in real use.

The numbers at the top of this post led to the 26 August change.

Two loops, one checkout. Two loops running in the same repository shared one working copy. One switched branches while the other was mid-commit, and commits landed on the wrong branch. Now each loop writes code in its own isolated git worktree.

Fixes nobody checked. At first, review was a single pass. The reviewer found problems, the writer fixed them, and the fixes went in unreviewed. Now the reviewer re-reads the whole change after every fix. The loop only ends on a clean review of the latest version.

Reviews that never ended. That rule created the problem in our opening numbers. Across ten pull requests: 43 review rounds, none clean on the first pass, four at or past the round limit. Each round took 3 to 14 minutes. A 26-line change that only touched comments took five rounds.

The cause was small stuff. A round that found only tidy-ups, like a rewording or a stale comment, still triggered another full review. And the reviewer kept finding fault with the wording of the previous round's fixes. So we split findings into defects and tidy-ups. A round with only tidy-ups now applies them and closes. The limit dropped to three rounds, and it is binding.

Summaries that didn't match the record. In both runs we checked, the loop's closing summary disagreed with its own review comments on the pull request. People read the summary, so now the loop takes every count from those comments, not from memory.

A person still decides what ships

The loop can plan, write, review and open a pull request on its own. It cannot ship. These rules make sure of that:

• No merging. Every session Miko starts is blocked from merging a pull request. Claude Code enforces the block even in its most permissive mode. The loop stops at an open pull request, and a person tells Miko “ship it”.
• A clean review of the exact version. Each review comment ends with a stamp naming the exact commit it reviewed. The ship step only accepts a clean stamp for the latest commit. An older version of this check accepted any comment that quoted the commit, so a build note could pass it.
• Proof the review happened. A review comment includes the reviewer's own token count and running time. A writer reviewing its own work can't produce those, so a skipped review shows.
• Shortcuts become backlog. When the critic raises an objection and we accept it as debt, it goes into the pull request under “Deferrals”. When the change ships, each deferral becomes a new issue.
• A weekly second look. Once a week, a scheduled cloud agent re-reviews everything merged that week and gathers the small fixes into one pull request. A person merges that too.

Still a work in progress

The loop isn't finished, and the team is still improving it. We change it when the numbers tell us to, and every change goes through the loop itself before it ships.

For the people we build for, the result is simple. Every change arrives with a plan that was graded before any code was written, a record of every review round, and a person who signed off on it.

Want to see what Miko can do? Read the Miko Assistant case study, or tell us what you want to build.