What a Software Factory Produces That a CI/CD Pipeline Does Not

A CI/CD pipeline moves a change that already exists from a branch to production. A software factory does something different: it governs the entire loop that produces that change in the first place, from the signal that triggered the work to the telemetry that comes back after it ships. The two get confused because they share tooling and both touch deployment, but an engineering team can have a sophisticated pipeline, green checkmarks on every pull request, and still find that delivery feels unpredictable and opaque. That gap exists because the pipeline was never built to answer the question a factory answers.

Warp's 2026 architecture guide draws this line with unusual precision. A CI/CD pipeline, in its framing, is a delivery mechanism: it automates building, testing, and deploying software that humans already wrote, and it says nothing about how that code came to exist. A software factory is something else entirely, a production model that starts with signals from the outside world, things like bug reports, new requirements, customer complaints, and manages that raw material through planning, execution, review, delivery, and monitoring. Encore's 2026 comparison makes a related point: a factory doesn't throw out CI/CD, it demotes it. The pipeline becomes one component of the deploy step, a release station inside a much larger production system, rather than the whole operation.

The confusion is understandable because both systems automate work and both end at a deployment. But the scope of responsibility is where they split. A pipeline answers one question: how do we ship this change? A factory answers three: what change should exist, how was it actually made, and what does production tell us to build next? A team that has only solved the first question has built something useful but partial, and mistaking that partial answer for the whole system is where the unpredictability creeps into teams that otherwise look well-equipped on paper.

Pipeline assumptions about code arrival under agent-driven development

CI/CD was built on two assumptions that held up reasonably well for twenty years and are now breaking under new weight. The first assumption: changes arrive one branch at a time, authored by a person who understands the codebase and is working at human speed. The second: automated tests are sufficient to confirm that a change behaves correctly. Neither assumption was unreasonable when it was written into the tooling. Both are now routinely false.

Encore's analysis of agent-driven development identifies exactly where these assumptions give way. Agents don't produce one change at a time, they produce many in parallel, and each of those changes often needs its own isolated environment with the specific infrastructure it touches, something a standard pipeline was never built to spin up on demand. Agent output also tends to need a person to confirm it behaves correctly in a running system beyond passing a test suite. A pass-or-fail test result tells you the code did what the test checked for. It says nothing about whether an agent made a reasonable decision along the way, and that's a different kind of verification than CI/CD was ever designed to provide.

Put those two breakdowns together: the pipeline's intake point turns into a chokepoint. More changes arrive than the system was ever sized to process, and the verification model built around automated tests alone wasn't designed to catch the particular class of mistakes agents tend to introduce. The data backs this up. CircleCI's 2026 State of Software Delivery found that feature-branch throughput rose 15% for the median team, while throughput on the main branch fell by 7% over the same period. Producing more code does not improve delivery if verification becomes the bottleneck, and that 7% drop on main is what happens when intake outpaces review.

DORA's 2025 research, cited by Encore, cuts even closer to the point. AI adoption continues to carry a negative relationship with software delivery stability, even as throughput turned positive in 2025 for the first time. DORA's research also found that a high-quality platform amplifies whatever effect AI adoption has, for better or worse, because AI adoption magnifies the dynamic already running in the system rather than introducing a new one. A team that bolts agents onto a pipeline-only setup doesn't get a factory out of the deal. It gets a faster, louder version of whatever the pipeline already was, fragility included.

The four things a software factory produces that a pipeline cannot

A software factory generates four things a pipeline has no mechanism to produce: standardized inputs, feedback that originates the next cycle of work, per-change context that can be reconstructed after the fact, and measurable throughput across the entire loop, not just the deployment step. Each is a genuine output, something the factory hands forward to the next stage of work, distinct from a feature sitting on a vendor's spec sheet.

Standardized inputs come first, and Overcut's September 2026 piece states the underlying principle as sharply as it's been stated anywhere: a factory is what you get when the output of one stage becomes a legitimate input to the next without a human copying anything between them by hand. A toolbox, no matter how well-stocked, is not a factory. A pipeline has no intake logic of its own, it receives a commit and acts on it, and the work of shaping that commit into something well-formed, scoped, and ready to build happens somewhere outside the pipeline entirely, usually by a person doing it manually.

Feedback that originates the next cycle is the second output. Factory.ai's 2026 guide describes a continuous loop: monitoring shipped software produces signals, bug reports, customer conversations, usage data, and those signals become the next round of planned changes, which get built, tested, reviewed, and shipped, whose monitoring in turn produces the signals after that. A pipeline runs in one direction only. It ends at deployment and has nothing to say about what happens next. A factory closes that loop so production telemetry becomes a signal that originates new work, not an afterthought someone checks when something breaks. Warp's architecture piece names the specific metrics this closed loop reports on a per-pipeline basis rather than estimating after the fact: deployment frequency, lead time for changes, change failure rate, and failed deployment recovery time, the four DORA metrics.

Per-change context that can be reconstructed is the third output, and it depends on what Warp calls observability and replayability. The factory records inputs, prompts, model versions, tool calls, and outputs, so that any shipped change can be reconstructed after the fact. That trace serves two purposes at once: it's the audit trail, and it's the input to the loop that improves the factory's own performance over time. Factory.ai is specific about what replayability actually requires: the inputs, the prompts, the model versions, and the policies in force at the time, all of which its audit and monitoring model and its OpenTelemetry export are built to guarantee. A pipeline logs pass or fail. A factory retains enough to replay the entire run, and that difference becomes critical the moment an agent-produced change causes an incident and the team needs to understand not just what shipped, but how it got made.

Measurable throughput across the whole loop is the fourth output. Overcut frames the distinction cleanly: a team that uses AI heavily is now a common thing to find. A team that has an actual factory is one that can answer what happened on any given run, not just whether the run succeeded. Throughput in a factory is bounded by how fast the team can define intent, review traces, and approve releases, not by how many engineers are available to type code, and that shift makes measuring progress harder than counting pipeline velocity ever was. Agent-effectiveness metrics, the time an agent spends generating a patch against the time a person spends correcting and reviewing it, are a factory-level measurement with no real analogue anywhere in pipeline tooling.

Why parallel agent output makes the merge queue load-bearing

When agents produce changes in parallel, the merge queue shifts from a convenience that smooths out messy timing to the factory's primary mechanism for controlling flow. Most teams are still running a queue that was designed for a world where pull requests arrived at human pace, a few per day from a small group of engineers, and that design doesn't hold once the arrival rate multiplies.

Graphite's 2026 analysis lays out the mechanics in detail. GitHub's native merge queue works by creating temporary gh-readonly-queue/ branches and expects workflows to respond to a merge_group event. GitHub Actions workflows need that event trigger set explicitly, and third-party CI systems have to be configured to react to pushes against the gh-readonly-queue/ prefix. Miss either piece of configuration and queued pull requests just sit there until the check timeout ejects them one at a time, a failure mode that's invisible until the queue backs up and someone asks why nothing is merging.

Graphite's stack-aware queue addresses a structural gap the native queue doesn't touch. When a stack of pull requests is enqueued together, the system can run CI for the entire stack in parallel and fast-forward merge all of them in one pass once every one of them is verified, rather than serializing them one by one. Asana, using Graphite, reported shipping 21% more code as a direct result of that change.

The factory framing explains why queue design carries this much weight. The merge queue is the specific point where the factory enforces policy about what's allowed to reach main, not just a tool for serializing commits so they don't collide, which makes it the natural meeting point for agent-driven flow control and human escalation to coexist. Get the queue wrong and every other factory output, the standardized inputs, the feedback loop, the replayable trace, backs up behind it.

What an agent's session transcript reveals beyond test results

An agent's session transcript functions as the factory's production log. It doesn't just record whether the output passed, it records how the agent arrived at that output, and that record is the only real basis for improving agent performance in a systematic way rather than guessing at it after each incident.

There's a genuine design tension in how a factory handles these transcripts. Dump the entire session history into the model's context on every run, and costs climb while the model drowns in noise it doesn't need. Rely only on summarized versions, and the detail that got dropped from the summary has a way of becoming tomorrow's critical bug. A factory operating at this level has to navigate that tradeoff on purpose, not by default settings someone picked once and never revisited.

Warp's architecture guide frames the transcript as part of a self-improvement loop. The trace serves as both the audit record and the input to the evaluations that shape the factory's next cycle of work, and agents, in this framing, need feedback loops more than they need perfectly engineered prompts. A bloated set of tools and skills available to an agent hurts its performance, so removing the skills nobody uses matters as much as adding new ones when the goal is better output. There's no way to know which skills to remove without actually reading the transcripts where they got used, or ignored.

A test result answers one question: was the output correct? A transcript answers several more: did the agent take a reasonable path to that output, did it use the right tools along the way, did it avoid the failure modes that will eventually produce a wrong answer even when this particular run happened to land correctly? Those are different questions, and a factory that only tracks test results is blind to everything the transcript would have shown it.

Machine legibility in the platform underneath the factory

A platform built for human developers will quietly undermine a software factory, because it was never designed to answer the questions an agent needs answered before it can act safely on its own.

Warp's guide names the test directly: a factory needs the platform road ahead of it to be machine-legible, and that requirement raises questions a platform team never had to answer when every consumer of the platform was a person logging in with their own credentials. What identity does an agent authenticate as? Who is accountable for what that agent does with the credentials it's been given? A human developer's access controls assume a person who can be asked, after the fact, why they did something. An agent needs that accountability designed into the system in advance, because there's no equivalent moment of asking afterward that resolves anything.

The factory-readiness test for any given platform component comes down to three questions. Can a machine read the interface it exposes and act on it without a person translating it first? Does it enforce policy without requiring a human to sit in the approval path for every action? Does it produce a record that the factory's observability layer can actually consume, the same kind of record that feeds the replayable trace and the transcript review described earlier? A platform that fails any one of those three questions will work fine for human developers and quietly break the factory built on top of it, and the break won't appear as an error message. The break appears as the fragility that CircleCI's data and DORA's research both describe: more code moving through the system, and less stability in what finally reaches production.