Skip to content
online
env0.46.1 · 1d135e2

How we ship products with an AI review on every pull request

Mainlane is one engineer and a team of AI agents. That raises a fair question: who checks the code an AI wrote? Our answer is another AI — one that didn’t write it — followed by a human who decides whether it ships.

Illustration: a code diff with added and removed lines, three review comments marked red, yellow and green, and a person approving with a check mark.

Mainlane is one engineer and a team of AI agents. That raises a fair question: who checks the code an AI wrote? Our answer is another AI — one that didn’t write it — followed by a human who decides whether it ships.

The loop

  1. A Claude session takes a task and opens a pull request.
  2. A separate reviewer starts in a clean session. It has never seen how the code was written, so it reads the diff the way a colleague would — without the author’s assumptions.
  3. The reviewer leaves findings in three levels: 🔴 must fix, 🟡 should fix, 🟢 nice to have.
  4. The author session fixes them and replies point by point, ending with a “Verification” section: the commands it ran and what they printed.
  5. The reviewer checks the new head. The loop repeats until there are no findings at all — not even 🟢.

Two rules keep it honest. A finding can only be disputed with a measurement — a number, a command output, a mutant that a test fails to catch — not with “it’s fine”. And after five rounds the loop stops and asks a human, so it never spins forever.

The human part

No agent merges. When the review is clean and CI is green on exactly the commit the reviewer saw, the session writes “ready to merge” and waits. The merge happens only after a person says so, and only for that same commit.

What it catches

A few real examples from this website’s repository:

  • In the pull request that added Lighthouse checks to CI, the reviewer noticed that a CSS build setting pointed at the wrong folder, so layout styles quietly disappeared from the site. Neither Lighthouse nor the accessibility checker flagged it. It also caught a fixed language banner that could cover the focused element for keyboard users.
  • In the database-backup restore check, the daily test compared the restored data with itself instead of with the export — it would never have noticed missing rows. The same review found an error message that could print a lead’s email into the logs.
  • In the Content Security Policy rollout, reports from browser extensions would have kept the “one week without violations” goal from ever being met, and external images in blog posts would have broken once the policy was enforced.

None of these were exotic. They were the kind of thing a tired person misses on a Friday evening.

In numbers

As of late October 2026 the loop runs across eight repositories, with 385 merged pull requests and 1,069 reviews. Most of the cost is the work itself: in the last week of October about three quarters of the tokens go to implementation and under a tenth to review.

Limits

The reviewer is the same kind of model as the author, so it can share blind spots. It doesn’t replace a human review of important changes, and text inside a pull request is treated as data, never as instructions. What it does replace is the step most solo developers skip: a second pair of eyes on every single change.

If you want the same process in your team, that’s one of our services — get in touch.