Overlooked Components of the Software Factory
(Or: What we learned turning agent work into a unsupervised software factory)
What We're Building At Fiberplane
Primitives to create your own self-driving software factory
fp: local-first issue tracking for humans and coding agents.drift: Bind docs to code and check for drift.switchyard: a light software factory for Effect.ts monoreposrv: evidence review tool (coming soon!)
Links:

Everyone Is Talking About Software Factories
OpenAI: "An open-source spec for Codex orchestration: Symphony."
StrongDM AI: "Software Factories And The Agentic Moment."
Simon Willison: "How StrongDM's AI team build serious software without even looking at the code."
exe.dev: "Everyone is building a software factory."
"A Dark Software Factory is an autonomous software production loop where agents turn intent into shipped code, validated by scenarios, and evidence, instead of human line-by-line review."
OpenAI's Symphony

What We'll Cover
Issue Tracker (
fp)Orchestrator (Codex)
Workers (Codex in Daytona Sandboxes)
What We Won't Cover
Planning
Review / Verification
Factory Observability
What’s overlooked about them?
How they connect to each other
How the orchestrator picks up and dispatches work to implementer
How code gets pulled in/out of sandboxes
Pulled down from GitHub?
Local worktree scp’d or mounted?
How work on dependent tasks gets merged together
Responsibilities of orchestrator versus the implementer
Who updates tickets?
Who files new tickets? (If out of scope bug found)
The interface
Issue tracker?
Slack?
A Factory Is A State Contract
A software factory is not mainly an agent launcher. It is a consistency contract between four layers:
| Layer | Question |
|---|---|
| Tracker | what work is eligible? |
| Orchestrator | what work is picked up? |
| Worker | what is happening now? |
| Human | what can a human trust? |
Correct means these layers agree. Safe means disagreements are visible before they become silent wrong behavior.
Demo
