Sideways, Not Up: Why AI Is Not a New Abstraction Layer - SixSidedDice.com - Blog

Jun 18, 2026

Thoughts<br>AI<br>CodingAssistants<br>Abstraction

Sideways, Not Up: Why AI Is Not a New Abstraction Layer

There is a tidy story doing the rounds, and like all tidy stories it is mostly told as if it were obvious. The story goes like this. Software has always climbed a ladder of abstraction. We started with machine code, then assembly gave us mnemonics instead of raw opcodes, then high-level languages and their compilers let us write for loops and forget about registers entirely. Each rung let us say more while caring about less. And now, the story concludes, AI is simply the next rung. You describe what you want in English, the model writes the code, and one day soon you will no more read that code than you currently read the assembly your compiler emits.

It is a compelling narrative because it has a true part welded to a false part. Andrej Karpathy put the true-feeling part memorably when he declared that "the hottest new programming language is English", and earlier still framed neural networks as "Software 2.0" in which "the process of training the neural network compiles the dataset into the binary". Matt Welsh took it to its logical extreme in the Communications of the ACM, arguing that "the conventional idea of 'writing a program' is headed for extinction". The ladder, the compiler, the next layer up. It all rhymes nicely.

I write this not as a cynic, but as a software craftsperson with over 30 years of experience building, maintaining, and occasionally rescuing systems that other people's abstractions had quietly betrayed. I have a great deal of time for AI coding assistants. I use them daily. But I think the abstraction-layer framing is the wrong mental model, and getting the mental model wrong is how teams end up surprised.

If high-level languages are an abstraction over machine code, is AI really an abstraction over high-level languages, or is it something else entirely wearing the same costume?

The Ladder, and Why It Is So Seductive

Let me make the case for the other side properly, because it is stronger than the lazy version suggests.

The honest core of the argument is that programming has always been the act of compressing intent. We do not write in machine code because expressing intent that way is slow, error-prone, and unbearable. Every layer we have added has been a more humane notation for saying the same thing to the same silicon. Seen this way, natural language is just the most humane notation yet. Marc Brooker makes this point well, and disarms the obvious objection in the process. Critics say natural language is too ambiguous to be a programming medium, to which he replies that "almost all programs are already specified in natural language. And always have been." The requirements document, the ticket, the conversation with the product owner: these were always the real source, and code was merely the transcription. AI just removes a transcription step.

Martin Fowler is, as usual, the most careful voice here, and he does not undersell the magnitude of the shift. He reckons LLMs "will change software development to a similar degree as the change from assembler to the first high-level programming languages", and that "talking to the machine in prompts is as different to Ruby as Fortran to assembler". That is not a small claim, and it is not made by someone prone to hype. If you want the strongest case for the other side, that is it: a transition as significant as the one that gave us the compiler in the first place.

I agree with the magnitude. I disagree about the direction. And the difference between those two things is the whole argument.

What a Real Abstraction Actually Does

Before we can ask whether AI is a new abstraction layer, we have to be precise about what an abstraction layer is for. The point of a good abstraction is not that it hides complexity. The point is that it lets you stop thinking about the layer below . That is the load-bearing property. When I write C# and hand it to a compiler, I genuinely do not think about the IL code that is generate or the x86 instructions it emits at execution time. I do not read them. I do not review them. I do not keep a copy in case the compiler has a bad day. The abstraction has earned my trust, and that trust is what buys me the productivity.

It earns that trust through three properties that we tend to take for granted precisely because they are so reliable. It is deterministic : the same source compiled with the same compiler and flags produces the same output, every single time, which is the entire premise behind reproducible builds. It is specified : the language has a grammar and a semantics, so the translation from source to machine code is defined behaviour I can reason about, not a surprise. And it is verifiable : when something goes wrong, I can reason backwards through a defined mapping to find out why.

The Compiler Keeps Its...