The Software Factory Velocity Trap

The industry has become obsessed with automating the SDLC, and for good reason. The path from tool use, to collaboration skills, to computer use has brought us to harnesses that build end-to-end applications fully autonomously, and those applications work in the real world. The harnesses have done this well for almost a year now. The industry is racing to push it further, with products being called software factories.

In my opinion these are mostly CI. The cycle I’ve seen is that every few months the labs drop a new model and harness that is better coordinated, better sandboxed, and that you can trust with more responsibility out of the box. That isn’t a reason not to experiment. I certainly am. But this isn’t a post about that.

This is a post about the outcome a factory is meant to achieve: the why behind building out your autonomous SDLC. It starts with why build a factory at all, and my central hypothesis is that most people start for the wrong reason. They cite speed as their number one criterion.

Why speed

It’s a natural place to start. Over the last 24 months speed has been one of the major benefits of working with AI, and it still is. Days of work in minutes, weeks in days, months in weeks. We’ve all heard these stories or lived them, and I’m sure many companies have captured real wins this way.

Here’s where I see it break down.

First, speed is hard to measure across the jump. Maybe your teams have good historical data on ticket volume, PRs, even product metrics. None of it is adjusted for the spike in volume that comes with agents, so as a baseline it’s close to worthless. An agent that opens ten PRs where a person opened one hasn’t made you ten times faster.

Second, time to market is a relative advantage, not an absolute one. Going fast only helps when you’re going faster than your competition, and your competition surely uses AI now too. Once everyone has the same factory, speed stops setting anyone apart.

That’s the trap. You build the factory to win on velocity, you can’t measure the velocity, and the velocity doesn’t win.

If not speed

This leaves a much harder measurement problem, and a goal-setting one. The goal is the easier place to start.

If not speed, then quality, reliability and performance become the way to measure your outcomes. Measuring them isn’t always obvious, but it isn’t impossible, and it’s often the precursor you need before you even consider automating your SDLC. Are you instrumented well enough? Can you quote your error budget? Your p95? A factory pointed at a system nobody can measure just changes it faster. Building that discipline in your team before you take on automation is worth considering.

Taste

The hardest of these is quality in the sense of taste and outcomes. It’s an art, not a science, and closer to behavioral economics than to software. Taste spans the product, the customer and the domain, not one specialty, so judging the whole output takes someone who can see across all three. It’s why generalists are so desirable right now. It’s also intensely domain specific, and it should be aligned to the core strength of your business.

No factory supplies that. It can only amplify what you already know about what good looks like for your customers.

For the annual plan

So as we all get into annual planning, don’t start with how many more features, initiatives, or even sign-ups you can generate. Take the time to ask what sets your business apart from its competitors, and how you’d leverage it. Then build the factory that serves that. Point the automation at the thing that makes you different. Measure it by quality, reliability and performance, not by how much it produces.