AI code needs more review time per line than human code
It looks right but is subtly wrong — because its failure modes are different
Human mistakes and AI mistakes are different in kind
| Lens | Human-written code | AI-written code |
|---|---|---|
| Kind of mistake | Typos, simple bugs — usually visible | Plausible but subtly wrong — hard to spot |
| Surface | Uneven (polished here, sloppy there) | Uniformly smooth → easy to let your guard down |
| Weak spots | Vary by person | Consistently weak on error handling, retries, edge cases |
| Review time | Fast per line | Longer per line — the faster the generation, the longer the verification |
Knowing where it breaks tells you where to look
Studies report that a substantial share of AI-generated code contains OWASP Top-10-class vulnerabilities (over half in some languages), and that it carries far more privilege-escalation paths and architectural design flaws than human code (Apiiro 2025 and others). Always review input validation, auth, and secret handling separately. (figures are a snapshot at time of citation)
Null/empty inputs, concurrency, timeouts, partial failure. The model writes the "goes well" case first and either omits exception paths or fills them perfunctorily. This is the prime review target.
It interprets the prompt plausibly and confidently implements behavior slightly different from what was asked. The cleaner the code, the easier this drift is to miss. Confirm "the thing that was asked for" first.
When the model generates implementation and tests together, the two share the same wrong assumption, so green tests verify wrong behavior. "Tests pass" ≠ correct. You have to supplement with human-authored scenarios.
Top to bottom — intent first, style last
Cross-check against the spec/issue line by line. Is it "the thing," not "something similar"? Any missing requirements or behavior added on its own? Review this first and weight it most.
Function signatures, return types, error contracts, backward compatibility. Models often quietly alter an existing interface and break callers.
Untrusted-input handling, authn/authz, secret/key exposure, injection. This is where AI code's most dangerous holes appear. Make it a separate pass.
Are null/empty/boundary, concurrency, timeouts, and partial failure handled? Do the tests cover more than the happy path? The model's weakest area.
Do the tests share the implementation's misunderstanding? Are the assertions substantive, or just filling the form? If in doubt, add one human-authored scenario.
Last. Do naming and structure match team conventions; can a maintainer follow it? AI code usually passes here, so spend the least time on it.
Common human mistakes in front of AI code
Fooled by the smooth surface, you approve fast. Subtle errors hide inside clean code.
Relaxing because the AI-written tests are green. Code and tests may share the same misunderstanding.
Reviewing at the same speed. The failure modes differ; same effort means you miss them.
Trying to review a PR where the AI dumped thousands of lines at once — focus collapses.
Trusting an AI review tool and skipping human review. They share the same kind of blind spot.
Same order every time — structure makes it faster and misses less
Read the PR description and linked issue and pin down "what it was supposed to do." Set expectations before you look at the diff.
Check requirements, contract, security, and behavioral coverage in the diff. Hunt deliberately for edge cases and error paths.
Check whether tests verify something real; if in doubt, request one added scenario. Style last, lightly.
If a review runs past 15 minutes, the PR is too big. Push back so future work is generated and submitted in smaller units.