This article republishes ideas from Addy Osmani’s original blog post with his permission.
The notion of a "software factory" goes back to Bob Bemer’s 1968 paper "The economics of program production" and imagines software as a repeatable manufacturing process rather than the isolated craft of individuals. Recent advances in large language models and tooling have made parts of that vision practical, but they also require clarity about what has truly changed and where old pitfalls reappear.
Three layers: loop, harness, factory
Osmani frames the stack as three nested concepts:
- Loop: a single agent repeatedly performs one job — gather context, act, check, repeat until a condition is met. It is the atomic unit of agentic work.
- Harness: the environment around a loop — sandbox, reachable tools, persistent memory between runs and the gates that define "done." Without a harness a raw model can spin endlessly; the harness makes runs useful and safer.
- Software factory: many harnessed loops running in parallel, fed by a queue, passing automated checks and a review gate, then deployed, with humans owning the outer oversight. A factory is an organizational diagram of loops rather than a larger single agent.
The factory flow
In the factory view, intent and production signals feed a work queue; the harness picks items, builds changes, automated checks vet them, a review gate approves, deploy ships, and monitoring turns production results back into signals. Generation, tests and scans are often cheap and run at scale; the persistent bottleneck is the review gate — human judgment.
Dark versus lit factories
- Dark factory: analogous to physical lights-out manufacturing, a dark software factory ships diffs no human has read, verified only by machines. Osmani cites physical examples like FANUC’s lights-out facilities (operating since 2001) and Xiaomi’s heavily automated 2024 factory to anchor the analogy: in all cases the product is assembled and shipped without a human reading it.
- Lit factory: the same pipeline but with "the lights" left on where judgment matters — humans stay upstream at product, design and architectural decisions rather than merely re-attaching review at the end.
Why dark workflows are tempting and risky
Automated agents can dramatically increase perceived throughput by removing human review. That raises a hidden cost: comprehension debt, the gap between how much code exists and how much humans still understand. A dark factory tends to accelerate that debt while tests remain green, producing a quiet, delayed reckoning rather than a single dramatic failure.
Experience and failure modes
Osmani references Dex Horthy of HumanLayer, who documented running a fully automated code factory for roughly four months during which no human read the produced code; diagnosing the resulting failures required painstaking manual debugging. The tension is between two conflicting metrics: maximizing token utilization (treated as progress) and preserving human comprehension of the system. Dark pipelines excel at burning through pristine code while tests stay green, but they accumulate subtle, hard-to-detect problems over time.
Back pressure: verification is the real bottleneck
The core constraint in a software factory is not generation but verification. "Back pressure" means you can only give a loop as much autonomy as you can cheaply and reliably verify. If the verification neck doesn’t widen, generated work will pile up or produce a surplus of low-quality PRs. Improving the model won’t automatically close that gap because long-term architectural excellence is expensive and slow to measure — costs measured in months or years, not minutes.
When a loop can be dark
A loop deserves full automation only if its check is cheap, runs frequently, and resists easy spoofing. Suitable gates include green/red oracles, type gates, property tests, and a review agent tied to a real rubric. The oracle should respond immediately and remain stable over time. Short loops are easier to verify than sprawling ones.
Dex’s rule of thumb: an agent holds context well for 3–10 steps, and begins to lose the thread past ~20 steps, because context accumulates and the agent wanders. That’s why short, well-scoped loops are safer to automate.
When the lights must stay on
Keep human judgment in the loop when a wrong answer is expensive and only a person can reliably catch it: subtle production bugs that tests miss, changes with large blast radius, or decisions that will shape a year or more of work. The human role increasingly becomes owning the outer loop: decide whether the fix approach is the right long-term strategy, verify the diagnosis and implementation, approve the change, and carry the consequences.
Practical safety nets and architecture
The safety net for model-driven coding is mostly conventional architecture: good types and method signatures, test seams, predictable code layout, short readable call stacks, well-defined component boundaries, and dependency injection. These practices make failures legible and replaceable. Osmani gives an example pattern: a nightly GitHub Actions job that fixes a single anti-pattern and opens a tiny pull request the team can quickly read — a low-risk unattended loop.
Graph vs loop: owning control flow again
In practice you often wrap loops in predefined directed graphs (conditional nodes, explicit edges), effectively reintroducing flowcharts and state machines. That structure provides mandatory checks and clear failure points: when a run dies you can point to the node that failed. The move away from explicit diagrams toward unconstrained loops felt liberating until those loops met long-maintained, complex codebases. Returning to an explicit control-flow graph is largely an admission that we needed the flowchart all along.
Where humans go next
Engineers should increasingly own the outer loop. Agents can investigate bugs, implement fixes and run tests — the inner loop — but the human job is to judge whether the chosen approach is right in the long term and to approve and take responsibility for changes. Robots can operate in the dark; humans must be able to see and understand what they’re doing. If the entire factory floor is dark and there’s no visibility or light switch, the system becomes dangerously brittle.
Conclusion
Model-driven automation has made large-scale software factories feasible, but the limiting factor is reliable verification and human comprehension. The practical challenge is deciding which loops to automate (the short, cheaply checkable ones) and which to keep lit (the high-stakes, architecturally significant ones). A balanced approach — combining harness engineering, deliberate architecture and targeted human judgment — buys back autonomy while containing comprehension debt.
