A work order.
Written before anything runs.
The software factory, explained.
What it is, where it came from, what AI code generation changed, and how to run one.
A software factory is a production line for software.
Work arrives as a standard order, is built in isolation from other work in progress, and passes the same inspection before it ships. The same order should produce the same outcome twice.
In one sentence: a software factory turns software delivery from a series of one-off projects into a line, where every unit of work follows the same path from order to inspection to merge. The term names a way of organising the work, not a particular tool, and it is older than most of the tools now sold under it.
It matters again because coding agents made the building step cheap. When a dozen units can be built at once, the questions that decide whether the result is useful are factory questions: what goes in, how the units are kept apart, and who checks what comes out.
Four things, or it is just a queue.
One workspace per unit.
Kept apart from other work in progress.
One inspection.
The same one on every unit.
Tooling installed once.
Instead of retyped for every unit.
Where the term comes from. Three eras, one idea: make software the way a plant makes parts.
The phrase is older than the internet. It surfaced in the late 1960s, the same years the 1968 NATO conference popularised "software engineering", as a reaction to projects that ran late and over budget: if hardware could be manufactured predictably, why not the programs that ran on it?
Japan's software factories, from 1969
Hitachi opened what it called a software factory, its Software Works, in 1969. Toshiba, NEC and Fujitsu followed with their own through the 1970s; Toshiba's Fuchu software factory, opened in 1977, is the best documented. They standardised methods and tools, reused code across projects, trained staff on one process and measured everything. MIT's Michael Cusumano documented them in Japan's Software Factories (Oxford University Press, 1991), the standard history of them. His finding was that the approach worked best for families of similar systems, and depended on management and a standardised process as much as on tools.
Microsoft's Software Factories, 2004
Jack Greenfield and Keith Short of Microsoft revived the term in Software Factories (Wiley, 2004). Their version was about product lines: domain-specific languages, models, patterns and frameworks that let a team assemble a family of applications instead of hand-writing each one. Much of it shipped as Visual Studio guidance and tooling. The emphasis on reusable assets and a defined process carried over; the model-driven machinery mostly did not.
US military software factories, from 2017
The US Air Force started Kessel Run in 2017 to build and ship software in house with modern practices, and Platform One followed as a shared DevSecOps platform other teams could build on. The Army Software Factory and many other units followed. In that world, a software factory means an in-house team plus a hardened pipeline that can take code to production quickly and repeatably, which is the closest of the three eras to how the word is used now.
The AI software factory. What changed when code got cheap to produce.
Every earlier software factory was organised around a scarce resource: the people who write code. Standard methods, reuse and pipelines all existed to get more out of each engineer's hours.
Coding agents removed that constraint for a large share of everyday work. A well-specified ticket can be built by an agent in minutes, and nothing stops ten of them running at once. An AI software factory, sometimes called an agentic software factory, is the line rebuilt around that fact: agents at the building station, people at intake and review.
What did not get cheaper is everything around the build. Somebody still has to decide what is worth building and write it down precisely. Ten agents in one checkout will overwrite each other, so every unit needs its own workspace. And every unit that comes back still needs a person to read the diff and decide. The bottleneck moved from writing code to running, reviewing and shipping it, which is exactly the part a factory organises. See what vibe coding looks like on a board for the single-developer version of the same shift.
The stations of a software factory. Seven, in the order a unit meets them.
Names vary between teams, but every working line has the same stations. Skip one and the work piles up at the next.
1. Intake
Work enters as an order with a fixed shape: the outcome wanted, what done looks like, and the files or systems in scope. A request that cannot be written in that shape is not ready for the line, and the cheapest place to find that out is here, before anything runs.
2. Plan
Before a line of code, the order is turned into steps and checks: what will change, in what order, and how each claim will be verified. A plan is short and it is reviewable. Reading ten lines of plan costs a minute; reading a wrong diff costs an afternoon.
3. Isolated build
Each unit is built in its own workspace, typically its own branch and git worktree, so two units in flight never edit the same copy of the code. Isolation is what makes parallelism safe: a unit that fails can be thrown away without touching anything else.
4. Inspection
Every unit passes the same written definition of done: type checks, tests, lint, and where it matters a run of the real app or a screenshot. The point is that the inspection is identical for every unit. A check that runs only when somebody remembers it is not a station.
5. Review
A person reads what came back, the diff and the evidence from inspection, and decides: ship it, or send it back with a reason. Review is where judgement lives, and in a line with generated code it is the station that sets the pace of everything else.
6. Merge and ship
Accepted units merge into the base branch and go out through the normal release path. Because units were built apart, some will overlap at merge time; resolving that is part of the station, not an exception to it.
7. Operate and feed back
What ships is watched, and what the line learns goes back into it: a convention written down, a check added, a skill installed. This is the station that makes the next order cheaper than the last one.
Levels of autonomy. From a line run by hand to the dark factory.
There is no standard scale, so here is the one we use. Each level hands more of the line to agents.
- Level 0: hand-run. People write every line. The factory is a process: tickets, branches, checks. Many good teams already run this way.
- Level 1: assisted. Autocomplete and a chat window speed up the person typing. Still one unit at a time, at the speed of one person.
- Level 2: one agent, supervised. A coding agent builds a whole unit while a person watches the terminal and approves each step.
- Level 3: parallel agents, every unit reviewed. Many units build at once, each in isolation, and each one comes back to a person for a ship or send-back decision. This is where the line starts to look like a factory.
- Level 4: agents check agents. A second agent reviews the first one's work and only some units reach a person, sampled or by risk.
- Level 5: the dark factory. Borrowed from lights-out manufacturing: no human reads the code before it ships. Orders go in, software comes out.
How Fredrin runs the dark factory
Fredrin runs Level 5 for the teams that choose it, and it is how Fredrin itself is built: its founders no longer read the code. It is opt-in. People still decide what is worth building, and merges happen on their own only if the team wants them to.
What replaces human review is a set of checks, each one a station on the line:
- Independent AI review, and an Approver step that decides what merges.
- CI on every pull request, plus verification runs that try the change for real.
- Automatic Fix CI when a build goes red.
- Merge conflicts predicted before they land, and resolved and verified when they do.
- A merge safety score on every pull request.
The honest caveat: the risk moves from review to the checks, and a check only catches what someone thought to check for. That is what Struggles is for. It shows where Workers got stuck or were corrected, traces each one to a root problem and files the fix, so the checks get better as the line runs.
Software factory vs CI/CD, DevOps and platforms. Neighbouring terms, and where each one stops.
| Term | What it is | What it covers | Where it stops |
|---|---|---|---|
| Software factory | A production line for software, end to end | Intake, isolated builds, inspection, review, merge, feedback | Deciding what is worth building |
| CI/CD | Automation that builds, tests and deploys a change | The inspection and shipping stations | How work enters, how units in flight are kept apart, review |
| DevOps platform | A suite for source control, pipelines and operations | Repositories, pipelines, deployment, monitoring | The shape of the order and the review queue |
| Internal developer platform | Self-service infrastructure a platform team offers developers | Environments, templates, golden paths | Producing and inspecting the units themselves |
| AI factory | A data centre built to train and run AI models | Compute, models, inference | Software delivery: it makes tokens, not shipped features |
The short version: CI/CD and DevOps platforms are parts a factory is built from, an internal developer platform is the floor it stands on, and an AI factory in the data centre sense is a different thing that shares a word. A software factory is the line itself, including the stations no pipeline runs: the order and the review.
Choosing a product to run one? See software factory platforms, compared: what each one is and who it suits.
How to set up a software factory. Seven steps, starting from the backlog you already have.
- Write the order template. Decide the fields every unit of work must carry before it can start: the outcome, the definition of done, the scope. Put it where the work is tracked, not in someone's head.
- Give every unit its own workspace. One branch and one git worktree per unit, created automatically, so parallel work never shares a checkout.
- Install the tooling once. Write the project's conventions, commands and known traps into files in the repository, and package repeat procedures as agent skills, so every unit starts with the same context instead of a retyped prompt.
- Define one inspection. List the checks every unit must pass, with the exact commands, and run them on every unit with real exit codes recorded.
- Put a review station in front of the merge. Make every finished unit land in one queue with its diff and its check results, and give the reviewer two moves: ship it or send it back.
- Cap the work in flight. Start only as many units as you can review the same day. Raise the cap when the review queue stays short, not when the machine has spare capacity.
- Measure and tune the line. Track throughput, review queue, rework and lead time, and turn every repeated send-back into a new check, a written convention or a better order template.
None of these needs new infrastructure on day one. A board, git worktrees and a written list of checks will run a small line; the rest is discipline. The tooling step is the one most teams skip and most regret: it is covered in more depth in how agent skills work and in Fredrin's Brain docs.
What to measure. Run the line by its numbers, not by how busy it looks.
A factory that starts a lot of work looks productive and may not be. These are the measures that tell you whether the line is actually delivering, and where it is stuck.
- Throughput. Units merged per week. The output of the line, counted at the end of it, not at the start.
- Review queue. How many finished units are waiting for a decision, and how long the oldest has waited. When this grows, the line is producing faster than it can be inspected by a person.
- Rework rate. The share of units sent back at least once. A rising rate usually means the orders are vague or a check is missing upstream.
- Lead time. From order written to change merged. It shows where units sit idle: waiting to start, waiting on checks, or waiting on review.
- Escapes. Defects found after merge that the inspection should have caught. Each one is a candidate for a new check.
There are no universal targets for these. Measure your own line for a few weeks, then change one thing at a time and watch which number moves.
Where a factory stops helping. Three things stay yours.
A bad spec.
Comes out badly specified, faster.
Review.
Every finished unit wants a human decision.
The merge.
Isolated units still have to merge.
The common ways a software factory fails, roughly in the order teams meet them:
- Vague orders. A line multiplies whatever goes in. An unclear ticket built ten times faster is ten times more rework.
- A review pile-up. Starting more units than anyone can read moves the queue from the build station to the review station and makes lead time worse.
- Overlapping units. Isolation keeps builds apart, not their changes. Two units that touch the same files will meet at the merge, so slice orders to overlap as little as possible.
- Flaky inspection. A check that fails at random teaches people to ignore checks. Fix or remove it before adding more units.
- Context that lives in people's heads. If conventions are not written into the repository, every unit relearns them, and agents relearn them badly.
- Measuring starts instead of merges. Units in flight are inventory, not output.
Fredrin's take. Code got cheap. Deciding, isolating and checking did not.
A ticket is the order.
It gets a plan, its own branch and git worktree, and checks that land in Review with the diff. Agent skills load when a task needs one.
Fredrin is a desktop kanban board that puts you in command of the line at level 3: many lanes building in parallel, and every unit landing for your decision. Here is one ticket going through it.
- Order. You write a ticket: the outcome, and which workflow steps it should run, such as a plan first, tests, or a screenshot.
- Plan. The ticket's agent writes an implementation plan and a list of verification checks onto the ticket, where you can read it before or while it builds.
- Isolated build. The ticket gets its own branch and git worktree and its own agent session, running Claude Code or Codex on the subscription you already pay for. Other tickets build beside it at the same time.
- Inspection. Before it can finish, the run executes its checks and records the real exit codes on the ticket.
- Review. The ticket moves to the Review column with its diff and check results. You ship it or send it back with a comment.
- Feed back. Decisions and conventions are written back to project memory in your repository, for your review, so the next ticket starts knowing them.
The board shows every unit's station at a glance, which is what turns review from a hunt through terminals into a queue. Read how Workers run tickets in parallel, or see AI coding on a board and cloud agents for running the line with your laptop shut.
Questions.
What is a software factory?
A repeatable production line for software: a standard order in, isolated builds, and one written definition of done every unit passes before it ships. The term describes how the work is organised, not a specific tool.
What is an AI software factory?
A software factory where AI coding agents do most of the building. Each unit of work gets its own agent and workspace, many run in parallel, and people move to the stations that still need judgement: writing the order and reviewing what comes back.
What are some software factory examples?
Hitachi's Software Works from 1969 and Toshiba's Fuchu software factory from 1977 in Japan; Microsoft's Software Factories initiative from 2004; and US military units such as the Air Force's Kessel Run and Platform One and the Army Software Factory. Today the term also describes teams that run many AI coding agents in parallel through one review queue.
What is a dark software factory?
A line where no person reads the code before it ships, named after lights-out manufacturing plants that run without people on the floor. Agents write, check and merge the work. Fredrin runs it for the teams that opt in, and so does its own team; the risk moves from review to whatever the checks fail to catch.
Is a software factory the same as CI/CD?
No. CI/CD is one station of it, the inspection and shipping end. A factory also covers how work enters, how units in flight are kept from colliding, and who decides what ships.
What is the difference between a software factory and DevOps?
DevOps is a culture and set of practices that joins development and operations; a DevOps platform is the tooling for it. A software factory is the production line built on top: the order format, isolated builds, a fixed inspection and a review station. Most factories run on DevOps tooling.
How do you build a software factory?
Write an order template, give every unit its own branch and worktree, install project context and skills once, define one inspection with exact commands, put a review queue in front of the merge, cap work in flight to what you can review, and measure throughput, review queue, rework and lead time.
What is a DoD software factory?
In the US Department of Defense, a software factory is an in-house team and platform that builds and ships software for the military with modern DevSecOps practices. Kessel Run, Platform One and the Army Software Factory are well known examples.
What changed with AI code generation?
Producing code stopped being the constraint. Deciding what to build, keeping parallel work apart, and checking what came back are now most of the cost, which is exactly what a factory organises.
How many parallel agents can one person run?
Fewer than the machine can start. Every finished unit wants a human decision, so review attention is the limit, not compute. Start with as many as you can review the same day and raise it when the queue stays short.
Does a software factory need AI agents?
No. Real tickets, a branch per unit and the same checks on every one is already a factory, run by hand. Agents make it cheap to have many units in flight.
Is "software factory" a product name?
No. On this page it is a general term for a way of organising software delivery, not a product. Fredrin uses it that way. Fredrin is the Multiplayer Software Factory that runs the line: people decide, a Worker builds each ticket, checks run on every unit, and merges happen on their own if you want.
More terms in the glossary.