Essay 01 · AI-Native R&D · 1 of 6
The AI-Native Handoff Tax
Why buying AI tools isn't the point and what is.
Open the interactive figure
The first month with agents looks incredible. Then it doesn't.
Carnegie Mellon put numbers on why. They tracked 806 open-source repos that adopted Cursor against a matched control group (the hidden cost of AI speed, MSR 2026). Teams added 3-5x more code in the first month. Within about two months that speed was mostly gone, eaten by the debt the extra code created: +30% static-analysis warnings, +42% complexity. Their conclusion: writing code was never the bottleneck. Maintaining, reviewing, debugging, and evolving it is.
Matches what we saw. The bottleneck didn't vanish when agents got fast. It moved, to us, to the gaps between people.
Here's the mistake I watch other teams make. They treat "AI-native" as a purchasing decision: buy the agents, hand out the licenses, wait for the speed. It never comes. Being AI-native isn't about adding AI tools. It's about collapsing the distance between the person who decides what to build and the work itself. Tools that don't close that gap just grow the bill. The hard part was never the tool, it's the change management: rewiring how the team works so the tool has somewhere to land. Buy the agents without changing the workflow and you've bought a faster way to hit the same bottleneck. We've all seen the articles: a company's internal AI spend up 6x in a year, on track to burn the annual budget in a few months; another pulling its internal coding-assistant licenses when usage blew up the bill with little to show. Tools without a workflow change aren't transformation, just a bigger spend.
You'll hear this called the "AI SDLC", AI threaded through every phase instead of bolted onto coding. I'm wary of the phrase, it's mostly something people sell. But there's a real distinction under it, and it's a spectrum not a switch: AI that assists a human typing faster, versus AI that builds while humans set direction and approve. We bet on the second. The job then is designing a system where humans set direction and judge results, and agents carry the work in between.
And here's the trap that makes the label hollow. Point AI only at the coding phase and the speedup evaporates downstream, where everything is still a manual handoff. The gains only compound when agents reach past coding into review, test, and the rest. That's the whole point: the handoffs, not the code, are what's worth fixing. And it only pays off if the gaps between people don't eat the speed you just bought.
Here's what actually happens when building gets cheap. Picture an assembly line where one station suddenly runs 10x faster. The line doesn't get 10x faster. It speeds up until the next station, or the handoff between them, becomes the new limit, and half-finished work piles up in front of every slower step. Software is the same. When an agent produces a working change in the time it used to take to write the ticket, the constraint moves to the handoffs: the spec waiting on a decision, the branch waiting on a review, the PR sitting open long enough to collect merge conflicts with everything that landed while it waited. That's the handoff tax. Paying it down is what this series is about.
The lesson: a big jump in speed doesn't let you just go faster, it forces you to find the new friction points and design them out. The conflicts that pile up while PRs wait for review were our first and worst one. So we built a workflow we call PuMP (Plan, Merge, Polish) to keep work moving through review before it rots. Next couple of posts get into it.
The other shift, and the whole of the next post, is when alignment happens. We moved it off the calendar and onto the moment the work needs it.
The rest of these posts are the specific, unglamorous practices: how we align now (Post 2); how we closed the handoff between deciding and building, when our PMs and designers started shipping (Post 3); how we review when everyone ships (Post 4); where our knowledge lives so it stops rotting in people's heads (Post 5); and what's left for a manager once the system routes the work (Post 6).
First friction point we hit was alignment itself, aka meetings. That's the next post.