The phrase "dark software factory" makes a good headline. It suggests agents quietly shipping software while the rest of us sleep. The less exciting version is also the more useful one: a system where code is accepted because the evidence is good enough, not because a person read every line.
Simon Willison's summary of Dan Shapiro's five levels describes that end state as a black box turning specifications into software.[3] The important question is what sits between the specification and the software being accepted.
Coding agents have made implementation abundant. Review, verification, deployment risk and accountability have not become cheaper in the same way.
Addy Osmani's factory model breaks this into loops, harnesses and gates. The agent loop gathers context and acts. The harness defines the tools, memory and checks. The factory coordinates the work into production. Humans still own the outer loop: deciding what should be built, what evidence is sufficient and who carries the consequence of being wrong.[4]
That outer loop is where buyers should look. A confident agent demo tells you very little about it.
A dark factory might remove routine code reading. It should not remove product judgement, security ownership or incident responsibility.
If nobody reads the code, someone still has to explain it when production is down, a customer reports a problem or an auditor asks why a change was allowed. The work has moved; it has not disappeared.
The practical division is clearer when you write it down:
If those pieces are missing, "dark" just means unreviewed.
A Microsoft Research/CMU benchmark gives a useful reality check. The best code-review agent configuration caught 71.9% of human-verified bugs within its top-five comments, up from 47.7% five months earlier. The same paper reports that agents still missed more than 20% of bugs humans found, and performance dropped by up to 25.5 percentage points on proprietary industry repositories where more project context was needed.[1]
That is real progress. It is not a reason to remove the review gate. It is a reason to make the gate risk-based and to understand where review agents need more context.
An agent checking its own work can catch mistakes. It can also repeat the same assumptions that caused them.
Use more than one kind of evidence:
An internal script and a payment flow should not have the same autonomy setting.
If people stop reading every line of code, they need a better control surface than "the agent said it works". That surface is the intent, constraints and evidence around the change.
A useful specification says what the system must do, what it must not do, which inputs and permissions are allowed, which failures are unacceptable and which checks prove the result. It also says who approves the outcome and what happens when the checks fail.
GitHub's Spec Kit fits here. It gives coding agents structured processes and documented outcomes rather than asking them to infer everything from a short prompt.[2] Formal proof systems go further for a narrower set of properties, which is where proof-driven development becomes interesting.
A team does not have to choose between reviewing everything and trusting everything. It can create lanes.
Lower-risk lanes might include internal tooling, generated migrations with strong tests, documentation updates or isolated prototypes. Authentication, payments, permissions, personal data and customer-facing decisions belong in a different lane.
For each lane, record the permitted actions, required checks, approval threshold, rollback path, accountable owner and evidence retained. Autonomy should increase only when the lane keeps producing accepted outcomes.
If a supplier proposes an AI software factory, ask:
The near-term goal for most teams should be a supervised factory with more automation where the evidence supports it. Agents can draft, test, investigate and prepare changes while people own intent, high-risk approval and consequences. Selected low-risk lanes may become darker over time. That should be earned by evidence.
Our AI consulting and automation work covers the practical version of this: define the workflow, the control boundary and the evaluation.