How Many Software Factories Are Running Inside a Single Engineering Org

When an engineering leader looks at a dashboard today, they see too many queues, too many alerts, and not enough of a story connecting them. PRs pile up in one place while a platform ticket sits untouched in another, and nobody can quite explain why a change that should take an hour takes three days. The organization is running several software factories at once, each with its own cadence, its own toolchain, and its own way of breaking down work, and the gap between them, not the slowness of any single one, is where speed actually goes to die.

The factory comparison holds up because each layer genuinely behaves like one: it has its own operators, its own rate of incoming work, its own rate of processing that work, and its own failure patterns. An org that treats the whole engineering org as a single pipeline will get the diagnosis wrong nearly every time, because the thing that is actually jammed is rarely the thing throwing the alert. Gartner's September 2026 market overview describes enterprise AI coding agents as autonomous or semiautonomous systems that find and use relevant context, turn human intent into multistep plans, and carry those plans through execution and verification across code, tests, and related engineering artifacts. That kind of sustained, cross-layer execution has multiplied the number of active factories running inside a single org: agents aren't just writing code anymore, they're generating work that moves through review, CI, merge, and provisioning, often without a human touching it in between.

What ties these factories together is that each one's output becomes the next one's raw material. Agent sessions produce PRs. PRs produce CI jobs. CI jobs produce merge events. The platform layer provisions the environment for everyone downstream, and merge events update it. Because these layers are chained, a jam anywhere stalls the layer upstream of it and starves the layer downstream of it. Understanding this chain, factory by factory, is the only way to find out where velocity is actually being lost.

The agentic coding layer: the factory that generates everything upstream

The agentic coding layer sits at the top of the funnel. Its job is to generate the raw material, branches, PRs, test results, diffs, that every other layer in the org has to process. Before anything can be merged, reviewed, or deployed, it has to be produced, and that production now happens at a volume and speed no human-only team could match.

Two distinct modes of work run inside this layer, and they behave like two different production lines. In synchronous mode, a developer stays in the loop while the agent edits code, asks clarifying questions, and runs commands inside an IDE or terminal, the pattern supported by tools like Claude Code, Cursor Agent, JetBrains Junie, Kiro, and Tabnine Agent. The output of that second mode is a branch or a PR that sits waiting for a human to review it later, on the human's schedule, not the agent's.

These two modes don't take turns inside an org, they run side by side, often on the same codebase, operated by different teams with different habits and different expectations about turnaround time. One team might have agents constantly proposing small, synchronous edits while a developer watches. Another might have a queue of asynchronous agents chewing through a backlog overnight, each one arriving at the merge layer with its own PR, on its own schedule. Each mode has its own arrival rate at the systems downstream, and that difference in rhythm is precisely what the next layer has to absorb.

A third pattern layers specialization on top of both: multi-agent pipelines that chain a Planner, an Architect, an Implementer, a Tester, and a Reviewer in sequence, mirroring how a real engineering team divides labor. Rather than producing a single PR, a pipeline like this produces a chain of artifacts, each one feeding the next agent in line before the chain ever reaches a human.

None of this amounts to agents running unsupervised. A Stack Overflow pulse survey found that most respondents still rarely or never let agents run on full autopilot, most blocked agents from making unapproved system changes, and most preferred a single, predictable agent over a complex multi-agent setup. The operating model that is actually in place across most orgs is delegated engineering with controls built in, not an assembly line running without anyone watching it.

The merge and CI layer: where the factory jams when the top of funnel accelerates

Agentic coding has made writing code the cheapest part of shipping software. It has done nothing to make landing that code any cheaper, and the merge-and-validation layer is now the tightest constraint in the entire system.

The math behind that constraint is structural. A merge queue running on a fixed CI cycle time has a hard ceiling on how many PRs it can land in a day, set by how long each validation run takes and how many can run at once. As the rate of incoming PRs, pushed up by agents working in parallel, climbs toward that ceiling, wait times don't rise gently with it. They spike, because a queue running near capacity behaves nothing like one running at half capacity: small increases in arrival rate produce large increases in wait time once a system gets close to its limit.

Agents make this worse in a specific way that human workflows never did. A human who hits a flaky test failure usually pauses, checks a log, maybe pings someone. An agent instructed to land a PR will often just retry, re-queuing the same change on the same flaky failure and burning a full CI run each time it does. Every one of those retries re-triggers the same cascade of delay for every PR sitting behind it in the queue. A retry habit that was mildly wasteful at human frequency becomes something close to a denial-of-service attack on the pipeline at agent frequency.

Atlassian's experience on the Jira team shows what this looks like at scale: with more than 800 developers and more than 300 merges a day, the act of merging itself was producing a meaningful rate of semantic failures and a weekly cycle of firefighting. After the team adopted merge queues, failures dropped to near zero, build times fell, and the team set its first formal merge SLO, a reflection of the fact that merge had to be managed as its own system with its own capacity planning, not treated as an afterthought bolted onto CI.

BMW's own published data tells a similar story from a different angle. Hundreds of changes merge daily across BMW's merge pipelines, and PRs there sit through substantial waiting time before processing even begins, on top of significant processing time once it does. BMW's own account of the data describes this as a real opportunity for optimization, especially during business hours, when developers are sitting idle waiting on a result that CI hasn't delivered yet.

Context compaction, the question of how much history and surrounding code an agent can carry forward through a long session without losing track of what it's doing, has become a design problem engineering teams now have to plan for directly rather than treat as a side effect of tooling choices. And the diagnostic most teams underuse at this layer is simply reading what happened inside a session. Anthropic's own guidance on evaluations states that production monitoring catches problems that synthetic evals miss entirely, and that an eval score shouldn't be trusted at face value until someone actually reads through the transcripts behind it. Without that kind of transcript analysis, a team has no way to tell which skills its agents are actually using, which ones are dead weight, or where sessions are quietly failing in ways that aggregate metrics never catch.

The platform engineering layer: the factory that provisions the environment all others run on

The platform engineering layer sits underneath both the coding layer and the merge layer, and it provisions the environment everything else runs on. Its failures are usually invisible until something above it breaks, at which point the cause turns out to trace back to a provisioning decision nobody was watching.

This layer's growth is not a minor trend. Gartner projects that 80% of large software engineering organizations will have established platform engineering teams as internal providers of reusable services, components, and tools for application delivery, up from 45% in 2022. So a minority practice has become close to standard operating procedure in under half a decade.

The monolithic internal developer platform, the single tool meant to do everything for every team, has failed to hold up for most organizations attempting it. What has taken its place by 2026 is a composable model: assembling a platform out of best-of-breed components connected by thin integration layers, rather than buying one system that tries to own the entire experience. The pattern that has emerged as canonical pairs a developer-facing front door, a catalog, documentation, and a self-service interface, with a declarative control plane for cloud infrastructure and an orchestration layer that composes work across clusters and providers. Delivered this way, as modular, independently deployable, API-first building blocks, a team can swap one compliant tool for another without triggering cascading changes across the rest of the stack. The platform can be repaved piece by piece as the ecosystem around it evolves.

None of this is a universal prescription. If a team spreads a meaningful developer headcount across multiple teams or services, internal developer platforms create real value. Below that threshold, the fixed overhead of standing up a platform engineering practice often costs more than it returns, and a well-configured CI/CD pipeline does the job better.

Code storage itself has become part of this layer's substrate, and agent-scale workloads are straining it in new ways. A new tier of infrastructure has emerged specifically to hold machine-generated artifacts, agent memory files, and design artifacts that change at a rate and volume human-first version control was never built to handle. GitOps has become the standard operating model for this new tier of infrastructure: the full state of infrastructure and applications is declared in code, stored in version control, and reconciled continuously by automated agents. Version control under this model is an active participant in the factory loop, read from and written to continuously by the same agents producing work upstream.

Where the factories collide

The real problem in a multi-factory org is rarely inefficiency inside any single layer. It's what happens at the seams between layers, where one factory's output arrives faster than the next factory can absorb it, or where a failure in one layer propagates in both directions at once.

The theory of constraints explains this with precision. When a single developer can direct several agents working in parallel, the volume of PRs produced stops tracking headcount, it tracks however many agents that developer chooses to run. Merge throughput, meanwhile, tracks something far more rigid: how many candidate states of the main branch the CI layer can actually validate in an hour. One side of that equation scales with a decision; the other scales with fixed infrastructure capacity. That mismatch is the entire story.

Orgs running these factories in parallel consistently hit three collision patterns. The first is a volume collision: the agentic coding layer produces PRs faster than the merge layer can process them, wait times compound, agents retry on flaky failures, and the queue saturates under its own weight. The second is a governance collision: the platform layer sets policies, permissions, environment constraints, approval gates, that agents encounter as opaque blockers rather than as structured signals they can act on, producing session failures that look like the agent failed at its task when the actual cause is a mismatch with the infrastructure around it. The third collision runs in the other direction entirely: a slowdown at the merge layer backs up into the coding layer, where agents sit on completed work waiting for a queue slot, consuming session budget and context window on waiting.

The common assumption, that all three of these factories can be managed under one engineering org given enough platform maturity, undersells how different they actually are. Each layer was built around different operators, different tooling assumptions, and different feedback loops: the coding layer optimizes for agent throughput, the merge layer optimizes for validated correctness per hour, the platform layer optimizes for safe, repeatable provisioning. Stitching these together after the fact, once each has already calcified around its own assumptions, is slower and more fragile than designing for how they interact from the outset.

Managing parallel factories as a coherent system

Accepting that an engineering org runs several factories at once changes what gets measured and where effort goes to fix it. Instead of tracking a single velocity number, each layer needs its own capacity measure, agent sessions produced per day, PRs validated per hour, environments provisioned per week, so that a slowdown can be traced to the layer actually responsible for it rather than blamed on whichever team happens to be most visible.

It also means treating the boundaries between layers as part of the system to design, not as places where one team's responsibility conveniently ends and another's begins. Atlassian built a merge queue with a published SLO after adopting merge queues on the Jira team, giving the coding layer a real number to plan against. A platform layer built from modular, API-first components gives the coding and merge layers a stable, inspectable set of constraints to work against instead of an opaque system that fails without explanation. And a practice of reading agent transcripts, not just dashboards, closes the gap between what a session's metrics claim happened and what the agent actually did inside it.

None of this removes the need for human judgment at the decision points that matter: approving a plan before code gets written, reviewing a PR before it merges, deciding whether a low-risk fix can ship on its own or needs a second look. What changes is the shape of the system those decisions sit inside. An org that understands it is running several factories, not one, can tell which factory is actually behind schedule, and can build the connective infrastructure, merge SLOs, composable platforms, transcript-level visibility, that keeps a jam in one from quietly becoming a jam in all three.