← Back to all posts

The economics of the dark factory: what happens when code is free

When implementation cost approaches zero, the economics of software production invert. The scarce resource is no longer coding — it's specification, validation, and trust.

dark-factoryeconomicssoftware-engineeringagentsbusiness

Software has always had unusually favorable marginal economics. Once written, a piece of software can be copied and distributed at near-zero marginal cost. This is why software businesses scale differently from physical-goods businesses.

But there was always a catch: the first copy was expensive. Writing the software required skilled labor, and that labor was the dominant cost in software production. The marginal cost of distribution was zero, but the fixed cost of creation was high.

Dark factories change this. When AI agents write the code, the fixed cost of creation drops dramatically. Not to zero — specification and validation remain — but to a fraction of what it was. This rewrites the economics of who can build software, how software businesses are structured, and where value accrues.

The cost structure before and after

In a traditional software team, the cost structure looks roughly like:

  • Implementation labor: 50-60% of engineering budget (writing code, reviewing code, iterating on code)
  • Specification and design: 15-20% (architecture, technical specs, product requirements)
  • Testing and validation: 15-20% (manual QA, automated testing, integration testing)
  • Operations and maintenance: 10-15% (deployment, monitoring, incident response)

A dark factory compresses the implementation bucket. StrongDM's team of three engineers, spending over $1,000 per engineer per day on AI compute, produces the output that would traditionally require a much larger team. The implementation labor cost is replaced by compute cost — and compute, unlike labor, is elastic, scalable, and improving in price-performance with every model generation.

The post-factory cost structure shifts toward:

  • Specification and design: 40-50% (this becomes the primary engineering activity)
  • AI compute: 10-20% (the new variable cost — roughly $1K+/engineer/day at current StrongDM-level spend)
  • Testing and validation: 20-30% (validation becomes more important, not less, when code is AI-generated)
  • Operations and maintenance: 10-15% (similar, but with new challenges around specification drift)

The total cost is lower — sometimes dramatically lower — but the composition is different. Engineering effort concentrates at the top of the funnel (specification) and the bottom (validation), with the middle (implementation) largely automated.

The StrongDM benchmark

The StrongDM case study provides the first real-world data point. Three engineers, operating under the rules "code must not be written by humans" and "code must not be reviewed by humans," producing at a rate that would traditionally require a significantly larger team.

The most striking number is the compute spend benchmark: if you are not spending at least $1,000 per engineer per day on AI compute, "you have room for improvement." At current model pricing, that buys an enormous volume of agent execution. Claude Opus 4.8 at list price is $15/MTok input, $75/MTok output. A thousand dollars buys approximately 13 million output tokens — the equivalent of generating tens of thousands of lines of code, plus reviews, plus test generation, plus iteration on failures.

Compared to a fully-loaded senior engineer cost of $600-800/day (salary, benefits, overhead), the math is straightforward: if the AI can produce even a fraction of that engineer's output at a fraction of the cost, the economic advantage is compelling. And the AI does not take vacations, does not switch jobs, and improves in capability with each model release.

The margin structure of dark factory businesses

This cost structure shift has specific implications for different business models:

SaaS businesses. The traditional SaaS cost structure has high initial engineering investment and low marginal cost per user. Dark factories compress the initial investment, making it feasible to build and maintain SaaS products with smaller teams. The competitive dynamic shifts: incumbents with large engineering organizations lose their headcount advantage against smaller, factory-enabled competitors. The moat moves from "we have more engineers" to "we have better specifications" — which is a very different kind of moat.

Agencies and consultancies. The traditional agency model sells engineer hours. More work requires more engineers, and revenue scales roughly linearly with headcount. A dark factory breaks this relationship. A small team can produce the output of a much larger one, which means revenue per employee can increase dramatically. But it also means the sales pitch must change: you are no longer selling "we have great engineers who will write your code." You are selling "we have great spec writers and validators who will define exactly what should be built and verify that the AI built it correctly." The client must be sold on the process, not the headcount.

Vertical software. The most interesting play may be in vertical SaaS — industry-specific software for niches that were previously too small to justify a dedicated engineering team. When the fixed cost of creation drops, the addressable market for custom or semi-custom software expands. Problems that couldn't support a five-person engineering team may support a one-person team plus a dark factory pipeline. The long tail of software opportunities becomes economically viable.

Where the money goes

If implementation is commoditized, the economic value in the software supply chain concentrates in three places:

1. Specification expertise. The people who can define precisely what should be built — domain experts who understand the problem, product thinkers who understand the user, architects who understand the system constraints. These people were always valuable. In a dark factory world, they are the primary constraint on output. Their leverage increases because their specifications can be executed at machine scale.

2. Validation infrastructure. The tooling that verifies AI-generated code against specifications, catches specification drift, and provides the audit trail for compliance and trust. Companies like CodeRabbit are early entrants here, but the category is wide open. Validation is not just testing — it is the entire chain of evidence from specification to acceptance, and it needs to be automated at the same scale as the code generation it checks.

3. Trust and distribution. When code is commoditized, the question "can I trust this software?" becomes the buying decision. The dark factory operator who can demonstrate rigorous validation, clean audit trails, and proven reliability has a structural advantage over competitors with similar output quality but weaker trust signals. This is especially true in regulated industries — finance, healthcare, infrastructure — where "an AI wrote this" is currently a liability that must be offset by evidence of correctness.

What breaks the model

The economics are compelling, but they rest on assumptions that can fail:

Model pricing does not stay flat. If AI compute costs increase — through provider consolidation, demand exceeding supply, or regulatory intervention — the cost advantage of dark factories over traditional teams shrinks. Conversely, if costs continue their current trajectory downward, the advantage grows. The economics are tied to a variable that teams do not control.

Specification costs may be higher than expected. The assumption that specification is cheaper than implementation depends on specifications being less voluminous and less complex than the code they replace. This may not be true. A specification precise enough for machine execution may approach the complexity of the code itself — different in form, but similar in information content. If so, the cost savings are real but smaller than the headline "code is free" suggests.

Quality externalities may dominate. If AI-generated code carries higher defect rates that must be caught in production, the operational cost of dark factory software may offset the development savings. This is the "specification debt" problem: flawed specs produce flawed outputs faster and more confidently than human teams would. The total cost of ownership may be higher even if the initial development cost is lower.

Trust is not free. For enterprise buyers, "no human reviewed this code" is currently a negative signal. Building trust — through validation infrastructure, audit trails, compliance certifications — costs money. The trust premium may erode some of the cost advantage, especially in the early years.

The equilibrium

Where does this settle? The most likely equilibrium is not "all software is built in dark factories" but a hybrid: dark factories handle the large fraction of software that applies well-understood patterns to business problems (CRUD, auth, API plumbing, dashboard construction, data pipelines), while human-led development handles genuinely novel systems, cutting-edge research, and domains where the cost of getting it wrong is catastrophic.

This is already the shape of the StrongDM experiment. The dark factory handles the predictable work. Humans handle the specification, the validation, and the exceptions. The ratio will shift over time as models improve and tooling matures, but the principle — factories for the known, humans for the unknown — is likely durable.

The economic prize is enormous: a large fraction of professional software development falls into the "well-understood patterns applied to business problems" category. Moving that work from labor cost to compute cost is one of the largest productivity improvements available in the global economy. The teams that figure out how to do it well — with rigorous specification, automated validation, and earned trust — will have a structural cost advantage that compounds with every model generation.

References:

Systems design is the core engineering discipline. Every system — whether a dark factory, an agent governance framework, or a software architecture — involves the same set of decisions: what are the components? what are their interfaces? what changes do we hide? what stays stable? The engineer who can answer these questions can design any system. The domain provides the constraints. The principles provide the method.

When code is free, the scarce resource shifts from implementation to specification. The person who can say exactly what to build becomes more valuable than the person who can build it. The economics invert.