Reviewing AI-generated code

Review AI output with the rigor of code review. If you cannot explain it, you cannot ship it. The failures are characteristic, which makes a short checklist useful.

Would you accept this from a new hire without comments? If no, do not accept it from yourself either.

Characteristic failures

• Invents APIs that do not exist
• Skips error paths and auth checks
• Writes tests that assert mocks were called, not behavior
• Copies outdated patterns from training data
• "Fixes" flaky tests by weakening assertions

Checklist before you approve your own AI-assisted PR:

1. Can I explain every branch?
2. Did I run the tests and a manual path for the risky case?
3. Are names and module boundaries consistent with the repo?
4. Would I accept this from a new hire without comments?

The highest-bandwidth pattern is often: you design the approach on a whiteboard or in a short doc, the agent implements under tests, you review and steer. That preserves architecture in a human head while outsourcing typing. Pure "agent from a one-line ticket" works for chores. It fails for ambiguous product work where the hard part is deciding what right means.

When pairing with a teammate, agree who drives the agent and who watches for domain mistakes. Two people both half-watching a stream of diffs is how bugs land.

Walking through a miss

The agent "fixes" a flake by deleting the assertion that caught a real race. CI is green. The race shipped. Your review should have asked: did this test get weaker, and was the flake a time or isolation problem instead? Weakening assertions is a characteristic AI tell.

Licensing: generated code can resemble training data. For novel risky areas, prefer writing critical algorithms yourself or from known-licensed internal libraries. Do not claim sole authorship of a design you did not understand in a promotion doc. When unsure, a PR note ("scaffolded with Claude Code; hand-reviewed auth paths") is cheap insurance and helps reviewers know where to look harder.

Common mistakes

• Rubber-stamping because tests are green. Green tests that assert mocks are a tell.
• Skipping the manual path on the risky case. Types are not a checkout.
• Two people half-watching the stream. One drives, one watches the domain.
• No disclosure on a large generated diff. Reviewers need to know where to look harder.

Check yourself

1. The agent made a flake go green by loosening an assertion. What do you do? Reject it. Fix the flake's real cause — time, isolation, network — not the assertion.

2. Can you write the PR description from memory? If no, you did not understand the diff. Do not merge it yet.

Key takeaways

• You own every merged line. Review it like a new hire's PR.
• Watch for invented APIs, skipped auth, and weaker tests.
• Design stays in a human head; typing can be outsourced under tests.
• Disclose large generated diffs so reviewers look harder.

Further learning

Next, protect growth in learning with AI tools.