Writing the Code Got Cheap. Landing It Did Not. What a Fleet of Coding Agents Actually Costs to Run

When Did Agent Fleets Stop Being a Demo?

For most of 2025 the parallel-agent conversation was a thought experiment illustrated with screenshots. In 2026 it acquired numbers, and the numbers came from companies whose engineering blogs are not usually in the business of overselling.

Stripe published the details of Minions, its one-shot end-to-end coding agents, which take a ticket or a Slack message and return a finished pull request with no human writing a line of the implementation. The disclosed volume was over a thousand merged pull requests per week at first publication and above 1,300 by the follow-up post. Ramp built its own background-agent harness and reported agents behind roughly 30% of merged pull requests in its main repositories early in the year, a share that later passed half.

The broader adoption picture is less dramatic but points the same way. Aggregated 2026 enterprise surveys put roughly half of organisations with engineering teams running at least one coding agent in production, with agents credited as author or pair-author on a rising share of merged pull requests. Compilations of those data points also show the familiar gap between experimentation and scale: many organisations have agents running, far fewer have them running in a way anyone would call governed.

What is worth noticing in the Stripe write-up is where the engineering effort actually went. The model is not the interesting part, and Stripe says so plainly. The interesting part is a fork of an open-source agent wrapped in layers of internal infrastructure: a central tool server exposing hundreds of internal capabilities, pre-warmed isolated environments, blueprints for common task shapes, and a CI path designed for machine-generated changes. The agent is a component. The harness is the product.

That distinction is the whole subject of this article. Every team can now generate more code than it could a year ago. Almost no team has correspondingly increased its capacity to review, integrate, test and operate that code. The fleet does not fail because the agents are bad. It fails at the seam where parallel output meets a serial trunk.

Where Did the Bottleneck Actually Move?

LinearB's 2026 benchmarks are the most useful public dataset on this, because the sample is large enough to be boring: 8.1 million pull requests across roughly 4,800 organisations in 42 countries. The headline findings are not about code generation at all. They are about queueing.

Agentic pull requests waited about 1,055 minutes before a reviewer picked them up, against roughly 201 minutes for unassisted work, a 5.3x difference. Teams with high AI adoption merged 98% more pull requests while review time rose 91%, and organisation-level productivity improvement landed in the region of 10%. The acceptance data is equally instructive: a minority of AI-generated pull requests cleared review without modification, against a large majority of human-written ones.

Read those numbers together and the mechanism is obvious. Pull request arrival rate went up sharply. Reviewer service rate did not. Anyone who has looked at a queueing model knows what happens next, and it is not linear: as utilisation approaches capacity, waiting time climbs steeply, so a queue that used to add ten minutes starts adding hours without any individual step becoming slower. The CI is the same CI. The reviewers are the same reviewers. The system is simply operating past the point where added arrivals are absorbed.

This is where a lot of 2026 AI-productivity reporting goes wrong. Sprint-level throughput metrics look excellent, because they measure the part that got faster. The number that matters is time from first commit to production, and that number is governed by the slowest serial stage, which is now human judgment applied to a queue that tripled in length.

It also explains a pattern engineering leaders keep reporting anecdotally: the fastest-adopting teams often show the least improvement in delivery. They did not adopt wrong. They removed a constraint that was not binding and left the binding one untouched.

What Does Parallelism Cost You at Merge Time?

The second cost of running agents in parallel is integration, and it now has empirical grounding. The AgenticFlict study assembled over 142,000 agent-authored pull requests from more than 59,000 repositories, replayed roughly 107,000 of them through deterministic merge simulation, and found merge conflicts in 27.67% of cases, spanning more than 336,000 distinct conflict regions.

More than one in four agent pull requests conflicting is a very different operating environment from the one most branching strategies were designed for. The paper also records meaningful variation between agents, with conflict rates for some harnesses roughly half those of others, which means the choice of agent and the way tasks are scoped both move the number. A companion line of research on the frequency and structure of agent pull requests on GitHub points at the same lever: larger diffs interfere more with concurrent work and conflict more often.

The mechanics are unsurprising once you say them out loud. Four agents working from four task specs against the same trunk each branch from the same commit, work for twenty minutes to two hours, and arrive at a trunk that has moved. If the task specs overlap in the files they touch, the merge order decides which implementation survives, and the loser is not always the worse one. Agents are also poor at noticing that they are now solving a problem someone else already solved forty minutes ago, because their context was captured at branch time.

The teams handling this well have converged on a small set of practices, none of them exotic. Task specs are written to be disjoint at the file and module level, not just conceptually distinct. Diffs are capped, because change size is the strongest single predictor of conflict. Work is stacked rather than fanned out where changes genuinely depend on each other. Agents run in separate git worktrees so they cannot corrupt each other's state, and there is an explicit integration order: first branch to finish merges, the rest rebase before they complete rather than after.

The organisational point underneath the tooling is that someone has to own the decomposition. Splitting a feature into three or four specs that will not collide is a senior design activity performed before any agent starts, and it is exactly the work that gets skipped when a team is measured on how many agents it has running.

What Does One Sandbox Per Agent Cost?

Parallel agents need parallel environments. Each concurrent agent wants its own filesystem, its own dependency tree, its own test database and its own ability to run the suite without another agent's half-finished migration in the way. That requirement multiplies your development infrastructure by the number of agents you intend to run, and it is where most in-house fleet projects discover they have started a platform engineering programme.

Stripe's answer was pre-warmed instances holding a full copy of the monorepo with services and build caches already loaded, giving a cold start around ten seconds. That is a deliberate engineering investment, and the guidance that came out of the background agents summit in May 2026, drawing on Stripe, Ramp, Spotify and Uber, frames the decision honestly: virtual machines, containers or lightweight sandboxes, traded off on compatibility, startup latency and whether you keep environments warm or destroy them after every run. Warm is fast and expensive. Cold is cheap and slow, and slow matters more than teams expect once a human is waiting on the result.

Then there is inference. Vantage's April 2026 cost analysis priced a typical 50-turn agentic session at roughly $6.00 on a frontier model against $0.60 on a cheaper coding-tuned model, with input tokens accounting for around 85% of spend at a 25:1 input-to-output ratio. Scaled to a 25-person team running about a thousand sessions a month, that is roughly $72,000 a year versus $7,200. The same analysis notes that agentic sessions ran around 200 times more expensive per session than the team's non-agentic usage, despite being a fraction of the count.

CI is the third line item and the one most likely to surprise a CFO, because it scales with pull requests rather than with engineers. If agents double your merged PR count and triple your opened PR count, your pipeline minutes, ephemeral environments and artefact storage move accordingly, and they move whether or not the extra pull requests were any good.

The metric that makes all of this legible is cost per merged pull request, split by author type. Teams that instrument it usually find their agent fleet is cheaper than they feared on inference and considerably more expensive than they expected on everything else, and that a meaningful share of the total is being spent on pull requests that were eventually closed unmerged.

How Many Agents Can One Engineer Actually Run?

The most useful operational number to come out of 2026 practice is a ratio, and it is smaller than the marketing implies. Teams running fleets seriously report settling around two to four agents per engineer, working on deliberately disjoint task specs, with the ceiling set by review capacity rather than by compute.

One published account describes five engineers running four agent fleets with ten to twenty concurrent implementation streams in steady state, under an explicit rule: each engineer's scope is sized so they can genuinely review every line their agents merge. When output outran that, the cap was enforced rather than raised, and quality held. The division of labour is stated cleanly: humans own boundaries, intent and verification, agents own implementation inside bounded contexts, and the two meet at machine-checkable contracts.

This is the part that most orchestration tooling cannot solve for you. Above roughly ten agents a flat supervisor structure stops working, because the orchestrator's own context fills with status rather than substance, and teams start building tiers of supervising agents. That works technically and does nothing for the human at the end of the chain, who still has to accept accountability for the merge. Adding a supervising agent does not add review capacity, it adds distance.

Two consequences follow for team design. First, the useful unit of scaling is the reviewing engineer, not the agent seat, so a budget that funds tool licences without funding senior capacity buys nothing. Second, ownership has to be narrow enough for the review to be real. An engineer who owns one bounded context can review four agents inside it. The same engineer spread across four services cannot review anything properly and will start approving on vibes, which is how you end up with the comprehension problems that surface six months later.

Why Does the Fleet Make Senior Engineers Scarcer?

The uncomfortable staffing conclusion is that the fleet increases demand for exactly the people who were already hardest to hire. Every capability the model above depends on is senior: decomposing work into non-colliding specs, designing the contracts that let bounded contexts integrate continuously, reviewing machine-generated code at volume without losing attention, and deciding when a plausible-looking diff is architecturally wrong.

There is also a subtler cost hiding inside the review queue statistics, and it is one nearshore buyers should read carefully. Pull request pickup time is, mechanically, a function of working-hours overlap. An agent finishes a pull request at 14:00 in Belgrade. If the engineer who owns that context is online, pickup is measured in minutes. If that engineer's working day starts nine hours later, the pull request ages overnight, the trunk moves under it, and the conflict probability rises with every hour it sits. The queue and the timezone gap compound each other, which is why the same fleet configuration produces very different cycle times depending on where the reviewers sit.

This is the practical argument for building agent-era teams inside a shared working day rather than around one. A dedicated development team in Serbia overlaps the full European business day and roughly half the US East Coast one, which means agent output produced in the morning is reviewed the same morning rather than the next. The point is not that the engineers are cheaper, although they are. It is that latency in the review loop is now a first-order delivery metric, and distributing a fleet across a nine-hour gap taxes it directly.

The second argument is capacity shape. Most organisations do not need a larger headcount to run a fleet, they need a denser one: a small number of engineers senior enough to own a bounded context and review everything that lands in it. That is the shape senior-led nearshore engagements are good at supplying, and the opposite of the volume model that offshore delivery was optimised around. StepTo staffs named senior engineers onto client contexts rather than rotating people through a shared bench, which matters more than it used to when the whole model depends on one person having enough continuity of context to review agent output credibly.

The third piece is the platform work itself. Isolated environments per agent, pre-warmed images, CI paths tuned for machine-generated changes and cost attribution per agent are platform and DevOps engineering, not application work, and they compete directly with the product roadmap for the same people. It is a well-defined, boundable programme, which makes it one of the more sensible things to hand to an external team while your own engineers stay on the product.

What Should You Instrument Before Scaling the Fleet?

Most fleet programmes are evaluated on the wrong number, which is how many pull requests the agents produced. Here is the set that actually tells you whether the fleet is helping, and all of it is derivable from your git host and CI provider without buying anything.

Start with PR pickup time split by author type. If agent pull requests are waiting materially longer than human ones, you have a queue problem and adding agents will make it worse. Track merge conflict rate and rebase count per pull request next, again split by author, because that is your integration tax and the direct feedback signal on whether your task decomposition is producing genuinely disjoint work.

Then measure the share of agent pull requests merged without modification, and the share closed unmerged. The first tells you whether the specs are good enough; the second is pure waste, and it is usually larger than teams expect. Add revert and hotfix rate within seven days of merge, which is the honest check on whether review is real or ceremonial at current volume.

On the cost side, track CI minutes per merged pull request and total cost per merged pull request including inference, environments and pipeline. That last figure is the one to put in front of a CFO, because it converts the entire conversation from adoption theatre into a unit economic that can be compared against the previous year.

Finally, keep watching cycle time from first commit to production as the headline. If PR throughput doubles and cycle time does not move, the fleet has bought you nothing except a longer queue and a bigger bill, and the fix is on the review and integration side rather than the generation side.

Where Should a Ninety-Day Plan Actually Start?

Weeks one to three: measure the current system. Pull the seven metrics above for the last two quarters and establish the baseline before any fleet exists. Most teams discover at this stage that their review queue was already the constraint and that the AI tools they rolled out last year made it worse in a way nobody attributed correctly.

Weeks four to six: fix the trunk before you scale the arrivals. Cap pull request size, enforce a rebase-before-merge order, adopt worktree isolation so parallel work cannot share state, and make the test suite fast and reliable enough that a machine-generated change can be verified without a human reading every line first. This is the least glamorous part of the programme and the part that determines whether everything after it works.

Weeks seven to nine: run one bounded context with a hard cap. Pick a service with a clear owner, give that owner two to four agents, and write task specs that are disjoint at the file level. Enforce the cap when output outruns review rather than raising it. Instrument cost per merged pull request from day one, and expect the first month to look worse than the baseline while the spec-writing skill develops.

Weeks ten to twelve: decide on evidence. Compare cycle time, conflict rate, unmodified merge share and cost per merged pull request against the baseline. If the numbers hold, expand to a second bounded context, which will move faster because the isolation infrastructure, the CI path and the spec conventions already exist. If they do not hold, the answer is almost never more agents, it is either better decomposition or more review capacity, and the metrics will tell you which.

Where this runs into trouble in practice is staffing, because the plan requires senior engineers to write specs, review at volume and own contexts, and platform engineers to build the isolation and cost attribution, all while the product roadmap continues. That is the gap a senior augmentation engagement is genuinely well suited to, and the reason it is worth scoping the platform work as its own deliverable with its own owner rather than as something the application team will get to.