The bottleneck has moved

Everyone’s celebrating 10x faster code. Nobody’s asking why nothing actually ships any faster.

For decades, we treated software development as if the expensive part was building.

And building was expensive.

Design took time. Development took time. Testing took time. So companies organised themselves around engineering capacity: roadmaps, backlogs, specs, sprint planning, prioritisation.

AI is changing that quickly.

Code can now be generated in minutes. Interfaces can be explored almost instantly. Prototypes that used to take days can be produced during a meeting.

And yet companies are not suddenly shipping products ten times faster.

Why?

Because the bottleneck has moved.

More accurately: AI is exposing a bottleneck that was already there.

The hidden cost of deciding

Understanding a problem, designing the right solution and getting people to agree on it has never been cheap.

Large organisations know this.

Weeks of workshops. Specifications. Meetings. Business analysts, product managers, designers, architects and engineering leads trying to align stakeholders.

And then there is rework.

A feature is designed, built, reviewed, and somebody realises it doesn’t solve the right problem.

So it gets changed.

Then changed again.

Accounting will usually classify most of that as development cost.

But if you build the same feature three times because the first two decisions were wrong, is that really a development problem?

A massive part of what we call development cost is actually the cost of bad, incomplete, or late decisions paid with engineering time.

AI is removing the camouflage

Imagine a feature that requires three weeks of discussion and three weeks of development.

If AI reduces those three weeks of development to just three days, the three weeks of discussion don’t shrink by a single second.

AI didn’t create a new bottleneck. It just stripped away the execution phase that used to hide the alignment phase.

Before anyone builds anything, teams still need to understand users, business rules, existing behaviour, technical constraints and compliance requirements.

They need to explore options.

Make trade-offs.

Agree.

That is where a huge part of the time already goes.

Existing products make the problem worse

Most AI product demos start from scratch.

Generate an app. Add a dashboard. Create a form.

That’s impressive, but it’s not how most companies operate.

They already have products with years of accumulated context: design systems, APIs, business rules, permissions, technical debt, compliance constraints and old decisions nobody fully remembers.

The hard question isn’t:

Can AI generate a form?

Of course it can.

The hard question is:

What should this form be in this product, for these users, with these rules and these constraints?

That’s not primarily a coding problem.

It’s a context and decision problem.

Faster execution makes bad decisions more expensive

There is another consequence of making software cheap to produce.

You can build the wrong thing much faster.

If the requirement is unclear, AI can implement the unclear requirement extremely efficiently.

If stakeholders disagree, generating five prototypes doesn’t automatically resolve the disagreement.

If context is missing, faster execution just moves you more quickly in the wrong direction.

When production becomes cheap, deciding what deserves to be produced becomes more valuable.

The next productivity battle is decision latency

I think this is where the next major productivity gains in software will come from.

Not only from coding faster, but from reducing decision latency.

The time between:

“We need to change this.”

and:

“This is exactly what we want to change, we understand the consequences, the right people agree, and engineering knows what to do.”

Today, there can be weeks between those two sentences.

Meetings. Figma files. Tickets. Documents. Slack threads. Specifications.

Then somebody implements the feature in a few days.

Making those few days twice as fast is useful.

Reducing the weeks before them is transformative.

We may have been measuring software costs wrong

We tend to measure conception as the cost of PMs, designers, workshops and specifications.

But the real cost is larger.

It includes coordination, waiting, translation between teams, late decisions, wrong decisions, and the engineering rework caused by them.

Once you include those costs, it becomes entirely plausible that in many organisations, deciding what to build was already as expensive as building it.

Maybe more expensive.

We simply booked part of the bill under engineering.

This is also the problem we’re working on with Peinture.

Not generating more code. There are already very good tools for that.

The interesting question is what happens before the code.

How do we bring the context of an existing product into the decision?

How do we reduce the layers of translation between business, product, design and engineering?

How do we shorten the distance between an idea and a decision that can actually be executed?

AI is making software development incredibly cheap. In doing so, it reveals a truth that has always been there: the bottleneck was never the keyboard. We’ve just removed what was hiding it.

So, honest question: how many weeks currently pass in your team between “we need to change this” and “engineering knows exactly what to do”?

That gap has a name now. It’s the most expensive line item nobody puts on the invoice, and it’s the exact part we’re building Peinture to remove.

Request a demo