Dark Factory
Explore is built with a dark factory delivery model: humans define the intent, the constraints, and the acceptance checks; agents implement the slice; CI and recorded evidence decide whether it is trustworthy enough to ship.
The point is not to remove human judgment. The point is to move human judgment up the stack, away from diff-reading and toward product intent, safety, validation, and shipped outcomes.
What Dark Factory Means Here
In practical terms, dark factory means humans write the spec, set the guardrails, and decide what “done” means. Agents do the mechanical implementation work and keep iterating until the harness is green. Humans review the outcome, not the line-by-line implementation.
That makes the model grounded rather than mystical. It is not “prompt in, magic out.” It is a delivery loop with explicit intent at the start, explicit validation at the end, and agents doing the middle of the work.
How This Repo Runs
Each substantive slice starts with a recorded prompt, a baseline snapshot, and a bounded branch. It ends with a run log, focused verification output, and a PR that links the prompt, the evidence, and the shipped change together.
CI is the gate. If a slice fails, the same PR is fixed until it goes green. Humans then approve the outcome and merge from evidence rather than habitually reading every diff.
That same loop also tracks AI usage and estimated cost on the PR. Once AI is part of delivery, the useful question is not whether it was used at all, but what this slice took and what it cost. That creates a feedback loop tied to the shipped change: prompt quality, context control, model choice, and reasoning effort all become easier to improve over time. It is the same practical point behind “Why put AI usage on the PR at all?”
How This Now Shows Up In The Product
The product itself is now part of the proof point. Explore is being shaped so both humans and agents can understand what state the account is in, what actions are safe, and what should happen next.
That shows up in grounded chat, explicit workflow and step design, safe-next-step guidance in the account flow, and public contract surfaces that are meant to be legible instead of implicit. The clearest example is the Agents page, which shows what this way of thinking looks like when the product itself becomes machine-readable: explicit workflow, explicit state, stable actions, and visible guardrails.
The goal is not to make the product “for agents only.” It is to make the system clear enough that humans and agents can operate it with less ambiguity and less hidden workflow knowledge.
Why Build It This Way
A better delivery model produces a better product. If the build process depends on tribal knowledge and informal diff review, the product tends to inherit the same ambiguity. If the build process depends on explicit contracts, visible evidence, and safe operating rules, the product gets clearer too.
That matters here for trust, for scaling engineering work, and for making this project a real case study rather than an opinion piece. The result should be a stronger public product, a more legible internal system, and a more practical path for applying dark-factory ideas inside larger Rails codebases.
Origin And Further Reading
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)
For the live product contract and agent-readable surfaces, see the Agents page.