We are programming AI in assembly language

In the series of articles I’ve been writing for Fast Company devoted to what I believe corporate AI should be, I’ve been touching on a very provocative idea: Perhaps the biggest problem of corporate AI as we know it so far is not intelligence, but the level at which we are programming it. As we speak, frontier models, elastic cloud infrastructure, vector databases, managed APIs, and large amounts of computation are available to basically any serious company. As a substrate, this is extraordinarily powerful. However, in order to put AI systems into production, we still require engineers who hand-assemble fundamental things such as persistence, memory, permissions, tracing, retries, orchestration, durable execution, tool access, context management, and evaluation. As we said before, this is like the internet in 1991, before the web was invented. Today, high-level languages (programming languages that use strong abstraction from the computer’s hardware details, so it’s easier for humans to read and write) are normal. However, decades ago, developers had to fight the machine directly, in machine or assembly language, something that John Backus described as “a hand-to-hand combat with the machine”. In IBM’s history of Fortran, the company explains there were tasks requiring up to a thousand machine instructions that could be easily expressed in just 47 Fortran statements, while at the same time detaching programs from specific hardware. It is not that Fortran made computation possible, but it definitely made it economically expressible at a higher level. We saw the same pattern with C, Java, or the web. Dennis Ritchie explains how C allowed Unix itself to be rewritten in a largely portable language, making it easier to move across machines. Later, Java made the JVM plus standard libraries into an explicit platform, starting the “write once, run anywhere” movement. Then the web transformed an already functional but complex internet by introducing a simple shared grammar (HTML, HTTP, and URLs) on top of the network substrate. In all these cases, the infrastructure existed beforehand, but the abstraction made it easily programmable and manageable. Today’s agentic stack looks a lot like another pre-language period: We use Python plus frameworks and services to program intelligent applications, with each piece managing fundamental characteristics separately. None of these products is unnecessary-quite the opposite-but their proliferation is also evidence that an underlying abstraction may still be missing. What happens when an ecosystem grows around individually supplying properties the substrate does not naturally provide? Quite simply, the ecosystem can start to be read as a sort of itemized invoice for a missing layer. Who’s validating the runtime problem? The market out there Think about LangChain, for instance: It explicitly distinguishes the harness around an agent from the runtime underneath it. They say production agents have requirements such as durable execution, memory, multi-tenancy, human-in-the-loop, observability, sandboxes, integrations, and scheduling. And they themselves explain that “to build a good agent, you need a good harness; and to deploy that agent, you need a good runtime.” Does this give you a clue?