Lesson 336 of 2116
Reviewing AI Code Like a Senior Engineer
Reviewing AI-written PRs is a different sport from reviewing human ones. Learn the structured review workflow that catches AI-specific bugs, plus the questions that separate confident-looking trash from real engineering.
Lesson map
What this lesson covers
Learning path
The main moves in order
- 1Reading Is the Job Now
- 2code review
- 3structured walk
- 4intent vs implementation
Concept cluster
Terms to connect while reading
Section 1
Reading Is the Job Now
When AI writes most of your code, reviewing becomes the engineer's primary craft. AI-written PRs look polished — better commit messages, better names, better formatting than humans usually produce. They also fail in stereotyped ways humans rarely do. The review checklist must adapt.
Human PR vs. AI PR — what changes
Compare the options
| Dimension | Human PR | AI PR |
|---|---|---|
| Surface polish | Variable | High — formatted, named well, comments present |
| Test coverage | Often skipped | Usually present (but may be tautological) |
| Off-by-ones | Common in custom logic | Common in loops AI generated |
| Hallucinated APIs | Rare | Common — calls to functions that don't exist in your codebase |
| Architectural fit | Usually consistent | May fight existing conventions |
| Risk of overconfidence | Self-aware | AI rarely flags its own uncertainty |
The structured walk: 7 stops, in order
- 1READ THE COMMIT MESSAGE — does it match the diff? AI-generated messages are often aspirational
- 2READ THE DIFF SUMMARY — count files changed; if >10, push back for a smaller PR
- 3VERIFY IMPORTS — every new import: is it real, is it the right version, is it on the allowlist?
- 4TRACE A REQUEST — pick one user-visible flow and walk it end-to-end through the changes
- 5CHECK EDGE CASES — does empty/null/zero/unicode have a test? Almost never on AI's first pass
- 6RUN THE TESTS LOCALLY — green CI is necessary, not sufficient
- 7READ THE TESTS — are they real tests, or assertions that mirror the implementation?
Five questions to interrogate AI code
Five questions you ask of every PR. Answers reveal whether the AI understood the task or merely shaped output to look like it did.
# Pin these to your monitor:
1. "What was here before, and why?"
— AI loves to delete code it doesn't understand the purpose of.
2. "What happens to this function on the most surprising input?"
— Empty? Null? Unicode? Very large? Concurrent?
3. "Does this change touch any business logic that has documented reasons?"
— Check ADRs, comments, related issues.
4. "Where in this PR would a malicious user attack?"
— Even if the feature isn't security-critical, ask.
5. "Could I reproduce this PR's intent in 50% fewer lines?"
— AI tends toward verbose; cut what doesn't earn its keep.The single highest-value review prompt
Cross-model adversarial review. Catches what same-family review misses.
# Run in a fresh chat with a different model than wrote the PR:
"You are a senior reviewer with no context on this PR's history.
Do not trust the description. Read only the diff.
For each changed file, list:
1. What this change does (1 sentence)
2. The single most likely bug introduced
3. The single most likely regression risk in adjacent code
Do not be polite. Be blunt. List concrete line numbers."What to push back on
- Renames you didn't ask for — `getUser` -> `fetchUserById` everywhere is a code-churn red flag
- New abstractions for one caller — premature generalization
- Tests that mirror the implementation (`expect(result).toEqual(result)`)
- Changes outside the stated scope of the PR
- Comments that explain what the code does, not why
Approving vs. requesting changes
Compare the options
| Signal | Action |
|---|---|
| Imports verified, tests cover edges, scope tight | Approve |
| Tests are tautological — match implementation 1:1 | Request: "rewrite tests against the spec, not the code" |
| Diff includes unrelated changes | Request: "split into separate PRs" |
| Hallucinated function call | Request: "verify <function> exists and document its source" |
| Performance claim with no measurement | Request: "add benchmark or remove the claim" |
| Security-critical path with no human-written test | Block until written |
“An AI PR with no review is a commit by an intern who has never seen production.”
Key terms in this lesson
The big idea: AI PRs look better than human ones and fail in different ways. The structured walk, the five questions, and cross-model adversarial review catch most of it. Reviewing well is now the engineer's most leveraged skill — what you catch in review is what doesn't ship to production.
End-of-lesson quiz
Check what stuck
15 questions · Score saves to your progress.
Tutor
Curious about “Reviewing AI Code Like a Senior Engineer”?
Ask anything about this lesson. I’ll answer using just what you’re reading — short, friendly, grounded.
Progress saved locally in this browser. Sign in to sync across devices.
Related lessons
Keep going
Creators · 50 min
AI-Assisted Code Review Workflows (for Teams)
Code review is the highest-leverage touchpoint in a team. Automating the noise with AI frees humans to focus on the irreducibly human parts. Let's design the workflow.
Creators · 14 min
Always Ask What Changed
Vibe builders can modify many files at once. Asking for the diff summary trains you to notice accidental rewrites before they become permanent. Write the smallest useful scope the agent can finish.
Creators · 14 min
Use A Second Model For Review
One agent writes the patch; another critiques it. The disagreement is where bugs hide.