fabro/docs/getting-started/dark-factory.mdx
Bryan Helmkamp 829a2b0c13 Add Dark Factory docs page and rebrand as "dark software factory"
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-14 12:05:35 -04:00

70 lines
4.3 KiB
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: "Dark Factory"
description: "How Fabro helps small teams incrementally adopt a dark factory approach to software development"
---
The term "dark factory" comes from manufacturing. Since 2001, FANUC has operated a factory near Mt. Fuji where robots build other robots — running unsupervised for up to 30 days at a time. The factory is "dark" because no humans are present and robots don't need light.
In software, the dark factory concept is different. It doesn't mean zero human involvement — it means **minimal human interaction** with the code itself. Humans supervise the specs, guardrails, and outcomes, not each line of code. Engineers shift from writing and reviewing code to defining what should be built, how quality is measured, and when to intervene.
This is an aspirational concept, and getting there is iterative.
## From coding to orchestrating
Dan Shapiro's [five-level framework](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/) describes the progression from AI-assisted coding to autonomous software production:
| Level | Name | Human role |
|-------|------|------------|
| 0 | Spicy Autocomplete | Copy/paste from chat |
| 1 | Coding Intern | AI writes boilerplate; human reviews everything |
| 2 | Junior Developer | Pair programming with AI |
| 3 | Developer | Most code is AI-generated; human is a full-time reviewer |
| 4 | Engineering Team | Human manages specs and plans; agents do the work |
| 5 | Dark Software Factory | Specs go in, software comes out |
Most teams today operate at Level 2–3: AI writes code, humans review it line by line. The transition from Level 3 to Level 4 is the hardest — it requires replacing ad-hoc human review with structured, repeatable verification that you actually trust.
## What makes it work
The dark factory isn't a single tool or practice. It's a set of capabilities that compound:
**Declarative workflows over imperative prompts.** When the process is a version-controlled graph — not a chat transcript — you can review, iterate, and share it like any other source file. The workflow itself becomes the specification of how work gets done.
**Deterministic verification over human review.** Test suites, linters, type checkers, and LLM-as-judge evaluations replace line-by-line code review. Failures route back to fix loops automatically. Humans define the criteria; the system enforces them.
**Multi-model ensembles over single-model dependence.** Using different models for implementation and verification breaks the circularity problem — where the builder and inspector share the same blind spots. Cross-critique with fresh eyes catches what self-review misses.
**Checkpointed execution over black-box runs.** Git commits after every stage create an audit trail. When something goes wrong, you can inspect, revert, or fork from any point — without having watched the run live.
**Continuous improvement over static processes.** Automatic retrospectives after every run feed a learning loop. Workflows get better over time, not just the code they produce.
## The human role in a dark factory
The dark factory doesn't eliminate engineering judgment. It redirects it:
| Before | After |
|--------|-------|
| Writing code | Defining workflows and prompts |
| Reviewing diffs | Defining verification criteria |
| Debugging test failures | Designing fix loops |
| Watching agent sessions | Reviewing retrospectives |
| Manual quality checks | Tuning goal gates and evals |
The goal is to spend your time on the parts that require human judgment — what to build, how to verify it, and when something doesn't look right — while the factory handles the rest.
## Further reading
<Columns cols={2}>
<Card title="Workflows" icon="diagram-project" href="/core-concepts/workflows">
Learn how workflow graphs orchestrate agents, commands, and human gates.
</Card>
<Card title="Human-in-the-Loop" icon="hand" href="/workflows/human-in-the-loop">
Control where and how humans intervene in workflows.
</Card>
<Card title="Quality Verification" icon="shield-check" href="/workflows/best-practices">
Build verification into your workflows.
</Card>
<Card title="Retros" icon="magnifying-glass-chart" href="/execution/retros">
Automatic retrospectives for continuous improvement.
</Card>
</Columns>