Why the Software Factory Needs an Infrastructure Layer of Its Own

The software factory has always been a system: an idea becomes code, code gets built, integrated, tested, and shipped, in a sequence that repeats thousands of times a year inside any serious engineering organization. The tools that run that sequence, continuous integration and continuous delivery, version control, merge workflows, code review, were all built around the same quiet assumption: one developer, one task, one pull request at a time. A person can only think about so much at once, type so fast, and review so many lines before judgment degrades, and that ceiling on human throughput set the pace for everything downstream. CI pipelines were sized to handle the volume one engineering team could realistically generate in a day. Merge workflows assumed a queue short enough that a human could glance at it and know what was going on. Code review assumed a reviewer with the time and context to read a diff written by a colleague who shared the same calendar, the same meetings, and the same understanding of what "done" meant. None of this was built poorly. It was built correctly for the conditions it served, and for two decades those conditions barely moved. The mismatch between that tooling and the work it now has to do wasn't visible until the conditions underneath it changed, and that change arrived faster than most engineering organizations expected.

Why coding agents broke the delivery pipeline's underlying physics

AI coding tools stopped being autocomplete sometime in 2025 and 2026. They became something that plans changes across multiple files, runs the test suite, reads the failures, and keeps adjusting until CI goes green, without a human steering each step. People still sit on the loop, reviewing and approving at checkpoints, but they're no longer in the loop for every action an agent takes. That shift matters less for the obvious reason, more code getting written, than for a quieter one: agents run asynchronously, often for minutes or hours in a cloud sandbox, and a pull request comes out the other end as a direct output of that process rather than as something a human happened to produce alongside a day of meetings and debugging.

This changes the math of the delivery pipeline. A CI system has a fixed ceiling on how many pull requests it can land in a day, set by runner capacity, test suite duration, and merge conflict rates. If the arrival rate of pull requests stays below that ceiling, wait times stay short and predictable, which is the kind of queueing behavior operations research has understood for decades. Push the arrival rate past the ceiling, even by a modest multiple, and wait times do not merely creep up. A queue that cleared in minutes starts backing up by hours, because every PR waiting behind a full pipeline adds delay to every PR behind it.

Agents make this worse through a second mechanism, one specific to how they behave. A flaky test that fails one time in twenty was a mild annoyance when a human hit it, shrugged, and re-ran the job once. An agent tasked with getting a change merged doesn't shrug. It re-queues the same pull request, burns a full CI run on each attempt, and does this as many times as it takes. A single intermittent failure now consumes pipeline capacity repeatedly and delays every other change stacked behind it. The net effect: teams with high AI adoption are merging nearly twice as many pull requests as they used to. Coding agents made writing code cheaper, but they did nothing to make landing that code any cheaper, so the delivery pipeline, not the developer, becomes the limiting factor on how fast software actually ships.

Atlassian, BMW, and the merge queue wall

This isn't an abstraction. Atlassian's Jira team runs more than 800 developers who produce over 300 merges a day, and at that volume, merging code had become a genuine reliability problem, not just an inconvenience. Engineers were coordinating merges by hand, and pull requests that had each passed CI on their own still kept combining to break the main branch, a failure mode that appears only when enough changes land close together and interact in ways no single review caught. Atlassian's own account puts the semantic failure rate from this at 7 to 10 percent before the team adopted merge queues. After adopting them, failures dropped to near zero, build times fell from 40 minutes to 35, and the team set its first merge service-level objective, a formal target for how long a merge should take, something it had never had before.

What stands out across cases like this is what the fix actually was. Atlassian's CI had not run slowly, and its engineers had not been careless. The pipeline architecture itself had never been designed for the rate of change arriving at it, and no amount of process discipline, more careful coordination, stricter review norms, was going to close that gap. What closed it was infrastructure built specifically to manage a merge queue at that volume: automated conflict handling, ordered integration, and failure isolation, replacing the manual coordination that had been the actual bottleneck. The lesson generalizes beyond any one team. Once pull request arrival rates exceed what manual coordination can track, the only remedy that works is purpose-built queue management, not a better spreadsheet or a stricter chat channel.

How agentic workflows changed what infrastructure needs to manage

The merge queue is the most visible symptom, but it's not the whole problem. Agents don't behave like occasional contributors who show up, make a change, and leave. They run as recurring, scheduled, event-driven processes that persist across time, so they resemble a piece of running infrastructure more than a guest contributor. A study examining 1,248 GitHub Agentic Workflow files pulled from across many repositories found that the instructions governing these workflows function as living specifications rather than one-off prompts: most of the files sampled were still being revised months after they first went into use, and the instruction content inside them routinely covered tasks, expected outputs, constraints, and process rules in detail. So the instructions themselves need the kind of maintenance a running system needs, because if a stale assumption gets baked into a recurring workflow, it doesn't just produce one bad output, it keeps producing bad outputs on every run until someone catches and fixes it.

Code storage faces a parallel problem. Git was designed for distributed, human-paced collaboration, so when agents access that storage at machine frequency from cloud environments, they strain assumptions the design never had to account for. Cursor's response is instructive: it built a Git-based repository service called Origin, running on an internal engine called Continuity, where pushes get written into S3 as a log of immutable objects rather than handled the way a traditional Git server would. The detail that matters isn't Origin itself so much as what it signals: giving agents reliable, high-frequency access to code requires rethinking storage architecture from the ground up, not bolting cloud access onto tooling built for human commit patterns. Taken together, the asynchronous execution, the living instruction sets, and the cloud-native storage demands point to the same conclusion: agents introduce an operational surface, instructions that need upkeep, sessions that need tracking, storage that needs to perform differently, that the CI/CD and version control stacks running most software factories today were never built to manage.

Platform engineers are now managing a system their IDP was not built for

Platform engineers feel this most directly, because the internal developer platforms they built produce these effects: those platforms were designed for human workflows, and that design choice is what now fails to manage agent activity. Those platforms were designed around a human developer persona: self-service provisioning so a person could spin up what they needed without filing a ticket, documentation so a person could find answers without asking a colleague, a service catalog so a person could see what existed across the organization. None of that was built to manage an agent session, supervise an autonomous CI retry loop, or control what tools a non-human actor running at machine frequency is allowed to touch.

Spotify's Backstage platform represents how good this human-centric model got. Every service at Spotify is automatically indexed with its ownership and APIs recorded, dependencies entered by hand into the catalog, and a separate feature called Scaffolder lets an engineer spin up a new microservice, complete with CI and documentation, in about two minutes. That is a genuinely well-built platform for a human developer, and it has nothing in it that was designed to answer the question an agent now raises: what happens when the thing generating pull requests isn't a person who occasionally needs a new service, but a process that runs constantly and produces a steady stream of changes that all need to land somewhere.

The developers who sit downstream of this gap now encounter a new kind of idle time. It used to be that a developer blocked on something was blocked on thinking, waiting for an idea, a design decision, a piece of information. Now a developer can finish a change by hand, push it, and find it stuck behind a column of agent-generated pull requests, all queued against the same test suite, with no tool in the platform built to triage that queue, decide what gets priority, or clear the blockage. Platform engineers are told to raise engineering velocity by rolling out agents across their organizations, but in the same breath they get handed a coordination and observability problem that nothing in their existing stack was built to solve. The platform can provision a service in two minutes. It has no native answer for what to do when forty agents are all waiting on the same CI run.

What a purpose-built infrastructure layer for the software factory does

Closing that gap takes an infrastructure layer designed around how agents actually operate: asynchronous execution, arrival rates measured in machine time rather than human time, cloud-native access to code storage, and a design that asks for human attention only when a decision genuinely needs human judgment, not for every routine coordination step along the way.

Three things set this layer apart from a CI/CD stack that has simply been patched to cope. The first is merge coordination that runs on its own by default: the queue itself should resolve conflicts, triage CI failures, and manage its own order, bringing a human in only for the decisions that actually require one, instead of bouncing every blocked pull request back to a developer to re-trigger by hand. The second is code storage built for how agents actually use it: treating Git as an immutable log stored in the cloud, backed by fast local caches, resolves the tension between Git's original distributed design and the centralized, high-frequency access that agents now need, a tension that tooling built for human commit patterns was never asked to solve.

The third is a matter of structure rather than feature: this layer should be assembled from components that each do one job well, connected through thin integration points, rather than bought as a single platform meant to do everything. That's not a stylistic preference. Agent capabilities, security requirements, and delivery patterns are changing so fast that no single vendor's roadmap can keep up, so a monolithic platform will fall behind on some dimension no matter how well-resourced it is. Composable, API-first components let the infrastructure layer keep pace with the factory itself, instead of being capped by how fast one vendor can ship.

This layer must be built now, before the gap compounds

This gap doesn't sit still waiting to be addressed later. It grows with every agent session you add to a pipeline that still lacks dedicated infrastructure to manage it, because each new session adds to the coordination burden sitting on tooling that was already undersized for the load. The GitHub Agentic Workflows study sampled 1,248 files across 276 repositories and found workflows already deployed at real scale, actively maintained, and growing more complex over time. The operational surface this piece describes exists now, not on some future roadmap.

Organizations that treated platform engineering, strong CI/CD, real test automation, careful architectural oversight, as a foundational investment before agents arrived are the ones able to turn agent-driven speed into real, predictable output. But if they didn't, they will find that agents amplify whatever was already there, dysfunction included, just as readily as they amplify discipline. The argument that existing CI/CD and merge tooling can simply be extended to cope runs into the same wall that extending propeller engines ran into when aviation needed jet speeds: the adaptation can go so far, but it cannot close a gap that comes from the wrong underlying design assumptions. The software factory is already operating as its own distinct infrastructure category. Engineering organizations can build the layer it needs on purpose, or find out they needed one after the pipeline has already failed them.