The Compounding Software Factory 📈
The third and final episode of our software factory series!
Hey there, Luca here!
Today I am back with the third and last article in our Software Factory series, written together with my friend Rob Zuber, CTO at CircleCI.
Before this one we published:
Why three articles? Because we like to work from first principles:
In the first article we established (with actual data) that teams that are getting far with AI are doing so thanks to good DX. The same teams that had good DX three years ago, are now winning the AI race: those at the 90th percentile are shipping >2x faster than before.
In the second article we said: ok, but once you have good DX, how do you create leverage with AI? And we laid out a plan in three steps:
📋 Specs — start by writing good, detailed instructions about things to be done. E.g. “create a button that has the following specs […]”
📚 Rules — turn specs into reusable rules for the AI to follow. This is when you can say to the AI: “create a button using our rules for creating buttons”.
🧩 Modules — is the final stage, when AI can reuse code directly, instead of rules, and you can simply say: “create a primary button”
This seems good enough, so why a third article?
Because if you do all of the above right, your outcome will be: a solid dev process, in which AI produces good enough work to be shipped.
Now, while this seems like an ambitious target already, I still think we should aim higher.
To understand why this matters, we need to take a step back and reflect on engineering teams before AI. Here is the agenda for today:
📉 The default path is degradation — the uncomfortable reality of engineering teams so far.
🐛 What causes teams to degrade — talking about coding hygiene, capturing knowledge, and building the wrong things.
📈 How to get better instead of worse — how to invert the trend on each of these dimensions.
🎽 Empowering managers — this is peak manager territory. Let’s talk about what managers should really do today in the age of AI.
Let’s dive in!