The framing that keeps showing up in AI industry coverage is the overnight disruption story: one morning, engineers wake up and their jobs are gone, replaced by some system that writes, tests, and ships code on its own. It is a compelling story and almost certainly wrong about how this actually unfolds. The more interesting question is what the real adoption curve looks like, because that curve determines which companies build durable positions and which ones get stranded waiting for a transition that arrives more slowly than the hype suggests.
Zach Lloyd’s interview at Latent Space on software factories is worth sitting with here. His account of how the concept developed is telling. It was not a grand vision handed down from some product roadmap. It emerged gradually, as automation capabilities accumulated piece by piece. First came one-off agents running in the cloud. Then agents running on a timer. Then the question of what a fully automated development loop would actually look like. The concept of a software factory, in his telling, followed naturally from watching those capabilities compound over roughly six months. That is a much more modest and realistic origin story than the industry usually tells about itself.
What makes the software factory model interesting as a business problem is where the real friction sits. It is not the technical capability to generate code. That part is largely solved, or at least solved enough that it has stopped being the binding constraint. The binding constraint is organizational trust. Lloyd is direct about this: “Companies will start with specific use cases, certain types of issues or lower-risk repositories. Those are places where they may be comfortable not having a human review every single line of code.” That sentence describes an adoption pattern that looks nothing like disruption. It looks like procurement, pilot programs, and incremental expansion of scope as confidence builds.
This matters because it changes the competitive picture considerably. If adoption is gated by organizational trust rather than technical capability, then the companies that win are not necessarily the ones with the most capable models. They are the ones that can build trust at the organizational level, which means reliability, auditability, clear failure modes, and integration with existing workflows. Anthropic and OpenAI are both selling into this market, but the question of whether their infrastructure actually supports that kind of trust-building is different from the question of whether their models score well on coding benchmarks.
The same pattern has shown up in every prior wave of development tooling. Version control, continuous integration, automated testing; none of these replaced engineers overnight. Each one started in low-risk contexts, proved itself, and then expanded into more sensitive parts of the stack. The software factory concept is following the same trajectory, just at a moment when the underlying model capability is genuinely more impressive than anything in those prior waves. That combination of real capability and slow adoption is what makes this period interesting to watch.
Lloyd’s account of the conceptual development is also useful as a reminder that the most important industry framing often does not come from the model companies themselves. Anthropic and OpenAI set the capability agenda. But the framing that actually shapes how developers and engineering organizations think about what they are buying often comes from people building on top of that infrastructure, working through the practical problems of deployment. The software factory framing is useful precisely because it is operational rather than aspirational. It describes a system with inputs, outputs, and a loop, not a replacement for human judgment.
The honest version of where this goes is probably what Lloyd describes: a gradual expansion from low-risk repositories outward, with human review remaining in place for anything that carries real consequence, and the automation handling a growing share of the lower-stakes work. As Lloyd puts it, “engineers are not going to wake up one morning and discover that a software factory has replaced their jobs.” The job changes shape; the workflow reorganizes around the automation; the scope of what requires human attention narrows. That is a real and significant shift, but it is a different kind of shift than the overnight replacement story, and it has different implications for every company building in this space.
The posts in this archive on Anthropic’s enterprise positioning and OpenAI’s deployment infrastructure keep circling the same problem: capability is necessary but not sufficient. The companies that figure out how to make the gradual adoption curve work in their favor, by meeting organizations where they actually are rather than where the hype says they should be, are the ones worth watching as this particular transition unfolds.