Video lesson coming soon
We're filming this one. The full written lesson below is ready to study right now.
Your team now ships code that an AI wrote much of. That code is fluent, confident, and sometimes subtly wrong. Reviewing it well — without either rubber-stamping or banning it — is a core new skill for the lead.
Where AI code fails differently
Plausible but wrong
Looks idiomatic, handles the happy path, misses the edge case.
Invented APIs
Calls methods/params that don’t exist or changed versions.
Silent assumptions
Assumes input shape, timezone, units the author never checked.
Security blind spots
Misses authz, injection, secret handling the prompt didn’t mention.
A review stance that scales
- Make the author own it: "AI wrote it" is not a defence. They explain it.
- Review behaviour and tests, not just the diff — does it do the right thing?
- Probe the edges: nulls, empties, concurrency, failure paths.
- Check it fits the codebase’s patterns, not just that it runs.
✓
Tests are the contract
Insist that AI-assisted changes come with tests that pin the intended behaviour. A passing, meaningful test suite lets you review intent, not just syntax — and lets the team move fast safely.
Takeaway
AI code fails plausibly. Make authors own it, review behaviour + tests + edges + fit — not just whether it compiles. Tests are how you keep velocity without rubber-stamping.