Dark Factory

This isn’t just 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)

View Factory Status dashboard

What Dark Factory Means Here

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. Humans approve outcomes; auto-merge is enabled once CI is green.
  6. Cleanup runs as part of the pre-flight before starting the next slice.

Built Like a Production App (On Purpose)

Why Build It This Way

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