Who Reviews AI-Written Code, and Can You Trust It?

Search “who reviews AI-written code” and the results are a list of tools. Search “can you trust AI-generated code” and you get a survey stat, usually the same one, and a recommendation to always have a human review it. Both are true as far as they go. Neither answers the question a working engineering lead actually has: when the agent’s code is wrong, who was supposed to catch it, and what does “review” even mean for output that reads as confidently when it’s wrong as when it’s right.

This is that answer. Not another tool list, and not “trust but verify” repeated with more words.

Who Reviews AI-Written Code Today?

In most shops, three things run over AI-generated code before it ships, and only one of them is actually reviewing it.

Tests and CI catch what tests and CI have always caught: things that don’t compile, behavior a test happens to cover, regressions in paths someone thought to check. Static analysis and linters catch style and a narrow band of known bug patterns. Neither one evaluates whether the approach was right, because neither one has an opinion about approach. They check the diff against rules, not against judgment.

The part that’s supposed to catch judgment is human review, and it’s the part most teams have quietly weakened without deciding to. A reviewer who has watched an agent turn out clean, working code fifty times in a row starts reading the fifty-first the same way. That’s not a discipline failure. It’s what happens to anyone reviewing a stream that’s usually right: the failure mode of AI code review isn’t a careless reviewer, it’s a good reviewer whose calibration drifted because the input got better.

A second AI reviewer helps here, if it’s built for it. The distinction that matters is whether that second reviewer is instructed to find a reason to reject the diff or just to summarize and comment on it, which is most of what ships today under the “AI code review” label. Adversarial AI code review is the mechanism for the first kind: a reviewer whose job is to argue against merging, calibrated so it doesn’t just cry wolf on every diff. On a YAGNI Team that reviewer is Proctor, a separate Agent from Wright, the one that wrote the code.

None of this answers “who reviews AI-written code” the way the question is actually meant, though. The honest inventory is tests, a linter, possibly a second model, and a human whose attention is a depleting resource. What’s missing from that list, in almost every shop that hasn’t sat down and decided it on purpose, is a named owner for the call.

Can You Trust AI-Generated Code?

Not by default, and not never. Both extremes are wrong in the same way: they treat trust as a property of the code instead of a property of the specific change.

A widely cited developer survey found that 96% of engineers don’t fully trust AI-generated code without review, and only 48% say they always verify it line by line before it merges, a gap that describes most teams: distrust in principle, inconsistent in practice. Security researchers who ran Copilot-generated code through adversarial benchmarks found roughly 40% of suggestions contained exploitable vulnerabilities in scenarios designed to surface them. Neither number says AI code is categorically worse than human code. Human code has its own well-documented defect rate. What they say is that AI code fails differently and often more confidently, which is a harder thing for a tired reviewer to catch than an obviously ugly line.

The honest answer isn’t a trust level for “AI code” as a category. It’s a trust level for this change, given what it touches and what happens if it’s wrong, which is the question the next two sections actually answer.

Who Is Accountable When AI-Written Code Breaks Something?

This is the part almost nothing in the search results actually commits to. Most pages gesture at “the developer is still responsible” and move on. That sentence is true and also does none of the work, because it doesn’t say what accountability is supposed to look like before something breaks, only that someone should feel bad after.

Accountability that means anything has to exist before the incident, not just in the postmortem. Concretely: every change has a named person who approved it shipping, that approval is on the record, and the record survives the person moving to a different team or the agent’s next hundred merges going fine. “The AI wrote it” is not an incident writeup, the same way “the intern wrote it” was never an acceptable answer for why nobody who could have caught it did.

This is also why “the agent has a good track record” can’t be the whole story on its own. A track record justifies less friction on review, not zero accountability. The two are different questions: how much scrutiny does this change need, and who’s on the hook if the scrutiny missed something. Managing AI coding agents covers the first question, the correction loop that justifies lighter review over time, when a person decides it does. The second question doesn’t get lighter no matter how long the streak runs, because it was never about the code’s quality. It’s about who was supposed to be looking.

Does Reviewing AI-Written Code Require a Different Process Than Reviewing Human Code?

The checklist barely changes. The mechanics of applying it do.

AI-written code tends to look more finished than it is. A human draft often has an obvious rough edge, a stub, a comment saying “fix this later”, that flags where to look closely. An agent’s first pass usually reads as done, formatted, named well, no placeholder comments, which removes the visual cue reviewers have relied on for years to know where the risk is hiding.

It also fails in a different place. Human bugs cluster around typos, off-by-one errors, forgetting a case. Agent bugs cluster around a plausible-sounding approach built on an assumption nobody stated out loud, the kind of mistake that survives a read-through because every individual line is defensible and the flaw is in what the lines were trying to do together. Catching that requires reading for the assumption behind the diff, not just the diff, which takes longer per line even when the code itself is cleaner. That’s the real reason AI code review takes more effort than it looks like it should: not more bugs, a different shape of bug that hides better in clean formatting.

The fix isn’t a longer checklist. It’s weighting review effort by blast radius instead of by lines changed, which is also exactly where the graduated trust question below actually lands.

Practically, that means reviewers need a different prompt to themselves than “does this look right.” A better one is “what would have to be true about the system for this to be the right approach, and did anyone check that it is.” That question catches the plausible-but-wrong pattern precisely because it forces the reviewer off the diff and onto the assumption underneath it, which is where an agent’s mistakes actually live.

How Much Should You Trust an AI Agent’s Code, Tier by Tier?

Trust here is a live example of the Ladder: two rungs, Supervised and Autonomous, set per line of work by a person who has read the track record, never toggled on all at once and never moved by the record on its own. What changes rung to rung isn’t whether review happens. It’s how much friction sits in front of the agent’s act, and that answer depends as much on what the change touches as on how long the agent’s streak has run.

Blast radius	Supervised (a named person clicks)	Autonomous (a person chose it, with the record beside them)
Docs, internal tooling, test-only changes	The act waits as a gate for the supervisor; fast because the stakes are low	The act goes ahead with a Receipt; a person still merges
Feature work behind a flag, reversible via rollback	Full read before merge, every diff, no shortcuts	The agent’s review posts on its own with a Receipt; a person still reads it and merges
Auth, billing, production infrastructure, anything customer-facing and hard to reverse	Full review, no exceptions	Not available: deploys, data migrations, and anything irreversible stay supervised on every line

The bottom row is the part most “graduated autonomy” writing skips, because it’s the least satisfying answer to give a buyer who wants a demo of full autonomy: on the changes with real consequences if they’re wrong, the floor doesn’t move no matter how good the track record gets. That’s not a limitation of the framework. It’s the framework working as intended. A person can take friction off the reversible work precisely because the irreversible work never loses any.

Where to Start

If your team is already shipping AI-written code without a real answer to “who reviews this and who’s accountable if it’s wrong,” the fix isn’t a stricter policy nobody follows. It’s making the three rows above explicit for the repos you actually have, naming who owns sign-off on the bottom row today, and deciding, with the record in front of you, when the top row gets lighter review. If the answer to “who reviews this” is going to include software, AI code review tools lists the criteria that keep a person in the answer.

That’s also the shape of YAGNI’s managed agent teams: Proctor reviews every pull request on its own while the approval that counts stays a person’s, the building lines start supervised by a named person, a person makes a line autonomous only with one explicit act and the record beside it, merging is always a person’s click, and production, auth, and billing stay human-held on every line, so the graduated trust in the table above isn’t a policy someone has to remember to enforce. It’s how the review gate is built.