---
title: Dark Factory
slug: dark-factory
type: concept
created: 2026-06-17
updated: 2026-06-17
status: active
tags:
  - dark-factory
  - automation
  - validation
  - software-engineering
sources:
  - dan-shapiro-you-dont-write-code-2026-02-13
  - 2389-dark-factory-dot-file-2026-03-09
  - jleechanorg-dark-factory-repo
related:
  - software-factory
  - dot-pipeline
  - code-review-vs-validation
  - digital-twin-universe
confidence: medium-high
contradictions:
  - Dark factory rhetoric minimizes human code reading, but practical systems still need humans to define intent, gates, threat models, and acceptable risk.
bead_refs:
  - dark-factory-rr4
---

# Dark Factory

A dark factory is a software production model where humans specify intent and validation policy while automated agents generate, test, repair, and ship code with minimal direct human reading of generated diffs.

## Core Claims

- The bottleneck shifts from writing code to designing a system that can safely create and validate code.
- `inference:` The durable work is not the emitted code alone; it is the factory definition: specs, process graphs, validation contracts, holdouts, evidence, and observability.
- Code review becomes less central than outcome validation, independent review, sandboxing, and telemetry.
- The strongest versions require realistic evaluation environments such as [[digital-twin-universe]], durable process artifacts such as [[dot-pipeline]], and repair loops such as [[healer]].

## Practical Definition

A dark factory is not "LLM writes a patch." It is a production pipeline with explicit inputs, agent roles, gates, isolated evaluation, failure logging, and policy for retries or human escalation.

## Open Tensions

- Human gates may be necessary, but too many gates recreate the manual bottleneck.
- Disposable generated code sounds freeing, but the runner, tests, and observability stack become critical infrastructure.
- "Do not read code" creates a security problem unless validation can catch unsafe behavior and supply-chain drift.
