Software Factory: What Changes When AI Agents Run the Delivery Pipeline
Most engineering organizations now have agents in several places at once. One completes code in the editor, one comments on pull requests, one triages incoming bugs, and two or three more run as scripts somebody wrote on a Friday afternoon. Each piece works. What has not changed much is how long a real change takes to get from a request to something running in production, or how sure anyone feels about that change when it lands. The agents got faster. The path between them stayed manual.
That gap is what the term software factory has attached itself to. It is an old phrase being reused for a new problem, and the reuse is mostly earned. What an organization builds around its agents now matters more than which agents it picked.
Key Takeaways
- A software factory is a production system for software delivery: standardized inputs, a defined path from signal to shipped change, automated quality gates, and telemetry on the whole run. Adding agents to a team without that structure gets you faster local work and the same delivery time.
- The term dates to the late 1960s and has been reinvented roughly every fifteen years. Every earlier version industrialized the process around the coding step. The agentic software factory is the first one to put a machine inside the step itself.
- The factory is a layer above coding agents, CI/CD, and platform engineering rather than a replacement for any of them. It originates and routes work; CI/CD still validates it; the internal platform still provides the paved road.
- Before widening agent-run delivery, get honest about verification capacity, blast radius, per-change cost, and the baseline you are measuring against. DORA found AI amplifies whatever your delivery system already is, good or bad.
- Overcut sits at the orchestration layer of this model. If you are past single-agent experiments and need multiple specialized agents coordinated across the lifecycle with organization-level policy and human approval gates, that is the problem we build for.
What Is a Software Factory
A software factory is a delivery system that turns a defined input into a shipped, verified change through a repeatable path, with quality control built into the path rather than bolted on at the end. The parts that make it a factory are the standardization and the instrumentation, not the automation. A collection of AI tools that each save an engineer twenty minutes is a toolbox. A factory is what you get when the output of one stage is a legitimate input to the next without a human copying anything between them, and when you can answer what happened on any given run.
In the agentic version, AI agents perform the work inside the stages: planning, implementation, test authoring, review, security checks. Humans define the intent going in and approve what comes out. That framing is consistent across the vendors staking out the category. Factory.ai describes an agent-native end-to-end system running as a continuous loop from signal to production and back. TrueFoundry's guide to the agentic software factory puts the emphasis on what sits underneath the agents: model supply, credential handling, quality control, telemetry, and spend metering. We would argue that lower layer is the actual product. Agents are increasingly commodity. The system that decides which agent gets which task, what it is allowed to touch, and who signs off is not.
An ai software factory and a team that uses AI heavily are different things. The second is common now. DORA's 2025 report put AI adoption among software professionals at 90%, roughly two hours a day. Very few of those teams have a delivery system that a change can traverse without a person shepherding it through each handoff.
Where the Software Factory Idea Came From
Robert Bemer was writing about software factories at General Electric in 1968. Hitachi opened the first real one in 1969, the Hitachi Software Works, a building where software was produced under statistical quality control with defect rates tracked per thousand lines of code. System Development Corporation ran its own experiment in 1975, and NEC, Toshiba, and Fujitsu followed within two years. Michael Cusumano documented the whole period in Japan's Software Factories in 1991. Microsoft revived the term in 2004 with the Software Factories book, aimed at model-driven development and code generation from domain-specific languages. The US Department of Defense revived it again around 2017 with Kessel Run and later Platform One, where a software factory means a managed environment with a paved pipeline and a continuous authority to operate, so teams inherit accreditation instead of relitigating it per project.
Four revivals, one constant. Every one of them industrialized the work surrounding the coding step: requirements, standards, tooling, pipelines, compliance. The coding step stayed human. That was the assumption the whole structure was built around, and it is the assumption that broke.
What the agentic software factory changes is where the labor sits. When an agent can produce a working change, the constraint moves off production and onto verification and governance. You stop optimizing for how quickly a change can be written and start optimizing for how quickly a change can be trusted. Most delivery systems in use today were designed under the old constraint, which is why bolting agents onto them produces a pile of pull requests nobody has time to review.
How a Software Factory Differs From Coding Agents, CI/CD, and Platform Engineering
The term gets used loosely enough to blur three different things.
Coding agents. An agent is a worker inside the factory, not the factory. It takes a task and produces a change. It does not decide which work is worth doing, route it to the right specialist, hold policy about what may touch production, or carry context from the incident that triggered the work to the review that approves the fix. Buying more agents does not produce a factory any more than hiring more contractors produces an assembly line.
CI/CD. Your pipeline validates a change that already exists and has already been proposed by someone. It has no opinion about where work comes from and no role before the commit. The factory covers the part CI/CD deliberately leaves out: intake, specification, assignment, and the coordination among agents in between. A working software factory triggers your existing pipelines and reads their results rather than replacing them. If a platform requires you to rebuild CI/CD around it, that is a red flag about the platform.
Platform engineering. This is the closest neighbor to the factory and the easiest to confuse with it. Platform engineering builds a paved road for human developers, optimized for discoverability and ergonomics. A factory needs that road to be machine-legible, which raises questions the platform team never had to answer. What identity does an agent authenticate as, and who is accountable for what it does with those credentials? What is the spend limit per run, and what happens when a task loops? How do you enforce a policy against something that does not read documentation? The honest version is that platform engineering is a prerequisite for the software factory model, and the factory makes every weakness in the platform expensive.
How Work Moves Through a Software Factory
Follow one bug report through the system.
A signal arrives, from a customer ticket, an alert, a security scan, or a product decision. In a factory this is a trigger, not a notification for someone to read later. It is normalized into a work item with enough structure for a machine to act on, which usually means an agent drafts a specification and a human confirms or edits the intent. That step is doing more work than it looks like it is: everything downstream inherits the quality of the spec.
An orchestrator then decomposes the item and assigns pieces to specialized agents. Implementation happens through a single coordinated write path, which is the pattern that has held up in production, while review, test, and security agents work alongside it with their own fresh context. Fresh context is the point. A reviewing agent that did not write the code and is not carrying the author's assumptions catches things the author cannot see about itself.
The change then enters the pipeline you already run. Tests, static analysis, and policy checks execute against a real diff, and failures route back to the responsible agent rather than to a person's inbox. Only after that does a human gate appear, and the human is looking at a change that has already survived several layers of machine scrutiny, so their attention goes to judgment calls rather than typos. After deployment, telemetry flows back into the factory, where the next signal starts the loop again. We have written more about that loop and the layer that runs it in the agentic software development lifecycle.
Getting the agents without the orchestration has its own failure mode. Multiple autonomous agents acting on the same codebase with no shared view of each other produce a specific kind of mess we have called agentic chaos: every agent behaving correctly on its own terms, the system as a whole behaving badly.
What to Evaluate Before Scaling a Software Factory
The pilot always looks good. Scaling is where the model gets tested, and there are a handful of questions worth answering before you widen the aperture.
Verification capacity. If agents produce four times the changes and your review capacity is flat, you have moved the bottleneck rather than removed it, and you have moved it to the stage where mistakes are caught. Plan the review side of the factory before you scale the production side.
Blast radius. For each class of work, what is the worst outcome of an agent being confidently wrong, and is that outcome recoverable? Documentation and dependency bumps are cheap to get wrong. Schema migrations and auth changes are not. Autonomy should be granted per class of work, not per team.
Enforcement location. Policy that lives in a prompt is a suggestion. Controls hold when they are enforced at an infrastructure boundary the agent cannot route around, which means credential scope, network policy, and branch protection rather than instructions in a system message.
Unit economics. Agent runs cost money per attempt, including the attempts that fail. Most organizations discover their per-change cost only after the invoice. Meter spend per workflow before you scale, not after.
Your baseline. This is the one most teams skip. METR ran a randomized trial in 2025 with sixteen experienced open source developers across 246 tasks and found they were 19% slower with AI tools available, while believing they had been 20% faster. Whatever you think you are gaining, self-reported estimates are not evidence. DORA's finding is the useful frame: AI acts as an amplifier of the delivery system that already exists. Strong systems get stronger and weak ones get worse faster.
We are not going to pretend the industry has clean numbers here. The 3x to 5x productivity figures circulating in consulting reports are practitioner estimates, not controlled measurement, and we would treat them as directional at best.
Where the Software Factory Model Is Heading
The adoption signals are real, and they are more specific than the headline claims. Spotify has merged over 1,500 agent-generated pull requests since early 2025 by building agents into the fleet management system it already had, with reported time savings of 60% to 90% on migration work. Those PRs still go through normal review. DORA's 2025 data showed AI adoption newly correlating with higher delivery throughput, reversing the prior year's finding, which suggests the surrounding practices are catching up to the tooling.
Accountability is the least settled question in practice: organizations have policies saying a human owns every merged change, and review queues that make that ownership partly ceremonial. Nobody has a good answer yet for what meaningful review looks like at ten times the volume, and "another agent reviews it" only moves the question. Standards are consolidating faster than expected, with the Model Context Protocol becoming the default way agents reach tools, which is quietly making the factory portable across vendors. And spend metering is becoming a first-class engineering concern rather than a finance problem, because the cost of a change is now a variable you can accidentally multiply.
Our own bet is on the orchestration layer. Models will keep improving and will keep converging in capability. The part that stays hard is running many specialized agents across a real lifecycle, inside an organization's existing GitHub and Jira and CI, with policies that hold and humans on the gates that matter. That is the layer we build, and we think it is where the durable value in the software factory model sits.
FAQs
Does adopting the software factory model mean replacing existing developer tools?
No. A factory layers over the repository, issue tracker, and CI/CD you already run, triggering existing pipelines and reading their results. What is genuinely new is the orchestration, policy, and observability layer above them. A vendor requiring you to migrate off your current stack is selling replacement, not a factory.
How much of the SDLC can realistically run inside a software factory today?
Well-scoped, high-volume, verifiable work runs end to end now: migrations, dependency upgrades, test backfill, lint and type cleanups, small bug fixes. Novel architecture, ambiguous product decisions, and anything with unclear correctness criteria still needs a person driving. Coverage tends to expand by work class, not by percentage.
Who is accountable when an agent inside a software factory ships a defect?
The human who approved the merge, and the team that owns the service. That is the only model regulators and security teams accept, and it holds only if approval stays meaningful. If review volume has made approvals a formality, you have accountability on paper and none in practice, which is a signal to slow the factory down.
What metrics show whether a software factory is working?
Watch end-to-end lead time from signal to production, change failure rate, and rework rate on agent-authored changes. Add cost per merged change and the share of agent PRs merged without human edits. Volume of generated pull requests measures activity, not delivery, and rewards the wrong behavior if you target it.
