Technology is becoming easier to build. Competitive advantage isn’t.

What is actually being compressed

Precision matters here, because the loose version of this claim is wrong. AI is not making technology free, and it is not making professional engineering unnecessary. It is compressing the labour content of producing a given piece of working output, and it is compressing it unevenly.

The parts falling fastest are the parts that were always the most repeated: interface work, integration glue, ordinary business logic, test scaffolding, migrations, documentation, routine analysis, first drafts of almost anything. The same pattern appears outside software — in engineering documentation, planning, quality analysis, administration, support and decision preparation.

The parts falling slowest were never mainly typing: knowing a domain well enough to recognise which behaviour is correct, operating a system under real load, integrating it with physical processes, and carrying responsibility when it fails.

Two consequences follow, and they point in different directions. Producing a plausible version of most things becomes dramatically cheaper. Producing a trustworthy version of a serious system becomes only somewhat cheaper. A great deal of enterprise value will be decided in the gap between those two words.

Cheaper to build is not cheaper to own — or cheaper to fail

A technology decision has three separate costs, and only one of them is falling quickly.

• Build cost — what it takes to create the thing. AI compresses this hard, and the effect is immediately visible.
• Ownership cost — operating, understanding, governing, securing, maintaining, integrating, supporting, auditing and evolving it. Parts of this compress. None of it disappears.
• Failure cost — what happens when the system is wrong. This is set by the process the system supports, and cheap creation does nothing to reduce it.

Organisations still evaluate technology mostly by build cost, because that is the number a proposal contains. As build cost falls, that number carries less and less information about the decision being made.

The cheapest system to build can become the most expensive system to fail.

That is not an argument for caution. It is an argument for classifying by consequence rather than by cost — which is what the critical process test is for.

Who captures the compression

A cost reduction is not a margin until someone fails to compete it away.

When one company’s engineering becomes forty percent more productive, that is an advantage. When every company’s engineering becomes forty percent more productive at the same time, it is an industry-wide shift in the cost curve, and the surplus accrues to whoever holds the strongest position in the value chain. Sometimes that is the incumbent. Frequently it is the customer, through lower prices or higher expectations at the same price. Sometimes it is an entrant who never carried the old cost base at all, or the platform that supplies the capability to everyone.

This is the most common error in AI strategy papers: treating a productivity gain as though it were proprietary. If a competitor’s engineers, planners and analysts can use the same tools — and they can — the gain reaches the market’s cost structure before it reaches anyone’s EBITDA.

Not “how much can we save?” but: where does the saving end up, and what do we own that lets us keep any of it?

What compression cannot reach

Some assets are indifferent to the cost of building, because they were never made of build effort.

A customer relationship survives. A regulatory approval survives. A dataset produced by ten years of operating a business survives. A workflow thirty thousand people are trained on survives. An installed base of physical equipment survives, and so does the service network around it. So does the reputation that allows someone to sign off on a consequential decision.

None of that is a technology moat, and that is precisely the point. As the build component of an advantage depreciates faster, the non-build components carry more of the weight — and those are exactly the components a conventional technical due diligence is not built to examine.

Abundant code does not make reliable systems abundant

It is worth separating two things that are routinely confused: code and system value.

Commodity functionality does get cheaper. But a system that carries a mission-critical process is not valued for its code. It is valued for installed base, deep process integration, operational reliability, domain knowledge, proprietary data, physical integration, security, auditability, lifecycle management, support and the fact that someone is answerable for it. Cheap generation reproduces none of those.

The plausible conclusion is not that serious software companies disappear. It is that the distance between something that demonstrates well and something an operation can depend on becomes the commercially interesting distance — and that reliable systems may become more valuable, not less.

What this changes for capital

For an investor, the practical shift is from measuring the asset to underwriting its half-life.

A company can be well run, well architected, growing and profitable, and still be a poor five-year holding, because what customers are actually paying for is becoming reproducible. Equally, an unremarkable business with a mediocre product can be a good holding, because it sits inside a workflow nobody wants to touch, or a physical process nobody can rebuild with software alone.

Neither judgement can be made from the code, and neither is limited to software companies. Both require a view of what the market looks like once building costs an order of magnitude less. Forming that view is what technology and AI due diligence is for, and it is the same view a board needs before it approves a large technology investment.