The bottleneck didn't disappear. It moved.

Here's the story you've probably heard. AI made engineers dramatically faster. Some people leaned in and are killing it. Others resisted, got frustrated, started fighting it. The natural reading is that one camp is brave and the other is scared. Fix the scared ones' fear, close the gap, everyone ships more.

I want to walk through why almost every part of that is wrong, one step at a time. Not because the fear framing is unkind, but because it will make you manage the exact opposite of what you should.

The starting observations aren't ours. They come from a Lenny Rachitsky podcast conversation with Fiona Fung. Fiona describes agent-heavy work starting to feel lonely, and points to pairwise programming lunches as a response. The conversation also raises a widening gap between the people leaning into AI and the people resisting it. Those are the things worth explaining. The reasoning that follows — why the loneliness is a broken collaboration graph, why the gap sorts by ownership, why there's a debt that lags the commit, why the incentives push both camps apart — is our own read of the mechanics. Treat it as a hypothesis you can check on your own team, which is how it's built to be used.

Start with a dumb-sounding question. If writing code got, say, 8x faster, why did anyone's team feel slower? People will tell you review takes forever now, PRs pile up, things sit. But if the machine writes the code, where did the slowness go?

It went to the one cost that was always the real cost. Writing code was never the expensive part of software. Understanding code was. When a human wrote a function, understanding came free — you understood it because you'd just reasoned your way through writing it. An agent breaks that link. The code exists, but nobody reasoned through it. So the reviewer has to reconstruct reasoning they never witnessed.

That's the whole trick. The bottleneck didn't disappear. It moved from authoring to comprehension. And comprehension is where it was already jammed.

So 8x more code isn't 8x more shipped. It's 8x more inventory piling up at a review station whose throughput didn't change. You can watch this happen. Agent-heavy PRs get bigger, because the machine produces more per unit of human intent, and a big diff you have to reverse-engineer tends to sit in review longer than one you'd have written yourself. The honest metric was never commit volume. It's review latency and revert rate. If those two go up while commits go up, you're not shipping faster. You're accumulating.

Now the loneliness. People treat it as a mood — we all work with our agents so much, it got isolating. But watch what pairing and async review actually do. Two people reviewing the same code build a shared mental model of it. That shared model is the thing collaboration produces. When each dev works alone with an agent, no shared model gets built. Nobody else has the picture in their head.

So the loneliness isn't a feeling you should treat with a lunch. It's what a collaboration graph looks like after the edges between humans got silently rerouted through agents. You can measure it directly: cross-review comment density drops, pairing minutes drop, the who-reviews-whom graph thins out. The pairwise programming lunch is a team sensing the missing edges and re-adding them at the social layer. But the edges went missing at the workflow layer. Lunch doesn't restore the shared model of the code.

Now the part everyone gets backwards: the gap between camps.

Agents aren't uniformly good. They're genuinely strong on greenfield and glue code — low coupling, well-known patterns, cheap to check. They're genuinely bad on legacy, high-coupling, safety-critical code — implicit invariants, wide blast radius, expensive to verify, easy to produce plausible-but-wrong output.

Follow that one step further. Adoption doesn't sort by courage. It sorts by what you own. The devs who are killing it mostly drew the code surface where agents win. The resisters mostly own the surface where agents produce confident, wrong code they personally would get paged for. Map the two camps onto your CODEOWNERS file and your on-call rotation. The gap often lines up almost exactly. When it does, it's a context distribution wearing a personality costume.

And there's a bill you can't see yet. Agents optimize local task success, not global structure. They duplicate a helper instead of finding the existing one, they quietly widen a function signature, because that's the shortest path to passing the immediate check. That can erode module boundaries more quickly than a human would. The cost shows up as authorship dilution: git blame points to a person who prompted the code but never reasoned through it, so at 3am during an incident, nobody can explain intent under pressure. Module decay and incident cost lag the commit by months. Which means a one-quarter measurement window shows you all the upside and none of the liability. You're borrowing against a bill that arrives after review season.

Last piece. Why are both camps fighting instead of merging? Because your promotion system still rewards visible shipping volume. Agent-heavy greenfield work is maximally visible — big PRs, fast, lots of it. The work of absorbing risk — reviewing agent output, writing the eval suite, catching the regression, holding the pager — is invisible and makes you look slow. So the reward system pays one camp in career capital and taxes the other. The resentment isn't emotional. It's two groups responding correctly to a reward structure that now points in opposite directions. Telling the maintainer to lean in and focus on what's in their control quietly blames them for a structural problem. You don't fix a broken promotion ladder with a lunch.

So what actually works. Three moves, all aimed at the mechanism.

First, stop tracking throughput and track the pair: review latency and revert rate, next to commit volume. Open your PR dashboard and add mean time-in-review and revert rate as columns. If both climb while commits climb, you've found the inventory pile, not a productivity win.

Second, put boundaries in CI, not in review prose. A tired reviewer approving a large agent diff will not catch a duplicated helper or a silently widened public interface. A build check will. Add import-graph linting and a fitness function that fails the build on new cross-module imports and on public signature changes that weren't declared. Prose lies about intent; CI doesn't. Pair this with a required decision log in every agent-authored PR description — what problem, what alternatives got rejected, what invariants the change assumes — so the reviewer has an entry point instead of a wall of generated code.

Third, credit the invisible work. Make "hardened N agent PRs," "caught this regression," and "wrote the eval suite guarding module X" into named, promotable artifacts. Turn the maintainer-verifier into a rewarded specialty instead of a career penalty. Your ground truth for all of this is the pager. Whoever gets paged at 3am is the person who must understand the system, so weight their comfort heavily and read their refusal to merge un-understood code as a signal, not obstruction.

One honest caveat. I've laid out three mechanisms — context sorting, a maintenance-debt time bomb, an incentive artifact — and they can't all be the main one for your team. So here's the question worth sitting with: on your team, does the AI gap line up with who owns the legacy code, or with who's up for the next promotion cycle? Those point to different fixes.

If you want to actually check tonight, do three things. Add review-latency and revert-rate columns to your PR dashboard and look at last quarter. Turn on import-graph linting so agent-eroded boundaries fail the build instead of passing review. Then overlay your AI-adoption split on your CODEOWNERS and on-call rotation, and see whether the resisters are just the people holding the pager. Whichever one it turns out to be, I'd genuinely like to know.