Software reuse built the empire of the instruction set. Machine-generated software is dissolving it, and quietly changing what a processor is actually for.
The instruction set isn’t going away. For as long as we build chips, some piece of software will be written to speak to one. What is dying is its status as the thing value attaches to. Read “dead” as “dethroned”: the instruction set architecture — the ISA — never really won on technical merit. It won as a cornerstone of economics.
That distinction matters, because economic instruments get repriced when the conditions that gave them their value change. And the thing that made “which instruction set?” the first and most consequential question in designing any computing system is now being repriced faster than much of the industry has noticed.
What an instruction set actually is
Strip away the engineering romance. An instruction set is the fixed vocabulary of primitive operations a processor understands — add these two numbers, fetch this value from memory, jump to that point in the program. Software, in the end, is a long sequence of these basic commands. The particular vocabulary a given family of chips speaks is its instruction set architecture: x86 (inside most laptops and servers), Arm (most phones), RISC-V (a newer, open ISA).
Underneath, the ISA is really a compatibility contract. Its economic job is to separate the investment in software from the specific hardware it runs on: write the software once, and it runs across a whole generation of chips, across different vendors, across silicon that hasn’t even been designed yet. A program compiled — translated down into that primitive vocabulary — for x86 keeps running on next year’s x86 chip without being rewritten.
That contract is why the industry consolidated onto a handful of instruction sets. x86 outlasted a graveyard of cleaner, more elegant designs not because it was better engineering but because it carried the accumulated software. Arm turned the same principle into a licensing empire — the value was never the chip design itself, it was the mountain of existing code that assumed Arm underneath it. Compatibility beat capability, again and again, for the same reason each time: software was expensive to write and expensive to move, so the interface that let you avoid rewriting it was where value compounded.
The ISA, then, was a moat around accumulated software. Its dominance rested on two assumptions everyone treated as permanent:
- Software is expensive to produce.
- Software, once produced, is expensive to move to different hardware.
Both are now weakening at the same time.
When software becomes cheap to regenerate
When you can generate working software from a high-level description, plain language, a system-level specification, an intent stated once and elaborated automatically by an AI “agentic” tool that writes and assembles the code for you, the source of truth stops being the code. It becomes the specification. The finished program is no longer a precious, hand-crafted object you preserve and laboriously port from one machine to another; it’s an output you regenerate on demand against whichever hardware you’ve chosen. For ordinary business and enterprise software, regeneration from intent is already close enough to reprice that object today. For verified, safety-critical real-time control — the domain that matters most here — it is a direction of travel, not yet a shipping capability.
Once that holds, both assumptions collapse together. The cost of producing software for a given piece of hardware falls towards the cost of merely specifying what it should do. And moving to different hardware stops being a porting project and becomes a re-run of the generator against a different back-end. The moment regeneration is cheap, the value locked up in accumulated, hardware-specific software loses its grip — and the reason to herd everyone onto a single instruction set goes with it.
A fair objection: if everyone now standardises on the generator and its toolchain, haven’t we simply relocated the lock-in one or two levels up? Partly, but the economics differ in kind. An instruction-set moat locks the artefact: the accumulated software you can’t afford to rewrite. A generator that produces software from a specification locks nothing so durable, point it at new hardware offering the same properties and it simply regenerates. What survives is a dependence on the specification and the validation suite, and both of those are, by construction, independent of the underlying hardware. The lock-in doesn’t so much move up a layer as dissolve into something that creators actually want to own: the definition of their own application.
We aren’t fully there yet — reliable intent-to-software is further along for business and application code than for hard real-time control, but the direction is unambiguous, and system architects buy for the direction, not for where things sit today.
If not the instruction set, what are you buying?
If the generation layer can target anything, “which instruction set?” drops beneath a more basic question: what does this silicon actually give the design process to work with?
The instruction set was always a proxy. We chose processors by their instruction set because we couldn’t cleanly separate “the software I already own” from “the machine I actually want.” Remove the software lock-in and the proxy dissolves — and you find yourself buying the underlying properties directly. Four of them matter:
- Interfaces — how the chip touches the physical world: the inputs and outputs it offers, the communication protocols it can speak, the electrical signals it can drive and read. For anything embedded in a physical system — a robot, a vehicle, a piece of industrial kit — this is often the whole point, not a footnote.
- Compute — raw and structured processing power: how much, at what precision, and for which shapes of workload.
- Timing — determinism: whether the chip can guarantee it will respond within a fixed time, every single time, rather than merely manage it on a good day.
- Cost and power consumption — the efficiency envelope the system has to live inside.
These are the attributes the automated design flow actually works with. The instruction set becomes an implementation detail beneath the generation layer — not extinct, demoted. The processor stops being a brand you standardise on and becomes a bundle of more abstract guaranteed, mix-and-match properties you select against.
The catch nobody wants to discuss: trusting machine-written software
Plain language is lossy; a specification written in it is ambiguous by nature. You cannot make an ambiguous input your primary design method unless you have an independent, rigorous way to confirm that the software the machine generated actually does what you meant. The generative layer proposes; a validation layer is what makes it trustworthy. The real loop is intent → generate → validate → iterate — and validation is the step that makes it safe to let a machine write software you’re going to ship into the real world. It isn’t a switch you flip; it’s a discipline — worst-case analysis on paper, mathematically checking the logic against a model, and measurement under deliberately hostile conditions.
The flow has two halves, and they are not equally mature.
Functional correctness — does the software compute the right answer? This has decades of tooling behind it: tests, logic checks, formal mathematical methods. Hard, but tractable.
Timing correctness — does it produce that answer within the time the system demands, every time? — is where most hardware cannot help you at all. And this is worth explaining, because it is the crux of the issue.
Modern high-performance processors are built to be fast on average. They guess which way a program will branch and race ahead on the assumption they’re right; they keep recently-used data in small, fast local stores called caches; and many cores share those caches and the connections between them. All of this is brilliant for average speed. It is ruinous for guarantees, because when a guess is wrong, or the shared resources are contended, the operation takes far longer — and you cannot say in advance how much longer. This isn’t a criticism of those chips; it is simply what decades of the worst-case-execution-time literature — the engineering study of the longest a piece of code can ever take to run — have documented for speculative, cache-sharing, contended designs: the worst case is either unbounded, or so pessimistic the bound is useless.
And here is the elephant in the room. You cannot validate a timing guarantee the hardware refuses to provide. No amount of clever software recovers a guarantee the silicon was never built to give. A scheduler — a piece of software whose job is to decide what runs when — sitting on top of a fundamentally unpredictable chip cannot manufacture a worst-case bound out of an architecture that was never designed to have one. The asymmetry runs one way only: a chip built to be predictable can happily run best-effort, average-speed work on top of its guarantees; a chip built purely for average speed can never have hard guarantees bolted on above it after the fact.
So a chip whose timing you cannot bound is a chip you cannot fully validate — and therefore one the automated design flow cannot safely target for anything that touches the physical world. Timing determinism stops being a nice line on a datasheet. It becomes the gate: the precondition for validation, which is the precondition for natural language-driven design to be trusted in any real-time system at all.
That is why the four properties above aren’t a flat list. Determinism is non-negotiable in a way the others aren’t, because it is the one that decides whether the validation loop can close at all.
The hardware has to move at the speed of the ideas
The whole promise of designing systems in plain language is speed to market: iterate in minutes, follow the market as it shifts, avoid freezing decisions you’ll want to change later. That promise is only real if the entire stack moves at that speed. If the silicon underneath demands a long, costly development cycle — bespoke up-front engineering (NRE, the non-recurring cost of designing a custom chip), fixed functions literally etched into a mask set (the set of physical templates used to manufacture a chip, expensive to change), an eighteen-month design-in that hard-wires the very features you wanted to keep fluid — then you’ve quietly reintroduced exactly the rigidity that plain-language design was supposed to remove. The generation layer iterates in minutes; if the hardware iterates in years, the hardware is the bottleneck, and adaptability dies in the silicon.
So the features that would otherwise be frozen into the chip have to stay malleable: software-defined interfaces, programmable timing behaviour, reconfigurable inputs and outputs. The chip should expose its properties to the generation flow as parameters the automated tool can compose against — not a fixed menu it has to take or leave as a whole. A fixed-function part hands the design flow a take-it-or-leave-it bundle. A flexible, deterministic, software-defined part hands it a design space with guaranteed properties — and that is the difference between hardware that keeps pace with intent-driven development and hardware that anchors it to the past.
[Full disclosure: I work on deterministic, software-defined silicon – GenSoC platforms – one of the classes of hardware this argument favours. Other approaches — lockstep safety microcontrollers (paired cores run in step and cross-check each other for safety), FPGAs (chips whose logic can be reconfigured after manufacture), and others — attack the timing problem from different angles, and several are converging on the same criterion.]
What this actually means
The instruction set was an abstraction optimised for software reuse, in a world where software was scarce and expensive to move. The emerging abstraction — intent, plus the validation that keeps it honest — is optimised for software regeneration, in a world where software is cheap to produce and cheaper still to re-target. When you stop preserving software and start regenerating it, you stop choosing processors by their instruction set and start choosing hardware by its provable, composable properties.
And among those properties, timing determinism sits first among equals — not for architectural elegance, but because it is the one property that cannot be recovered above indifferent hardware, and therefore the one that decides whether the validation loop can close and the whole method can be trusted.
The honest caveat: this isn’t fully here today, intent-to-verified-software for hard real-time control is early. But the direction is driven by economics, not enthusiasm. The moment regeneration is cheaper than reuse, the instruction set stops being where value accrues, and a chip’s provable properties become the thing you’re actually buying.
The instruction set isn’t dead because a better one came along. It’s being dethroned because the thing it was protecting, expensively hand-written software you couldn’t afford to rewrite, has stopped being the thing you need to keep.
Mark Lippett
CEO, XMOS
