From AI-generated code to production software / Choosing who helps you
Who reviews AI-generated code, if there is no human sign-off?
An automated check can only catch a mistake somebody already wrote a rule for. It cannot notice that the rule itself is missing. That is the real question behind "who reviews AI-generated code": not whether a check ran, but who is responsible when the failure is a rule nobody thought of yet.
Published July 28, 2026. Editorial.
Key takeaways
- An automated check enforces a rule that already exists. It cannot notice that a rule is missing, which is the failure that actually reaches customers.
- Accountability for AI-generated code belongs to the team that released it, for the whole project and after release, not to a single reviewer signing off on one pull request.
- A large eval suite catches everything with a right answer. What it cannot catch is a requirement that was wrong in the first place.
- Ask a development partner what happens inside their team when a missing check reaches a customer, not just whether a check exists.
People ask this question a specific way, and the phrasing matters: if AI writes the code, who reviews it? Most of the time the honest answer they are hoping to hear is the name of a person. That is understandable, and it is also the wrong place to look for the real answer.
What an automated check can and cannot do
An eval suite, run against every change before it merges, is the right tool for almost all of what used to require a human reading every line. It does not get tired on line four hundred. It is exact, catching an off-by-one a tired reader's eye would smooth over. It runs the same way in three years as it does today.
What it cannot do is notice that it is missing a rule. A check enforces a decision someone already made: this input must be validated this way, this permission boundary must hold, this response must contain these fields. If nobody wrote that rule down, because nobody thought of the case it covers, the check passes and the gap ships. That limit is not a bug in any particular suite. It is what a check is, by definition: enforcement of an existing decision, not discovery of a missing one.
So the question "who reviews AI-generated code" is really two different questions wearing one sentence. The first is mechanical: did this change pass everything we already know to test for? The second is not: is there something here nobody thought to test for yet? Only the second one needs a person, and it is the one that actually decides whether a codebase stays trustworthy as it grows.
Why "a named reviewer" is not, by itself, the answer
It is tempting to answer the accountability question with a title: a senior engineer signs off on every pull request. That sounds reassuring, and it does not survive the volume problem. Review capacity is fixed by hours and attention. The amount of code a team can generate is not. A reviewer facing a diff ten times larger than what they used to see does not give it ten times the scrutiny; attention per line falls as the diff grows, and it falls fast. A rule that requires one person to read everything either becomes a bottleneck that slows a team back down to pre-AI speed, defeating the entire point, or it becomes a formality that nobody actually has time to do properly.
The fix is not removing the person. It is being precise about what the person is for. Anything with a right answer, behaviour, contracts, permission boundaries, error paths, performance thresholds, belongs in the automated suite, checked on every change with no human in the loop. Everything without a right answer, whether the requirement itself made sense, whether this is the right design, whether the eval that just passed is actually strong enough to mean something, stays with a person. That split is what lets review stay fast at high volume instead of becoming the new bottleneck once generation gets cheap. We cover the mechanics of building that split in evals vs tests vs code review.
Where the responsibility actually sits
Here is the part that answers the original question properly. When something reaches a customer that should not have, the useful question is not "who was the reviewer on that one pull request." It is "whose job was it to notice that the check protecting this was missing, and what changes now that it is known to be missing." That responsibility has to sit with the team that released the software, for the life of the project, not with whoever happened to click approve on one diff and then moved to the next task.
On our own work, that is why accountability is structural rather than a signature. We own a project through production and after release, which means the team that shipped a gap is the team that closes it, adds the check that would have caught it, and answers for the pattern if it shows up again. A rotating reviewer credit on individual pull requests does not produce that; a team that stays responsible for outcomes does. Eval-driven development is the mechanism that makes this practical instead of aspirational: the suite carries the weight of everything with a right answer, so the team's attention goes to the smaller set of judgment calls a check cannot make.
What to ask a partner instead of "do you review the code"
Everyone will say yes to that question, because it costs nothing to say. Better questions get you a real answer:
What automated checks run on every change before it merges, and are they written from the specification or copied from the implementation? A suite written after the code tends to just describe what the code already does, which proves nothing.
What happens inside your team when a gap reaches a customer? A team that adds the missing check and moves on is different from one that treats it as a one-off and hopes the next diff catches it.
Who is accountable for this project a year from now, not just for this week's pull requests? A single reviewer's name on a merge answers a narrower question than you are actually asking.
Where this fits
This page is about the accountability question specifically. For the practical, line-by-line version of what a person should look for when reading a generated diff, see how to review AI-generated code. For what changes once more than one engineer is generating code without a shared standard, see AI coding governance. And how to evaluate an AI development partner covers the wider set of questions worth asking before you hire one.
Every change we ship goes through the eval suite first and is our responsibility for the life of the project after that, not just for the pull request it arrived in. If you want to see how that works against a specific codebase, talk to us.
Common questions
If AI writes the code, who reviews it before it ships?
An eval suite checks everything with a known right answer on every change: behaviour, contracts, permission boundaries, error paths. What that suite cannot do is notice a rule that nobody wrote yet, which is why a team stays accountable for the whole project rather than a single reviewer signing off on individual pull requests.
Can an automated check replace a human reviewer entirely?
No. A check enforces a decision someone already made. It cannot tell you a requirement was wrong, that a feature should not exist, or that an entire case was never considered. Those are judgment calls, and only a person handles the ones a check was never designed to catch.
Is a named engineer signing off on every pull request the right way to get accountability?
It does not scale on its own. Review attention per line falls fast as diff size grows, and AI-generated changes can be far larger than a human-written one. The workable version splits the work: anything with a right answer goes into an automated suite checked on every change, and a person handles the smaller set of judgment calls left over.
Who is responsible when AI-generated code causes a production failure?
The team that released it, for the life of the project, not one person who approved a single change. Responsibility that lives with the team means the gap gets a permanent fix, a new check added to the suite, rather than a one-off patch that leaves the same failure possible again next time.
What should I ask a development partner about how they review AI-generated code?
Ask what automated checks run on every change and whether they were written from the specification rather than copied from the implementation. Ask what happens inside the team when a missing check reaches a customer. Ask who is accountable for the project a year from now, not just for this week's merges.
Does a large eval suite mean human review is not needed anymore?
No, it means human attention goes where it is actually useful. A strong suite covers everything with a right answer, freeing a person to focus on whether the requirement made sense, whether the design will hold up, and whether the suite itself is strong enough to mean something, which are all judgment calls a check cannot make.
Why can't a check just be written to catch every possible mistake?
Because a check can only encode a rule someone already thought of. The failures that reach customers are usually the ones nobody wrote a rule for in the first place, not the ones the existing rules were supposed to catch. That gap is exactly why accountability has to sit with a team that keeps closing it, not with a fixed checklist.
Related reading
Who signs off on AI-written code?
A test can only enforce a rule somebody already thought of. When AI writes most of the code, the question that decides whether a codebase stays trustworthy is who is accountable for the rule that was missing.
Never let the model grade its own work
When the same run writes the code and the tests, a passing build proves only that the code is consistent with itself. That is not verification, and it is the most common way an AI-built codebase becomes confidently wrong.
More in Choosing who helps you
AI coding governance: what enterprise teams need in place
One engineer moving fast with AI tools is a personal workflow choice. A whole team doing it without a shared standard is a governance gap, because the inconsistency adds up across every person changing the code. Here is what a reasonable minimum set of controls looks like.
How to evaluate an AI development partner
Hiring an AI development partner is harder than a normal build decision, because you are not buying a finished capability, you are buying judgment applied to something that does not fully exist yet. Here is what actually separates a good partner from a confident pitch.