Code diffs are not the bottleneck

Bottlenecks tend to shift, not disappear. The go-to complaint for a while, now that we can all agree code generation is cheap and reliable, has been that there's simply too much code to review. But what we call "code review" serves a lot of purposes, and most of them aren't about reading the diff line by line.

There are second order effects, like knowledge transfer and mentorship, that we're going to need to grapple with as individuals, as companies, and as an industry. But the core function that putting up a pull request serves is and always was a verification gate. Some of that (maybe even most) can be verified deterministically and automated. Things like logic bugs or repository conventions can now reliably be handled by agentic review processes. But ultimately someone (or something) needs to answer questions like: Is this even a good idea? Is the approach reasonable given the constraints? Does it actually work as intended?

That last one is the most critical, and where keeping a human in the loop still matters for most companies, for two reasons. First, intent is often poorly conveyed, so agents can't reason about it accurately, but humans, with lots of implicit context, can. Second, while "empirical verification", as one of this week's articles describes it, is something to strive for, most changes, most PRs, most companies simply aren't there yet (and who knows if they ever will be). So we (still) need humans to infer intent and verify the change.

The teams who are truly moving faster aren't especially good at reading, and they're not just skipping verification entirely either (at least not the ones we're talking about). They've built a verification system they trust, which lets them allocate human attention more discriminately. The bottleneck isn't reading, it's confidence.

Here's what we've been reading this week.

10 thoughts on reviewing and verifying code

Rahul Gupta from Ramp with some quick bites on review, with verification at the center where it belongs. Stop thinking of frontier models as "code writers," he argues; think of them as English-to-code interpreters that turn your idea into correct code regardless of how complex the output gets.

Time it takes to ship software is completely disconnected from time to produce the PR. How long the work takes depends fully on ability to review and merge code while managing risk at scale.

He suggests smaller diffs in high-risk areas (auth, identity, data access, money movement) get read line by line, every time, no matter how good the model got. Large diffs in verifiable areas (frontend and backend plumbing, code with no network or DB access, performance you can benchmark) get treated like a black box: don't read every line, prove the outputs are right and quarantine anything that could do damage. Line-by-line reading becomes the expensive instrument you save for where being wrong actually hurts. Code review is one verification method among many, and the win is a system that routes each change to the cheapest method that's still trustworthy.

Agentic code review, audited

Addy Osmani wrote a novella on agentic review, and it's worth your time even though it wanders and not every turn holds. If you just want the highlights skip to "What to actually do" towards the end.

The constraint moved downstream, to the one step that did not get faster: a person being confident the change is right.

Two things to flag before you paste it into a planning doc. He says that when a human writes code, "intent comes along for free." It never did. Divining intent was always the hard part of review, and an agent can be goaded into writing the why down even when it won't volunteer it. And don't anchor on his numbers: the headline figures come from a December 2025 CodeRabbit dataset, six months stale in a field that turns over monthly and conveniently flattering to the company selling AI review.

Where he ends up is the useful part. How much review a change needs depends on its blast radius, and most advice was written by someone operating at a very different one. We'd push that further: every PR sits differently on his three axes (blast radius, half-life, and how many people need to understand it), so there's no fixed rule to copy. The gain comes from building a system that embraces that variability instead of pretending one review depth fits every change. Strapped for time? Skip straight to his "What to actually do."

A junior engineer's perspective

An intern at Boundary, with a different viewpoint on the same theme. Two weeks into a YC startup, he reports that his team almost never reviews code; what they review, heavily, is design docs. Push the intent upstream and the code that lands is already well-bounded, so verification is cheap because the hard thinking happened before the diff existed. That's real, and it's the right instinct. But code review was quietly doing a second job, knowledge transfer and mentorship, and a team that drops it without replacing that job loses the thing that turns a junior engineer into a senior one. Worth deciding on purpose where that learning now happens, rather than discovering in a year that it stopped.

Not related to code review but worth highlighting: [Pylon's Claude spend by team](https://x.com/marty_kausas/status/2066913707192410559). Marty Kausas published Pylon's spend by function this week. Engineering is #1, no surprise. The standout is #2: Support, ten people at about $1,100 each, now spending more per head than marketing, CS, and sales. His read on why is the part to sit with:

Engineers crawl massive codebases. Support crawls just as much for a single ticket: docs, logs, past tickets, the customer's whole history. High-context job. Same shape as writing code.

Last year AI cost was almost all engineering; now it's company-wide. The functions quietly catching up are the ones doing high-context work, but they key here is visibility so you can make sense of it all.

Also worth your time: [writing the loop](https://www.youtube.com/watch?v=JoXbk2fm7jM&t=127s). Claire's latest How I AI is a hands-on walk through writing agent loops in Claude Code and Codex, the move from prompting an agent interactively to building automations that prompt themselves. It connects straight back to this issue's spine: a human still owns the intent behind an agent's PR, and loop design is where that ownership either lives or quietly leaks out. Good for anyone on your team looking to level up.

Two things to try this week

Both shipped from Anthropic this week, and both are worth a look if you're a Claude shop.

• [MCP Enterprise-Managed Auth](https://x.com/ClaudeDevs/status/2067655887662272723). Admins can centrally authorize MCP connectors for the whole org, so every tool and data source a person needs is wired up on first login instead of through a pile of hand-rolled keys and one-off handoffs. If "agents that can act in our real systems" has been stuck in a security review, this is the unblock. Stand it up for one team and watch what they reach for.
• [Claude Code Artifacts](https://x.com/claudeai/status/2067671912038240487). Interactive pages built from a session, shared at a private link, and the headline example is a PR walkthrough. That's a verification aid hiding in a feature announcement. Take your next genuinely gnarly agent PR, generate the walkthrough, and see whether your reviewer gets confident faster with the why laid out than with a wall of green diff. (Beta on Team and Enterprise.)

If you only have appetite for one, do the second. It's the one that touches this week's whole argument.

Good luck out there. And if you're joining us June 27, we'll see you very soon.

— Claire + Zach