I’m sure we’ve all seen this before… You’re driving and there’s a car speeding and weaving in and out of other cars, driving dangerously and passes you. You observe them pass a few other cars and then they are out of sight. Then a couple minutes later you pull up to a light and that same car is right next to you. All that effort, and they aren’t any faster.

There is a lot of talk in our industry about software factories, being “AI Native”, and agentic loops.

Software Factories are ways of reimagining the software product lifecycle so that AI is in every part of the cycle. Humans input intent which get refined into proposals and then specs that are handed off to agents to do the work. The validation is also done by agents and the deployment is done by agents. Feedback is gathered and fed back in as intent.

The rise of this trend is unsurprising. LLMs are getting pretty good at large parts of this value chain and if you could wave a magic wand and automate large parts of it of course you would.

Executives and leaders are starting to push for this approach. Automate (with tokens). Faster delivery. More value. Growth. Market share. Profit.

The devil is, as they say, in the details.

Software projects are complex, and writing code is but one part of it. Agents are good at that part, provided you give them clear & precise direction and scope.

The hardest part of my job as an engineer (and where I likely provide the most value to organizations) isn’t to come up with the best algorithm, the most useful abstraction, or the most maintainable code (though these are valuable). It is to align on a direction and get the other folks involved on the same page. If we know what we are building (and often what we are not building), how we will know it is successful, and how to get there, then the building part isn’t really that hard.

There is this idea that teams adopting AI can be “2x, 3x, 5x faster” and that type of rhetoric is dangerous and misleading. If you give a few engineers runway, the best tools, and a clear direction to move in, they will do really well. Environments where people are able to ship fast with AI also happen to be environments where shipping code “the old way” is also pretty fast.

But most projects don’t have this luxury. You have unclear or imprecise requirements, dependencies on other teams, and incomplete documentation. In larger organizations it can be hard to find out who even has the ability to provide you with the answer to a particular question. You have legacy systems that are being retired and new ones that are being designed to replace them, but somehow you still need to integrate with both because of reasons.

These environments are common, and I’ve experienced this type of thing my entire career. This is the work. Knowing exactly what you need or want to build and all you need is time and a computer is an absolute luxury. And in these environments, LLMs will speed up aspects of the software lifecycle. It will write code, it will think through requirements, it will ask you a barrage of questions to help hone in the requirements, and it will help you test your changes and put up a PR. Quality of the code and the need for human review notwithstanding, this provides a measurable speed increase for teams using AI to build software.

But building software is only part of the value chain. We don’t build software just because. We build it to serve a larger goal for the business. To make money. The software requirements come from people who see the business and the current state of things and want to deliver software to add new features, meet new compliance requirements, fix bugs, etc. These requirements (the intent) are important and more valuable than ever.

We also have to test, deploy, and monitor our software. This often requires other teams, infrastructure, and end users using the product to actually realize the value we deliver.

If we take the BUILD phase and shrink it, what happens to the phases it it is dependent on? Can we build more things? Sort of.

As we build more things, the validation and deployment part of our pipeline piles up. You can’t rely on human code review or manual QA for each change anymore because they won’t be able to keep up.

And there isn’t an infinite number of things to build either. Things we are dependent upon (new work with clear requirements, bugs with sufficient repro info and context, necessary changes from upstream teams, etc) now need to be delivered faster to keep up with our new pace.

You can’t just write code faster and expect the rest of the organization to keep up.

Organizations who make this assumption are the car stuck at the stop light, waiting to jam their foot on the gas pedal, only to be met with another red light and traffic along the way because they haven’t fixed the other constraints in the system.