Implementation isn't the expensive part anymore

Imagine coding becomes five times cheaper. Not 10% cheaper, not 20% cheaper: five times cheaper.

What happens to the cost of software?

The obvious answer is that software becomes five times cheaper. It doesn’t.

Implementation is only one part of the cost of shipping a product. You still need to understand the problem, decide what to build, and get stakeholders to agree. Then you need to coordinate people, validate the solution, handle security and compliance, and understand the existing system. And, quite often, you change your mind halfway through.

AI is making implementation dramatically cheaper, but it is not making all of those other costs disappear. So the economics of software development are starting to change.

The visible part of a feature

Implementation has always been easy to see. You have five developers working for three weeks, so you can estimate the cost: it appears in Jira, in the project plan and eventually on the invoice.

The rest is much harder to see. There was probably a workshop two weeks before development started. Then ten Slack threads, a product manager waiting for an answer from compliance, a designer waiting for validation, and a meeting where six people discovered they did not actually agree on the original requirement. Then an architect explains that the obvious solution does not fit the existing system. Then part of the feature gets rebuilt because an important constraint appeared too late.

All of that is part of the cost of the feature. We just don’t account for it very well.

Implementation is the visible part of the iceberg. A lot of the cost sits underneath.

Shrink implementation cost, and the proportions change

Take a simplified feature. The exact numbers don’t matter, but say the organisation spends 20% understanding and designing it, another 20% coordinating and validating it, and 10% dealing with technical, security or compliance constraints. 40% goes into implementing it.

The remaining 10%? That’s misunderstandings. The rework that happens when people didn’t actually agree in the first place.

Now make implementation five times cheaper. That 40% becomes 8%. Everything else is still there.

On the new total, implementation is down to roughly 12% of the cost, from 40% before. It’s no longer the dominant cost, not because coordination became more expensive or compliance became slower, but simply because its relative weight collapsed along with its cost.

Imagine coding becomes 5x cheaper. What becomes expensive is everything around it.

This changes where productivity needs to come from

Over the last few years, a huge amount of effort has gone into developer productivity: better frameworks, better infrastructure, copilots, coding agents, automated testing and faster deployment. And we should keep doing it, the gains are real.

But there is a diminishing return if the rest of the organisation does not move with it. Saving four days of implementation on a feature that spends three weeks waiting for decisions is useful. Saving another two days after that is a lot less interesting.

At some point, the next productivity gain has to come from somewhere else: from reducing the time required to understand, align and decide. This is especially true in larger companies, for the reasons we laid out in The bottleneck has moved: it was never a code problem for them. The product already exists, with years of business rules, systems and stakeholders to hold together.

AI can generate the implementation. It still needs the right context.

From protecting cost to making decisions faster

A lot of our current product process was designed to protect expensive implementation. We specify things before building them, we create mockups before writing code, with gates between business, product, design and engineering at every step.

That made sense when producing a first implementation was expensive. But if a first implementation becomes almost free, some of those boundaries become questionable.

Maybe the first meeting looks different too. Instead of a static screen, stakeholders are pointing at something they can actually click through: moving a button, testing a flow, catching the real objection live instead of two sprints later. The prototype stops being the output of the conversation and becomes part of it.

And maybe the first implementation is no longer something you create after the decision, but one of the tools used to reach it. That is not a small process improvement, it changes the economics of product work.

The next optimisation target is upstream

The biggest impact of AI on software won’t just be that developers write code faster: that’s already happening. Once implementation becomes cheap enough, organisations are forced to look at everything surrounding it.

How long does it take us to understand a change? How many times is the same intent rewritten before it becomes actionable? How much engineering time is actually rework we could have avoided?

Those questions become much more important when code itself stops dominating the equation. This is a big part of what we’re working on with Peinture. Not replacing another coding tool, but working further upstream: using the existing product as context, making changes tangible earlier, reducing the distance between an initial business need and something precise enough to be implemented.

Because if implementation keeps getting cheaper, the next major source of productivity won’t be found inside the codebase. It will be found in everything we currently do before we touch it. That’s the part worth fixing first.

Curious what that looks like on your own product?

Request a demo