Dark factories change another deeply rooted assumption in software engineering: the primary human engineering artifact is no longer the code.
The Plan Becomes the Input
It is the intent supplied to the factory.
That intent cannot simply be a vague prompt. There is an enormous difference between telling an agent to “build a user management system” and supplying an orchestratable engineering plan that defines the required outcome, architecture, constraints, acceptance criteria, and evidence.
A dark factory does not eliminate specification. It makes specification existential.
Poorly defined intent multiplied by autonomous execution creates industrialized ambiguity. Well-defined intent multiplied by autonomous execution creates leverage.
This is why I use the word vetted deliberately when describing plans entering a dark factory. A production-ready plan is not a transcript of somebody brainstorming with an LLM. It is an engineering artifact that has itself been reasoned about and challenged. Its assumptions are visible, its boundaries are explicit, its acceptance criteria are testable, and its intent is sufficiently precise that a production system can act upon it without repeatedly returning to a human for clarification.
The plan becomes the raw material entering the factory, and software emerges from the other side.
That moves scarcity upstream.
When implementation becomes abundant, intent becomes scarce.
Trust Moves Into the Factory
The most obvious objection to removing humans from routine coding and code review is trust, and it is the correct objection. We should not trust autonomous engineering simply because a model is impressive. We should trust it only after constructing a production system worthy of that trust.
The mistake is assuming that trust must primarily come from a person reading the code afterward.
Human code review is one trust mechanism. At machine scale it becomes an increasingly weak one, which means trust has to move into the production process itself.
A mature factory begins with architectural and policy constraints before implementation starts. Validation expectations are explicit. Security requirements participate in the workflow. Testing is mandatory, and evidence is required rather than merely requested.
The factory also introduces independent perspectives. The process that creates an implementation should not simply declare that implementation correct. Its work should be challenged by another reasoning path operating with a different purpose and fresh context.
The builder's task is to satisfy the plan. The validator's task is to find reasons why it did not.
If validation fails, the factory needs to determine what kind of failure occurred. A local implementation problem can return to a fresh builder context. Repeated structural failure may route upstream toward planning or architecture. A sufficiently serious, persistent, or high-risk condition may cross a human boundary.
This is where orchestration becomes something more sophisticated than agents calling agents. The factory needs failure classification, bounded retries, and explicit escalation policy.
An agent that repeatedly fails is not demonstrating autonomy.
It is stuck.
Infinite retries are not resilience. They are an uncontrolled production incident.
Who Validates the Validator?
Adversarial validation creates an obvious recursive question: if we no longer assume the builder is correct, why should we assume the validator is?
We should not.
Using a different model family or fresh context can reduce correlated reasoning, but it does not eliminate it. Models can share conceptual blind spots and confidently incorrect assumptions. Simply appointing another probabilistic system as the final oracle recreates the same problem one layer higher.
An early result from a recent arXiv preprint by Eric S. Qiu and Joyce Gill provides a useful warning. In their experiments with adversarial agentic code review, a naïve interactive reviewer-and-critic configuration exposed a false-consensus failure mode. On one benchmark, simply adding cooperative agents did not produce the strongest review; the approach improved when disagreement was made explicit and evidence-grounded. [2]
Because this work is both recent and not yet peer reviewed, I would not treat its specific result as settled evidence about how all multi-agent review systems behave. The broader warning, however, is worth taking seriously: adding more agents does not automatically add independence.
Independence has to be engineered.
A mature factory therefore has to construct confidence from different forms of evidence. Model-based critique can be paired with deterministic testing, static and security analysis, architectural invariants, and independently derived acceptance criteria. Higher-risk work may justify additional reasoning paths or explicit human authority.
The point of adversarial validation is not that the validator is infallible. It is that no single reasoning process should be allowed to both construct reality and certify that reality unchallenged.
Trust emerges from the system of checks, not from the presumed wisdom of one agent.
What This Looks Like in Practice
Illustrative example: The following scenario is a generalized example of how a governed orchestration can behave. It is intentionally abstracted from any particular organization, product, repository, or implementation and is included only to make the operating model concrete.
A real orchestration makes one path through the factory concrete.
In a multi-phase run involving a TypeScript reporting capability, an implementation reached Gate 4 and was rejected because the validator identified a type defect in the associated specification: a TS7006 implicit-any condition.
The failure did not invalidate the plan or expose an architectural contradiction, so the workflow did not unnecessarily return to planning. The correction remained scoped to the implementation stage where the defect belonged. After the type issue was repaired, the affected phase was rechecked and passed; Gate 5 subsequently completed with eleven tests passing.
The original failure remained part of the evidence.
That is important because the system did not succeed by making the first builder infallible. It succeeded by detecting a defect, locating it at the appropriate level of the production hierarchy, correcting it, re-evaluating the result, and preserving the history of what happened.
The example also illustrates a distinction that matters when designing an autonomous production line: a validator rejection does not necessarily equal a full orchestration rework cycle.
Some defects can be caught, corrected, and revalidated inside the current phase. Others are substantial enough to push work backward into a broader portion of the lifecycle. If repeated attempts reveal that the implementation cannot satisfy the plan, the correct response may be to stop asking new builders to solve the same problem and route the issue upstream toward planning or architecture instead.
A different production path illustrates the other side of autonomy. In governance-sensitive workflows, agents can complete planning, implementation, validation, testing, and evidence assembly yet still lack authority to cross the final boundary. The system reaches a deliberately human-owned gate, stops, presents the evidence, and waits for an explicit decision before continuing.
That is not a failure of autonomy. It is autonomy operating within its authority.
Those paths matter together. One demonstrates that the factory can keep a local implementation defect local rather than escalating unnecessarily. The other demonstrates that it can recognize a boundary it was never authorized to cross.
The important capability is not merely retry.
It is discrimination.
Experience, Authority, and the Hard-Hat Gate
A dark factory is not a factory without humans. It is a factory in which humans stand in different places.
I have spent decades writing software. I love code, understand it deeply, and believe that anyone responsible for serious software architecture needs strong engineering foundations. It is precisely because of that experience that I increasingly believe my own time is poorly spent manually producing implementation that a properly governed machine can produce faster and often better.
That conclusion is not anti-engineer.
It comes from being an engineer.
Experience provides the priors required to recognize good architecture, dangerous abstractions, weak assumptions, and failure. That judgment does not become less valuable when implementation becomes autonomous; it moves upward.
Someone still has to determine what the factory may do, what evidence constitutes confidence, how much autonomy a class of work deserves, and when the system has exhausted its authority. Those are human responsibilities, and they place the engineer increasingly above the production line rather than inside every production step.
There will still be moments when someone has to put on the proverbial hard hat and step onto the factory floor. A workflow may repeatedly fail. Permissions may block execution. Requirements may contradict one another. A risk classification may demand explicit approval.
Those are legitimate intervention points, but they should become exception paths rather than permanent fixtures of every software production cycle.
The responsible objective is not to preserve human participation at every layer because humans historically performed every layer. It is to place each form of intelligence where it provides the greatest value.
What We Must Let Go Of — And What We Must Never Surrender
| We must be willing to let go of | We must never surrender |
|---|---|
| Code authored as the measure of engineering value | Human accountability for what the organization creates |
| Routine human implementation as the production model | Product intent and strategic judgment |
| Line-by-line review as the default trust mechanism | Architectural authority and constraint design |
| Prompts as substitutes for engineering plans | Explicit, testable acceptance criteria |
| Human-readable wikis as the only durable engineering memory | Controlled, versioned, machine-consumable context |
| Fixing defects only in the resulting code | Improving the factory that produced them |
Removing humans from routine implementation does not mean removing humans from control. It means moving human expertise to the control surfaces where it has the greatest leverage.
