When Writing Software Stops Being the Scarce Bit

For most of my career, producing software has been expensive.

Not simply in money. Good engineering capacity is scarce. There are always more things an organisation could build than people available to build them, so a lot of the machinery around technology has evolved around deciding which things deserve that scarce capacity.

AI is starting to change that equation.

I can see it at a tiny scale in my own building. Things that would once have been beyond my technical ability can now be built, tested, changed and rebuilt extraordinarily quickly. The interesting part is increasingly not whether I can make the software exist.

It’s whether I understand the problem well enough to make the right thing exist.

That makes me wonder what happens at organisational scale when writing software stops being the scarce bit.

The constraint doesn’t disappear. It moves.

Understanding the problem is still scarce. So is access to users who can tell you whether you’ve understood it correctly. Product judgement is scarce. Trusted data and useful organisational context are scarce. Permissions, integration capacity, attention, adoption, operational ownership and the ability to tell whether a service actually improved anything are all scarce.

Making code cheaper does not automatically make any of those things abundant.

In some cases it may expose them more clearly.

If a team can produce three plausible solutions in the time it previously took to build one, choosing what deserves to exist becomes more important, not less. If prototypes can appear in days, the organisation needs to get much better at distinguishing an experiment from something it is prepared to own and operate. If changing the implementation is cheap, ambiguity about the outcome becomes relatively expensive.

This is why I think the AI coding conversation is bigger than developer productivity.

The obvious question is how much faster an engineer can produce software with an agent. That’s useful, but it keeps the existing operating model largely intact: same demand, same decisions, same flow of work, just faster coding.

The more disruptive question is what parts of that operating model existed because engineering capacity was scarce.

What happens to prioritisation when trying something is cheap? What happens to funding when useful software can emerge before a traditional business case would have been completed? What happens to architecture when many more people can create working systems? What happens to service ownership when building becomes easier than operating? What happens to product management when the cost of testing an assumption collapses?

Those are not coding questions.

They’re organisational questions created by a change in the economics of coding.

Software becoming abundant does not mean software stops mattering. Engineering, architecture and systems thinking may become more important because there is more software being created, more quickly, by more people and agents.

But the source of advantage may shift.

The scarce capability may be less about producing the code and more about knowing what should be built, giving machines the right context and boundaries, integrating it into the real organisation, and exercising judgement over the result.

When software becomes abundant, the interesting question is not what becomes easy.

It’s what becomes scarce next.