Software factory and dark factory

What is a software factory, and what is a dark factory?

A software factory is a delivery pipeline where coding agents do the writing, the testing and the first review, many changes at once, while people decide what gets built and own the gates the work passes through. The word factory points at repeatability, not size: the same steps run every time, and what comes out carries a record of the checks it survived.

A dark factory is that pipeline with the human reading taken out. The name comes from manufacturing, where a plant with nobody on the floor has no reason to keep the lights on. In software it means the same absence: an agent writes the change, an agent writes the test, an agent reviews the diff, and the only human contact is the spec going in and the behaviour coming out.

They are two points on one line, and every team using a coding agent sits somewhere on it. Your position is not set by how many agents you run, but by which checks a change has to pass before a customer sees it.

Where the name comes from

Software factory is not a 2026 coinage. Hitachi was the first company anywhere to hang the word on a real software operation, its Software Works, in 1969, and Toshiba, NEC and Fujitsu built their own; Michael Cusumano at MIT documented all four in his 1991 book Japan's Software Factories. The idea then is the idea now: standardise the process, build tooling for the parts that repeat, check quality on the way through. The US Department of Defense borrowed the word for the same reason, starting with the Air Force unit Kessel Run in 2017, where it means an accredited pipeline a team can ship through without re-arguing every control.

Dark factory comes off the shop floor. FANUC has run its plant in Oshino, Japan with the lights off since 2001, where robots assemble robots and the site runs unattended for weeks. Nobody claims the plant designed itself. Engineers set the parts, the tolerances and the tests, and a measurement rig on the line decides whether a unit passes. That is the part of the metaphor that transfers, and the part most write-ups skip.

What the pipeline looks like

A company running this seriously has five stages, recognisable whatever the vendor calls them.

1. A spec goes in, not a chat message. The intent, the constraints, what is out of scope, and the check that proves the feature works.

2. Agents work in parallel on separate branches. Several attempts at one task, or several tasks at once, each in its own sandbox, so a bad run costs only tokens.

3. A machine reviews before a person does. A second agent that did not write the code reads the diff against the spec, so human attention arrives at a change already argued with once.

4. Automated checks decide. Tests, a clean build, a security scan, a reconciliation against output you know is right. This is the gate that actually stops things, and everything upstream feeds it.

5. A person approves the merge. Someone with a name and a job title accepts the change into the branch that becomes production.

The documented case of deleting the reading from stage five is StrongDM, a security software company whose AI team published its rules in February 2026: code must not be written by humans, and code must not be reviewed by humans. Their replacement is a Digital Twin Universe, behavioural clones of services like Okta and Slack, against which the agents run thousands of end-to-end scenarios an hour. Some scenarios are held back, so a run cannot be tuned to pass the exam that will mark it. Their own rule for how hard to push: if you have not spent a thousand dollars on tokens today per human engineer, the factory has room for improvement.

Review capacity is what limits how much ships

Here is the whole argument. An agent produces more changes in an afternoon than a team reads in a week, so the pipeline runs at the speed of its verification, never at the speed of its writing. How fast people read code has been stable for a long time: the SmartBear study of a Cisco Systems team puts the useful limit at 200 to 400 lines in one sitting and under 500 lines an hour, with defect detection falling off sharply above that pace.

Faros AI, which sells engineering analytics, published telemetry in 2025 across more than 10,000 developers on 1,255 of its customer teams. Teams with high AI adoption merged 98 percent more pull requests and completed 21 percent more tasks, while the average pull request grew by 154 percent, review time by 91 percent and bugs per developer by 9 percent. More changes arrived, each one was bigger, and the reading queue swallowed the gain. This is a vendor's own customer data rather than an independent study, so take the percentages loosely and the direction seriously. DORA, Google's research programme on software delivery, lands in the same place: AI improves throughput, but often at the cost of stability if your foundation is not solid.

So compare the two shapes on one dimension: what limits how much work can ship. Gated by human reading, the ceiling is reviewer-hours, and it does not move when you add agents; they only lengthen the queue. Gated by automated verification, the ceiling is how fast the checks run and how much real risk they cover, and it moves when you write more checks or buy more compute. Neither is safer by definition, and a shallow automated gate ships bad code faster than a tired human ever could. The difference is that one of the two constraints can be engineered.

Two teams ship the same feature

A wholesaler wants customer-specific price lists in its webshop: agreed prices per customer group, volume brackets, and a fallback to the list price.

Team A has six people and agents on everything. In one week the agents open 40 pull requests instead of the usual eight, around 400 lines each against the usual 160. That is 16,000 lines arriving at two reviewers. At the pace the Cisco data calls effective, roughly 400 lines an hour, reading all of it is 40 hours, so 20 hours each in a week where both also have their own work. The first ten get read properly and the rest get skimmed. Three weeks after go-live one customer group gets the wrong bracket above a certain order quantity, and nobody can say which change did it.

Team B has three people and one gate. Before any code they sit with the sales manager for an hour and write the pricing rules down as 14 test cases, two of which must be rejected: an expired agreement, and a bracket with a gap in it. Then they build one check that costs an afternoon, a reconciliation that recomputes last month's invoice lines with the new engine and compares the totals against what was actually billed. Six changes ship that week instead of 40. On the fourth, the reconciliation fails on one customer group, a few hundred euro off: the same bracket bug Team A found in production. It never reaches the merge.

Team B did not ship less because it used less AI. It shipped less because a gate that means something rejects things, and every rejection is work nobody had to undo in front of a customer. The reconciliation also keeps working if the team doubles its agents tomorrow. The 40-hour reading queue does not.

Who signs off when nobody reads the code

Nobody reads the code does not mean nobody is responsible. Someone still decides the thing ships. In a dark factory that decision moves upstream, from reading the diff to accepting the specification, the scenarios and the score, but it stays with a person, and so does everything that follows from it.

Eran Kahana, writing for Stanford Law School's CodeX centre in February 2026 about the StrongDM case, named the difficulty exactly: the same class of technology that writes the code also decides whether the code works, so builder and inspector share their blind spots. His illustration is an agent that satisfied a test by returning true, which passes and does nothing. He also points at a gap most companies have not looked at: liability clauses drafted for human-reviewed code now sit on top of software no person has examined.

Regulation does not care who typed it. If a change touches personal data, GDPR applies to the result. If the product falls under a conformity assessment or a security review, that review still happens and a person signs it. An unread change that fails in production is your change. Simon Willison's version is worth keeping: a computer can never be held accountable, and that is your job as the human in the loop.

If you are commissioning the software rather than building it, ask who accepts the change, by name, and what that person looked at first. "The pipeline was green" is a real answer if you can also see what the pipeline checks. "The agent handled it" is not.

What to watch out for with a software factory

Volume of plausible-looking changes. Agent output looks like careful work: sensible names, a tidy commit message, a test alongside. The old signal that a change deserved attention, that it was visibly rushed, is gone. Twenty correct-looking diffs wear a reviewer down and the twenty-first goes through unread.

The tests come from the same place as the code. A suite written by the system it grades is an exam the student also marked. Holding scenarios back is one countermeasure; writing the acceptance criteria yourself, with the person who owns the process, is the cheaper one.

A codebase nobody on the team understands. This is the slow cost. When something breaks on a shipping day, the response depends on someone holding a mental model of the system, and that model gets built by reading and changing code. Take the reading away and you get the year-two problem: it works and nobody knows why.

Published figures on how much code AI writes are not measurements. Sundar Pichai said on Alphabet's October 2024 earnings call that more than a quarter of new code at Google was AI-generated, then reviewed and accepted by engineers, and that second half goes missing in most retellings. Satya Nadella said at Meta's LlamaCon in April 2025 that 20 to 30 percent of the code in Microsoft's repositories was written by software, better in Python than in C++. Both companies have quoted higher numbers since. None of these defines what counts as AI-written, none is audited, and none says what a check would have caught.

What a small company takes from this

You are not going to run a software factory, and you do not have the volume that needs one. What transfers is smaller and works at any size: a written spec, a check a machine can run, and one named person who accepts the result.

Those three make any agent work safe, whether it is a coding agent building an internal tool or an agent handling supplier mail. Without the spec, the agent answers the wrong question well. Without the machine check, you are the check, and you will not keep up. Without the named person, nobody notices when the first two are wrong.

Start with the check. It is the cheapest of the three. Pick the one number in your business that has to reconcile, sales in the report against sales in the source system, invoiced against delivered, hours booked against hours billed, and have a machine compare it on every change.