The AI Software Factory Powering Your Next Reorg

Over the next year or two, coding agents are going to drastically change how companies structure their engineering teams. You'll still have engineers and developers. But increasingly, you'll have them on centralized teams building the infrastructure for development — the platform everyone else builds on top of. Call it your Software Factory. Specs on one side, apps out the other.

Right now we're relying on individual teams to figure out their own best practices, their own way of using AI in their process. But like artisanal coffee, that's expensive. Just like Kubernetes, DevOps, Cloud, and every specialized function before it, this gets centralized — to ensure production-grade workflows, proper entitlements, and the ability to scale across functions. Think platform engineering, but staffed by people with a deep understanding of how software actually gets built. And it doesn't stop at "DevOps." The platform rubs right up against the business-aligned users. Increasingly, your customers won't be other developers. They'll be business users building on their own.

So what does an AI-powered software factory encompass?

• Your development environments
• Your deployment platform
• Testing infrastructure
• Secrets, entitlements, identity
• Skills for your data and systems

That last one is the whole game. It's what a developer who's been at your company for a while brings that an off-the-shelf Claude Code session can't: they know how YOUR company has chosen to solve all those little problems. How does our LDAP work? Where do I get an API key? What do we use for databases here? To make agents successful, they need all that context from the get-go. The encoded answer to "how do WE do this" is the actual product the platform sells.

On the input side, we'll see a shift from "deep developers aligned with an app or function" to mostly business users interacting with the factory to get what they want built. They work, perhaps with a human, with another AI, even their own brains (the horror), to develop a spec, hand it over, and iterate until they've got the application they want to use. I imagine that spec goes through an approval process before it hits the factory. Is it worth building? Should we invest in it? You'll need some control here, beyond a pool of money set aside for prototyping, to keep wasted effort in check.

Then the great question: who maintains all these apps? You'll have SRE-style support at the platform level. But for funded projects, a business-aligned product engineer actually owns the thing. Prototypes? Ownerless! Good luck :)

So this splits engineers into two camps. Your platform engineers build and run the machine. Your product engineers own the products that come out of it. They're the glue: spending far more time on the context of what they're building while deferring the implementation details to the factory. That keeps driving demand for people who understand the product, can own the decisions the factory generates, and make sure good calls are being made about what actually ships.

Here's what gets interesting. Because the bulk of your build capacity now lives in a centralized platform, it's no longer trapped wherever you happen to have headcount. You can point your product engineers and build capacity at whatever the business actually needs. It kills the "well, we built it because we had the resources sitting there."

And the new constraint for companies that build a factory: if you want more product, you're limited by dollars and specs. Once you have the platform, you just pour more specs and more dollars into the machine.

The ideal profile for most companies ends up being a hybrid product engineer/manager. Technical enough to build and stand behind the quality, product-minded enough to drive a roadmap and ship what users actually want. Your core engineers build the factory. Your business people build the product.

The macro decision companies will make is - do you buy or rent your factory? You'll be able to buy from plenty of vendors, but you'll be locked into their way of doing things: their costs, their design choices, their roadmap. You can build it yourself, but that takes a level of scale and expertise most companies don't have. And do you even keep developers in-house? You could outsource to a company offering an end-to-end software factory, staffed with their developers, that you just interact with.

Which leaves the real question. In a world where there's a factory printing software on demand, what is your business, really? How do you stay competitive?

I think it comes down to radical customer empathy. When everyone can build anything, building stops being the differentiator. Knowing exactly what to build is. The people who win will be the ones who understand their customers well enough to build precisely what they want and build with them. It'll show up in niches, where the cost of building for a small segment finally pencils out and whoever actually understands that segment takes it. It'll show up in an excellent GTM.

We can all pretty much agree the moat around the code is drying up. The value is everywhere else now: GTM, how you treat customers, how you evolve, how you run every other part of the business.