Insights · Updated

What Is an AI Software Factory?

The idea is almost sixty years old. What changed is who works the line.
By

"AI software factory" is having a moment. It's in pitch decks, in job posts, and on our own homepage, which calls Agentastic.dev "the multi-agent IDE for your AI software factory." If we're going to use the phrase, we owe you a definition.

Hand-drawn ghosts working the stations of a software assembly line, from an incoming issue to a merged pull request

So here's ours. Then the history, which goes back further than you'd guess, the parts a factory actually needs, and how to start one without reorganizing your team.

The short version#

An AI software factory is a repeatable system in which coding agents do most of the production work, like writing code, running tests, and opening pull requests, while engineers decide what gets built and what ships.

The agents are the workers. The factory is everything around them: how work comes in, where agents run, how their output gets checked, and how it merges.

That second part is the whole point. Anyone can open five terminals and start five agents. If you still have to babysit every step, you don't have a factory. You have a workshop with very fast apprentices.

One naming note: an AI software factory is not an "AI factory." NVIDIA, Dell, and Cisco use that phrase for data-center infrastructure that trains and serves models. That kind of factory makes models; this kind uses them to make software.

The term is older than you think#

Software people have been borrowing from manufacturing since the 1960s.

In 1968, Bob Bemer of General Electric argued for a "software factory": standard tools, a common interface, and a database of past projects, so that output depended less on which programmer you happened to get. Hitachi was the first company to actually build one under that name, opening the Hitachi Software Works in 1969. System Development Corporation followed in 1975, and NEC, Toshiba, and Fujitsu set up their own in 1976 and 1977.

The best-documented results came from Japan. MIT's Michael Cusumano studied those shops for his 1991 book Japan's Software Factories. At Toshiba's factory in Fuchu, the share of delivered code reused from earlier projects rose from 13% in 1979 to 48% in 1985, and output per programmer more than doubled between 1976 and 1985.

The term kept coming back. In 2004, two Microsoft architects, Jack Greenfield and Keith Short, published Software Factories, a book about assembling applications from patterns, models, and frameworks instead of writing everything by hand. In 2017 the US Air Force started Kessel Run, its first software factory. By September 2021 the Air Force had 17 of them.

Every version chased the same goal: make software production repeatable enough that output stops depending on heroics. Standard tools, reuse, process, measurement. What none of them could change was the labor. Every station still needed a person, and hiring was the only way to add capacity.

Coding agents change that. The line can now be staffed by software, which is why the phrase is back.

The 2026 wave#

In 2026 the term went from metaphor to org chart. A few of the teams that described their factories in public:

  • StrongDM (February) runs what it calls a software factory with two rules: code must not be written by humans, and code must not be reviewed by humans. Scenario tests and simulated copies of services like Okta and Slack replace code review (StrongDM).
  • OpenAI's harness engineering team (February) shipped an internal product with about a million lines and no hand-written code, from roughly 1,500 pull requests by three to seven engineers driving Codex (OpenAI). In September, The Pragmatic Engineer went inside OpenAI's agentic software factory.
  • Factory (June) relaunched its platform around the idea, calling the software factory the system engineers build that in turn builds their software (Factory 2.0).
  • LaunchDarkly (July) wrote that AI moved the bottleneck "out of writing code and into the process of reviewing that code and deciding what the specs are" (LaunchDarkly).
  • Vercel (August) built a factory for the AI SDK that, four weeks in, authored a quarter to a third of merged pull requests, with every agent in its own sandbox and a person merging every change (Vercel).
  • Warp (August) launched Warp Factories, infrastructure for cloud software factories defined as code (Warp).
  • Uber reported that more than 70% of its pull requests are attributed to local or cloud agents, and described its software factory's layers and cost model (Uber).

Their setups differ, but the shape repeats: isolated workspaces per task, machine checks before people, and humans deciding what ships. We compare the products in the best AI software factory tools.

What makes it a factory#

A factory is a line of stations, each with a clear input and output. For software, the line looks like this:

  1. Intake. Work arrives from where it already lives: the issue tracker, error monitoring, team chat, or a schedule. Nobody should have to copy a ticket into a terminal.
  2. Plan. A ticket becomes something an agent can execute: a clear prompt, the relevant context, and a definition of done.
  3. Build. Agents work in parallel, each in its own isolated workspace (a git worktree, a container, or a VM) that starts in a known-good state.
  4. Review. Every change lands as a diff. Tests and AI review catch the obvious problems, and a person reads what's left and decides.
  5. Ship. The change goes out as a pull request, CI runs, and it merges.

Two things aren't stations but hold the line together. The first is reproducible environments: an agent dropped into a bare checkout burns half its budget working out how to install dependencies. The second is visibility: with ten runs going, you need one place that shows what's running, what's stuck, and what needs you.

Each missing piece has a recognizable symptom. Without intake, you have a tool you operate by hand. Without isolation, your agents fight over the same files. Without review, you have a faster way to ship bugs.

Review is the bottleneck#

Here's the part the pitch decks skip. Agents can already produce diffs faster than anyone can read them. Once generation is cheap, a factory's throughput is set by review, not by how many agents you run.

A few things actually move that bottleneck:

  • Smaller tasks. A 40-line diff gets a real review. A 2,000-line diff gets a skim and a prayer.
  • Machine checks first. Tests, type checks, and an AI review pass should reject the obvious failures before a person spends time on them.
  • Proof that it runs. A screenshot or a quick look in a browser beats reading a UI diff line by line.
  • Standing rules in the repo. Put your conventions in the agent's instructions and your review prompt, so the same mistake doesn't come back every run.

What doesn't work is skipping review. The whole promise of a factory is consistent output, and nothing makes output less consistent than code nobody read.

Light factories and dark factories#

Not everyone agrees with that last point. A dark software factory runs with no human writing or reading code: people write specs and acceptance scenarios, and machines build, verify, and ship. Dan Shapiro calls it level 5 of AI-assisted programming, and StrongDM says it works this way. Addy Osmani contrasts it with a light factory, where people stay at the decision points and machines handle everything in between (Software Factories, Light and Dark).

For most teams the light factory is the right target today. If you're curious about the other end, read what a dark software factory is and what replaces code review there.

One vendor's factory, or your own#

There are two ways to get a factory today.

The first is to buy one. Several companies now sell a line where their agent runs in their cloud and you review its work in their dashboard. It's the fastest way to start, and for some teams it's the right call.

The catch is that the agent is the part of the line that changes fastest. The best coding agent this year probably won't be the best one next year. A single-vendor factory ties your intake, compute, review, and merge process to one vendor's agent, and swapping it out means rebuilding the line.

The second way is to build the line yourself and treat agents as interchangeable workers. The stations stay put. When a better agent ships, you add it and route work to it. Your issue tracker, environments, review habits, and CI don't change.

That's the bet we made with Agentastic.dev. For a side-by-side look at both routes, from Factory, Warp, and 8090 to Codex, Claude Code, and open-source parts, see the best AI software factory tools.

Start small#

You don't need a reorg or a platform team. Build the line one station at a time:

  1. Pick one boring category of work. Flaky tests, dependency bumps, docs that drifted, small bugs with a clear repro. Well-specified work with an obvious definition of done.
  2. Make the environment reproducible. Write a setup script that takes a fresh checkout to a working state. It's the single biggest factor in whether agents succeed.
  3. Run a few agents in parallel. Two or three, each in its own worktree, on separate tasks. Watch where they get stuck.
  4. Put review on rails. AI review first, then your read of the diff, then CI. Keep tasks small enough that you actually read them.
  5. Automate intake last. Once the first four are boring, let a schedule or an issue start the runs.

The order matters. Automating intake before review works is how you end up with forty pull requests you don't trust. Our step-by-step guide, how to build an AI software factory, walks through each station with Claude Code and Codex.

Two newer terms describe the work at each scale. Harness engineering is making one station reliable: instructions, tools, tests, and a clean workspace for each agent. Loop engineering is keeping stations running without you: triggers, separate checkers, memory, and budgets. A factory is many loops, each around a good harness.

How Agentastic.dev fits#

Agentastic.dev is a native macOS app for running coding agents in parallel, and it has something for each station:

Two honest limits. Local runs need your Mac awake with the app open, so work that should keep going after you close the lid belongs on an SSH host or a cloud VM. And issues don't turn into pull requests on their own: you start the run, or a Manager Agent or scheduled task picks the work up while the app is running. We think a person should still be the one who merges.

For the whole line on one page, see the AI software factory in Agentastic.dev. If you mostly want to run several agents side by side, start with the multi-agent IDE. For how one agent can coordinate others, from fan-out to manager and worker, read our guide to agent orchestration.

The job moves to the floor#

The factory metaphor gets one thing right that "AI pair programmer" never did. The interesting work moves from the line to the floor: deciding what gets built, designing the stations, and signing off on what ships.

That's still engineering, just a different part of it, and it is the difference we draw in agentic engineering vs vibe coding. The teams that get the most out of agents won't be the ones running the most of them. They'll be the ones with the cleanest line: clear tasks, reproducible environments, and review that someone actually does.

Agentastic.dev is free for macOS. Bring the agents you already use and build the line one station at a time.

Frequently asked questions#

What is an AI software factory?#

An AI software factory is a repeatable system in which coding agents do most of the production work, such as writing code, running tests, and opening pull requests, while engineers decide what gets built and what ships. The agents are the workers; the factory is everything around them: intake, isolated workspaces, review, and merge.

Where does the term software factory come from?#

From the 1960s. Bob Bemer of General Electric argued for a software factory in 1968, Hitachi opened the Hitachi Software Works in 1969, and NEC, Toshiba, and Fujitsu followed in 1976 and 1977. The US Air Force revived the term with Kessel Run in 2017.

What are the stations of an AI software factory?#

Intake, where work arrives from issues, chat, or a schedule; plan, where a ticket becomes an executable prompt; build, where agents work in parallel in isolated workspaces; review, where tests, AI review, and a person check each diff; and ship, where a pull request runs CI and merges. Reproducible environments and visibility hold the line together.

What limits the output of an AI software factory?#

Review. Agents can produce diffs faster than anyone can read them, so throughput is set by how much you can review well. Smaller tasks, machine checks first, proof that the change runs, and standing rules in the repository move that bottleneck.

How do I start building an AI software factory?#

Pick one boring category of work, make the environment reproducible with a setup script, run two or three agents in parallel, put review on rails, and automate intake last, once the first four steps are routine.

Is an AI software factory the same as an AI factory?#

No. NVIDIA, Dell, and Cisco use "AI factory" for data-center infrastructure that trains and serves AI models. An AI software factory is a delivery system in which coding agents build, test, and propose changes to your software. The first makes models; the second uses them to make software.

What is a dark software factory?#

A dark software factory is an AI software factory with no human writing or reviewing code: people write specs and acceptance scenarios, and machines build, verify, and ship. StrongDM describes running this way. Most teams keep people at the decision points instead, which Addy Osmani calls a light factory.

Should I buy a vendor's AI software factory or build my own?#

Buying is the fastest start, but it ties intake, compute, review, and merge to one vendor's agent, which is the part of the line that changes fastest. Building the line yourself lets you swap agents as better ones ship while your tracker, environments, review habits, and CI stay put.

About the Author

Adel Ahmadyan

Builds Agentastic.dev, the native macOS multi-agent IDE.