AI Didn't Replace Anything. It Repriced Everything

The argument was about the wrong thing

For three years the public conversation about AI has been an argument about replacement. One camp said nothing was happening — autocomplete with good PR. The other said everything was ending — professions, companies, the labour market itself. Both were loud, both were confident, and both made the same mistake: they treated a curve as an event.

Roy Amara’s old observation still holds. We overestimate the effect of a technology in the short run and underestimate it in the long run. The short run produced a great deal of drama and very little change. The long run is now arriving, and it is much less dramatic and much more consequential than either camp expected.

Nothing got replaced. A great many things changed price. And prices are what strategy is made of.

For a manager running a company that both produces software and consumes software to run itself, exactly one price change matters more than all the others: the cost of building a tool that fits your business exactly, instead of renting one that doesn’t.

Two precedents worth ten pundits

Factories didn’t get faster when they got electricity. They got electricity in the 1890s. Manufacturing productivity didn’t move meaningfully until the 1920s. The reason is well documented: the first generation of electrified factories ripped out the steam engine, bolted in one enormous electric motor, and left everything else exactly as it was — the overhead line shafts, the leather belts, the machines crowded around the driveshaft because that was where the power was.

They had swapped the power source and kept the architecture. The gain was close to zero.

The productivity explosion came when someone realised that electricity let you put a small motor on each machine. Once each machine carried its own power, the driveshaft was unnecessary, and once the driveshaft was gone, you could lay out the factory floor according to how the work actually flowed. That was the change. The motor was just the enabler.

Containers were a steel box. When Malcolm McLean sent the first container ship out of Newark in 1956, the innovation was almost embarrassingly simple. The gains took roughly twenty years to materialise, because they required rebuilding ports, ships, cranes, trucks, rail, customs procedures, and labour agreements. And the distribution of winners was brutal and geographic: Newark rose while the Manhattan piers died; Felixstowe rose while the London docks died. The technology was available to everyone. The re-layout was not.

The lesson both precedents teach is the same one, and it is the lesson most AI adoption is currently failing:

The technology is not the change. The re-layout is the change.

An AI tool dropped into an unchanged workflow is a big electric motor bolted to a driveshaft. It works. It produces a demo. It produces almost no compounding advantage. The advantage belongs to whoever notices which constraint has been removed and rearranges the floor.

The constraint that has been removed is the cost of writing software that fits.

Part 1: The floor — where AI assists and will not replace

Every software company sits on an infrastructure floor: hypervisors, networking, storage, identity, the firewall data plane. In most companies this floor is now a mix of open-source and commercial components, and the honest position is that you should not be building any of it.

That is not because it is “too hard.” It is for five structural reasons that AI does not touch:

Physics does not appear in the context window. An SFP28 link that won’t come up because of an FEC mismatch. A drive returning ILLEGAL REQUEST on a truncated IDENTIFY. A fan curve, a backplane, a marginal cable. The diagnosis of real infrastructure regularly depends on state that isn’t text and isn’t reachable from a prompt.

Consequence asymmetry. A wrong commit costs a revert. A wrong firewall rule costs an outage or a breach. A wrong storage command costs data that does not come back. The tolerable error rate is different by orders of magnitude, and error rate is precisely where current systems remain unreliable.

Accountability cannot be delegated. Under PCI DSS, SOC 2, ISO 27001, NIS2 — a named human is accountable for a control. You can delegate work to a model. You cannot delegate accountability to one, and no auditor will accept the attempt.

Running systems are not codebases. A three-year-old cluster has history, drift, undocumented decisions, and a state nobody can fully observe. Code is legible. Infrastructure is archaeological.

The economics of the commons. There are perhaps four hypervisors worth running, and each represents thousands of person-years. Building the fifth was a bad idea in 2015 and remains a bad idea now. Cheaper code does not make it good.

So the floor stays bought or adopted. But notice what AI actually does here, because it is not small:

• It collapses recall time across enormous documentation surfaces. Most senior troubleshooting time isn’t thinking, it’s looking things up.
• It reads forty thousand lines of logs and proposes three hypotheses ranked by plausibility.
• It writes the Ansible role, the runbook, the post-incident report — the documentation debt that every infrastructure team carries and never pays down.
• It explains an unfamiliar subsystem at 03:00 to the one engineer who is awake and doesn’t own it.

This is enormous value. It is simply value on the assist side of the line, and that is a structural position, not a temporary one. Infrastructure is where AI is most useful as an assistant and least appropriate as an autonomous agent.

Part 2: Where AI co-works — and what actually determines the boundary

“Assistant versus agent” is usually discussed as a question of model capability. It isn’t. The variable that matters is who holds the verification loop.

Assistant mode. The human initiates, the human reviews every output, the human is in the loop at each step. Correct for irreversible actions, production systems, and anything where the cost of a wrong action exceeds the cost of a human read.

Agent mode. The AI initiates and iterates against an automated oracle. The human reviews the result and the diff, not each step. This requires two things:

1. A fast, trustworthy verification signal — tests, a type checker, a linter, a staging environment, an idempotent apply with a working dry-run.
2. A bounded blast radius — a branch, a container, a scratch namespace, a rollback that has actually been rehearsed.

If you have neither, you do not have agentic AI. You have unsupervised AI, which is a different and considerably worse thing.

The strategic implication is the part managers consistently miss:

The amount of AI leverage you can safely extract is a function of your test coverage, your CI, your rollback capability, and your environment isolation.

Two companies buying identical licences will get radically different returns, and the difference will not be the model. A team with real CI and rebuildable environments can hand an agent a task and review a diff. A team without them must review every line, which caps their gain at roughly typing speed.

This is good news for a 10–50 person shop. Engineering maturity is buildable in months, and it is the multiplier on every subsequent AI investment. Fix the verification loop before you expand the agent footprint. For infrastructure specifically, your verification loop already has a name: --check mode, terraform plan, immutable rebuilds, and observability good enough to tell you within minutes that something moved.

Part 3: The three buckets, and the bill you’re already paying

Every piece of software your company touches falls into one of three categories. Most companies have the boundaries in the wrong place — and they were put there for reasons that were correct at the time.

Bucket 1: Always rent. Accept the cost on day one.

Operating systems. Office suites. Chat and video. Email and calendar. Identity providers. Payroll and tax. Payment processing.

These share properties: commodity function, well-defined interfaces, no competitive differentiation, and often compliance liability you would be insane to take on voluntarily. Some of them are valuable precisely because everyone else uses them. Building here is not thrift, it is vanity. Budget for it and stop revisiting the decision.

Bucket 2: Build on bought primitives.

The category nobody names, and where most of the actual work lives. You do not build a database; you build your application on Postgres. You do not build an identity provider; you build your access workflow on top of one. You do not build a message bus, an object store, or a TLS stack.

You build the layer that encodes your logic on top of primitives you didn’t write. This is where AI’s effect is largest, because assembly, integration, and glue is exactly the work it is best at.

Bucket 3: The tools where renting actively harms you.

Here is the core of it. When you rent software that encodes a process, you are not buying a capability. You are buying somebody else’s opinion about how your work should be done, and then reorganising your company to match it.

That trade was rational for thirty years. Development was slow and people were expensive, so paying in process distortion to avoid paying in engineering was correct arithmetic. It was correct in 2010. It is being repriced now.

And the bill you are paying is not the invoice. Look for these four line items, none of which appear in your SaaS spend report:

Process distortion. Ask each team: what do we do awkwardly because the tool requires it? Every workaround, every parallel spreadsheet, every “we just don’t use that field” is a payment. Your best people are absorbing friction daily so that a vendor’s data model can stay intact.

Change latency. The last time the business needed a real change to a rented tool, how long did it take? If the answer is “we requested it and it’s on their roadmap,” your ability to change how you operate is capped by a company whose priorities are set by its median customer, not by you. In a market that moves, change latency is competitive position.

Exit cost, which compounds. Data gravity, integrations, retrained habits, historical records. Every year you stay, leaving costs more. This is not accidental; it’s the business model.

Ownership of the data and the semantics. Not just where the rows live, but who defines what a row means, and who gets to change that definition on Tuesday.

Against those four, the counterweight used to be an eighteen-month build. Today, for a well-scoped internal tool, a competent small team with AI assistance can be running v1 in weeks. That does not make the decision automatic. It makes it a decision again, for the first time in a decade — one you should be actively re-examining rather than inheriting.

The shadow-IT proof. You already know this argument is true, because every company has business-critical spreadsheets and half-abandoned Access databases holding processes together. Those exist because the official tool didn’t fit and someone built the missing piece in the only medium available to them. Businesses have always wanted tools that fit. They just couldn’t afford to build them properly. Now they can — and the alternative to building it properly is not “nothing,” it is the spreadsheet that already exists and that nobody has backed up.

The honest counter-argument

Any manager who reads the above and reaches for a budget line should first internalise this, because it is where the failures will come from:

AI has collapsed the cost of the first 80%. It has barely touched the cost of the last 20% and the following ten years.

The lifetime cost of an internal tool is not writing it. It is:

• being on call for it
• patching it, and chasing dependency churn indefinitely
• a backup and restore path that has actually been tested
• the bus factor when the one person who understood it resigns
• documentation, onboarding, and access control
• ten years of small changes, each individually trivial

AI reduces the writing cost by something like five to ten times. It reduces the maintenance cost by considerably less — though it genuinely helps, particularly at reading unfamiliar code, generating tests, and grinding through upgrades. So the build-versus-buy line moves, but it moves less far than the demo suggests.

The predictable failure of the next two years is the manager who models the build at the 80% figure, ships four internal tools in a quarter, and discovers in year two that they have acquired four unmaintained products and no owner for any of them. That failure will be blamed on AI. It will not be AI’s fault.

The discipline that prevents it is unglamorous: build fewer things, own them properly, and treat every internal tool as a product with a named owner, a test suite, and a documented decommissioning path.

There is also a precedent for over-promising here worth remembering. The late 1980s sold CASE tools and 4GLs as the end of programming. They were not. But FORTRAN is the better analogy: Backus’s team knew the only way to displace hand-written assembly was to prove the generated code was competitive. At first it wasn’t. Then it was. Then almost nobody wrote assembly again — and the people who kept the skill were the ones who could debug the compiler. That is roughly the position senior engineers are in now, and it is a strong position, not a threatened one.

What to do in the next ninety days

1. Inventory your SaaS by process distortion, not by cost. For each tool, two questions: What do we do awkwardly because of this? and Last time we needed a change, how long did it take? Rank by that, not by invoice. The top of that list is your candidate set — and most of it will stay rented, which is fine. You are looking for the two or three that are genuinely costing you more than they charge.

2. Build exactly one thing, and instrument the true cost. Pick internal glue, not a product feature. Ship it. Then measure everything for six months — incidents, hours, changes, complaints. You now have a real coefficient for your own company instead of a vendor’s or a pundit’s.

3. Invest in the verification loop before the agent footprint. CI, tests, staging, dry-run, rehearsed rollback, observability. This is the multiplier on every AI euro you will spend for the next five years, and it is worth doing even if AI stalls entirely.

4. Write the assist/agent boundary down as policy. Which systems require a human in the loop at every step, which permit an agent with review of the diff. Name them. In a regulated environment this is not optional, and writing it down is also the fastest way to discover that half your team has been improvising.

5. Train the people you already have. A senior engineer with AI is a far larger jump than a junior with AI, because the bottleneck moves from producing to reviewing — and review is a judgement skill that takes years. AI raises the value of your senior people. Budget accordingly, and be sceptical of any plan that reads “hire more juniors, AI will cover the gap.”

The floor is still the floor

None of this is a case for building your own hypervisor, your own firewall, or your own storage stack. That floor stays where it is, and AI’s role there is to make a small team dramatically more effective at running someone else’s excellent software — faster configuration, faster diagnosis, better documentation, shorter incidents. Assist, not replace, and structurally so.

The case is about the layer above it: the tools that encode how your particular business actually works. That layer has been rented for thirty years for a reason that was true and is becoming less true every quarter.

The factories that electrified in 1900 and kept the driveshaft got nothing for it. The ones that noticed the constraint had lifted, tore out the overhead shafts, and rebuilt the floor around the work — those ran away with the century.

The question worth putting to your leadership team this quarter is not how do we adopt AI. It is:

What are we currently doing awkwardly, only because building the tool that fits used to be too expensive?

Everything strategic follows from the answer.