AI software factory: what it is and how we run one

An AI software factory is a repeatable system in which AI agents take written tasks to a reviewed pull request, while people set the intent and decide what ships. The agents do the building. The factory is everything around them: the spec, the checks, the preview and the review gate.

We run our development this way. AI writes most of our code. A senior reviews every change and is accountable for what reaches production. Below is what the term means, the light and the dark version, what a factory needs and how a team of 3 to 30 developers can start.

What is a software factory?

The term has two meanings, and search results mix them.

The old meaning is decades old. Hitachi called its software division a "software works" in 1969, and Wikipedia describes a software factory as "a structured collection of related software assets that aids in producing computer software applications". In practice it came to mean a shop that builds software on order with a standard process: templates, fixed roles, the same steps for every project.

The new meaning is about AI agents. CircleCI defines it as "a system for turning engineering intent into production software through repeatable, increasingly automated workflows". Agents write the code, machines check it, and people steer.

Light factory or dark factory?

Dan Shapiro proposed five levels of AI in programming, from autocomplete up to the "dark factory", named after plants that run with the lights off.

Some teams say they work this way. Simon Willison wrote about StrongDM's AI team, whose rules include "Code must not be written by humans" and "Code must not be reviewed by humans". They replace human review with specs, scenarios and heavy automated testing. It is a serious experiment, and it fits teams that can measure correctness almost entirely by machine.

A light factory keeps the same automation and adds one thing: a person who reads the result before it ships.

Where are we? On Dan Shapiro's five levels, our client work sits at level 3 to 4: agents write the code and a person reviews every change. Our AI colleague takes tasks to a pull request at level 4, for now on our own projects. Level 5, the dark factory, is not where we want to go.

Why don't we run a dark factory?

Because the software we build calculates prices, sends emails to customers and holds company data. A test suite checks what someone thought to write down. A reviewer also asks whether the change makes sense for that business, whether it matches what was agreed and what happens when the data is messy.

AI writes most of our code. A senior reviews every change and is accountable for what reaches production. That second sentence is the whole difference between our factory and a dark one.

Review does not mean rereading every line by hand. The checks have already run. The reviewer looks at the intent, the risk, the tests and the parts a machine cannot judge. That is why the factory needs small pull requests: a person can review fifty lines well and two thousand lines badly.

What does an AI software factory need?

Agents are the easy part. You can rent the same models as everyone else tomorrow. What makes a factory is the line the work moves along:

• A written spec with acceptance criteria. What should change, how you will know it works, what is out of scope. An agent cannot read your mind, and neither can the reviewer. Our way of writing these is in spec-driven development with AI agents.
• A repository with reliable setup and checks. One command installs, one runs the tests, one builds. If a new developer needs a day to get the project running, an agent will fail too.
• Tests that fail before and pass after. A new test must be red on the old code, or it proves nothing. More in red-green TDD with AI agents.
• Preview deploys. Every pull request gets its own running version, so the reviewer clicks through the change instead of imagining it.
• A review gate. Automated review first, then a person. Only a person merges.
• Small pull requests. One task, one change, one thing to review.

How we wire these together, from an issue to a pull request, is in harness engineering in practice. Our AI colleague, an agent that takes tasks from the backlog to a pull request while a person merges, is described in this case study.

Where does an AI software factory break?

Mostly in the same places a human team breaks, only faster.

• Vague tasks. "Improve the checkout" produces a confident change nobody asked for. A factory amplifies unclear intent.
• Flaky setup. If tests pass on one laptop and fail in CI, the agent spends its time fighting the environment, not the task.
• Tests written after the code. They describe what the code does, not what it should do, and they pass by definition.
• Big pull requests. Review turns into a rubber stamp, and the human in the loop stops being one.
• Rules in someone's head. Conventions that are not written in the repository do not exist for an agent. A shared rules file fixes much of it, see Claude Code best practices for teams.

How do you start an AI software factory in a team of 3 to 30 developers?

Start small and on real work, not on a demo project. In the order we would do it:

After a few weeks you know where the line jams: the specs, the setup, the tests or the review. Fix that first, then add the next task type. The factory grows one reliable step at a time.

Is your repository ready for an AI software factory?

Tick what your team has today.

Want an AI software factory in your repository?

We set this up inside a team's own repository as part of AI-native SDLC for development teams: the rules, the checks, the loop and the review gate, on your real backlog. Everything stays with your team.

We get back to you within two business days, and together we pick what to fix first.

If you'd rather talk first, book a 15-minute meeting with Filip.

Where does work in your team jam today: the spec, the setup, the tests or the review?

Frequently asked questions

What is an AI software factory?

A repeatable system in which AI agents take written tasks to a pull request that passes automated checks, and people set the intent and decide what ships. The factory is the system around the agents: specs, a reliable repository, tests, preview deploys and a review gate.

What is a dark software factory?

The far end of the scale, where no person writes or reviews the code: specs go in, software comes out. Dan Shapiro named it after factories that run with the lights off. Some teams report doing it. We do not, because for software that runs a business we keep a person accountable for every change.

Is a software factory the same as a software house?

In the older meaning, roughly yes: a shop that builds software on order with a standard process. The new meaning is about how the code gets made inside any team, with AI agents doing the building and people steering intent and review.

What does a team need before it can run an AI software factory?

Written tasks with acceptance criteria, a repository that sets up and runs its checks reliably, tests that fail before the change and pass after it, preview deploys, a review gate and small pull requests. Without these, more agents only produce more unreviewed code.

How big does a team have to be?

Not big. A team of 3 to 30 developers can start with one repository and one kind of task. Very small teams of one or two usually need only a short rules file for the agent, not a factory.