In the previous post, I traced the history of fungibility across four technological eras — mechanical, electrical, digital, and the internet. Each era dissolved a barrier that had seemed permanent, created enormous value, and immediately revealed the next barrier that had been hiding behind it.
The internet era ended with a specific revelation: information could travel anywhere, but systems couldn't understand each other. The data existed. The connections didn't.
This post is about what happened next — and why it matters more than it might appear.
- Plumbing as the bulk of real engineering — and why standards only ever partially bridged incompatible systems
- What changed when AI made translation cheap: agreement before the fact vs comprehension after the fact
- The money/barter analogy — double coincidence of wants, applied to technical compatibility
- What interoperability solved and what it leaves: intent, judgment, and who still architects when glue is free
What Developers Actually Spend Their Time On
Ask a non-developer what software engineers do, and they'll describe something like: understanding a problem, designing a solution, writing code that implements it. The interesting intellectual work of translating human needs into executable logic.
This is accurate for perhaps a third of what actually happens. The rest — and this is not an exaggeration — is plumbing.
Plumbing, in software, means the connective tissue between systems. It means reading data from one format and writing it in another. It means authenticating against an external service, handling the seventeen edge cases in its API documentation, and writing the retry logic for when it times out. It means mapping the fields in one database schema to the fields in another. It means building the adapter that lets the thing your team built talk to the thing the other team built.
None of this is intellectually interesting. All of it is necessary. And across the industry, it consumes a staggering fraction of engineering time — in many organizations, more than the implementation work it surrounds.
This is not because developers are inefficient. It is because interoperability is genuinely hard, and the attempts to solve it at the level of standards have always been incomplete.
Why the Coordinated Solution Never Fully Worked
The history of technology is littered with attempts to achieve fungibility through standardization. USB was supposed to replace a dozen connector types. Bluetooth was supposed to make wireless devices speak a common language. REST was supposed to make APIs interoperable. OAuth was supposed to make authentication universal. SQL was supposed to make data portable between databases.
These efforts are genuine achievements. They made large categories of integration possible that hadn't been before. But they share a common failure mode: they work well within their domain and break down at the edges, where systems built on different assumptions need to communicate.
Standards require coordination — political as much as technical. They require the relevant parties to agree on a common shape before they build, which means they always lag behind innovation, always involve compromise, and always leave the most interesting edge cases unspecified. Every standard creates a new class of non-standard things that the standard doesn't cover.
The result is a world where the major connection patterns are standardized and everything else requires custom work. And in practice, "everything else" is most of what organizations actually need.
The fundamental problem with standards as a solution to interoperability is that they solve the problem in advance, by forcing things into a common shape. But the things that need to connect are built by different people, at different times, with different assumptions. The common shape is always approximate. The gaps are always real.
The Universal Translator Arrives
AI didn't solve the interoperability problem by creating a better standard. It solved it by making translation between representations cheap — most of the time, for many integration tasks, compared with hand-written glue.
This is a categorically different approach, and its implications are still being absorbed.
A standard requires agreement before the fact — both systems conform to the same shape, so they can connect. A translator requires nothing of either system — it reads one, understands it, and writes the other. The systems don't need to know each other exists. They don't need to have been designed with each other in mind. They just need to be comprehensible, and AI has made an enormous range of systems comprehensible to an AI that can then bridge them.
The practical consequence is something that would have seemed remarkable five years ago and now feels almost mundane: you can describe what you want to connect in plain language, and the connection gets built. You can type your food intake in a chat interface and have it appear as structured entries in a database. You can describe a transformation between two data formats and receive working code that performs it. You can connect an API you've never seen to a system you built yourself, without reading the full documentation, because the AI reads it for you and writes the glue.
The plumbing is not gone. But its cost has collapsed. What used to take a skilled developer days now often takes minutes. What used to require knowing both systems intimately now often starts from describing what you want.
What remains is everything standards never fixed either: proving correctness, handling security and access control, meeting latency and compliance constraints, and operating the result in production. AI shifts where the hours go; it does not erase the need for judgment when the stakes are real.
What Barter Actually Required
To understand what this means, it helps to think about what money replaced.
Barter requires what economists call a double coincidence of wants. To trade, you need to find someone who has what you want, wants what you have, is available at the same time and place, and agrees on the relative value. Every one of these conditions must be satisfied simultaneously. The search cost is enormous. The failure rate is high. Complex economic activity is nearly impossible.
Money breaks every one of these conditions. You sell what you have to anyone who wants it. You buy what you want from anyone who has it. The two transactions are decoupled in time, space, and counterparty. The double coincidence of wants dissolves into a single coincidence of wants, and the market becomes vastly more efficient.
AI is doing the same thing for knowledge work that money did for barter. Before AI, connecting two systems required a double coincidence of technical compatibility — the data had to be in the right format, the API had to speak the right protocol, the developer had to know both sides. AI breaks much of this condition for a large middle of integration work: if both sides can be described clearly enough, a bridge can be drafted quickly. The hard parts slide toward specification, verification, and operations — not toward memorizing field lists.
This is not an incremental improvement in developer productivity. It is a phase transition in what's possible — the same kind of transition that money represented relative to barter. Not faster barter. A different kind of economy.
The Next Bottleneck
Following the pattern from the previous post: every fungibility revolution solves the current bottleneck and reveals the next one.
Electricity solved distance for energy and revealed that information couldn't travel. The internet solved travel for information and revealed that systems couldn't interoperate. AI is solving interoperability and revealing... what?
The answer is probably intent. The remaining friction in knowledge work is not connecting systems — it's knowing what to connect them to do, and why. The cost of execution has collapsed. The cost of knowing what's worth executing has not. (The same bottleneck appears, in different clothing, when you ask what context an agent actually needs — most reasoning is more local than it looks.)
This connects back to an earlier post in this series on cognitive ability versus fluid intelligence. The engineers who built careers on knowing things — syntax, API surfaces, system internals — face the steepest substitution curve. The engineers who built careers on judgment — knowing which problem to solve, recognizing when a system is getting more complex than it needs to be, understanding what users actually want — find that their comparative advantage has never been larger.
The heaviest plumbing tax is largely gone for many tasks; the architecture still requires someone who understands what they're building and why.
Fungibility has always worked this way. It doesn't eliminate the need for human judgment. It eliminates the specific tax that was consuming judgment's time. And each time that tax is lifted, the judgment that was always underneath it becomes visible — and more valuable — than before.
That seems like the right place to end up.