Why AI hasn't 100x'd product development…yet

Everyone has had that moment with AI: you ask a model to do something that should take a full day… and a minute later a fully-formed solution materialises. Magic.

I have had a few of these moments myself. I recently “coded” a vision type of an updated version of our product from scratch using a coding agent. It began as a quick experiment and within days it turned into something that looks almost identical to the actual product, and we now use it regularly in customer conversations. And outside of work, I used the same tools to create a personalised comic book for my niece and nephew for Christmas. On my own, this would have been impossible (I can’t draw), yet now I can generate characters, scenes and storylines in minutes.

Despite all this, whilst individually we are all a bit more productive, teams are not shipping products 100x faster.

Why not?

Right now, most conversations about “AI for developers” boil down to one idea: help me write more code, and for product managers it’s much the same, help me write a spec faster, tidy up a user story, or summarise some research.

And that’s fine, but it’s not transformative.

If 100x speed-ups were as simple as individuals typing faster, we’d already have figured it out. We haven’t. Which suggests something deeper.

We are treating AI as an individual productivity booster when the real opportunity is systemic.

The steam engine mistake

A good analogy comes from the Industrial Revolution when factories were powered by giant steam engines. One monstrous turbine in the centre, belts running everywhere, everything organised around that constraint.

Electricity arrived, offering cheaper, cleaner and more flexible power, and factory owners responded by… replacing the steam engine with an electric motor.

Same factory layout. Same belts. Same workflows.

Productivity went up a bit, but the promised revolution didn’t arrive.

It did arrive 20–30 years later, when new factories were designed entirely around electricity. Local motors. Distributed power. New workflows. New roles. New processes.

Technology alone wasn’t enough, the factory had to be reimagined.

Our product development “factory floor”

For the last few decades, everything about the way we build software has been shaped by a single assumption:

Code is expensive.

So we built an entire organisational machine around that idea:

• product specs to avoid wasting engineering time

• agile rituals to reduce rework

• pair programming as a quality mechanism to avoid rework

• merge requests and code reviews as a safety net

• CI/CD as a guardrail

• UAT cycles, staging environments, release trains

Even the architecture reflects this worldview. We carefully curate every line. CRUD (Create, Read, Update, Delete) workflows receive hours of engineering attention. We treat code as artisanal craft because historically… it was!

Now AI has arrived, and suddenly the cost of code has collapsed.

And what did we do? We replaced the steam engine with an electric motor. We slotted AI into the existing rituals instead of asking whether the rituals still make sense.

Stop optimising the old world. Start designing the new one.

The question shouldn’t be “How do we help developers write the same code faster?”, it should be “What does product development look like when code is no longer expensive?”

Because if writing code costs almost nothing:

• Do we still need PRs for 100% of changes?

• Do we still handcraft CRUD apps?

• Do we still write specs the same way?

• Do we still structure teams around the bottlenecks that no longer exist?

This extends to the architecture itself. Some parts of the system must remain at a gold standard of code quality and must always involve human led assurance. Security must be correct. The numbers must be correct. The underlying data model must be correct. And, of course, the core differentiation of the product must be correct. These are the load bearing parts of the system.

But huge swathes of the codebase are not load bearing. CRUD workflows do not require the same scrutiny. In many cases all that matters is that the UI behaves as intended and that it correctly persists the data model. How it gets from the UI to the data model, and the precise quality of that glue code, often does not matter at all. If AI can generate and regenerate these parts safely, why build them the old way?

We need to rethink the entire operating model of product development, from team structure to tooling to architecture. We need a holistic redesign that creates an AI native factory floor.

And yes, it’s uncomfortable. It means unpicking decades of habits, rituals, and identity. But it’s also the biggest opportunity of our careers.

Why this matters now

Organisations everywhere are being told to transform for AI. Change their processes. Rethink their workflows. Rebuild their operating models.

The reason this matters is simple. There is a huge opportunity for the first teams who figure out how to build products in an AI native way. If the cost of code really has collapsed, and if we redesign the entire product development system around that fact, then the speed we can move at will change completely.

The teams who crack this will operate at a pace that feels magical to their customers. Features will appear in days rather than weeks or months. Ideas will move from concept to shipped product so quickly that the cycle of feedback, iteration and improvement becomes almost continuous.

And from the outside, especially to competitors, this kind of velocity will look impossible. It will feel like being overtaken by something that is playing a different game entirely.

I don’t know the final blueprint yet. But I do know the framing needs to change. It’s time to stop asking how AI can make developers faster. It’s time to ask how AI reshapes product development itself.