Where an AI Coding Agent Actually Moves Your Bottleneck

Our support queue was clearing tickets in nine minutes flat, then sitting for four hours before an agent ever touched them. Same story shows up on engineering teams right now with an AI coding agent: the code gets written in minutes, then it queues. If you just swapped in an AI coding agent and throughput on your team barely moved, you haven't found a broken tool. You've found your real constraint, and it isn't where you were looking.

That's the useful way to read what's happening across engineering orgs in 2026. An AI coding agent (software that plans, writes, and often tests code changes with limited human prompting, as opposed to an autocomplete-style assistant) removes friction at the writing step. But writing was rarely the poste limitant (the limiting step, the one that dictates the throughput of the whole line) on a software pipeline. Review, CI, and deployment usually were. Speed up a non-constraint and you don't get more finished work. You get a bigger queue in front of whatever comes next.

Where did the bottleneck go after you added an AI coding agent?

Two industry datasets from 2026 point the same direction. In CircleCI's State of Software Delivery report, feature-branch throughput on the median team rose 15% year over year, but main-branch throughput, the number of changes actually reaching production, fell 7% over the same period (CircleCI, 2026 State of Software Delivery). More work entering the front of the line, less work exiting the back.

Separately, in GitLab's developer research covered by InfoQ, 85% of respondents agreed that AI has shifted the bottleneck from writing code to reviewing and validating it, and 79% said the overall delivery process hasn't kept pace with coding speed (InfoQ, AI coding outpaces governance). That's not a tooling gap. That's a constraint that moved and nobody re-measured the line.

Little's Law doesn't care that the code got written faster

Little's Law tells you why this happens, and it isn't specific to software. It's the same math behind a fulfillment center's pick queue or a hospital's discharge process:

WIP = Throughput × Cycle Time

WIP is work-in-process, everything sitting in your pipeline right now (open PRs, tickets in review, orders picked but not packed). Throughput is completed units per unit of time. Cycle Time is how long one unit takes from start to finish.

Speed up code generation without touching review capacity, and you're pushing more units per hour into a stage whose throughput hasn't changed. WIP has to go somewhere. It piles up as an open-PR backlog, a growing merge queue, or reviewers skimming diffs faster and missing more. None of those are free. A pull request sitting three extra days doesn't cost nothing, it costs context: the author has moved on, the reviewer has to re-load the whole change, and rework gets more expensive the longer it waits.

The coding step isn't the only place "AI agent" shows up now

Worth separating two things that get lumped together under "AI coding agent." Some tools are narrowly built to write and modify source code inside a repo. Others are general-purpose agents that happen to include a code-writing mode alongside research, browsing, and document generation.

Genspark is the second kind: a no-code "Super Agent" that can browse the web, generate slides or docs, and write and run code from a single prompt. That breadth is useful for a generalist, but it's a different tool for a different job than something purpose-built to live inside your CI pipeline and open pull requests against your actual codebase. Match the tool's design to the stage of your pipeline you're trying to unblock, not the other way around.

Manus goes further still, operating inside a full virtual computer (browser, terminal, file system) to plan and execute multi-step tasks end to end and hand back a finished deliverable. For an ops team, that's a useful mental model even outside code: an agent that finishes a whole unit of work, not just the fastest sub-step of it, is the one that actually moves throughput.

PCE: the one number that tells you if the agent is helping

Process Cycle Efficiency (PCE) is the ratio of value-added time to total cycle time, and it's the most honest way to check whether an AI coding agent improved your pipeline or just moved the bottleneck around:

PCE = Value-Added Time / Total Cycle Time

Before you adopt an AI coding agent, measure the current split: how much of a typical change's lifecycle, from first commit to merged in production, is actually spent writing or reviewing code, versus waiting in a queue. Most teams have never pulled this number and are surprised by it. PCE below 25% is common on software pipelines, meaning three-quarters of a change's total lifetime is waiting, not being worked on.

Run the same measurement 30 to 60 days after rollout. If PCE went up, the agent freed real capacity and your team is using it. If PCE stayed flat or dropped, the agent sped up an already-fast step and the extra output is sitting in queue, invisible until someone tallies open PRs on a Friday. This is exactly the kind of read where an AI analysis layer earns its place: it's not enough to know PCE moved, you need the verdict on which stage absorbed the difference, and that reads faster from an automated breakdown than from someone eyeballing a Kanban board.

Three signs review, not the agent, is your limiting step

A few patterns show up consistently once teams start measuring instead of assuming:

• Open PR count trends up while merge count stays flat. More units entering the line, same number exiting. Classic WIP buildup in front of an unchanged constraint.

• Average PR size grows. An AI coding agent that generates a full feature in one pass produces bigger diffs than a human typing incrementally. Bigger diffs take longer to review per PR, which shrinks reviewer throughput even if headcount and review speed per line stay constant.

• Time-to-first-review climbs faster than time-to-merge-after-approval. If the wait is mostly before someone starts looking, that's a queueing problem (not enough review capacity, or reviews aren't prioritized), not a review-quality problem.

None of these require exotic tooling to track. A weekly pull from your git host's API, plotted against the week you rolled out the agent, is enough to see the shape of the shift.

What a support queue gets right that engineering pipelines usually miss

Support and fulfillment operations have been fighting this exact problem for longer than AI coding agents have existed, and the fix generalizes cleanly. A queue that answers first-contact tickets in nine minutes but takes four hours to reach a specialist tier isn't a resourcing story about the specialists being slow. It's a signal that the fast tier is over-resourced relative to what's downstream, and that pulling more tickets into the front doesn't help until the back tier's capacity changes.

Engineering teams skip this step constantly because code review doesn't look like a queue on a dashboard the way a ticket count does. It's PRs sitting quietly in a "waiting for review" state, easy to not notice until someone asks why a two-week-old feature still hasn't shipped. Theory of Constraints (the idea that a system's overall output is capped by its single limiting step, not by the sum of every step's individual speed) says the fix is never "make the fast part faster." It's find the actual limiting step, protect its capacity, and only then decide whether the fast part needs more speed at all.

There's a second, quieter constraint that shows up a few months after an AI coding agent ships more code, faster: documentation drift. Nobody notices until a new engineer's onboarding takes twice as long because the docs describe a system that changed three sprints ago. A docs-as-code platform like GitBook, which syncs against the same repo the agent is committing to, at least keeps the paper trail from falling further behind than the code itself. It doesn't fix the review bottleneck, but it stops a second one from forming in the dark.

Should you slow down your AI coding agent on purpose?

Sometimes, yes, and that's not a popular thing to say about a tool everyone's excited about. If your review capacity is fixed for the next two quarters (headcount frozen, reviewers already at capacity), letting an agent triple the rate of incoming PRs doesn't create more finished, deployed features. It creates a longer queue and, per the CircleCI data above, a lower main-branch success rate, because reviewers under volume pressure catch less.

The honest move in that situation is to cap how much an agent generates per cycle, or gate its output behind a pre-review pass (linting, automated test coverage checks, a smaller-diff policy) before it ever reaches a human reviewer. That's not an anti-AI position. It's the same logic as not scheduling more units onto a line than your slowest station can absorb.

If the actual constraint turns out to be reviewer attention rather than reviewer headcount, workflow agents built for triage and routing, like Lindy AI handling inbox and notification overhead around a team's day, can free up real review hours without touching your codebase directly. Worth testing before assuming the fix has to be "hire more reviewers" or "buy more agent seats."

Where to actually invest next

Run the PCE calculation before you expand agent usage further, not after. If value-added time as a share of total cycle time hasn't moved since rollout, don't buy more agent seats yet. Put the next budget line into review capacity, CI throughput, or merge-queue automation instead, whichever the data points to, and re-run the number in 30 days.

If PCE did improve and review is keeping pace, that's the signal to expand the agent's scope, not before. Measure first. The teams getting real throughput gains from an AI coding agent aren't the ones who adopted it fastest. They're the ones who found their actual limiting step and fixed capacity there before letting the fast step run any faster.