Who Accepts AI-Generated Code That Nobody Wrote

Code review works on an assumption nobody states. Somewhere there is an author, and the author can answer for the code: why this approach, what happens in that case, what they considered and rejected. The reviewer's job is to interrogate that reasoning, and the author's ability to defend it is most of what makes approval mean something.

Generated code removes the author. The person submitting it can tell you what they asked for. They often cannot tell you why line 47 handles the case that way, because nobody decided it.

That does not make the code worse. It makes approval rest on something that has to be named, because the old basis is gone and nothing replaced it by default.

1. Three bases for AI-generated code acceptance

There are only three answers to who accepts, and each has a cost. Choosing deliberately beats discovering which one you drifted into.

• The prompter accepts: Whoever ran the generation owns the output. Simple, matches how pull requests already work, and it is what most teams do without deciding to.The problem is that it asks for accountability without the means. A person who cannot answer for line 47 is being asked to stand behind it anyway, and the predictable result is either genuine risk transfer to someone who cannot carry it, or a quiet fiction everyone maintains.
• The reviewer accepts: The approver owns it, on the basis of having read it.Honest, and expensive in the one resource you have least of. It also runs into the completeness problem: a finished-looking deliverable of 20 files gets skimmed, not read, and the approval means less than it appears to.
• The check accepts: The deliverable is accepted because it satisfies a specified set of properties, verified mechanically. A person owns the specification and owns the decision to trust it, rather than owning each line.This is the only one that scales, and it relocates accountability rather than dissolving it. Somebody wrote the contract, somebody decided it was sufficient, and both of those are answerable positions.

Most mature arrangements combine the third for the mechanical properties and the second for the judgement, which is a division of labour rather than a compromise.

2. What changes in the pull request

Four practical shifts, and the first one is the whole article in a sentence.

• The question moves from "why did you do it this way" to "what did you verify": The first is increasingly unanswerable and the second is always answerable. It is also the better question, because it produces a checkable claim rather than a narrative.
• The description carries the verification, not the reasoning: What was generated, from what input, which checks ran, what the reviewer looked at by hand. That is a record you can consult after an incident, which a rationale is not.
• Size stops indicating effort: Reviewers have always used volume as a proxy for how much care went in, and therefore for how carefully to read. A 900-line change produced in 20 minutes breaks the proxy. Read by risk instead: the boundary with your system, the defaults, the error paths.
• The presence of tests stops being evidence: It used to signal that somebody thought about failure modes, because writing them forced it. Now it signals that tests were requested. What they assert is the only thing that carries information.

3. The question that arrives after an incident

This is the part worth settling before you need it, because the conversation goes badly when it is improvised.

A pipeline built from generated code corrupts a month of data. In the review, the meeting or the postmortem, somebody asks who approved this.

Under the first basis, the answer is a person who could not have caught it. That is an unfair outcome and it produces the wrong lesson: people become reluctant to submit generated work, or they submit it with a disclaimer, and neither improves anything.

Under the third basis, the answer is different and more useful. The deliverable satisfied the contract, and the contract did not cover the failure. That points at a gap in the specification, which is fixable, rather than at a lapse in attention, which is not.

The second answer is also the honest one in most real cases. Reviewers rarely catch the defect that causes the incident. They catch the ones that are visible, and the incident is almost always caused by something that was not.

Two things follow from choosing the third basis deliberately.

• The contract has to be owned by a named person: An unowned specification decays, and after an incident an unowned specification means nobody is accountable, which is worse than the situation you started from.
• A gap found by an incident becomes a clause: That is the loop that makes the arrangement improve. Without it, the contract is a snapshot of what you knew before your first serious failure.

4. What to write down now

Four things, and none of them takes longer than a meeting.

• Which basis you are using, per category of work. Generated ingestion code might be accepted on checks. A change to authentication might require a reviewer who read every line. Both are defensible, and the mistake is having no stated answer, because then the answer is whichever one is convenient after the fact.
• Who owns the contract: One name, with time allocated to maintain it.
• What the pull request has to state: What was generated, from what, which checks ran, what was reviewed by hand. Four lines in a template.
• What the reviewer is still responsible for: Explicitly, so it is small and real rather than implicit and unbounded. Usually: the boundary with your system, the defaults, whether the thing solves the right problem.

That last item is worth protecting. A reviewer with a short, explicit, genuinely important list does that job well. A reviewer nominally responsible for everything does none of it, and everybody knows it.

What to take away

Review used to rest on an author who could answer for the code. Generated code removes the author, and the basis for approval has to be replaced rather than assumed.

Three bases exist. The prompter, which asks for accountability without the means. The reviewer, which is honest and does not scale. The check, which scales and moves accountability to whoever wrote and accepted the specification.

Pick one per category of work, name the owner of the contract, and shorten what the reviewer is responsible for until it is a list they can actually honour. Then change the question in review from why you did it this way to what you verified.

The second question is answerable, checkable, and it was always the better one.

PrettyWhale.ai produces artifacts an acceptance test needs: a full test suite, a machine-readable output schema, documentation of the failure behaviour. The point is not that review disappears. It is that approval can rest on verified properties rather than on a rationale nobody can supply.