Answer
How should AI-written code be reviewed?
Same standard, different order. Check what it did not do first, because that is where machine-written changes fail.
To the same standard, in a different order. Look first at what the change does not cover: the case not handled, the caller not updated, the test not run. That is where machine-written changes fail.
The standard should not move. A change is accepted because it is correct, fits the system, and can be maintained, and where it came from does not alter that. Applying a lighter standard because the volume is higher is how the review becomes a formality, and applying a harsher one because of provenance wastes attention that belongs on the parts that actually differ.
What does change is where the failures concentrate. Human-written code fails in ways a reader recognises: an obvious oversight, an unfinished thought, a style that signals uncertainty. Generated code is uniformly confident and locally plausible, so reading it produces a weaker signal than usual. Its characteristic failures are elsewhere: a case that was not handled and is not mentioned, a caller that was not updated, an assumption that holds in the example and not in the data.
So the productive order starts with the negative space. Which inputs does this not handle. Which callers of this function exist and which were updated. Which tests exercise this path and did they run. Which file should have changed alongside this one. These questions are answerable quickly by search, and they are where the yield is. The line-by-line read comes after, and it will find less than it usually does.
The second shift is towards running rather than reading. A change should arrive with evidence that it works: the test that failed before and passes now, the output before and after, the reproduction of the original problem. This is a higher bar than most human changes are held to, and it is reasonable here because the cost of producing that evidence is low for the party that made the change and the value of it is high for the reviewer.
The third is the diff hygiene check, which takes seconds. Files touched that the task did not require. Reformatting. Regenerated artefacts. A change substantially larger than the task warranted. None of these is about correctness and all of them predict maintenance cost, and they are visible before any code is read.
One caution about volume, since it is the practical constraint. If more changes arrive than can be reviewed properly, the correct response is to slow the arrival rather than to lighten the review, because a lightly reviewed change carries the same risk as an unreviewed one and creates a record suggesting otherwise. This is uncomfortable and it is the whole question for teams adopting these tools at pace.
Review generated code for what is missing before you review it for what is wrong, because what is present will usually look fine.
Siddharth Sharma, Context Theory
Related questions
Should the person who prompted the change review it?
They should read it and they are not an independent reviewer, for the same reason an author is not. They know what was intended, which makes them likely to see the intent in the code rather than the code. Where the change matters, a second reader who did not see the prompt is worth the delay.
Can an AI review AI-written code?
Usefully for the mechanical layer — missed callers, unhandled cases, inconsistencies with surrounding code — particularly when the reviewing pass sees the change and the requirement without the conversation that produced it. It does not replace the judgement about whether the change should exist, which is the part that requires knowing what the system is for.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
2026 speed-to-lead benchmark · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Workflow | Generated code is uniformly confident and locally plausible, so a line-by-line read yields a weaker signal than for human-written code whose failures carry recognisable markers of oversight or uncertainty. | Comparing defect detection rates from reading alone across human-written and generated changes. |
| Software | The characteristic failures of generated changes sit in the negative space — an unhandled case not mentioned, a caller not updated, a test not run — which are addressable by search rather than by reading and are where review yield concentrates. | Searching for callers of every changed function and checking which were updated. |
| Response | Requiring evidence that a change works — the previously failing test now passing, the before and after output, the reproduction — is a higher bar than most human changes carry and is justified because producing it is cheap for the author and valuable to the reviewer. | Comparing the time to produce the evidence against the time a reviewer spends establishing the same thing independently. |
| Constraint | Where change volume exceeds review capacity, lightening the review produces the risk profile of unreviewed change plus a record implying review occurred, so the correct adjustment is to the arrival rate. | Comparing the number of changes merged per reviewer per week against the number reviewed at full depth. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one