Why AI-first engineering ultimately requires machines to build the software, machines to challenge the software, and humans to design the factory that makes the outcome trustworthy.
The Uncomfortable Conclusion
There is a position in the industry today that sounds appropriately responsible: use AI, but carefully. Let it generate some code. Perhaps ten percent, twenty percent, or eventually half. Keep developers in control. Have humans review everything. Preserve the existing Software Development Lifecycle, insert AI wherever it improves productivity, and collect the resulting efficiency gains.
That is a perfectly reasonable way to begin adopting AI. It is not where this ends.
Once an organization has demonstrated that machines can reliably perform implementation within mature architectural, security, quality, and governance constraints, continuing to require humans to participate in every implementation step is no longer inherently safer. At scale, it becomes the bottleneck.
A system capable of generating software at ten times human speed but requiring every generated line to move through a one-times-speed human review process is not a ten-times system. It is a one-times system with a very large queue. We have accelerated one station on the production line while leaving the architecture of production unchanged.
The apparent safety of exhaustive human review also becomes questionable as machine output grows. A skilled engineer can thoughtfully review hundreds of lines of code. Thousands become difficult. Tens of thousands become superficial. When autonomous systems can alter broad architectural surfaces while producing implementation, tests, migrations, and configuration together, pretending that a person reading every resulting line remains the primary mechanism of trust eventually becomes more ritual than control.
The question therefore has to change. Instead of asking how much AI-generated code we are comfortable allowing, we should ask:
What engineering system would need to exist before human implementation and line-by-line human review were no longer necessary as routine parts of software production?
That is the dark factory question.
AI-Assisted SDLC Is Not the Destination
Most organizations today are still trying to fit AI into an operating model designed around human implementation.
A developer receives a ticket and remains responsible for implementing it. An AI assistant helps formulate the solution. Perhaps an agent writes the first version. The engineer inspects the result, modifies it, creates a pull request, and another engineer reviews the work. Tests and security checks execute before a delivery pipeline eventually moves the result toward production.
That model can be far more productive than traditional development, and there is nothing inherently wrong with it. Structurally, however, remarkably little has changed. The human remains the production worker and AI has become a more sophisticated power tool.
That is AI-accelerated SDLC.
A true Agentic or AI Development Lifecycle, an ADLC, is different because it inverts the relationship. Machines become the primary production workforce while humans increasingly design and govern the production system.
That distinction is why I resist describing the transition merely as AI-assisted software development. Assistance preserves the existing hierarchy. Dark factory engineering replaces it.
The mature system is no longer a developer sitting inside an IDE asking an agent to make changes. It is an engineering environment capable of accepting structured intent, orchestrating specialized intelligence, validating what that intelligence produces, enforcing policy, and escalating only when the production system reaches the boundaries of its authority.
At that point, the IDE becomes incidental. Individual models become replaceable workers whose performance can be measured and whose assignments can change as stronger intelligence emerges.
The factory becomes the product.
Autonomy Is Not Maturity
One useful reference point comes from Shapiro's five-level framing, which maps AI coding to the familiar idea of increasing driving automation. At its highest level, the software process becomes a dark factory: effectively a black box that transforms specifications into software without humans participating in implementation. [1]
I agree with the central inversion.
I would draw the maturity boundary differently.
The industry tends to discuss this transition primarily along one axis: implementation autonomy. How much code does AI produce? How little does a human have to touch it? At what point does the human stop reading the diff?
Those are important questions, but they describe only half of the system.
The second axis is governance maturity.
An organization can be highly autonomous in implementation and immature in governance. It can operate sophisticated agents while possessing weak evidence, poorly defined authority, untrusted context, ambiguous escalation, or little ability to explain why the system did what it did.
That is technically advanced automation.
It is not a mature dark factory.
Conversely, an organization can have strong governance while retaining humans throughout implementation because it has not yet earned enough confidence to remove them. These are separate dimensions, and treating them as one creates a dangerous assumption: that increasing autonomy automatically represents increasing engineering maturity.
It does not.
The destination I am describing sits toward the upper end of both dimensions: high implementation autonomy and high governance maturity.
That leads to a crucial distinction:
No human code review does not mean no human review.
This distinction is especially important for security-sensitive, safety-critical, regulated, or otherwise high-risk work. A mature autonomous production model does not imply universal removal of human oversight. These workloads may retain explicit human review or approval boundaries even when routine implementation elsewhere becomes highly autonomous. Human accountability remains; what changes is where that authority is exercised.
Humans stop routinely reviewing the artifact that machines are becoming better suited to produce. Human authority moves toward product intent, architecture, risk, governance, evidence, exceptional conditions, and the outcome that ultimately matters.
The objective is therefore not maximum autonomy everywhere.
It is maximum justified autonomy inside explicit boundaries.
That is the dark factory I believe enterprises should be building toward.
What a Dark Factory Actually Is
The term comes from manufacturing. A highly automated production facility does not require people standing beside every machine, and in the extreme case the production floor can operate without illumination because the machinery performing the work does not need the lights.
There is an important limitation to that analogy.
Software factories are not generally producing ten thousand identical copies of a verified design. Much of software engineering remains bespoke, and each plan entering the factory may describe something the system has never built before.
What becomes industrialized is not the product. It is the production discipline.
Risk classification can repeat. Planning contracts can repeat. Validation responsibilities can repeat. Evidence requirements, retry semantics, escalation policy, and governance can repeat even when the resulting software is different every time.
Traditional manufacturing controls variance in the product by repeating a design. Dark factory engineering controls variance in the process by repeating the rules under which novel designs are produced.
We are not mass-producing software. We are industrializing the system that produces it.
A dark software factory is therefore not a coding chatbot, an IDE agent, an enormous prompt, or unattended vibe coding. It is not an autonomous model with permission to modify a repository and the hope that everything works out.
A dark factory is a governed software production system.
Humans provide vetted intent. The factory determines how that intent should be manufactured. Specialized agents perform the work and independent agents challenge it. Policies constrain execution, failures trigger controlled correction, and evidence records what occurred. Risk determines how much autonomy is allowed, while exceptional conditions cause escalation.
The production line can run dark because the governance surrounding it does not.
The important element in that architecture is not any particular agent. Agents will change. Models will change. Harnesses will change. Today's strongest planning model may not be tomorrow's, and a model that excels at implementation may be mediocre at architectural reasoning.
The factory has to survive all of them. We are not designing engineering organizations around AI models; we are designing factories capable of employing them.
