The Era of the Software Factory 🏭
A reflection based on the latest State of Software Delivery report
A few weeks ago, I had Rob Zuber, CTO of CircleCI, on the Refactoring podcast.
We discussed how AI is changing software delivery, and the conversation continued well after we stopped recording.
A few weeks later, Rob shared an early copy of CircleCI’s State of Software Delivery 2026 report—which comes out today—and the data connected a lot of the dots from our conversations. So we decided to write this piece together: my take on the findings, with Rob’s perspective from the inside.
The report is based on 28+ million CI workflows across thousands of teams worldwide, and reveals something we have long suspected: the performance gap between top and average teams is widening. And it’s widening fast.
Elite teams (99th percentile) are reaching delivery speeds that would have been unimaginable two years ago, while the median team hasn’t moved much at all.
One story from my earlier interview with Rob captures this well. A team at CircleCI was debating whether to run user research for a new feature—the usual approach. Rob pushed back: just build a prototype overnight and test it with real users.
Even if the code was, worst case, 100% throwaway, the learning would be more accurate, and the cost would be just ~$100 in compute and a few hours of an engineer. The alternative would have been weeks for the research, more people involved, and possibly more shallow insights.
For someone like me, who has been involved in startups and lean teams for his whole career, it’s counterintuitive to think code-first. Much of what we know about building products is based on the implicit assumption that writing code is the most expensive part, by far.
So when such cost drops, the initial outcome is that engineers get faster. But when it keeps dropping, like in the last year, we get to a point where a lot of hypotheses don’t hold anymore, and we need to rethink the process as a whole: how we make decisions, how we structure teams, how we think about quality, and so on.
You stop optimizing individual developers, and start designing a new production system. Rob and I started calling this the software factory, and it became the lens through which the rest of this piece came together.
Here is what we’ll cover:
🏭 From craftsman to factory — why this is bigger than “AI makes coding faster”
📊 The widening gap — data from the 2026 State of Software Delivery
🎛️ Control systems thinking — a mental model for running your factory
⚡ What elite teams do differently — practices, not tools
🛠️ How to start — without rebuilding everything
Let’s dive in!
I am grateful to Rob and the CircleCI team for partnering on this piece and giving me preview access to their report. You can check it out below.
Disclaimer: even though CircleCI is a partner for this piece, I will only provide my unbiased opinion on all practices and tools we cover, CircleCI included
🏭 From Craftsman to Factory
Let’s lead with an interesting bit from the State of Software Delivery. Actually, three bits:
Activity on feature branches (where most coding happens) is up 59% YoY — the largest increase ever observed.
Activity on the main branch, though, which is closely correlated with production deployments, is down by 7%.
Build success rates are down to 70.8%, the lowest in five years.
The way I see it is that engineers by now are comfortable with AI-assisted coding, and, as a result, teams are generally writing more code than ever. But it also feels that, when it comes to shipping, this confidence drops. Code fails more often, which makes engineers less eager to merge and deploy.
So while AI makes the generation of code faster, everything that comes after (or before) that — testing, reviewing, integrating, deploying — largely stays the same (or gets worse!), unless you do something about it.
I’ll also throw in my own experience into the mix. For the last two months, I have been running a small-group coaching program for CTOs where, among other things, I help them identify the bottleneck in their dev process — the step that limits the throughput of the overall system.
In theory, that bottleneck can be anywhere. In practice, it’s never coding.
For some, it’s manual QA. For others, it’s creating good requirements. For many, it’s code reviews. For one of them, it’s collecting good feedback from customers, so they can act on it.
As coding gets cheaper and faster, it’s changing the cost structure of the whole process, and bottlenecks now live in the parts that AI hasn’t attacked yet. In other words, the whole system is up for discussion, and chances are it’s going to look way more like a factory than today’s craftman’s workshop.
Steve Yegge’s Gas Town is an obvious example that comes to mind. If you forgive the chaos, the waste of tokens, and the Mad Max theme, it looks directionally correct to me: a system of agents coding in parallel, orchestrated by higher-level agents that create and execute plans, and report back to their human overlords.
But as much as Gas Town can look at times like a 360° self-sustaining orchestration system, it’s still only focused on coding! Love this quote from Dan Lorenc:
Gastown is a preview of agent programming, but the future isn’t “code gets written faster.” The future is: change gets shipped faster. And those are not the same thing.
Teams are trapped because CI takes forever, tests are flaky or missing, review cycles are slow, merge conflicts pile up, confidence is low, production is fragile, and there are “oh god please don’t touch that” zones nobody wants to own.
If this plays out the way I think it will, software engineering turns into CI engineering.
Code is cheap. Green CI is priceless.
So how do we build what’s missing? Let’s go back to the data 👇
📊 The Widening Gap
We were saying: more code, more breakage, less delivery.