Light and dark software factories

A dark software factory is a software delivery loop in which no human reviews the code before it ships. The agents write the change, the agents review it, the checks pass, and it merges. A light software factory automates everything around the review and keeps a person at the merge gate. Both are factories in the 2026 sense: repeatable loops that turn tickets into tested pull requests. They differ in exactly one place, and that place is where this guide spends most of its time.

The names borrow from manufacturing. A lights-out plant runs with nobody on the floor, so the lights can stay off. The analogy is useful as long as you remember what a factory floor and a codebase do not share: a stamping press makes the same part a million times, and a coding agent makes a different change every run.

Where the terms come from

Three pieces of writing from early 2026 fixed the vocabulary. Dan Shapiro, the Glowforge founder, published a five-level model of AI-assisted development in January, and named the top level the dark software factory. In February, StrongDM published its own software factory with two rules that remove people from both writing and reviewing code; Simon Willison wrote about it on 7 February and gave it a far wider audience. Addy Osmani then framed the whole space as light and dark in an essay that has become the usual reference point.

If you have read none of them, start with Osmani's essay. The sections below describe each in turn without reproducing them, then explain where we land.

Shapiro's five levels

Shapiro's model is a ladder. Each rung moves more of the work of writing and reviewing software from people to models, and each rung changes what the people who remain actually do. At the bottom, a developer uses AI to type faster and reads every line. Further up, the model writes whole changes and a person reviews the diff. Higher still, a person judges the outcome, the behaviour and the tests, rather than the code. At the fifth level, nobody on the team reads the code at all. Shapiro calls that the dark software factory.

The useful thing about the ladder is not the numbering but the observation that the rungs are different jobs. A team at level two needs good code reviewers. A team at level four needs good acceptance criteria and a test suite it trusts, because that is all it has left to review. A team at level five needs a way to find out it is wrong that does not involve a person reading a pull request, which is a much harder thing to build than it sounds. Shapiro's writing is at danshapiro.com.

StrongDM's two rules, as reported

StrongDM's software factory is the clearest public example of a team choosing the dark end on purpose. As reported, the factory operates under two rules: code must not be written by humans, and code must not be reviewed by humans. Humans write specifications, build the harness, and decide what the factory should make. The agents do the rest, and the quality control is the test and verification machinery rather than a reviewer.

What made the piece travel was the discipline of the rules rather than any claim about speed. Simon Willison, who wrote it up in February 2026, has spent years documenting what agents can and cannot be trusted with, and his interest signalled that this was an experiment worth watching rather than a marketing line. The factory's own write-up is at factory.strongdm.ai.

Two things about the StrongDM approach are worth keeping even if you never go dark. The rules are absolute, so there is no slow drift where a human quietly starts patching the agent's work by hand. And the effort moved upstream: when nobody reviews code, the specification and the tests are the product, and they get the attention that code review used to get.

Osmani's light and dark framing

Osmani's essay describes a software factory as harnessed agent loops run at scale: not one developer with one assistant, but many agents working through a queue inside a harness that gives them context, tools, checks and limits. He then separates the light factory, where human judgment stays in the loop at the points that matter, from the dark factory, where it is removed. He does not treat dark as the inevitable endpoint. He treats it as a choice with a cost, and he is candid that the industry does not yet know for which kinds of software that cost is worth paying.

The gate is not a speed bump on the way to automation. It is where the team's judgment is applied to the one thing the machinery cannot judge: whether this change should exist.

That sentence is ours, not Osmani's, but it is the conclusion we draw from his framing. The parts of the loop that are mechanical, which is most of them, should be automated completely. The one part that is a judgment should be kept, and it should be kept deliberately rather than by inertia.

Why we build light factories

We set up factories for teams that already have a backlog, a repository and a ticket tool. Every one of them starts light, with a person approving every merge, and we argue for staying light for longer than most teams expect. The reasons are practical rather than philosophical.

• Accountability has to live somewhere. When a change breaks production, a team needs a person who decided it was ready. In a light factory that is the approver, and the approval is recorded on the pull request. In a dark factory the answer is "the tests passed", which is a description, not a decision.
• Most test suites have not earned it. A dark factory is only as safe as its checks, and a typical codebase has gaps, flaky tests and behaviour nobody wrote down. The review gate catches what the suite does not, and it also shows the team, pull request by pull request, where the suite is thin.
• Reviewing teaches the factory. Every request for changes is information about the rules file, the tickets or the agent's limits. A team that reads the agent's pull requests for a few months ends up with a far better factory than one that never looks.
• The cost of the gate is small when the loop is well built. A reviewer reading a focused pull request with passing checks and a clear summary spends minutes, not hours. The expensive part of review was always the back and forth with the author. The agent does not mind being asked twice.
• Regulation and customers ask who approved it. Teams in finance, health and the public sector are asked to show a human control on changes. A recorded approval on every merge answers that question without extra process.

None of this says dark factories cannot work. It says a dark factory is a destination you arrive at by proving, class of change by class of change, that your checks are a better judge than your reviewers. Few teams are there, and the ones that are got there by running light for a long time.

The autonomy dial

Light and dark are not two switch positions. In practice autonomy is a dial with at least three settings, and a team can be at different settings for different kinds of work in the same repository.

1. Every change approved. The agent opens pull requests and a person reviews each one before it merges. This is where every team should start and where most of its work should stay until the suite is proven.
2. Exceptions only. Routine changes that pass every check get a light review: a glance at the summary and the test list rather than a line-by-line read. Anything unusual, anything touching a sensitive path, gets a full review. The rules file decides what counts as routine.
3. Auto-merge on green. For narrow, low-risk classes of change that the team chooses by name, such as dependency bumps within a version range or copy fixes in a content directory, a passing suite is enough to merge. This is the only setting that is dark, and it is dark for a few file paths rather than for the repository.

The rule for moving the dial is that the tests earn each step. If the auto-merged dependency bumps have not caused an incident in months and the suite covers the integration points, the setting is justified. If a reviewer keeps finding things in the "routine" pull requests, the dial goes back. The decision is made on evidence from the factory's own history, which is another reason to run it light first: light factories produce that evidence.

Our software factory setup work builds exactly this dial into a team's own GitHub and ticket tool, starting at the first setting and moving only when the tests justify it.

Common questions