AI can produce code faster than most organizations can review, release, and learn from it. That is the promise behind the dark software factory: requirements go in, working software comes out, and much of the delivery process runs autonomously.
The promise is attractive. It can also hide the real constraint.
A faster coding step does not automatically create a faster, safer, or more useful delivery system.
If you ask me, a quick litmus test for whether you need a software factory is to think about what happens if all of your engineers leave tomorrow? Can you still ship code? Is that critical for you? If yes, then you need a software factory because this is an asset that you own instead of a typical cost center in your profit and loss statement. It can enable you to continuously produce software from every role inside of your organization instead of only from engineers.
Before trusting a software factory vendor with production software, buyers need evidence that the system understands the product, fits the organization, and produces changes that can be independently verified.
What is a dark software factory?
A dark software factory is the vision of an automated delivery system that can turn an objective or requirement into deployed software with limited human intervention. The shorter industry term “dark factory” can also describe physical automation, so we use “dark software factory” here to make the software-delivery scope explicit.
Coding agents are part of that system, but they are not the whole system!
A complete factory also needs product context, planning, architecture, testing, security, release controls, observability, feedback, and clear accountability.
That distinction matters. A coding agent performs work. An AI software factory defines how that work becomes an accepted software change. The factory is the operating model around the model.
Watch the webinar
In this webinar, we examine three common dark software factory claims and explain what business leaders should ask before buying into them. The article below distills the main argument into a practical vendor checklist.
Fallacy 1: Faster code means faster delivery
Generating code is only one stage of delivery. We will never get bored repeating this so lets go:
- Requirements still need to be understood.
- Changes still need to be reviewed, tested, integrated, released, monitored, and supported.
- If coding becomes dramatically faster while those activities remain unchanged, the bottleneck moves downstream. Teams receive more changes than they can confidently evaluate.
This is why output volume is a weak success metric.
I’m not surprised that DORA’s delivery metrics balance throughput with instability. Lead time matters, but so do failed changes, recovery time, and rework.
If you outsource your software factory build then a vendor should show that accepted outcomes improve without shifting hidden work into review, incident response, or maintenance.
Industrial automation offers a useful warning here by the way. Adidas reported that its Speedfactories shortened development and production lead times. It later transferred the technology into its wider Asian supplier network to improve capacity use, flexibility, and economics, while discontinuing production at the original sites.
What do you take from this? For me the lesson is not that automation failed. It is that speed has to work inside the broader operating system!
Small tasks, routine upgrades, and well-specified bug fixes can still be excellent starting points. They are bounded, their outputs are easier to verify, and mistakes are usually reversible. The mistake here is treating success on a bounded task as proof that the same system can autonomously handle an entire product.
Fallacy 2: The model removes the capacity problem
A stronger model can remove effort from implementation, but it does not remove the need for product judgment, architecture, context management, evaluation, security, governance, cost control and so on.
Capacity moves into building and maintaining the harness around the model.
Let me rephrase:
- the model itself should be replaceable.
- Models improve, prices change, and different tasks favor different tools.
- The durable investment is the system that supplies trustworthy context, limits permissions, checks outputs independently, records decisions, and escalates uncertainty to the right person.
In our own delivery work, projects perform better when implementers have enough context and authority to challenge assumptions.
A handoff model that expects engineers, or agents, to execute instructions without questioning them can automate the wrong decision very efficiently. This is why code generation is only part of delivery.
Fallacy 3: One generic factory can fit every organization
Reusable infrastructure is valuable. Agent runtimes, connectors, sandboxes, evaluation tools, and orchestration platforms can accelerate construction. But a generic tool does not arrive knowing your product strategy, architecture, release process, risk tolerance, customer commitments, or definition of acceptable work.
Consider a request for a customer dashboard. A system may correctly produce names and contact details while missing the business need to understand churn, lifetime value, and acquisition cost. The software can be technically correct and strategically wrong. Without product context, the factory creates more back-and-forth rather than less.
The practical answer is not to reject generic platforms. It is to understand where they sit on the dark software factory automation spectrum. Generic infrastructure can be a strong foundation. The operating factory still has to be adapted to the organization.
What a credible factory must understand
Product
The system needs access to product strategy, business objectives, current customer feedback, and the reasons behind a requirement. It also needs a reliable way to detect missing context and ask for help instead of confidently filling the gap.
Process
The factory must fit the real delivery process: how work is planned, reviewed, tested, released, observed, supported, and improved. It needs explicit handoffs between automated and human-controlled steps.
Standards
Architecture, design systems, testing, reliability, security, infrastructure, compliance, and service levels must be encoded as enforceable controls. Independent verification for autonomous delivery matters because an agent’s own report is not independent proof that its change works.
10 questions to ask a dark software factory vendor
- Which delivery bottleneck does the system remove, and what might replace it? Ask for a before-and-after value-stream view, not a coding-speed demo.
- How does it receive product strategy, business context, and current customer feedback? Ask to see the actual context sources and update process.
- What happens when a requirement is incomplete or strategically wrong? Ask for an escalation trace showing that the system can stop and request clarification.
- Which delivery steps are encoded, and which remain human-controlled? Ask for the workflow and approval boundaries.
- How are architecture, design, security, compliance, and reliability standards enforced? Ask for policy checks, architecture decisions, and evidence from a sample change.
- What independent evidence proves that a generated change works? Ask for evaluation results, test evidence, a deployment record, and a rollback demonstration.
- Which actions require human approval, and who remains accountable? Ask for the permissions model and a clear responsibility map.
- Which outcome metrics are tracked? Look for accepted changes, escaped defects, rework, review burden, lead time, and cost per accepted change, not lines of code.
- Who maintains the harness as models, systems, rules, and business processes change? Ask for the operating plan and ongoing cost model.
- What can you retain when the vendor relationship ends? Ask for a handover plan covering code, context, evaluation evidence, audit logs, and operating knowledge.
These questions turn a broad promise into evidence a buyer can inspect. They also expose whether the vendor is selling a useful component, a managed service, or a complete operating system. The distinction affects cost, ownership, and risk.
When generic tools are enough
Not every organization needs a bespoke factory. Generic tools can be enough when work is bounded, success can be checked objectively, consequences are limited, and changes are reversible. Internal learning experiments are another good use because their purpose is to discover where automation helps before expanding its authority.
As scope and consequence grow, the surrounding controls need to grow with them. Teams should add autonomy gradually, measure useful outcomes, and keep engineering controls for AI-generated software visible throughout the process.
Frequently asked questions
Is a dark software factory the same as an AI coding agent?
Nope! A coding agent completes implementation tasks. A dark software factory connects product context, implementation, independent verification, release, operations, and feedback into an automated delivery system.
Does AI-generated code always create technical debt?
No. Technical debt grows when changes are accepted without sufficient context, standards, verification, ownership, or maintenance. Those risks exist with human-written code too, but automation can increase their volume and speed.
What should buyers measure first?
Start with the delivery constraint you expect the system to remove. Then measure accepted outcomes, lead time, defects, rework, review effort, recovery, and total cost. Avoid treating generated code volume as business value.
Start with the constraint, not the tool
The most credible dark software factory is not the one with the most impressive coding demonstration. It is the one that can explain its context, controls, evidence, ownership, and limits.
Before buying another AI coding product, identify the constraint that is actually slowing delivery. Bring Camplight your largest bottleneck for a focused 30-minute assessment. We will help determine whether the right response is automation, a bespoke harness, process change, or no dark software factory at all.
