The Dark Software Factory

A software factory with the lights off changes one thing first, and it is not the software. It changes who does what. When the machines write the code, review it, test it, deploy it and document it, the person who used to do those things does not disappear; they move to the gates, and the gates become the job. The question a buyer should ask of any ‘autonomous’ pipeline is therefore not how clever its agents are but where its gates sit, what a gate can see when it opens, and whether the system can tell the truth about what it did on the far side of one. Most cannot, and the ones that cannot are not dark factories but dark rooms with an optimistic status light on the door.

This one turns a written specification into a merged pull request with no person in the loop except at the gates. A spec, a markdown document describing one unit of work, is handed to an orchestrator built on DBOS and Postgres, which dispatches a sequence of Claude Code agents, each with one role: one plans, one writes, one reviews, one audits for security, one tests, one deploys, one documents, and an eighth, off the main line, turns a plan into a dependency graph of specs and authors them. Each agent hands the next a structured JSON message with mandatory outcome fields, and every step is checkpointed, so a container restart resumes the run at the last completed step rather than paying for the same model call twice. Four projects run this way today, on isolated worker containers, from one Compose stack, and one of them is the quoting engine at eBatt.ai.

The hard part was never calling a model seven times. It was making the sequence durable, so that it survives restarts, redeploys, expired credentials and agents that fail in creative ways, and making it honest, so that a run which did not do what it claimed cannot report success. The second is harder than the first, and the system’s own documentation is candid about how often the first version of a signal said the opposite of what had happened. A DBOS workflow row reading SUCCESS means the workflow returned, which a halted spec also does; the on-disk marker is the only authority on outcome. A deployer once wrote ‘success’ while the sprint’s code never reached the remote, because the builder skipped the push and a reset discarded a correct local merge, so the orchestrator now checks the remote tree itself and trusts none of the agent’s proof fields. Four consecutive green rehearsal runs once reported writing a file that never existed. Each of those is a trap that looks like success, and each has a named check in front of it now.

I wrote the first version of this as a set of terminal panes and a polling loop, and it lost state every time the laptop slept. But the rebuild on a durable workflow engine did not remove the person from the system; it moved the person to a shorter list of better questions, and it made the machine answerable for the rest. That is the whole design in one sentence: the automation is allowed to be fast, and it is not allowed to be sure.