Governance is not process. It is survival.
John Butler created and maintains SDF as a free, open-source engineering project, drawing on more than 20 years of hands-on startup product and software-delivery responsibility.
Software Dark Factory (SDF) exists because AI-assisted delivery has made an old startup problem more urgent: teams can now produce work faster than they can confidently review, govern, and trust it. The model was not born from a governance framework. It came from the reality of owning software delivery end to end in startups: clarifying ambiguous ideas, building in small implementation steps, testing, deploying, watching production, maintaining systems, and carrying the consequences when things break.
This memo explains why SDF exists, the engineering lessons behind it, and why speed only helps when the resulting work remains reviewable.
The experience behind SDF
Built from full-SDLC responsibility.
For more than 20 years, I have worked in startup environments where the same person often has to move from product definition to implementation, testing, deployment, production support, maintenance, and scaling.
The playbooks behind SDF were not invented as marketing content. They were extracted from real delivery responsibility: solo ownership, small teams, production systems, AI-assisted workflows, and the need to move faster without lowering the engineering bar.
The most dangerous failures were rarely obvious syntax errors. They were changes that crossed hidden business boundaries: pricing, fulfilment, access, commercial commitments, ownership, operational support, or customer trust.
In that context, governance is how teams preserve control as delivery accelerates: keeping intent, risk, evidence, and verification attached to the work.
Why now
Agents make the old discipline explicit.
Experienced engineers already know that loose briefs create expensive downstream problems. Agentic development makes that more visible.
The executor is faster now, but delivery has not become simpler. Faster code generation only helps when the brief, boundary, verification, evidence, and review travel with the change. Agents should strengthen that workflow, not bypass it.
SDF starts with foundations serious software delivery already depends on: clear scope, reviewable changes, executable checks, risk management, proven design patterns, and disciplined delivery. Those foundations still apply with agents in the loop.
A faster way to produce code is not the same as a faster way to deliver software.
Origin and direction
Why “Software Dark Factory”?
Software Dark Factory began with a lights-off ambition: software work performed increasingly autonomously, with minimal human intervention.
Building and testing that idea exposed the foundations reliable delivery still needed. Models could produce working changes, but the result also depended on repository-specific standards, architecture, maintainability, executable verification, retained evidence, and clear authority boundaries.
SDF is the practical layer that emerged from that work. The current Developer Preview keeps human judgement at review, approval, and merge while making more of the delivery process explicit, executable, and inspectable. It does not prove correctness.
The longer-term direction remains progressively greater autonomy. The destination may be lights off; today, the responsible operating model is lights dimmed: more of the delivery process made explicit and executable within clear standards, verification, and human review boundaries. Autonomy should increase selectively, only as work has earned the right to run with reduced human intervention.
Origin proof
Explore was the agent-first proof ground.
Explore My Profile is the real Rails product where this work started: an interactive professional profile designed to be readable by people and accessible to agents.
Its agent-friendly workflow needed clear state, approval, evidence, and boundaries. The delivery discipline around Explore—intent, checks, review, and human decisions—helped shape the approach that became SDF.
Practical benefits
What the SDF loop changes.
SDF makes the engineering expectations around a change easier to see, run, and review without taking the workflow or decisions away from the team.
- Repository-owned standards become visible and executable.
- Verification runs and reruns are recorded honestly.
- Failed or blocked history remains inspectable.
- Reviewers receive clearer intent, limits, checks, and evidence.
- Teams keep their tools, workflow, and human decisions.
- SDF complements coding agents rather than replacing them.
Operating thesis
The goal is controlled speed.
The goal is not uncontrolled automation. It is controlled speed: intent, evidence, checks, review, and human approval remain attached as AI-assisted work moves through the repository.
In the open-source Developer Preview, the SDF CLI makes repository-owned guidance and verification more executable and keeps the history available for review. It works around existing coding agents and team workflows rather than replacing them.
People still decide whether to approve, merge, and release. SDF helps prepare the work for those decisions; it does not make the decisions or prove the software correct.
Writing and public work
The ideas behind the work.
I am not dropping twenty years of delivery practice for agentic speed
Read the essayWrite clean code is a hope, not an instruction.
A public LinkedIn discussion on why agent instructions need examples, constraints, verification, and evidence—not just phrases like TDD, SOLID, refactoring, and clean code.
Read the LinkedIn discussionA note from John
Work and collaboration.
I built SDF to share a practical approach to keeping AI-assisted delivery reviewable. I’m also open to relevant senior product-engineering and hands-on technical-leadership roles, selected consulting work, and thoughtful technical collaborations.