What is a software factory?

A repeatable production line for software: work enters as a standard order, moves through fixed stations, is built in isolation from other work in progress, and passes a written definition of done before it ships. The emphasis is on the system rather than the individual build — the same order should produce the same outcome twice.

Is a software factory the same as CI/CD?

CI/CD is one station of it — the inspection — and it is the station most teams already have. A factory also covers how work enters, how units are kept from colliding while they are built, and what a reviewer is handed when the work comes back. A pipeline with no intake discipline is a very good inspector for a queue nobody specified.

Does this only make sense for a team?

It is most valuable to one person, which is the opposite of what the word suggests. A team has reviewers, a standup and a shared sense of what is in flight; one person running a dozen agents has none of that and needs the system to supply it. The smaller the human side, the more the line has to carry.

What changed with AI code generation?

The constraint moved. Generating a plausible implementation is now fast and can run many times at once, so producing code is no longer what limits throughput — deciding what should be built, keeping concurrent work from colliding, and checking what came back are. A factory is organised around exactly those three, which is why the shape is worth borrowing now.

Does a software factory only apply to code?

No, and none of the four requirements mentions code. A unit of work with a written definition of done, a workspace it cannot collide in, a fixed inspection, and tooling that lives at the station describe any process where producing a candidate got cheap and judging it did not — research, design exploration, copy, data pipelines, support triage. The limit is not the subject matter, it is whether you can say what done means for the thing coming off the line.

How many parallel agents can one person actually run?

Fewer than the machine can start, and the limit is review attention rather than compute. Every unit that finishes wants a decision, so throughput is capped by how quickly a human can look at a diff and say ship or send back. That is the honest reason a factory page spends more words on the inspection station than on the line.

Does a software factory need agents at all?

No. A team that writes real tickets, branches per unit of work, and runs the same checks on every one is already running one, by hand. Agents change the economics — they make it cheap to have many units in flight at once — which is what turns the discipline from good practice into the thing holding the whole system together.

Software factory

A software factory is an organised production line for software: work arrives as a standard order, moves through fixed stations, is built in isolation from other work in progress, and passes an inspection with a written definition of done before it ships. What makes it a factory is that the same order produces the same outcome twice — a property of the system around the work, not of whoever or whatever does the building.

What generated code changed

Not the quality of the output — the location of the constraint.

A model will produce a plausible implementation of a well-described change in minutes, and it will produce twenty of them in parallel for about the same wall-clock cost as one. Writing code stopped being the scarce step. What did not get cheaper: deciding what should be built, keeping concurrent work from colliding, and establishing that what came back is correct. Those three are now the whole cost of a feature.

Intake, isolation and inspection are exactly what a factory is for, and they are what a chat window does not give you. When production is the cheap part, they stop being overhead and become the product. A team that generates code faster than it can specify or review it does not have a throughput problem solved — it has moved the queue somewhere less visible.

Four things, or it is just a queue

None of these is a property of the model. They are properties of the system it runs inside, which is why swapping in a better agent does not supply any of them.

A work order: Not a prompt. A unit of work with scope, an approach, and a list of conditions that decide whether it is finished. If that list is written after the code, it describes the code rather than the requirement, and the inspection at the end is a formality.
Isolation: Two units of work in one working directory is not parallelism, it is contention: uncommitted changes bleed across, one failure poisons the other, and neither can be reviewed alone. A branch and a checkout each is the cheapest thing on this list and the one most often skipped.
An inspection: The station that makes a factory a factory. Every unit hits the same gate — build, tests, the order's own conditions — and its result travels with the work, so the reviewer reads evidence rather than re-deriving it.
Tooling on the line: In a plant the jigs live at the station, not in a worker's pocket. The equivalent here is procedure the agent can load on demand, versioned with the line rather than retyped into a chat window each time — which is what an agent skill is.

One line, three stations

This is Fredrin, which is a software factory for one person: a board of work orders, a branch and worktree per unit, and a review column where everything lands. Recorded from the running app.

The order is written before the machine starts

A ticket opens on its mission — the plan, design and build steps this piece of work requires — and the run starts against that, not against a sentence typed into a prompt. Planning and building are separate buttons on purpose: the cheapest place to catch a misunderstanding is before any code exists.

Units run at the same time, and never in each other's way

Work moves out of the backlog into Running, and each ticket takes a branch and a worktree of its own. That is what makes the count on the Running column mean something: five in flight is five isolated checkouts, not five agents editing one directory and blaming each other for the result.

It comes back with its own inspection attached

A finished unit lands in Review carrying the conditions it was given, ticked off one by one with the commands that were actually run. The reviewer reads a diff and a result rather than re-deriving whether it works, and the decision is one button. Merge completes the ticket.

The jigs live at the station

A line is only as capable as the tools bolted to it, and the tools an agent can reach are a decision someone makes once rather than a thing each run improvises.

claude-video is a small, exact example. An agent cannot watch a video: hand it a screen recording of a bug and the best it can do is guess from the filename. The skill installs one command that pulls the captions, samples frames with ffmpeg, transcribes the audio when there is no caption track, and hands the frames back as images — so a bug report that arrives as a thirty-second recording becomes a piece of work the line can actually take.

That is also how the three clips above were described. Rather than assume what they show, the build for this page ran that skill over each recording and read the frames it produced: the mission checkboxes in the first, the branch-and-worktree caption and the Running column in the second, the ticked acceptance checks and the merge action in the third. The sentence under each clip is written from what was on screen. It is a small thing, and it is exactly the sort of small thing that separates a line from a person doing everything by hand — the jig was installed once, and now every run has it.

The general shape is an agent skill: a folder of procedure the agent loads only when a task calls for it, versioned with the project rather than retyped into a chat window. Which is the fourth requirement, and the one that compounds — every skill on the line is available to every unit of work that comes after it.

What a factory does not fix

Three ceilings, all of them real, and none of them removed by running more agents.

A line amplifies the order it is given. Uniformity is the whole promise, and a badly specified change produces badly specified output faster and more consistently than a person would have. The work that decides whether a factory is worth having happens before the run starts.

Review is the real ceiling. Every finished unit wants a human decision, so throughput is bounded by how fast someone can look at a diff and say ship or send back. Doubling the agents doubles the queue at that station, which is why the inspection is worth more engineering than the line.

Integration is not free. Units built in isolation still have to merge, and the more of them in flight the more often two of them have opinions about the same file. Isolation buys a clean build and a reviewable diff; it does not buy agreement.

Fredrin is the agentic development environment built for the case where those three are the problem: a backlog of real orders, a branch and worktree per ticket, and a board whose review column is the point rather than an afterthought.

Why a software factory for everything

Nothing in the four requirements is about code. That is the whole reason the shape travels.

Read them back with the word "code" removed. A unit of work with a written definition of done. A workspace where it cannot collide with anything else in flight. A fixed inspection every unit passes. Tooling that lives at the station rather than in someone's head. None of that is specific to a pull request — it is the description of any process where the making got cheap and the deciding did not.

Which is now most of them. The same inversion that hit code has hit research, design exploration, copy, data pipelines, migrations, support triage: a model will produce twenty plausible candidates while a person can still only judge a few, so throughput moves to intake and inspection in exactly the way it did for software. A line built for one of those is very nearly a line built for the others, because the parts doing the work are interchangeable and the stations are not.

The honest limit is the inspection. A factory generalises exactly as far as you can say what "done" means for the thing coming off it. Where that is checkable — it builds, the tests pass, the migration applies — the line runs itself and a human ships. Where done is a matter of taste, the inspection is still a person looking, and the factory buys you the isolation and the queue discipline but never the judgement.

Questions

What is a software factory?: A repeatable production line for software: work enters as a standard order, moves through fixed stations, is built in isolation from other work in progress, and passes a written definition of done before it ships. The emphasis is on the system rather than the individual build — the same order should produce the same outcome twice.
Is a software factory the same as CI/CD?: CI/CD is one station of it — the inspection — and it is the station most teams already have. A factory also covers how work enters, how units are kept from colliding while they are built, and what a reviewer is handed when the work comes back. A pipeline with no intake discipline is a very good inspector for a queue nobody specified.
Does this only make sense for a team?: It is most valuable to one person, which is the opposite of what the word suggests. A team has reviewers, a standup and a shared sense of what is in flight; one person running a dozen agents has none of that and needs the system to supply it. The smaller the human side, the more the line has to carry.
What changed with AI code generation?: The constraint moved. Generating a plausible implementation is now fast and can run many times at once, so producing code is no longer what limits throughput — deciding what should be built, keeping concurrent work from colliding, and checking what came back are. A factory is organised around exactly those three, which is why the shape is worth borrowing now.
Does a software factory only apply to code?: No, and none of the four requirements mentions code. A unit of work with a written definition of done, a workspace it cannot collide in, a fixed inspection, and tooling that lives at the station describe any process where producing a candidate got cheap and judging it did not — research, design exploration, copy, data pipelines, support triage. The limit is not the subject matter, it is whether you can say what done means for the thing coming off the line.
How many parallel agents can one person actually run?: Fewer than the machine can start, and the limit is review attention rather than compute. Every unit that finishes wants a decision, so throughput is capped by how quickly a human can look at a diff and say ship or send back. That is the honest reason a factory page spends more words on the inspection station than on the line.
Does a software factory need agents at all?: No. A team that writes real tickets, branches per unit of work, and runs the same checks on every one is already running one, by hand. Agents change the economics — they make it cheap to have many units in flight at once — which is what turns the discipline from good practice into the thing holding the whole system together.

Or run the line yourself, on a backlog you already have.

Request invite Read the docs