Stop Calling it a Factory — Caleb's notebook

There is a lot of talk about building software factories, completely automating the software development process so agents are doing all of the work instead of software developers.

I am onboard with the goal. I am actively working toward further automating our development process using AI agents.

Fundamentally, this is what we’ve always done as software developers. We build software to help the process of building software to be faster and more enjoyable while we build software. We even give away most of the tools we build for free. More than that, we listen when people tell us the tool we built and gave away for free is broken and we spend the time to try to fix it. Crazy right?

All of that is great and I support it. But. It’s not a factory we are building. The language we use here is important because calling it a factory diminishes the goal we are pursuing and the problems we are solving. We are doing something more difficult than building a factory.

What is a factory?

Hand-drawn diagram: input, arrow, a box labeled factory, arrow, output

A factory makes sense when:

I need to make a bunch of one thing (or a few things)
I want to be able to efficiently and reliably make a bunch of that thing
The final product is fully specified outside of the factory and prior to the factory producing anything
The factory’s job is done when the thing exits the factory
The factory’s efficiency at scale outpaces the initial and continued investment to maintain the factory

When I want to make a new thing, I can’t just do that with an existing factory. An existing one might be able to be reconfigured to support producing a new thing. Just as likely, a new factory is needed.

The only way this makes sense as a mental paradigm for software development is if you argue that all software is built with the same parts, tools, skills, etc. and that means we can create a completely generic enclosure capable of producing anything. If that is the logic, good luck to you. Yes, theoretically if you break things down far enough, all software is made with the same parts. Cars, airplanes, and cereal are also all made of atoms. We don’t manufacture all of those in the same factory.

We are not building software factories. The software is the factory.

What are we building? What can it do?

Hand-drawn diagram: input, arrow, a box labeled the software, arrow, output; underneath, the crew loops back, taking feedback and errors from the output and building, fixing, adding, removing and validating the software

It is meant to build, maintain, and improve a specific factory (piece of software)
It can add entirely new functionality
It can remove functionality
It can build a prototype you can demo to customers
It can receive and process customer feedback
It’s actively listening for errors and defects affecting users
It can validate its own changes to ensure it doesn’t break previous functionality
It can do (almost) everything that it previously took a team of engineers to do

The software is the factory. We are building the pit crew, the QA team, the maintenance team, and everything else necessary to build, tune, optimize, fix and expand the capabilities of the factory. And it will be able to do this work better and faster than a team of human engineers could do it.