The Software GardenZero-eyes PR approval ← Contents
The Software Garden

Zero-eyes PR approval

Pull requests that merge without a human reading the code.
That doesn't mean the humans have left. It means they're looking somewhere else.

Scroll ↓
The convergence review loop

One agent reviews. Another addresses the feedback. Repeat until clean.

We put agents in a loop around the pull request. A reviewer agent reviews it. An author agent addresses the findings. The reviewer reviews again.

The loop converges: each round has fewer findings, until a review comes back clean. Then the PR merges.

Reviewer agentfinds problems
→
←
Author agentaddresses them
PR #482 · Add order exportin review
findings per round:
What “zero eyes” means

Humans aren't out of the loop. They're looking at the loop.

Not this

Humans are out of the loop

Turn on auto-merge, stop looking, and hope.

This

Humans engineer the loop

  • Looking at the loop
  • Looking at what escapes the loop
  • Working out how to make the loop stronger
To begin with

At first, human eyes go on the code.

Not to approve each PR, but to assess the quality of the automated loop. You're judging the reviewer, not the change.

  • Is this review letting in code that erodes the safety of the codebase?
  • Are duplicate implementations appearing?
  • Does a PR that passed review fail in integration or production?
time → human eyes on the code → escape! escape! escape

Attention steps down as trust in the loop is earned. Each escape sends eyes back to the code, and then into tuning the loop.

Why duplication matters

Duplicate implementations cause whack-a-mole.

Three PRs each passed review, and each added its own way to calculate an order total. Nobody noticed, because each one was fine on its own.

Then a rounding bug shows up in a user report. You fix it. Another report arrives about the same bug, somewhere else. Then another. One defect, many bug reports.

A review loop that lets duplication in is quietly multiplying future bugs.

🐞checkoutcalcTotal()
🐞invoicesorderSum()
🐞exporttotalFor()
 
When something escapes

Tune the reviewer's whole environment, not just the reviewer.

The obvious targets are a stronger model and a better prompt. They help, but they're not enough on their own.

We also need to address the context the reviewer works in, and the structural guardrails around it. The strongest fix makes the defect impossible, so no reviewer has to catch it.

We're engineering the environment to tune the entire system.

The obvious
Reviewer
A stronger modelMore capable review, at more cost.
Reviewer
A better promptTell it what to look for.
The context
Context
What the reviewer can seeArchitecture, conventions, the existing implementations a change should reuse.
The structure
Inner loop
Types and code structureCan we make this class of defect impossible in the type system?
Inner loop
One source of truthCan we generate contracts from a single source, so there's nothing to duplicate?
CI
Architectural rulesCan a CI rule reject it, such as a module boundary or a banned pattern?
The real question

Not “does it work?”, but where it works and where it fails.

Zero-eyes approval isn't a switch you flip for the whole codebase. It works well for some kinds of change, in some parts of the code, and fails for others.

Map it. Then engineer the system to fix the failures, one class at a time, and watch the map turn green.

loop is reliablesome escapesescapes often
 

Illustrative map.

So

Zero eyes on the PR. Eyes on the system.

Zero-eyes PR approval doesn't mean humans are out of the loop. It means humans are looking at the loop, at what escapes the loop, and at how to make the loop stronger.

Next: Every model has an envelope → ← There are no flaky tests Contents