Software factory: what it is and how to run one in 2027

In short: a software factory is the system that turns a steady stream of work requests into tested, shipped software with AI agents doing most of the production work. It combines an intake queue, shared context, sandboxes where agents run, automated checks, human review gates, delivery and monitoring into one repeatable line. The agent is one machine on that line. The factory is the whole line, and the people who run it.

This guide explains what a software factory is, where the term comes from (it means four different things depending on who you ask), how a modern factory is built layer by layer, how one change moves through it, who runs it, what it costs, how to measure it, and a realistic path to running one in 2027. It also covers when a factory is overkill.

It is written for founders, CTOs and engineering leads at companies with roughly 5 to 50 engineers who already use coding agents and want to move from "a few people with Claude Code or Cursor" to a reliable production system. Almost every page that ranks for this topic today is written by a vendor that sells one layer of the factory. This one is not.

‍

Key takeaways

• A software factory is a repeatable system for producing software: standard inputs, standard tooling, automated checks, human gates and measured output. In 2026 the production work inside it is increasingly done by AI agents.

• The agent is not the factory. Most of the work is in the parts around it: specs going in, sandboxes, verification, review, delivery and learning from mistakes.

• Throughput moves the bottleneck. When agents write code in parallel, review queues and CI pipelines become the constraint. OpenAI reported some CI systems taking roughly 10 times the load within about six months.

• You run a factory with metrics, not vibes: the four DORA metrics plus agent-specific ones such as acceptance rate, intervention rate, review queue time and cost per merged change.

• Build it in three stages. Crawl with one agent and full review, walk with parallel agents and a managed queue, and only run with auto-merge on proven low-risk work.

• Most small teams should not build a full factory. A focused version on one repository and one class of work gets most of the gain.

‍

What is a software factory?

A software factory is a managed system for producing software with repeatable inputs, standardised tooling and measurable output, where each step from request to release is defined, automated where possible and checked by a gate. In its 2026 form, AI coding agents do most of the execution: they turn specifications into code, tests and pull requests, while people define what gets built, set the rules and approve what ships.

The useful comparison is a physical factory. A factory is not a single machine. It is the layout, the supply of materials, the quality checks, the people who supervise and the process for improving the line over time. A team where each developer runs an AI agent on their laptop has machines. A software factory has a production line.

That distinction matters because it is where most of the effort goes. Warp's guide to software factory architecture describes the foundations as orchestration, feedback loops and centralised environments, with agents as the execution layer on top. In other words, the agent is the part you buy. The factory is the part you build.

‍

The four meanings of "software factory"

The term is older than AI agents, and search results mix its meanings. It helps to know which one someone means before you compare advice.

The first meaning comes from industry. In the late 1960s and 1970s, companies such as Hitachi set up "software works" that applied manufacturing discipline to programming: standard processes, reusable components and quality control. Michael Cusumano documented the Japanese approach in his 1991 book Japan's Software Factories, and Factory's history of the concept traces it back to Robert Bemer at General Electric. The idea was reuse and repeatability, decades before AI.

The second meaning is the defence one. From around 2017, the US Air Force and Department of Defense set up "software factories" such as Kessel Run and Platform One: in-house DevSecOps teams with standard pipelines, approved tooling and pre-cleared environments so software could ship to the military faster. Even there the label has shifted. In an October 2026 interview, Kessel Run's leadership said it is no longer a software factory in that sense and has moved to a government-led, vendor-managed model.

The third meaning is common in the Netherlands and Belgium: a "softwarefabriek" built on low-code platforms, where business applications are assembled from configurable building blocks rather than written by hand. Useful, but a different subject.

The fourth meaning, and the one that dominates search results in 2026, is the agentic software factory: a production system in which fleets of AI coding agents do the building and humans set intent, policy and the final checks. That is what this guide covers. It keeps the original idea of repeatable, quality-controlled production and swaps the workers on the line.

‍

Software factory vs SDLC, CI/CD, DevOps and platform engineering

A software factory overlaps with several familiar terms. The short version is that each of them is a part of the factory, and none of them is the whole thing.

• The SDLC is the process: the phases every change goes through, from plan to release. The factory is the system that runs that process many times in parallel. We explain how each phase changes with AI in our guide to the AI SDLC.

• CI/CD is the pipeline that builds, tests and deploys a change. In a factory it becomes the independent quality check on agent work, and it has to handle far more volume.

• DevOps is the culture and practice of shared ownership between development and operations. A factory assumes it.

• Platform engineering builds the internal developer platform: the paved roads, environments and self-service tools engineers use. Gartner expected 80% of large software engineering organisations to have platform engineering teams by 2026. In a factory, that platform is what agents run on too.

So a factory is what you get when the platform, the pipeline and the process are designed for agents as first-class workers, with intake at one end, people at the gates and measurement throughout.

‍

How a software factory is built: the 8 layers

A working software factory has eight layers. You do not need all of them at full strength on day one, but you need a minimum version of each, because a factory is only as fast as its weakest layer.

‍

‍

1. Intake

Work enters as tickets, bug reports, alerts or requests and is turned into a clear specification before any agent starts. This is where most quality is won or lost. A vague ticket produces a confident, wrong pull request. Minimum version: a short spec template that every task must fill in, with acceptance criteria and what is out of scope.

2. Context

Agents need to know how your codebase works: architecture, conventions, which patterns to use and which never to touch. This lives in rule files in the repository, documentation and a knowledge base of past decisions. Minimum version: one well-maintained rules file per repository that is updated whenever review catches a mistake.

3. Execution sandbox

Agents run in isolated environments with their own copy of the code, limited permissions and no access to secrets or production data. Isolation is what makes it safe to run several agents in parallel. Minimum version: containers or cloud dev environments that an agent can spin up and throw away.

4. Agent runtime and models

This is the layer most people think of first: the coding agents themselves and the models behind them. Tools in this space include Claude Code, OpenAI Codex, GitHub's Copilot coding agent, Cursor, Devin and Factory's Droids. GitHub's Agent HQ lets agents from several vendors run inside one control panel. Minimum version: one agent the team knows well, with the ability to swap models without rebuilding everything else.

5. Verification

Automated checks run on every change before a person looks at it: tests, type checks, linting, security and dependency scans, and any project-specific rules. In a factory, CI stops being a convenience and becomes the independent judge of agent output. Minimum version: a test suite that covers the code agents will touch, and failure messages an agent can read and act on.

6. Review gate

A human reviews each change against its spec and decides whether it merges. This is now the most expensive step on the line and the one most likely to become a queue. Minimum version: a named reviewer of record for every change, and a rule that pull requests stay small.

7. Delivery

Approved changes move to production through the same safety practices as before: staged rollouts, feature flags, monitoring and quick rollback. Minimum version: automated deployment with a one-step rollback.

8. Observability and learning

The factory records what each agent did, why, and how it turned out, so runs can be replayed and failures traced. Mistakes caught in review are turned into rules, evaluations and better specs. This is the layer that makes the factory improve instead of repeating the same errors. Minimum version: a weekly review of agent failures that ends with updated rules.

‍

One change through the factory, end to end

A concrete example makes the layers easier to picture. Say a customer reports that exports fail for accounts with more than 10,000 records.

The report lands in the intake queue. A person, or an agent with a person approving, turns it into a spec: the failing behaviour, the expected result, a test that reproduces it, and a note that the export format must not change. An agent picks up the spec in a fresh sandbox, reads the repository rules, finds the cause (a timeout on a single large query), writes a fix that pages through the data, adds the reproduction test and opens a small pull request.

CI runs the full test suite, the security scan and the performance check. Everything passes. The reviewer of record reads the change against the spec, spots that the page size is hard-coded, and asks for it to come from configuration. The agent updates the pull request within minutes. The reviewer approves, the change ships behind a flag to 10% of accounts, monitoring stays clean, and it rolls out to everyone the next morning.

Two things happen afterwards that make it a factory and not just a fast fix. The run is logged so anyone can see what the agent did and why. And the review comment becomes a rule: "limits and page sizes come from configuration, never constants". The next agent that touches similar code will not make that mistake.

Now picture the failure path. If the spec had been vague ("fix exports"), the agent might have rewritten the export format, the tests would still pass, and the reviewer would face a large, confusing diff. That is why intake and review, not the agent, decide how good the factory is.

‍

If your team needs a starting point for the intake layer, our free AI product requirements template gives you a spec format agents can work from, with acceptance criteria and out-of-scope rules built in.

‍

What changes when agents work in parallel

A factory's promise is throughput: many agents working on many changes at once. That moves the bottleneck in ways teams often do not expect.

Review becomes the queue. When ten agents can each open a pull request in an hour, the limit is how many changes people can read carefully. Teams that ignore this either merge without proper review or watch the queue grow.

CI becomes the next constraint. In a report on how OpenAI runs its own agentic software factory, the Pragmatic Engineer described some CI systems taking roughly 10 times the load in about six months. CircleCI's 2026 delivery data points the same way: for a typical team, activity on feature branches rose about 15% while throughput on the main branch fell almost 7%. More code was produced; less of it reached production.

Agents also keep getting more capable. METR found in 2025 that the length of tasks AI agents can complete has doubled roughly every seven months. That is good news for the factory and a warning for the gates: bigger tasks mean bigger changes to review, so scoping work into small pieces matters more every year, not less.

‍

How to run a software factory: people and rituals

A factory needs fewer people writing code by hand and more people running the line. In a small company these are hats, not job titles, but someone has to wear each one.

• Factory owner: owns the whole system, its metrics and its improvement. Usually the CTO or a senior engineer.

• Spec writers: product people and engineers who turn requests into clear specifications. No work in the factory has a bigger effect on quality.

• Reviewers of record: senior engineers accountable for each change that merges. One name per change, never "the team".

• Platform owner: keeps sandboxes, CI capacity, permissions and deployment healthy as agent volume grows.

Three rituals keep it working. A daily look at the queue: what is waiting for spec, review or a decision. A weekly failure review: every agent mistake that review caught, turned into a rule, a test or a better template. And a monthly look at the scorecard and the bill, to decide which class of work the factory takes on next.

‍

How to measure a software factory

You cannot run a factory without a scorecard. Start with the four DORA metrics and add the ones that only exist when agents do the work.

• Lead time from approved spec to production.

• Deployment frequency.

• Change failure rate.

• Time to restore service.

• Acceptance rate: the share of agent pull requests that merge with no or minor changes.

• Intervention rate: how often a person has to take over a task.

• Review queue time: how long changes wait for a human.

• Rework rate: merged changes that need fixing within two weeks.

• Cost per merged change: tool and model spend plus human review time, divided by changes shipped.

The research gives a reason to measure rather than assume. Google's 2025 DORA report found 90% of respondents using AI at work and over 80% reporting higher productivity, yet 30% have little or no trust in AI-generated code. The factories that work are the ones that can show with numbers where that trust is earned.

‍

What a software factory costs

The tools are the cheap part. Seat plans for coding agents and model usage typically run from tens to a few hundred euros per engineer per month, and parallel background agents add usage costs on top. The expensive parts are review time, CI capacity and the engineering work to build the intake, sandbox and learning layers.

The best single number to track is cost per merged change. A worked example with simple assumptions: a team of 6 engineers costs about €600 per engineer-day in the Netherlands. In a month the factory ships 120 changes. Each change needs on average 1.5 hours of spec work and 1 hour of review, which is 300 hours, or about €22,500. Tools, models and extra CI add, say, €3,000. That is roughly €213 per merged change.

Compare that with your current cost per change before the factory, and with the rework rate after it. If cost per change drops and rework stays flat, the factory is working. If cost per change drops but rework climbs, you have moved cost into next month's bug fixing.

‍

Build, buy or partner?

No single product is a software factory, so the real choice is which layers you assemble yourself and which you buy or bring in.

Buy the commodity layers: coding agents, model access, CI, sandboxes and deployment tooling. These are improving faster than any small team could build them, and you want to be able to swap them as the market moves.

Build the layers that are specific to you: intake templates, rule files, review standards, evaluations and the learning loop. That is where your knowledge of your product and customers lives, and it is what makes your factory better than a competitor using the same agents.

Partner when you need the factory running before you can hire the people to run it, or when you want a senior team to set up the line and train your engineers to operate it. We cover how agents coordinate and how much freedom to give them in our guides to AI agent orchestration and AI agent autonomy.

‍

The path to running a software factory in 2027

Do not try to build the whole factory at once. Teams that succeed move through three stages and only advance when the metrics say they are ready.

‍

‍

Crawl, for the next one to three months: one repository, one class of work, one agent. Every change starts from a written spec and gets full human review. The goal is to build the rules file, the test coverage and the baseline metrics. Move on when acceptance rate is stable and review keeps up.

Walk, through the first half of 2027: a managed intake queue, several agents working in parallel sandboxes, CI sized for the extra load, and a named reviewer for every change. Track cost per merged change and rework every month. Move on when review queue time and change failure rate stay under control for a full quarter.

Run, from the second half of 2027 for most teams: agents handle well-defined classes of work end to end, such as dependency updates, small bug fixes and test coverage, and low-risk changes can merge automatically under policy. People focus on specs, architecture and high-risk review. Every run is logged and can be replayed. Only automate merging for a class of work once its change failure rate has proven low over time.

‍

Where software factories go wrong

The failure modes are predictable, which means they are avoidable.

• The dark factory too early. Engineer Addy Osmani describes a "dark factory" as one where code ships that no human has read. It can work for narrow, well-tested tasks. Applied broadly, it creates comprehension debt: a codebase nobody on the team understands.

• Throughput without capacity. More agents and the same reviewers and CI produce a longer queue, not faster delivery.

• Agent actions, not just agent code. An agent that can install packages, call APIs or change infrastructure can do damage before any code review happens. Restrict actions in the sandbox, not only in review.

• Scope creep inside a change. Agents happily fix three extra things while solving one. Small specs and strict review against the spec stop this.

• No learning loop. Without turning mistakes into rules, the factory repeats them at scale.

For European teams, add two more checks: the data-processing terms of every AI vendor under the GDPR, and documented AI literacy training for the people using agents, which the EU AI Act has required since February 2025. We cover these guardrails in more detail in our AI SDLC guide.

‍

When you do not need a software factory

A factory is an investment, and for many teams a lighter setup is the better choice.

• You have fewer than about five engineers and one product: a well-run AI SDLC with good specs and review gets most of the benefit without the extra layers.

• Your work is mostly discovery: if you do not yet know what to build, throughput is not your problem.

• Your codebase has little test coverage: build the tests first, or the factory will produce changes nobody can verify.

• Your changes are safety-critical or heavily regulated in ways that require formal traceability agent workflows do not yet provide.

A good test: if your backlog is full of well-understood, repetitive work and your senior people spend their days on it, a factory will pay off. If your hard problems are deciding what to build, it will not.

‍

How we run our own factory at Codelevate

We build client software and our own products on factory principles, so this is practice, not theory. Work starts as a written spec, agents build in isolated environments, automated checks run before anyone reviews, a named person approves every change against the spec, and a person decides each release.

Our website builds are a good example of a small factory line. Four specialised agents run in sequence: one turns a design or brief into a precise build spec, one checks every value against the client's design system before anything is built, one builds, and one audits the result and returns a pass or a numbered list of failures. Two of those steps are hard gates. When review catches a mistake, it becomes a rule in the project's knowledge base, and every agent reads those rules before its next task. The same mistake should only ever happen once.

The lesson we keep relearning is that the agents are the easy part. The factory is the specs, the gates and the memory. Those are what make the output trustworthy enough to ship.

‍

The bottom line

A software factory is a production line for software, and in 2026 the workers on that line are increasingly AI agents. The agent is the part you can buy. The factory is the part you build: intake that produces clear specs, sandboxes that make parallel work safe, verification and review gates that keep quality up, and a learning loop that makes the line better every week. Start small, measure cost per merged change and rework from the first month, and only take people out of the loop where the numbers prove it is safe. That is how a team of 10 can ship like a team of 30 in 2027 without losing control of its own code.

‍

‍

Free download: our AI product requirements template gives your intake layer a spec format agents work well from. If you want a software factory running on your own backlog, we can set up the first line with your team, run it alongside you, and train your engineers to operate it. Book a call with Nicko to see what that would look like for you, or read how a dedicated product team from Codelevate works.