Who reads the AI's code? What a code review looks like when most of the change was generated

At four on a Thursday a change lands in the review queue. It adds team invitations to the product: 1,400 lines across 23 files, with a neat summary at the top, headings, a bullet list of what was done, and a line saying all tests pass. The developer who opened it started the task after lunch.

Nobody typed most of those lines. That is normal now, and it is not the problem. The problem is the next step. Someone is supposed to read this before it reaches customers, and that someone has forty minutes, their own work to finish, and a change that looks better organised than anything a tired human would have written.

This article is about that step in a small team: what the numbers say has happened to review, what gets missed in a generated change and why, the rules that teams of three to ten are settling on, and what to ask for if you are paying someone else to build your product and cannot read the code yourself.

More code, the same number of readers

Faros AI, which measures engineering teams from their own tooling, looked at more than 10,000 developers in 1,255 teams in mid-2025. On teams that used AI heavily, developers completed 21% more tasks and merged 98% more pull requests. The average pull request was 154% larger, and the time spent reviewing one went up 91% (Faros AI). Bugs per developer rose 9%.

Put those together. Roughly twice as many changes, each about two and a half times the size, is five times as much code arriving for review, and the people reviewing it have not multiplied. Writing got faster. Reading did not.

Developers know it. In Google's 2025 DORA survey of nearly 5,000 technology professionals, 90% used AI at work and more than 80% said it made them more productive, yet only 24% said they trusted it "a lot" or "a great deal", and 30% trusted it a little or not at all (Google). Stack Overflow's 2025 survey of more than 49,000 developers found the top frustration, named by 45%, was "AI solutions that are almost right, but not quite", and 66% said they were spending more time fixing such code (Stack Overflow).

Almost right is exactly the kind of wrong that review exists to catch. So it is worth asking what review can actually catch.

Review was already near its limit

The best-known guidance on review size predates all of this. SmartBear's study of a programming team at Cisco concluded that a reviewer should look at "no more than 200 to 400 lines of code" at a time, that attention "starts dropping off after about 60 minutes", and that reading faster than 500 lines an hour produces a sharp fall in the number of defects found (SmartBear). Google's engineering guide says the same thing from the author's side: "100 lines is usually a reasonable size" for a change, "1000 lines is usually too large", and reviewers may "reject your change outright for the sole reason of it being too large" (Google).

By those figures the Thursday change needs about three hours of careful reading, in three sittings. It will get forty minutes. Nobody decides to review badly. The arithmetic decides for them.

What gets missed in a generated change

CodeRabbit, which sells a review tool, compared 470 open-source pull requests in December 2025: 320 with signs of AI co-authorship and 150 without. It counted 10.83 issues per AI-assisted request against 6.45 for the others. Logic and correctness problems were 75% more common, gaps in error handling nearly twice as common, and some security problems up to 2.74 times as common, with "improper password handling and insecure object references" the most prominent (CodeRabbit). The authors say plainly that they could not be sure which requests were written only by people, and they have a product to sell, so read it as a direction, not a measurement. Veracode's test of more than 100 models on 80 coding tasks points the same way: the output introduced a security flaw in 45% of cases, and the company's chief technology officer added that "it's not improving" (Veracode).

The interesting question is why a human reviewer lets these through. Five reasons come up again and again.

It looks finished. People judge code partly by its surface: consistent names, comments, tidy layout. In a colleague's work those are signs of care. A model produces them every time, whether or not the logic underneath is right, so the signal reviewers have relied on for years now tells them nothing.

The summary was written by the author of the code. A description that says "validates that the user belongs to the team" will be believed unless someone finds the line that does it. Sometimes there is no such line. The summary describes what the code was meant to do.

What is missing is harder to see than what is wrong. A reviewer can spot a bad line. Noticing that a check is absent means holding the whole feature in your head and asking what should be there. "Insecure object reference" is the textbook case: the code fetches invitation 812 correctly and never asks whether it is your invitation.

The tests came from the same place. A model asked to write a feature and its tests will often write tests that confirm what the code does, including its mistakes. All green, and it proves little. Worse is the quiet edit: an existing test that was failing has been changed so that it passes.

There are passengers. A reformatted file here, a renamed helper there, a new dependency nobody asked for. Each is harmless to look at and together they bury the forty lines that matter.

Six rules small teams are settling on

None of these needs a new tool. They are habits, and a team of four can adopt them in a week.

1. The person who opens the change owns every line

They have read it all before asking anyone else to, and they can explain any part of it without looking it up. "The tool wrote that bit" is not an answer a reviewer has to accept. This one rule removes most of the trouble, because it moves the first careful reading back to the person with the most context.

2. A size limit, enforced by sending it back

Pick a number, say 400 changed lines outside tests and generated files, and return anything larger to be split. A generated change splits easily: ask for the data model first, then the server logic, then the screens. Reformatting and renames go in their own change, which can be approved in a minute because it is nothing else.

3. Four areas always get a second person

Whatever the size, whoever the author, however urgent, a second human reads any change that touches these, slowly:

Many teams add two more: new dependencies (does the package exist, is it maintained, who publishes it) and anything that touches keys, deploy scripts or infrastructure. Keep the list short enough to remember. Its purpose is to spend scarce attention where a mistake costs a customer, not where it costs a re-run.

4. The tests are the contract, so a person decides them

Before the code is generated, someone writes down the cases that must hold, in words if not in code: a member of another team cannot accept this invitation; an expired link shows this message; inviting the same address twice sends one email. The model can then write both the tests and the feature. The reviewer reads the tests first and checks them against the list, because twelve cases are quicker to read than 1,400 lines and say more about whether the thing is right.

Then two checks that take a minute each. Has any existing test been changed or deleted? That needs a reason in writing. And does a new test fail when the feature is switched off? One that passes either way is testing nothing.

5. Read in a fixed order, and run it

Summary, then tests, then the files in the four areas, then everything else. Then run the change and try the unhappy path by hand: sign in as one customer and ask for another customer's record by its number. That single experiment finds the most expensive class of fault in generated code, and no amount of reading replaces it.

6. A machine reviewer is a first pass, not a signature

Automated review is worth having. It is tireless about unused variables, missing error handling and known bad patterns, and it clears the small stuff so a person can think about the design. But it shares blind spots with the tool that wrote the code, and it cannot know that invitations in your product are meant to expire after seven days. Use it before the human, never in place of one, and record in each change which person approved it.

What it costs

A 400-line change read at the pace the Cisco study recommends takes about an hour. A team merging eight of those a week spends a working day on review. That feels expensive beside a feature that took an afternoon to generate, and it is the right comparison to make out loud, because the alternative is not zero. It is the same hour spent later, by someone who has lost the context, with a customer waiting.

It also changes who is good at the job. Reading a confident, plausible change and finding the one thing wrong with it is a skill, and it is becoming the main one. We wrote about what that does to hiring in the missing junior developer. If you want to see how you or a candidate do at it, we built an exercise: a short change with a persuasive description and two planted faults.

If you have no developer: eight things to ask a contractor to show

You are paying an agency or a freelancer, they use AI tools (they should; you are getting the speed), and you cannot judge the code. You can still judge the process. Ask to be shown, on a shared screen, not told:

1. The history. A list of changes with dates, sizes and descriptions. One enormous change a week is a warning. Many small ones is a habit.

2. Who approved each one. A name that is not the author's, at least on anything touching sign-in, permissions, payments or the database structure. A one-person contractor should say honestly that there is no second reader, and tell you what they do instead.

3. The tests running. Not a statement that they pass. The page where they ran automatically on the latest change, with the count.

4. Which tests changed this month, and why. A good answer is quick and specific.

5. The two-customer test, live. Two accounts. Signed in as the first, try to open something belonging to the second by changing the number in the address. It should refuse.

6. The last database change. Where the backup from before it is, and how they would undo it.

7. What was added from outside. The list of packages brought in since the last time you asked, and one sentence on each.

8. One file, explained. Pick any file at random and ask what it does and why it is built that way. You will not follow every detail. You will be able to tell whether they have read it.

Put the ones you care about in the brief before work starts, so they are part of the job and not a surprise at the end. We described a brief that does this in how to brief a contract developer in the AI era. And if the product is already built and live, the checks in six things before customers log in are the ones to run this week.

The question in the title has a simple answer in a team that is doing this well. The person who asked for the code reads all of it. A second person reads the parts where a mistake reaches a customer's account, money or data. And the tests, which a person chose, read the rest every time anything changes.

Sources

Faros AI, The AI Productivity Paradox (23 July 2025); Google, How are developers using AI? Inside our 2025 DORA report; Stack Overflow, 2025 Developer Survey results (29 July 2025); SmartBear, Best practices for peer code review; Google engineering practices, Small CLs; CodeRabbit, AI code creates 1.7x more problems (17 December 2025); Veracode, 2025 GenAI Code Security Report press release (30 July 2025). All pages read on 13 October 2026. Faros and CodeRabbit sell tools in this area and Veracode sells security testing; their figures are quoted with that in mind. "Five times as much code", the three hours for the Thursday change and the working day of review a week are our own arithmetic from the figures quoted. The six rules and the eight questions are our own.