Software Factories for Skeptics

Are you one of those AI-pilled people who is still skeptical of software factories? If you’re tired of all the blogs about software factories, here’s one more. But hopefully this one can explain why the concept is actually a lot more digestible than you might think.

The skepticism is understandable because the version most people are reacting to is a lights-out operation. The one where tasks come in, agents plan the work all by themselves, write the code independently, test it, review it, and ship it without humans touching the implementation.

Dex Horthy has written about HumanLayer’s attempt to build a lights-out software factory and why they eventually moved away from it. A system where nobody reads the code and agents continuously ship changes is still a pretty aggressive bet.

Not only are dark factories not where we are today, they’re also probably too dystopian to be desirable anyway.

It turns out there are plenty of practical, engineering-driven reasons to justify a software factory today, using a different definition. A software factory doesn’t have to mean removing humans from software development, and it doesn’t even have to mean changing that much about how developers work.

So what does a software factory actually add if humans are still doing much of the work? How does it fit around the coding assistants developers already use? And what do companies gain when the work, data, and process are part of a shared system?

There are some practical aspects of software factories that are worth considering.

Light Factories

Addy Osmani’s distinction between light and dark software factories is a good starting point. A dark factory is the fully autonomous version where agents handle most of the development process and humans largely stop reading the code. A light factory keeps humans involved in planning, implementation, review, and approval.

For the skeptics, the most important takeaway is that light factories are still factories. Factories of all kinds have always had humans working in them. Automation changes what people do and how many people are required, but the factory is the larger system used to organize and scale production.

And as you’ll see below, the system is the part worth investing in. It’s where your engineering operation differs from someone else’s, and it might become a competitive advantage in a world where coding agents can spit out code effortlessly.

Whether you automate a small part of that system or most of it, it’s still your system. The level of automation can vary without changing the system around the work. The factory is that system, and you’ve always had some version of it.

Coding Agents Have Built-In Ephemeral Factories

Take a look at what happens inside a modern coding assistant. Give it a sufficiently complicated task and it might launch a subagent to investigate the repository, another to research a dependency, and another to review the resulting implementation. At that point you already have something that looks a lot like a small factory with workers.

But those “dynamic workflows,” as some coding agents call them, are also increasingly ephemeral. The model decides what the work breakdown should be, spins up those workers, and then throws away the plans (and the recipes) after it’s done.

Their findings get summarized back into context, but the decomposition of the work and the workers largely disappears when the run finishes. We keep the resulting code, but surprisingly little of the structure around how the work was produced.

In a company with a lot of developers, this is happening over and over inside each developer’s coding session, using whatever approach the model comes up with each time for that scenario.

A software factory abstraction, if you embrace it, could simply mean putting a system around that work, making more of the work breakdown process reusable and more consistent with your system. Seems practical, right?

Visibility of Everyone’s Coding Sessions

Imagine 100 engineers working in their own Codex or Claude Code sessions. Each engineer has a coding assistant, each assistant can launch its own workers, and some developers might have several coding loops running at the same time.

From the perspective of the organization, its managers, and other related teams, most of this activity is invisible. There is usually a ticket at the beginning and eventually a commit or pull request at the end. But most of the work between those points is happening inside individual coding environments.

A factory gives you a pane of glass across that activity. You can see what is being worked on, where agents are stuck, and where humans are intervening. If you don’t trust your agents (and maybe you shouldn’t), this feels fairly important.

The factory doesn’t necessarily need to own the coding environment, although many commercial software factories do. Ideally, one developer can keep using Codex, another can use Claude Code, someone else can write the implementation themselves, and background agents can run as well. The factory provides a common system and view across all of them.

Factory Work Is Still Iterative

Even in the scenario where the factory produces the initial pull request in response to a ticket, it doesn’t mean the agent gets one shot and the work is done. The development process can still look surprisingly similar to the way you work locally with a coding assistant today.

In Codex or Claude Code, you might let the agent implement something, review what it did, tell it that it misunderstood a requirement, and ask it to make another change. You keep steering the agent until you’re happy with the result.

A factory can work the same way. An agent picks up a task and opens a pull request, a developer reviews it and leaves comments, someone adds more context to the ticket, and the agent picks the work back up. There can be as many iterations between humans and agents as the work requires.

The biggest difference, again, is visibility to the organization. In your coding assistant, most of the feedback, decisions, and intermediate work are trapped inside your session. In a factory, the same process can happen through shared systems where the rest of the organization can see it.

With the factory pattern, you’re not giving up the ability to steer the agent. You’re just moving that interaction into a system that you’ve designed.

Software Factories Are Data Factories

When we say visibility is lost in all of those local coding sessions, we really mean there is a missed opportunity to mine those interactions for useful data.

Coding assistants generate an enormous amount of information while they work, such as what approaches they used, what tests they ran, when they had to ask humans for help, and whether they understood the documentation and architecture.

Without investing in a system to mine that data, it’s almost certainly getting lost. It’s true that some of it exists in Git, CI, and issue trackers, but not the sort of implementation and process-level data that could help you improve your system.

The factory gives you a place to connect that data. Across thousands of tasks, you can start seeing which kinds of work consistently need human intervention and where agents get stuck. You can compare different prompts, models, and verification approaches against the results they actually produce.

Once you have all that data, you’re at a point where you can learn from it and start improving your system. You need a system in the first place, and then you need data about how that system operates. Only then can you improve it.

Factory as Code

Once you have that data, you also need something to iterate on and improve. With independent coding assistants, what is that thing? Perhaps an AGENTS.md file checked into a repo, but not much more.

The system you want to build is actually much richer than that. You want to describe the transformations in your process through a series of standard prompts, while making verification requirements, model routing, tools, context, policies, and human approval points defined parts of the factory.

That’s why many software factories are their own Git repos, and the contents of those repos can range from actual code to Markdown to config files. But all of it is version controlled, human and agent editable, and testable.

You can then iterate on those pieces as a system. A prompt change can be measured against outcomes, and different models can be tested against different kinds of work.

It doesn’t mean you’re source controlling every task or everything your factory can do, just the shared pieces you want to make repeatable and consistent.

The Strategy Loop

Most concepts of software factories focus on the main factory and worker loops. Work comes in, the factory loop breaks it up and assigns it to one or more worker loops or agents that execute it, and software comes out. But it’s helpful to think about another loop that is more strategic to the factory.

One version of this is the self-improving factory. All of the data the factory collects can be used by an agent to improve the factory itself. It can identify repeated mistakes and propose changes to instructions (with approval, of course), find missing context, and surface performance issues.

Another manifestation could be an agent loop that is continually trying to understand your business and keep the factory up to date. This could mean tracking features, product decisions, architecture, customer feedback, and other work to build up knowledge bases or context graphs that future agents can use.

Or, even better, all of that context can be used to change the design and shape of the factory itself to better match how the company actually works.

It’s Semantics

The term “software factory” is largely an expression of a set of useful design patterns that, when applied, might improve the way your company builds software. In that sense, it’s hard to argue with at least some of these patterns being valuable.

But a software factory can also become a semantic lens over your entire engineering operation, or maybe even your entire company. It’s a system that understands how each engineer works, what tools they use, how work gets done, and how all of those pieces fit together.

I would argue that if you adopt even one of the patterns above, you already have some aspect of a software factory. Perhaps we’ll eventually come up with a better name that causes less skepticism.