Rethinking Code Reviews
Engineering teams are drowning in PRs and nobody wants to say it out loud.
At Pocus, as we adopted more AI coding tools, code reviews became the bottleneck. I had some time over the weekend to dig into why we even have code reviews, which led me to this post by the Graphite team. Long story short, they started as a way to catch bugs because they were expensive to fix. As tests took over that job, reviews quietly reinvented themselves around readability and coherence. That shift made sense: source code was the highest level of representation available, and keeping it readable was the best way to keep a codebase maintainable over time.
Coding agents have fundamentally changed how code gets written, and the review process hasn't kept up. Something that took days now takes minutes, and PR volume has gone up by an order of magnitude. Engineers used to carve out focused time to review carefully, which was feasible when frequency was manageable. Today the same engineer has a dozen PRs waiting before lunch. This is not a discipline problem. It is a structural one.
Abstractions
The reason for this is simple. We have never reviewed the code that actually runs on the machine. When you push code to production, a compiler transforms it. A JIT runtime might recompile it again at execution time. The binary executing on the CPU looks nothing like what you wrote. Nobody asks to review the optimized assembly. We implicitly agreed that the right level to reason about code is the highest level of representation available.
For most of software history, that abstraction was source code. It no longer is. When you open an unfamiliar codebase today, most engineers ask Claude to explain what the relevant module does, how data flows, what the abstractions are. English is now where intent is expressed and decisions are made. Code is increasingly the compiled artifact of that English, the same way assembly is the output of a compiler given source code. The same logic that pointed reviews toward source code now points them toward English. Reviewing below the highest level of representation is a broken process. We are doing it because we haven’t fully accepted what has changed.
Pipeline
Think about how the code generation pipeline has changed today
When humans wrote the plan and the code. It made sense for humans to review both. Reviewing the code in the new world is like reviewing the assembly in the old one. It is the wrong level.
The engineer’s job is to own the plan. That means spending real time in plan mode, working with the agent to understand the problem space, identify the right abstractions, and surface the business context no tool can fully internalize. Most engineers doing this well already run in plan mode much longer before letting the agent write any code. Once the plan exists, let the agent iterate without interruption. At Pocus, the difference in quality between code reviewed after one agent pass versus several was consistently significant.
This also means accepting that agent-generated code won’t always be as clean as what a skilled engineer would write by hand, similar to how compilers sacrifice readability for performance. That’s manageable. Refactoring is easy with high test coverage and a written plan. Rewriting in a new language becomes tractable when the plan exists independently of the implementation.
Future
My strong belief is that the code review process needs to be rethought from the ground up. Not just to deal with the influx of code, but to open up contribution to people who aren’t traditionally software engineers. Today, making a change to a codebase requires knowing the language, the conventions, the patterns. In a plan-first world, an engineer who understands the logic and knows language X can meaningfully contribute to a codebase written in language Y. The plan is language-agnostic. The agent handles the translation. This is a bigger shift than it sounds. It fundamentally changes who can contribute to a codebase and how teams are structured.
Plans need to become first-class artifacts. Not a one-liner PR description, but a structured document: what new classes are we adding, what existing tools are we reusing, what invariants might we be breaking etc. The back and forth happens on the plan, not the code. Code review gets scoped down to one question: did the agent implement what the plan said? The plan gets committed alongside the code. The plan shows the diff. The code is the current snapshot of the world.
Today
We're in a transitionary period. We haven't fully arrived at the future but we've definitely left the past behind. Things are moving fast enough that some of this might be outdated in a month. Here are some things I've found to be helpful.
Let agents loop and review their own code before you jump in. Looking earlier means reviewing something that’s about to change anyway. Iterate on your CLAUDE.md every day. Every time the agent produces something wrong, check in how you want it to think about the codebase. You get to good output faster than you’d expect. Stack your PRs. Agents produce large sprawling changes and stacking forces the right level of decomposition.
Invest heavily in tests - fuzzy as well as deterministic. Non-determinism in code generation should be caught by tests, not human reviewers. Agents make high coverage easy to achieve and tests are what make refactoring safe when agent output needs cleaning up.
Start breaking up the monorepo. Most large monorepos contain things that have no business being together. A data ingestion pipeline and internal warehouse models share almost no code yet often live in the same repo. Agents struggle with giant context. Clearer boundaries with explicit contracts make agent output dramatically better.
Coda
Try a thought experiment: imagine deleting your IDE. What would actually break? The answer tells you a lot about where you're still working the way you used to.
The engineers who figure this out earliest will have a real advantage. The instinct to read every diff and personally verify every change made sense in the old world. The new instinct is to stay close to the plan, trust the harness, and spend your judgment on what only you can provide. Things are moving fast and chaotic right now. Embrace the chaos.