You might think AI would help developers move faster, but that’s not always true.
I’ve been thinking about this a lot lately. The answer lies in the theory of constraints: a system moves only as fast as its slowest part. For software teams, that part is usually code review.
I work with a lot of developers, and from what I’ve seen, velocity and output don’t change much, even though every change uses AI. There are many reasons for this:
We just hit new bottlenecks (code review)
The coordination overhead between people slows things down
Teams aren’t adapting their workflows to allow AI to work effectively
I think many of these problems get worse in larger teams, especially when existing processes and coordination overhead slow things down. I’ve seen teams take months to deliver projects AI could deliver in hours. This isn’t an exaggeration; I’ve seen it happen.
Anthropic wrote a great article about this that’s worth studying. They increased their daily merges from 2,500 to over 30,000 in just four months. With so much code, humans can’t realistically review everything.
Coding might be faster now, but new bottlenecks are showing up in the development process.
We review code because, even with smart AI and talented developers, perfect code is rare on the first try. That’s normal - quality comes from iteration. But code review isn’t perfect. Just because a human looked at your code doesn’t mean it’s completely safe. If it were, we wouldn’t see bugs in production.
So the goal isn’t to have humans review every change. Instead, we should build systems that catch most problems and bring in human review only when it’s really needed.
Here's how Anthropic does that.
Match the review to the risk
Instead of seeing code review as one simple step, think about it in terms of risk. Not every change matters the same. For example, updating documentation doesn’t need as much review as changing your payment processing logic.
The Anthropic team sorts each change by risk level and uses that to decide how to review it:
Low risk = agents review and merge
Medium risk = 1 person reviews
High risk = 2 people review
Tell the reviewer what matters
Add a REVIEW file to your project. This file guides the AI reviewer on what to focus on in your codebase. For example, your team might have problem areas that aren’t obvious or standards to follow.
Read REVIEW.md before you review the code. This addresses some obvious objections to AI, like “it doesn’t have context on how our team works”.
Run multiple review agents
When using agents for code review, have multiple agents focus on different areas and combine their findings. Inside Claude Code, you have /security-review and /code-review. I recommend running both.
Make it a system
We all get tired and forget things sometimes, so don’t rely on memory. When I start a project, I set up the agent to run automated code checks and reviews on both my computer and GitHub.
This way, you’re not just prompting agents as needed. You’re making your development process more organised and consistent. You don’t need a complicated setup. As agents improve, you can keep things simple.
Release gradually and measure it
Some issues will always slip through. Anthropic sends changes to internal teams first and can quickly roll back if something goes wrong. I’ve also become comfortable with auto-merging certain types of changes.
Measure your review process. Track how long it takes a change to go from opened to merged, and how often you need to revert changes. For example, from June to September, merged pull requests to Claude Code more than doubled, while the number of reverts dropped by over 40%.
The six levels of AI code review
Here’s the full process from the Anthropic article, step by step. Each level catches a different kind of problem, so a mistake has to get past all of them to reach production.
Local review. Before you open a pull request, run your tests, build, linting and type checks, then ask a fresh agent to review the change. I always use a fresh sub-agent. No AI agent writes perfect code the first time, and Boris Cherny, who created Claude Code, says this local loop makes the final result two to three times better.
AI review on every pull request. Once the change is on GitHub, an AI reviewer checks it again. You can use Code Rabbit, Greptile, Claude Code, or Codex, which I use.
Security review. Claude Code has a /security-review command that looks for SQL injection, cross-site scripting, authentication and authorization flaws, insecure data handling, missing validation and vulnerable dependencies. Automate it, because most of us will forget to run it.
Deterministic checks. Linting, type checking, formatting, and build checks catch obvious errors before an agent or person has to. Ask your agent to set them up for your language, both locally and on GitHub.
Human approval scaled by risk. These are the risk levels from earlier. A classifier labels each change as low, medium, or high risk, which determines how many people review it. Whoever made the change is still on the hook, even if an agent wrote the code.
Gradual release and fast rollback. Changes go to internal teams first. Some problems, like memory leaks and performance issues, only show up in production, so you need a way to roll back quickly. Anthropic also reviews incidents every week and uses the misses as context for future reviewers, so they catch the same mistake next time.
No matter how skilled you are, you’ll make mistakes. The solution isn’t to read every line of code. Instead, match your review process to the risk and set up systems to catch the rest.
PS: Get all the resources from this video here: https://skool.com/ai-developer
Thanks for reading.
Have a great week.