In The Bottleneck Flipped, @darrillaga named something we'd all been feeling: the constraint moved from the AI to the human. The models got fast. We didn't keep up. That piece was about the human side — planning, context drift, the ability to stay ahead of the machine.

This piece is about the other side. The infrastructure between the code and production. The delivery pipeline.

Absorption rate

Every delivery pipeline has a property that nobody names but everyone feels: its absorption rate — how fast it can take in a change and turn it into running production code. From PR open to production. The full path.

Most teams don't think about absorption rate because they've never had to. When humans write code, the production rate is low enough that the pipeline absorbs everything without strain. CI takes 20 minutes? Fine — a developer pushes two, maybe three times a day. Code review takes hours? That's okay — there are only a few PRs open at a time. Deploys are batched and manual? Reasonable — changes accumulate at a human pace.

None of these decisions were wrong. They were rational tradeoffs for a world where the production rate never exceeded the absorption rate. Build queues didn't back up because there wasn't enough throughput to create contention. Review bottlenecks were manageable because the volume was manageable. Sequential deploys worked because the cadence was slow enough that sequential was fine.

AI changed the production rate. The absorption rate didn't change with it.

A Tuesday afternoon

I can point to the moment this became concrete for us.

Three agents were running in parallel. One was implementing webhook verification for our Jira integration. Another was adding filtering logic to the session list API. A third was fixing an edge case in devcontainer port forwarding. Normal workday. The kind of Tuesday that used to take a week.

By 2pm, three PRs were open. CI picked up the first one. Eighteen minutes later, it passed. But by then, PR two and three were queued behind it. PR two started its run. Eighteen more minutes. It passed — but now PR one had been reviewed and merged, and PR three had a merge conflict on a shared type in @crunchloop/dap-events. The agent rebased, pushed again. Another eighteen-minute CI run.

By 4pm, we had shipped one of the three features. Not because the code was wrong. Not because review found issues. Because the pipeline could only absorb changes at the rate it was designed for — and that rate assumed one developer, working sequentially, pushing a few times a day.

The agents produced three days of output in an afternoon. The pipeline absorbed one day's worth. The other two days sat in queue, waiting for a system that was never built for this throughput.

That afternoon cost us nothing dramatic. But multiply it by every day, every team, every sprint — and you start to see the real cost of AI-driven development. Not the AI. The pipe it ships through.

The constraint moves

After that Tuesday, the instinct was to fix CI. Make it faster. And we did — we rewrote the pipeline from 289 lines to 123, collapsed redundant jobs, leaned harder on Turborepo's dependency-aware caching. The eighteen minutes came down. The queue pressure eased.

For about a week.

Then the bottleneck moved to review. PRs were building and testing faster, but they still sat waiting for a human to look at them. We started using automated review tools for routine changes — lint-clean, type-safe, test-passing PRs that didn't touch architectural boundaries. That freed human review time for the PRs that actually needed judgment.

Then the bottleneck moved to merge conflicts. More PRs merging faster meant more contention on shared files. Then to deployment — our CD pipeline assumed a cadence of a few merges per day, not a dozen. Each stage we accelerated revealed the next constraint.

This is the theory of constraints applied to software delivery, and it's not new. What's new is the forcing function. At human production rates, most pipelines had enough slack that bottlenecks were tolerable — they existed but rarely bit. At AI production rates, the slack evaporates. Every inefficiency that was hidden by low throughput becomes visible, and blocking.

The question changes from "which stage is slow?" to "can any stage in this pipeline keep up with the production rate?" That's a systems question, not a point optimization.

Judgment vs. logistics

I don't want to oversimplify this into "automate everything." That's not the point, and it's not what we're doing. The point is: every human touch in the pipeline needs to justify its presence when the production rate is 10x what it used to be.

Some human involvement is essential. Architectural decisions, product judgment, security review on sensitive paths — these require reasoning that no automated check can replace. The goal isn't to remove humans. It's to ensure that humans in the loop are doing judgment work, not logistics.

The rest — the waiting, the manual approvals on routine changes, the review of code that's already been validated by automated checks — is not safety. It's not quality. It's latency with a name tag that says "process."

We've been pulling on this thread systematically. Each piece builds on the others, and each will get its own entry:

Automated code review — handling routine PRs so human review goes where it matters. CI pipeline optimization — cutting the feedback loop so the queue doesn't become the bottleneck. Event-driven flows — removing the human wait between stages: merge triggers build, build triggers deploy, deploy triggers verification. Auto-merge — the question @darrillaga raised: if every quality gate passes, what is the human click actually adding?

What matters here is that these pieces are interdependent. Automated review without fast CI just means the review finishes quickly and then waits. Fast CI without automated review means the build is ready but the review queue grows. Event-driven deploys without either mean you're deploying faster into a pipeline that's still jammed upstream. You don't get to optimize one stage. The absorption rate is set by the full path.

Measure before you optimize

If this resonates, here's the diagnostic. Pick your last twenty PRs. For each one, measure four timestamps: PR opened, CI completed, review approved, merged to production. Then look at where the time actually sits.

Most teams assume CI is their bottleneck. Often it's not. Often the longest segment is the gap between CI completing and a human starting review. Or the gap between review approval and merge. Or the gap between merge and deploy. The constraint is rarely where you think it is — because you've never measured the full path at the granularity that matters.

That measurement is your absorption rate. Production rate minus absorption rate is the speed you're leaving on the table. At human pace, the delta was small enough to ignore. At AI pace, it's the whole story.

What we know and what we don't

Know:

The delivery pipeline is the binding constraint on AI-driven development speed, not the model
Pipeline stages designed for human pace become bottlenecks at AI pace
Point optimization doesn't work — the constraint moves to the next stage
Automated quality gates can handle routine validation that humans currently do manually

Don't know:

Where the right boundary is between automated and human review — we have instincts, not proof
Whether auto-merge at scale creates risk we haven't encountered yet at our current volume
How far event-driven automation can go before the complexity of the event system itself becomes the problem
What monitoring and observability need to look like when the deployment rate is 10x the current baseline

The sharp edge

The industry spent two years making AI write code faster. Better models, better prompts, bigger context windows, better tool use. That work mattered.

But it optimized the production rate without touching the absorption rate. And the output of the system was never set by how fast you produce. It's set by how fast you can absorb.

Every team running AI agents today has a delivery pipeline that encodes an assumption about how fast code arrives. That assumption is now wrong. And until the pipeline changes, the AI isn't slow. It's waiting. For a review that takes three hours. For a CI queue that's three deep. For a deploy that happens when someone remembers to trigger it.

The speed is real. You just can't ship it yet.