# Software Factories, Light and Dark
The concept of a software factory represents a fundamental shift in how development organizations scale work. At its core, a software factory automates the repetitive loops that developers execute daily. The factory framework runs these loops at different speeds depending on human involvement.
A light factory keeps humans in the loop. Developers maintain judgment and concentration while trading some speed for reduced errors and better oversight. This model preserves human decision-making at critical points. Teams can catch problems before they cascade. The tradeoff is straightforward. Human review takes time. But that time prevents expensive failures.
A dark factory removes humans from the loop entirely. Automation handles code generation, testing, deployment, and monitoring without human intervention. Speed increases dramatically. Breakage risk also increases, but proponents argue systems designed properly catch failures at scale before users see them. The dark factory bets on automation reliability.
The distinction matters because it frames how enterprises think about developer productivity. Light factories treat developers as the rate limiter. Removing friction around their work multiplies output. Dark factories treat humans as the rate limiter. Removing them entirely multiplies output further.
Both approaches harness continuous loops. Code gets written, tested, deployed, and monitored constantly. Light factories add human gates at strategic points. Dark factories eliminate gates and trust instrumentation instead.
Current AI capabilities accelerate dark factory thinking. Large language models can generate code candidates at scale. Automated testing frameworks validate those candidates. Deployment pipelines push changes live without human review. Observability systems catch regressions. The loop becomes a fully autonomous cycle.
The implementation question turns on risk tolerance and domain. Financial services and healthcare systems tend toward light factories because regulatory requirements and liability stakes demand human judgment. Consumer products with rapid iteration cycles and high tolerance for small failures often run darker operations.
Organizations often run both simultaneously. A dark factory handles routine updates to stable modules. A light factory oversees critical business logic and customer-facing features. The boundary between them shifts as confidence in automation grows.
The real tension surfaces around accountability. Dark factories create attribution problems. When automation breaks something, who owns it? The engineer who wrote the rules? The team that trained the system? The organization that chose to remove humans? Light factories answer this clearly. Humans reviewed it. Humans approved it. Accountability flows backward.
Addy Osmani's framing highlights that factories represent a spectrum, not a binary choice. Most mature teams operate somewhere between extremes. They optimize for their risk profile and competitive constraints. Fintech companies moving fast in low-regulation spaces might run very dark operations. Enterprises in regulated industries run very light ones.
The evolution toward darker factories accelerates as AI models improve. The practical question for engineering leaders is not whether to adopt factory thinking, but where on the spectrum their organization should operate. That depends on tolerance for outages, regulatory requirements, customer expectations, and engineering culture. The software factory paradigm simply makes those tradeoffs explicit.