Same Reviewer, Different Results — AI Code Quality Is Decided Before the Review

Short version: the quality of AI-written code is decided before the review, not by how smart the reviewer is. Two things matter. Did a human approve the design before a single line was written? And has the first PR a human sees already been filtered once? By the end you should be able to pick an approach for a task just by looking at its size.

How I used to work

For a long time it looked like this.

"build it" in Claude Code -> code -> PR -> review command -> Before/After screenshots

For a copy change or a single config value, nothing beats it. I had no complaints.

Then an AI implementation harness landed at work (a SaaS built on Rails). A harness here means a team-defined sequence for the AI: what it does in which order, and where it has to stop.

/plan -> plan.md (design summary), a human reads it and sets approved: true
  -> /implement (code in a git worktree -> spec -> rspec, rubocop
                 -> self-review -> Draft PR -> pre-review -> self-fix, 2 rounds max)
  -> a human marks it Ready -> final review

My first reaction, honestly: "The final review uses the same reviewer as my old review command. What's supposed to change?"

Side by side, the difference wasn't in the review. It was everything in front of it.

Where the two paths split

Step	"Build it"	Harness
Design	Settles implicitly during the chat	Fixed in plan.md. Zero lines of code until a human approves
Reading the ticket	Easy to implement whatever fix the ticket suggests	A separate step says "don't trust the ticket's fix, go back to the real requirement"
Where it stops	Whatever the session decides that day	Four fixed stops: plan approval, premise check, right after a migration, report
Specs	Written after the code, to match it	One row in the test case table = one example
First PR a human sees	Raw	A Draft that already went through a pre-review
"Why did we do it this way?"	Gone when the session closes	Kept in plan.md

What grew was stops, not automation

Look at the table again. Most of what the harness adds is places to stop. It pulls the human decision points forward, ahead of the code, and pins them there.

If you catch a wrong direction in finished code, you throw the code away. Catch it at plan.md and you throw away a one-page design note. No reviewer, however good, closes that cost gap.

The harness deliberately doesn't mark PRs Ready or merge them. Whoever clicks Ready owns the generated code. Tying the responsibility line to one button is a small thing, and I like it a lot.

It's not a strict upgrade

Screen checks fell out. The old flow had Before/After screenshots built in. The harness just says "a human checks the screen." For UI changes you end up bolting the old tool back on.

It's heavy for small jobs. There's a mode that skips approval, but the worktree and pre-review costs stay.

You can't hand-edit plan.md. Hand edits drift from what the investigation found, so you regenerate it through the chat instead. Mildly annoying.

Branches get locked. Git won't check out the same branch in two worktrees at once. While the harness holds the branch in its worktree, running the old review-cycle command means removing the worktree first.

Which one to use

Task	Pick
One string or one config value	"Build it"
Obvious approach, several files	Either. With the harness, use the skip-approval mode
Design choices, DB changes, impact analysis needed	Harness
The UI changes	Harness, plus Before/After screenshots at the end

What I haven't measured yet

No numbers yet. The plan is to run two tickets of the same size, one each way, and compare time spent and review findings. Until then, "it catches wrong directions before the code" is a claim about the structure of the flow, not something proven with a caught case.

How a harness differs from just writing better prompts is in a separate post: Harness vs prompt engineering.

If your team is bringing in an AI implementation flow and you're unsure where it should stop, feel free to ask negabaro. We're running this exact sequence on real work right now.