Software delivery is slow because the constraint moved

Software delivery slows down for reasons that sit around the code rather than in it: work batched too large to move, validation that arrives too late to be cheap, tooling that changes faster than teams can absorb it, and plans that drift from what gets delivered. In 2026 those four explain most of the gap between how fast code is written and how fast it ships, and faster coding makes all four worse.

None of the four shows up if you only watch how fast engineers code. They show up in the rest of the software delivery system, from scoping through release, which is where this page looks. One exception before starting: if your stage data says the slowdown sits in code review specifically, the cycle time diagnosis is the better place to begin; what follows covers everything upstream and around it.

The default diagnosis of slow delivery is that engineers aren't producing enough, so the fix is more engineers or faster tools. That diagnosis was weak before AI and is wrong after it. Rob Zuber, CTO of CircleCI, describes the shift that broke it:

"I feel like the job of engineering right now is building the tools that build things more than it is building the things, right? Like that's the big shift that we're making."

— Rob Zuber, CTO of CircleCI, on Dev Interrupted, Why the traditional pull request has a target on its back

When generation is no longer the slow part, adding generation capacity does nothing for delivery. The constraint is somewhere else, and the four places below are where it usually is.

The fastest way to slow delivery is to ship in big pieces. Large changes wait longer at every handoff, get reviewed more shallowly, and fail in ways that are harder to isolate. AI makes big pieces cheap to produce. LinearB's 2026 benchmarks put AI-assisted pull requests at roughly two and a half times the size of unassisted ones at the 75th percentile, above the 300-line threshold a reviewer can hold in their head.

Zuber's point is that the old remedy, break it into small PRs, doesn't survive contact with agent-scale output either:

"Taking a 2,000 line PR and breaking it up into 10 lines at a time is nonsense, right? And then tack on your standard PR delay, which you'll get out of your numbers, right? Like why would we do that to ourselves?"

— Rob Zuber, CTO of CircleCI, on Dev Interrupted, Why the traditional pull request has a target on its back

So batch size has to be managed at the planning stage, before the work exists, by scoping what an agent or an engineer is asked to produce in one unit. Once the 2,000-line change is open, every option for moving it is slow.

Delivery is slow when the first serious check on a change happens at the end of the pipeline. A test that fails after a change is written, reviewed and queued for deploy costs a full loop back to the start. The same test run inside the authoring loop costs seconds.

Zuber's team moved validation into the agent's working loop for exactly this reason, in cycles of thirty to sixty seconds rather than at the merge gate. The principle generalizes past any product: the earlier a change is validated, the fewer stages it travels through before being sent back.

There's a second trap inside this one. When agents write the tests, the tests tend to pass by construction:

"Agents love to stub everything out, right? To mock everything so you're not actually testing any of the business logic or any of the interaction with other systems or whatever. And it's like, cool, everything passes 'cause its goal is to get to green."

— Rob Zuber, CTO of CircleCI, on Dev Interrupted, Why the traditional pull request has a target on its back

Green pipelines that don't validate anything move the failure to production, which is the slowest place to find it. Validating the validation (whether a broken change would be caught) is part of the delivery problem now, not a separate quality problem.

The third cause is self-inflicted. Organizations trying to move faster adopt new tools and techniques weekly, and the cost of each change lands on engineers who were trying to ship something.

"Not for everyone every day cannot be try this new tool, try this new tool. Now we've changed the way that we're gonna do this and we've changed the way that we're gonna do this. It's like great, by the time I get updated on today's stack, it's time to go home and then tomorrow learn tomorrow's stack."

— Rob Zuber, CTO of CircleCI, on Dev Interrupted, Why the traditional pull request has a target on its back

CircleCI's answer is to pick a small number of changes that pay off across the whole team, watch the outliers who've found something that works, and distribute what works as defaults (skills, templates) that engineers inherit without having to learn them. Delivery speed depends on most of the team spending most of its time delivering, and a stack that changes daily guarantees it doesn't.

The fourth cause is the one leadership feels first. Sprints and quarters commit to a set of work, and a shrinking share of it ships on time, because the volume of activity has gone up while the volume of finished, deployed work hasn't. The symptom is planning accuracy falling even as PR counts rise.

Dan Lines, LinearB's co-founder and COO, describes what that looks like from the inside:

"My planning accuracy in my sprints are decreasing. I'm not actually doing what I say I'm gonna do. It's not, uh, stories aren't getting completed. Bugs aren't getting fixed. I'm not actually providing value back to the business. I'm just messing around with AI and doing a bunch of volume stuff."

— Dan Lines, co-founder and COO of LinearB, on Dev Interrupted, Stop measuring AI adoption. Start measuring AI impact.

Planning accuracy, the share of committed work completed in the period, is the delivery metric that catches this, and it's the one to watch alongside cycle time. A team can have an acceptable cycle time on the work it finishes and still be slow, because the work it finishes isn't the work it committed to.

If your stage-level data shows pickup or review time carrying most of the slowdown, this framework isn't the first place to look; the review-stage diagnosis is, and it's covered in the cycle time spoke. And if the organization hasn't adopted AI coding tools in a meaningful way, causes one and three mostly don't apply yet; batch size and planning drift remain, and they were slowing delivery long before 2026.

Why is our software delivery slow even though developers are faster with AI?

Because generation stopped being the constraint. Delivery slows in the stages around coding: large batches, validation that arrives too late, tool churn, and plans that no longer match what ships.

What's the first metric to look at for slow delivery?

Break cycle time into its stages to see where work waits, then check planning accuracy to see whether what ships is what was committed. The two together separate a speed problem from a focus problem.

Does breaking PRs into smaller pieces still help?

Yes, but it has to happen at scoping time. Splitting a 2,000-line agent-generated change after the fact costs more than it saves; scoping the task so the change is small to begin with is the version that works.