Share this post
You know the PR. Thirty files, three thousand lines, and a cheerful "it's all good." The one you skim, can't possibly hold in your head, and LGTM on the way past because what else are you going to do.
Now imagine fifteen of those landing in a day. That's where we are.
This is the written companion to the video I just published — same arc, more receipts. Below are the five levers I've researched and actually use to review AI-generated PRs at scale.
▶ Watch the full breakdown on YouTube. The live demos for every lever are in there.
Why Review Became the Bottleneck
Not long ago, code was the bottleneck — and we had strategies for it. Some places asked developers to open one PR a day, keeping them small and easy to review. Other places still went big and LGTM'd them away. Either way, it was manageable. Sure, we had a PR backlog, and yeah, you'd have to chase people to actually review your stuff — but it worked.
Then AI shuffled the cards on everything. Now generating code is just a prompt away. Thirty files, three thousand lines — that's often the norm now, not the exception. You ask the agent, it goes "I got you, boss," and blasts out a PR, all shiny, with unit tests that pass. And when fifteen of those land in a day, LGTM stops being the shortcut and becomes the default.
So the bottleneck moved. It's not generating the code anymore — it's reviewing it. And everyone's drowning.
Here's why it's so hard. There's no ground truth for "good code" — good depends on your architecture, your conventions, what you're building next. And to really review a change, you have to hold its full scope in your head, which falls apart fast when the diffs are thousands of lines and they're landing by the hour. That's the battle. And to date, nobody's solved it.
I haven't either — let me be clear about that. But I've spent hours researching this, experimenting, and learning what other people are doing, and I want to share the insights I found useful. Not "here's the answer." More like "here's what's actually working."
Because here's the thing: we can't keep ignoring the shift. We can't review every single PR and stay the bottleneck — that math doesn't work anymore. We have to move with it and adjust. And realistically, the only way to do that is to get help: from AI, and from automated tools.
That means a few mindset changes. We focus on teaching the agent what good looks like, even without a perfect ground truth — best effort beats no effort. We categorize changes and review by risk level, so we spend our attention on what actually matters. And we reinvent the process itself so that we're no longer the thing everything waits on.
There are more ways to do this than I'll cover here. But below are five concrete approaches that help address this new-world stampede of code changes. Think of them as layers — local, to CI, to cloud. You don't need all five. Stack the ones that fit.
Lever 1: Pre-Commit Hooks
The first lever is pre-commit hooks — and the magic word is cross-agent. It doesn't matter who wrote the code: Claude, Codex, whatever's hot next quarter. The hook runs the same for all of them. One gate, every agent.
What you put in that gate is up to you. I lean on static checks, but they can be dynamic too — a linter, a formatter, whatever quality gates you like. The important part isn't which flavor you pick; it's that they run deterministically and don't take any context. No model, no tokens, no round-trips — they just run, every time, and give you the same answer. semgrep is a great example: it lets you write static rules and keep adding to them as you learn what your agents tend to get wrong. Use it, try something else, or lift the setup I use — you drive.
In the repo I use in the video, there are three: a linter, a formatter, and semgrep. One semgrep rule catches a no-f-string-in-SQL pattern — the kind that quietly becomes a SQL injection, and exactly the kind of thing an agent will happily write a hundred of. The hook catches it and stops it cold.
And that determinism is what makes it a review tool, not just a linter: because the output is predictable, you feed it straight back to the agent. It reads the failure, fixes the code, re-runs. No human in the loop for the boring, mechanical stuff — you save your attention for the calls that actually need a brain.
Lever 2: Harness Hooks
The next lever is harness hooks, and this one's a great spot in the pipeline that most people walk right past.
A harness hook lets you handle different models differently, right inside the tool that's running the agent. And like pre-commit hooks, it doesn't pollute the context, and it can cost you basically nothing.
Here's the tradeoff I keep coming back to. Claude has a built-in code review, and it's very, very good. But run that review inside CI and it costs real money — when I did it, somewhere around fifteen to twenty-five dollars per review. Hooking the review into the PR sounds like the right place, and in a lot of ways it is, but the round-trips add up. Every time the reviewer reads the diff, thinks, goes back and forth — that's tokens, and it's slow.
Run that same review locally, from inside the harness, and it's faster and cheaper. From within Claude, it can run for free. And — this is the part I can't stress enough — it runs in a clean context. Don't dump your review loop into the same context that's busy building the feature; you'll just confuse the model. Fresh eyes, every time.
One pattern I like: use Codex to review Claude's code, or the other way around. A second model, clean context, no shared bias. It's a genuinely good way to keep quality up.
The way I wire it, the hook bails instantly if it's not a relevant commit, so it's cheap by default. When it does fire, it runs a bounded loop — a capped number of iterations so it doesn't try to self-heal forever — runs the review against a rubric you control, and feeds the findings back. On a recent run it flagged a duplicated WHERE-clause builder and a handful of other real issues on main, all easy to hand straight back to the agent to fix.
And review is just one thing you can aim a hook at. Don't like it? Drop it. Point the hook at something else entirely — have a second agent, with a clean context, go write the tests instead. Same idea, different target. These are patterns to adapt, not a recipe to follow — take the shape and aim it wherever your pipeline hurts.
Harness hooks cost near zero, don't touch your context, and stop bad code close to the source.
Lever 3: Auto Review in CI
The third lever is binding review into your CI — using tools like CodeRabbit and the others in that space. They're getting better and better.
They cost a license, sure. But they earn it, and you can drop them in as a last automated gate before a human ever looks. You don't have to — you can mix and match, experiment, swap tools. But as that final gate, this is a strong spot for one.
What I like about them is the walkthrough. Instead of just dumping a list of findings, CodeRabbit walks you through the change: which commits, which files moved, a narrative of what actually happened. It'll even draw you a sequence diagram. That's a genuinely nice way to look at a PR you didn't write — you get the shape of the change before you dive into the lines.
And these tools catch things you'd miss, often a lot cheaper than running the full Claude Code review — though that one's still fantastic when you want the very best pass. Different tools, different tradeoffs. Try a few, see what fits.
There's one more thing CI is quietly great for: risk tiering. You can bake your own logic into the pipeline — the same deterministic checks from Lever 1, plus scripts that sort PRs by risk. Low-risk changes can auto-merge. Higher-risk ones route to a human. I'm staying deliberately vague on where you draw those lines, because that's your call and your codebase, not a number I can hand you. But the capability — letting the pipeline triage so humans only see what actually needs human eyes — is exactly the leverage you want when fifteen PRs are landing a day.
Lever 4: Ask the LLM to Explain the PR Back to You
This is my favorite lever, because it flips the whole thing around.
Instead of grinding through the PR line by line, ask the LLM to explain it back to you.
You can have it summarize, sure. But you can go further — and honestly, make it fun. In the video, I ask the agent to explain the diff as a fairy tale. It goes off and narrates the change back to me as a little story: the expense tracker, the hall of budgets, the reporting logic as a chamber of secrets. Sounds ridiculous. Works anyway.
Because of what's happening underneath. To narrate the change, the model has to actually walk the flows — what got added, how the pieces connect, what the reporting does. And when you read that story back, especially on the gnarlier, riskier PRs, you catch things. You'll hit a line and go "wait — that's not right." If you're technical, it makes it very easy to spot the exact moment the agent wandered off and did something dumb.
It's a review technique wearing a story costume. The format lowers the friction of understanding a change you didn't write — and understanding is the whole game. And when the narration raises a flag, that's your cue to do the last thing on the list: go actually look at the code.
Lever 5: Sandbox Agents in the Cloud
The last lever is off the beaten path — a bit of a hidden gem, and it points at where I think all of this is heading.
Run your agents not on your machine, but in the cloud.
Here's why that matters, and it's subtle. When an agent writes code, the diff is only half the story. The other half lives in the conversation — how it got there, what it tried, what it ruled out, why it made the calls it made. Capture that, share it across your team, and review gets dramatically easier. You're not reverse-engineering intent from a diff anymore. You can just read the reasoning.
In the demo, I spin up a channel that provisions a VM and runs the code review inside it. You watch the whole thing happen: the VM comes up, the agent runs in it, and you can even tunnel in and see it work live. It goes hunting for real bugs — and then, the part I love, you can just chat with it. Ask it to explain things back. It's all in the cloud, so none of it is chained to your laptop.
Which opens something up: one engineer — or even a non-engineer, a PM, a CEO — can kick this off, build a feature, and hand the whole session, code plus conversation, to an engineer to pick up and understand. You can commit the entire conversation right alongside the code. And everything else still stacks on top — the summaries, the explain-back, all the levers above still apply.
But don't follow my path just because it's mine. The real shift is this: start reviewing with the context, not just the diff. Think about how much code is basically auto-generated now — the way Swagger spits out a client from a spec. When the code is generated, the code isn't the original work anymore. The conversation is the input, the intent, the thing that actually deserves your attention. Start looking at changes through that lens.
Sandboxes just make that context easy to share and review — but they're not the only way. A great example: Kun Chen, an L8 engineer at Meta, built a tool called no-mistakes that takes the context and the diff and hunts for errors across both. No sandbox required — it's a clean example of reviewing with the context instead of squinting at the diff alone.
I'll admit I'm biased: I still think shared sandboxes have huge value, not just for reviewing PRs but as a way to run whole workflows. But bias aside, the principle stands on its own — this much code coming at us means we have to reinvent how review works. And as more teams start sharing their workflows and their agent conversations, I think this is the direction it goes.
What This Adds Up To
Let's be honest about where we are: nobody has cracked fast, high-quality review at scale. Not me, not anyone.
But the direction is clear. Automate more of the review, remove yourself from being the bottleneck, and keep your standards intact along the way — whether they live in your AGENTS.md, your CLAUDE.md, or the guardrails you build around them.
That's what these five levers do. Hooks catch the mechanical stuff locally, for free, before it reaches you. CI review and risk tiering act as a last automated gate. Explain-back and shared sandboxes change how you understand a change at all. Local, then CI, then cloud — stack the ones that fit.
The one shift that matters most: stop being the bottleneck. You can't hand-read fifteen PRs a day, and you were never meant to. Teach your agents what good looks like — and if you want to go deep on how to teach them, that's its own rabbit hole (your context file outranks your prompt) — then let them and your tools do the first passes, and spend your judgment where it actually counts. That's the whole game.
Try them. Break them. Build better ones. Then tell me what you found at doryzidon.com.
Key Takeaways
Stop wasting time on AI. I run practical experiments — real lessons you can use tomorrow, biweekly.
Subscribe to AI Will Replace Your Engineers
Watch, read, and build
