My AI agents get a fairer code review than many engineers I’ve known.
That’s not a punchline. It’s a design decision, and the reasoning behind it says something uncomfortable about how human review works — and how it breaks.
The pattern
Here’s a scene I’ve watched play out more than once, close enough to study the mechanics.
An engineer submits a pull request. It gets blocked: add detailed comments. They add comments. Blocked again: attach before-and-after screenshots. Attached. Now: where are the tests? Tests added — including, say, two seeded failure cases among three thousand, because the code renders a warning when the error rate is above zero but rounds to zero percent, and that branch never executes otherwise. Verdict: “you’re spamming the test suite.” Also, separately: “why is this on mock data?”
And then the finishing touch, delivered at the end of the pipeline: now delete the comments — you comment everything too verbosely.
Notice the shape. The requirements grew after each one was met. The objections contradict each other — too few tests and too many, not realistic enough and too much realism. And the final requirement revokes the first one: the circle closes exactly where it began. A gate like this cannot be passed. It can only be survived — or not. Follow that thread to its end and you reach the truth of the situation: the objection was never the objection. The person was.
Call this an unbounded gate: a review process whose acceptance criteria are discovered retroactively, one rejection at a time. It wears the uniform of engineering rigor. It is not a quality mechanism. It is a rejection mechanism — and the engineer on the receiving end, who keeps meeting every requirement and keeps being wrong, eventually gets a label. Usually the label is toxic. Or difficult. Or doesn’t fit the culture.
Three tells
A bounded gate and an unbounded one look identical on any single day. The difference shows over time, and it’s diagnosable:
1. Criteria appear after the work, not before. A real gate is finite and stated upfront: here is what “done” means, here is what review checks. If the definition of acceptable grows in response to compliance, you’re not being reviewed — you’re being exhausted.
2. Objections contradict each other. “More tests” and “stop spamming tests.” “Too abstract” and “too much copy-paste.” Contradictory requirements can’t both be about the code. When objections are inconsistent, they’re consistent about something else.
3. Review findings answer to no one. In most teams, a reviewer’s comment is a demand by default. There is no step where the finding itself is judged — valid or noise? proportionate or vindictive? So review power is unbounded and unaccountable, and anything unbounded and unaccountable eventually gets used for things other than quality.
Why nobody fixes it
Because of who would have to pay.
For a manager, “our review process is being used as a harassment mechanism” is not information — it’s an invoice. Admitting it means owning every bad merge and every departure it caused. Labeling the engineer is cheaper: one difficult person, handled, case closed. This isn’t malice; it’s cost arithmetic. The messenger gets shot because the message is expensive.
There’s a second asymmetry worth naming. The same critique lands completely differently depending on the seat it’s delivered from. “Our decision gates are broken” from a newly-joined engineer is noise from someone who hasn’t earned the right. The same sentence from a hired consultant is a deliverable the manager will proudly carry upstairs — because now it’s a transformation initiative, not an admission. Positions, not arguments, decide what counts as insight. Which means an org that only hears process critique from expensive outsiders has built a tax on its own best insiders.
The fix is architectural, not moral
You cannot fix an unbounded gate by asking people to be nicer. You fix it the way you fix any unaccountable power: with structure. Four rules:
Acceptance criteria are fixed before the work. Written down, agreed, versioned. Review checks the work against them. New concerns discovered mid-review are legitimate — as new criteria for the next iteration, stated as such, not as retroactive grounds for rejection.
Findings are themselves reviewed. Every review comment passes a verdict: valid or not, in scope or not. The reviewer’s authority is real but accountable. Judging a judgment — “is this finding valid?” — is a narrower, more answerable question than “is this code good?”, and it’s the step that turns review from a power relation into a process.
Burden of proof is assigned deliberately, not socially. Sometimes the burden should invert — in my pipeline, a change that weakens a test is treated as guilty until proven innocent. But that inversion is a written rule applied to a category of change, not a mood applied to a person.
Deterministic checks decide; opinions advise. Whatever can be verified mechanically — tests, lint, structural rules, evidence against acceptance criteria — is decided by machinery. Human and LLM judgment operates in the space that remains, where it’s actually needed.
Here’s the reveal: this is a description of the code review process in my software factory — the one my AI agents go through. A developer agent implements against pre-agreed criteria; a reviewer agent reviews; a verdict step filters the reviewer’s findings for validity; deterministic gates decide. I didn’t build it this way to be kind to the agents. Agents can’t feel harassed. I built it this way because it’s what review looks like when you design it purely for correctness — when there is no status to defend and no messenger to shoot. Strip the social games out of review, and what remains is: criteria first, findings accountable, evidence decides.
The uncomfortable corollary writes itself.
About that “toxic genius”
There’s a popular piece of management wisdom: don’t hire toxic geniuses; culture beats CV; better an honest average performer than a brilliant jerk. Fine advice — against actual jerks.
But the advice has a silent assumption: that the collective is healthy and the deviant is the defect. Sometimes. And sometimes “toxic” is the name a comfortable equilibrium gives to the first person who points at the gap between how decisions are made and how they should be. The label is cheap, sticks well, and conveniently requires no process audit.
So before diagnosing a person, run the gate test. Were the criteria written before the work? Do objections stay consistent? Do findings answer to anything? If yes — maybe you do have a difficult person, and the advice applies. If no, you don’t have a toxic engineer problem. You have an unbounded gate, and it will keep manufacturing “toxic” engineers out of your sharpest people until you bound it.
A team whose review criteria are written down before the work begins can absorb the most demanding engineer alive. A team whose criteria grow retroactively can’t safely employ anyone worth employing.
This is the fourth piece in a series on running an AI software factory: the trust ladder (how autonomy is earned), pets-not-cattle (where agent sessions live), and lights-on (why factories that delete review fail). This one is about what the factory taught me in the other direction — what machine review, designed with no feelings to spare, reveals about human review.