Software Factories Are a Local Maximum

The healthy scenario used to be: “Two weeks? Let’s descope. What’s the smallest experiment we can do here?” Now, it’s turned into “Let’s spin up another agent on it and see how it goes.”

Fifteen years ago, I had a sticker on my MacBook saying “typing is not the bottleneck” (along with an awesome Clean Code sticker). It still isn’t!

Fine, Factories Are Cool

Surely you’ve heard about software factories recently (though I believe the term was coined in the 60s; talk about repeating trends). In short, it’s about setting up your agents with clear tasks and context so that they can solve those as autonomously as possible.

I concede that these can be extremely useful in certain scenarios. Like tackling boilerplate migrations, refactoring, or handling small bugs and tweaks. Yet, these are all local maxima wins.

When it comes to bigger issues, meatier tasks, many mistakenly believe factories will be a silver bullet. They won’t, because the bottleneck was never about typing.

Once Upon a Time

It used to be that we had a natural space, an inviting platform for pushback, for chutzpah. That’s healthy friction. The price of doing the work helped us weigh it against its value. When the cost seems immaterial, nothing is stupid enough to merit not doing.

Go back a bit and think about what things looked like. I’m going to assume you, dear reader, were part of those software organizations that were above average. Therefore, merely delivering the roadmap wasn’t unheard of. In virtually all of the amazing teams I’ve worked with, the problem wasn’t just cranking out more code. That was easy. We needed to make that code count more. (If merely delivering is still an issue, reach out.)

We always had work to do, but in many startups the issue is more about closing the feedback loops and ensuring that we learn from what we do. It takes time to get code into potential users’ hands and see what they think about it. Features often would ship into the void. Product and engineering, working well together, had to think about users’ needs, have hypotheses, create metrics and form experiments.

We had space for chutzpah and pushback, because an estimate of a week or two would naturally get us thinking about better ways to perform the experiment. Now that things seem “cheap,” we stop thinking about the next leaps that will take us from the current local maximum to the next stage.

The “Why” Problem

Generating code rapidly didn’t shrink the “why” problem. It’s still there. Truth is, most Product teams were struggling as is to define their “why” enough. Now, they find themselves burning the midnight oil repeatedly answering “what” questions to feed Engineering. “Why” remains starved.

“Why” has become the main bottleneck, and we have to address it to actually leverage this AI thing. The future of software engineering revolves around engineers stepping on business’s toes and gaining enough understanding to answer some of those “why” questions themselves.

Software factories barely worked before GenAI because engineers rarely had enough context and understanding of the intent to execute fast. The assumption that we now have enough of that to enable an endless stream seems plainly wrong. If it wasn’t enough to feed human engineers, it will never keep up with the agents. Don’t let the hype confuse you.

To leverage our newfound capabilities, make your team focus on the “why” more than ever. Ensure that they have enough context and product mastery to ask the right questions. Have the descoping conversations, not to save up tokens, but rather to ensure we make every token count. Optimize for actual learning and insights instead of aiming at vanity metrics like PR count.

Software factories only make your team’s decisions that much more valuable. Turn them into product engineers so they can make them correctly. Factories will get you to the top of the hill and fast. But it’s up to you to ask whether it’s the right hill.