Why I Don’t Recommend Reviewing AI-Generated Code
The problem is not that AI-generated code needs no validation. The problem is where we spend human attention.
“AI is probabilistic, so it cannot produce deterministic results. Therefore, we must review AI-generated code.”
This is a common argument.
It sounds reasonable. I think it points our attention in the wrong direction. AI output absolutely needs validation. That does not mean the main engineering effort should be line-by-line review of code generated by AI.
Myth: AI is probabilistic, so its code is less reliable
The reality is that human output is probabilistic too.
For a small function, say 10 to 30 lines that checks whether an integer is even, both humans and AI are usually stable enough. As the granularity grows, randomness grows with it. Even the same programmer may design the same system differently at different moments. Otherwise, refactoring would not be such a common activity in software engineering.
Take a long-running operation such as creating a virtual machine. One engineer may write it as procedural code. Another may model it with the Command pattern. Another may introduce a Builder. These choices affect maintainability, yet they do not automatically determine whether the final behavior is correct.
The myth gets one thing wrong:
Code is not the result. Code is how we reach the result.
If I make the point more bluntly: human output also depends on the weather. Did the engineer sleep well last night? Did they eat properly today?
Myth: Code review is one of the core quality gates in software delivery
In many real delivery processes, code review is probably less important than people imagine.
In projects I have experienced, architects responsible for review could be unable to merge already-approved pull requests in time. Meetings, schedules, context switching, and delivery pressure all turn review into an unstable human process.
In modern software delivery, most quality assurance comes from tools and tests: type checking, static analysis, unit tests, integration tests, and CI. These mechanisms are imperfect, but at least they can run repeatedly.
Software systems are black boxes in an important sense. The well-known “duck test” captures the idea: if something looks like a duck, swims like a duck, and quacks like a duck, it is probably a duck.
The same applies to code. If the behavior matches expectations, if edge cases are covered, if failure paths are handled, the internal implementation does not need to satisfy one person’s aesthetic preference.
So what changes with AI-generated code?
There is an old joke in engineering teams:
10-line PR: 10 comments.
1,000-line PR: LGTM.
At around 100 lines, many reviewers are already mentally checked out.
AI-generated code makes this problem more visible. It increases the speed of code production, and it reduces the marginal value of manual line-by-line review. If we keep placing the main quality responsibility on “a human has carefully read every line,” the bottleneck simply moves from writing code to reading code.
The thing I do not recommend is treating review of AI-generated code as a process where a human engineer reads everything the AI produced and then uses experience to decide whether it feels reliable.
That can work for small changes. It is not a scalable quality strategy once AI becomes a larger part of software development.
The more interesting question is:
What should we actually review when AI generates code?
My current answer is: review the evidence, not every line of code itself.
That deserves a separate article.
Key takeaways
- AI-generated code needs validation, but line-by-line review is not always the best use of human attention.
- Human output also has uncertainty, especially as implementation scope grows.
- Code review is an unstable quality gate when it depends heavily on overloaded human reviewers.
- Tests, static analysis, type checks, and CI provide repeatable evidence that review alone cannot provide.
- For AI-generated code, the next useful question is what evidence should be reviewed.
The future of code review should be less about proving that a human has read every line, and more about proving that the system can accept the change.