This guide complements the blog article "Reviewing AI code is a different job" with concrete approaches that any team — from junior to senior — can implement immediately.
The funnel: reviewing AI code in layers
AI code rarely has problems at the line level. The errors sit higher up: wrong place in the system, wrong pattern, wrong assumption. That's why it pays to work from the outside in — and at each layer decide whether to go deeper or reject immediately.
- Architecture: Does this belong here? Which service, which module? Does the responsibility fit? If the AI created a new module that belongs in an existing service — reject at the architecture level. Don't even look at the code. Thirty seconds instead of thirty minutes.
- Conventions: Does this follow our patterns? Error handling, logging, inter-service communication, module structure. A scan at the structural level. Don't read a single line of logic, just look: Does this look like our code, or like generic textbook code? If it violates project conventions — send it back before getting lost in details.
- Duplicates: Does this already exist? Quick search in the codebase. AI loves to rebuild what already exists. If the generated utility class is a copy of something in the shared library repository — send it back. No reason to keep reading.
- Implementation: Only now the code. And even here, not line by line, but targeted: How does it handle errors? What happens under load? What assumptions are baked into the tests? Which edge cases are missing?
Six practices for everyday work
- Before the review: load context, not just the diff. Before you read a single line, look at where the code lands. Which service? Which module? What are its neighbors? What conventions apply there? Five minutes of orientation save thirty minutes of debugging.
- The "Why this way?" question as standard. With human code, you can ask the author: Why did you solve it this way? With AI code, there is no author. So ask yourself the question — for every design decision in the generated code. If you don't have an answer, that's a warning sign.
- Check against project documents. ADRs, coding guidelines, wiki entries — whatever the project has. Explicitly hold AI-generated PRs against them. Not because the docs are always current, but because the deviation marks the interesting spot. If the AI code does something differently than the docs prescribe, there are two possibilities: The docs are outdated, or the code is wrong. Both are worth clarifying.
- Search for existing code before accepting new code. AI doesn't know that three modules over there's a utility class that does exactly this. Or that the team built a shared library for this case a year ago. A quick search in the codebase prevents duplicates that create long-term maintenance problems.
- Actively demand non-functional requirements. AI thinks in happy paths. What it doesn't build: timeout handling, retry logic, behavior under load, error scenarios that only occur in production. Simple checklist: What happens when the external service doesn't respond? What happens with a thousand concurrent requests? If the AI code has no answer to that, the review isn't finished.
- Write down unwritten rules. Every convention that exists only in people's heads is a convention that AI code will break. Every architecture decision that was never documented must be re-made with every AI-generated PR. The afternoon when the team writes down its unwritten rules is the afternoon from which AI reviews take half as long.
Why documentation is now mandatory
In a world without AI, Architecture Decision Records, maintained coding guidelines, and documented conventions were nice-to-haves. Good if they existed. Not tragic if they didn't — because the knowledge lived in the team's heads.
In a world with AI, they become prerequisites.
AI can only consider the context it receives. If project conventions aren't documented anywhere, AI-generated code will ignore them. If architecture decisions live only in the heads of three seniors, every PR will violate at least one of them.
Projects that have documented their conventions will integrate AI code with less friction. Projects that haven't will spend more time on reviews than they save through AI generation.