Blueprint for an AI-Driven Software Factory

I've been thinking a lot about what building a software factory actually looks like. It's something I want to do in my current role, and I think the shape of it is starting to become clear.

The Ground Rules

Rule number one: humans shall write no code.

Rule number two: in most cases, code should be reviewed by AI, not by humans. There are exceptions, but the trick is knowing when to enforce them.

In any software product, some things are riskier than others. You should be able to use AI to flag which requests are risky enough to need human review and which are safe enough for AI review alone. And those AI review loops should just be circular — running until the AI approver is satisfied that the generated code meets all the requirements.

Clear Success Criteria

The specifications need to have clear success criteria, and the agent writing the code needs a way to check those criteria.

For software libraries — things without a user interface — that's fairly straightforward. For web applications or mobile apps, it's more tricky, especially when you get into the UI. There are tools emerging to solve this: Agent Browser, screenshot comparison tools, visual regression testing. So maybe part of the software factory is that the artifacts generated from a specification need to include visual proof — videos of it working, screenshots — for a human to verify.

The Conductor Agent

I think you probably need a conductor agent that can look at a specification and orchestrate the work. Maybe it's a lot of agents. But you really need a way to flag a specification or a piece of it as being critical — as needing human eyes.

Though I still kind of laugh about that, because in my case, I think an AI is probably many times better than me at reading and understanding code. Even with thirty years of experience doing integrations, system administration, database administration — the only thing I'm really bringing is broad pattern recognition from decades of seeing systems succeed and fail. The AI can already read the code better than I can.

What Comes Out the Other End

What I think a software factory looks like: I give it a blueprint, and it spits out a product that meets all the specifications and has proof of testing. If it doesn't work, it just goes back into the factory and gets redone, reshaped, remolded until it does.

And these factories can run all night. All day. On the holiday. All the time.

It's going to be really hard to compete with that if you think your job is taking a blueprint and writing all the code for it. I just can't see a place for that anymore.

The Real Engineering Work

The real engineering work will be in building these software factories. That's the interesting work right now. Which is wild, because you're basically building automation that makes your own work less essential.

But someone has to build the factory. And then maybe the next evolution is a bigger software factory that can build smaller software factories. I don't know — but it's an interesting thought to explore.

What This Means for Small Businesses

If a small company doesn't have the engineering talent to build a factory, they could buy one as a service. That's probably what'll happen.

When I think of traditional factories, I think of products that are all the same — every widget is identical, it's boring. But that's what's different about software factories: they can build super individualized software.

Instead of a 500-person small business having to buy basically the same CRM that every other company their size buys because it's the only one they can afford — HubSpot or whatever — I really think these companies are going to be able to build exactly what they want.

You're just going to need somebody who can put what you want down on paper. And that's the skill that matters: being able to clearly specify what you need, so a factory can build it.