Dark Factory

This website was not built as a personal site with a chatbot.

It is a live experiment in building software with a dark factory delivery model: specs in, software out, with outcomes validated by a harness instead of humans reading diffs.

The trigger was Simon Willison's write-up on StrongDM's Software Factory approach and the provocative stance that no humans should write code or review code.

Full post: Dark Factory: No humans should write code (and what it taught me)

What Dark Factory Means Here

• Humans define intent (specs and constraints).
• Humans define acceptance (scenarios and harness checks).
• Agents implement end-to-end and iterate until the harness is green.
• Humans approve outcomes, not diffs.

How This Repo Runs

1. JOB prompt recorded with goal and acceptance criteria.
2. Run log recorded with verification outputs.
3. PR created with prompt and run log links.
4. CI is the gate; failures are fixed in the same PR until green.
5. Human approves outcomes and merge proceeds.
6. Post-merge cleanup runs on develop, then the next slice starts.

Built Like a Production App (On Purpose)

• Integrations that pull content from external sources.
• Versioned API contracts with tests.
• Admin and maintenance flows for content sync.
• Harness-first CI quality gates.
• Secrets hygiene with fixtures for CI.

Why Build It This Way

• A better personal site for recruiters, founders, and engineers.
• A public case study for guarded agentic delivery.
• A transferable path for dark-factory style work inside larger Rails monoliths.

Factory-Line Analogy

The model is similar to physical factory lines in telecom manufacturing: shared safety and QA standards, with each line owning a bounded station end-to-end.

Applied to a monolith, that means multiple software factory lines with shared guardrails and subsystem ownership.

Where This Is Going

• More external integrations for fresh content.
• AI Q&A with source citations.
• Stronger system tests and eval coverage to reduce human review load.