After the factories

Everyone seems to be building a software factory right now, and the word covers a lot. For some teams it means a few agents opening pull requests. For others, specs go in and running software comes out, and nobody reads the code. At the far end, a rough idea goes in, and the factory writes the requirements and carries them all the way to production, governance included.

So what makes a good one? The shortcut answer would be how much it ships and how little anyone has to touch it. I think that’s a trap. Shipping more doesn’t mean shipping better, and what matters most is still the outcome for the people using it.

Working on one, I’ve come to think getting there is less about the agents than it seems. They’re the part that changes fastest. A new frontier model arrives every few months and can make much of what you built around the last one obsolete. That may change once progress slows down, but for now I’d rather invest in what lasts, which in my opinion is the harness.

The harness is everything the agents run inside: the instructions they follow, the tools, skills and workflows they can use, and guidance on when to use what. It also holds the knowledge no model picked up in training, like the specifics of your business, and checks like tests and reviews.

It works a bit like a restaurant kitchen. Chefs come and go, but the recipes and the way service runs stay, so a new chef can cook well from the first night. A better chef might bring new recipes, drop a few that only made up for the last one, or plate things more nicely, and some chefs work better in certain kitchens. But a chef needs a kitchen, and a kitchen needs a chef. Models and harnesses work the same way.

Now say the factory works. Volume goes up, even if it was never the goal, simply as a side effect of doing things right. And the bottleneck moves to the parts of the cycle that were designed around people: where we decide what to build, and where the work gets merged and shipped.

The deciding part of the cycle: prioritization, roadmaps and quarterly planning were built to ration engineering time, which isn’t what’s scarce anymore. What’s hard now is staying focused on what’s worth building when every idea is cheap to try, and finding out quickly whether it worked. That puts strategy back at the center: defining the vision, where you’re going and what it means for the work. Taste matters more, and experimentation becomes the normal way to ship.

The shipping part of the cycle: this is where frontier labs are already running into issues, and talking publicly about how they’re handling them. In October, Anthropic wrote about replacing Git internally with its own system, Scion, after merges went from about 2,500 a day in May to over 30,000 by September. OpenAI kept Git on the surface but built Pando, a new backend, to carry the load from Codex. Git is probably just the first.

We can already see software development being reinvented around these new flows, and the one I’m most bullish on is self-improving software. There are a few ways in. One is upkeep: agents triaging issues as they come in, fixing them and releasing the fix. Another is optimization: agents watching how a feature is used, proposing a change, testing it, tuning it and trying again, in an almost endless loop. Coming from monetization, that second one feels very familiar. The loop optimizes whatever you measure, so someone has to decide what that is, or at least agree with it, and make sure it’s measured correctly. That matters even more as we spend less time inside the loop and more on the outer one, deciding how it should run.

Most of this is still happening inside the tech industry, at companies that can afford to build their own factories. That’s where it starts, but I don’t think that’s where the real benefit is. The largest companies building better products is good, and I’m sure I’ll benefit from it too. But what excites me more is when these tools reach everyone else: a small business running its own factory, building what it used to rent, and keeping some of the margin others have built entire businesses on.