Nobody reads the assembly

Engineering · Dwayne Donaldson · October 23, 2026 · 7 min read

Illustration of the layers of programming languages stacked from machine code at the bottom, through assembly, FORTRAN and C, Python and JavaScript, up to intent, specs and tests at the top. A dashed line on the left climbs upwards, marking where people read the code. An arrow on the right points down to machine code, marking what the chip runs.

This week I compiled a six-line C function that adds up a list of numbers, and then, for the first time in a long while, I opened what the compiler had actually produced. On my laptop it came out as 47 lines of ARM64 assembly. Built for an Intel chip, the same six lines became 41 lines of completely different instructions. I closed the tab after a few minutes, which I suspect is what most programmers do on the rare occasion they look.

We stopped reading that layer decades ago. The compiler writes it, the tests pass and nobody opens it. My thought, and the reason for this article, is that AI is about to give us the same relationship with Python, Java and TypeScript. And if nobody reads those either, I'm not sure what they are for any more, because readability was always the point of them.

The last time this happened

In 1957 IBM shipped the first FORTRAN compiler for its 704 computer. John Backus, who led the team, later wrote that programmers at the time saw efficient programming as a creative art that couldn't be automated, and they had good reason to. Most "automatic programming" systems of the day produced slow code. So the team barely worried about the language. Backus called that the easy part, a prelude to the real problem of "designing a compiler which could produce efficient programs". He knew FORTRAN would only be used if it came close to hand-written code, on almost every job.

It worked, obviously. Compilers got good enough that the people who still read their output became a specialist crowd. Matt Godbolt built Compiler Explorer for them in 2012, a website where you type code on the left and watch the assembly appear on the right. It's a lovely piece of work, and I'd guess the majority of working programmers have never opened it.

Who the readable layer is for

High-level languages exist for people. Python didn't become popular because the chip likes it. The chip would much rather have the 47 lines. Python's own style guide says it plainly, quoting Guido van Rossum's point that code is read much more often than it is written. Every bit of readability is there for the next person who has to understand, review or change the thing, and that includes you in six months.

Side-by-side comparison. On the left, a six-line C function called sum that adds up a list of numbers. On the right, the 47 lines of ARM64 assembly that clang produces from it at optimisation level O2, including vector instructions and three branch labels. A note says the same function built for an Intel chip is 41 lines of different instructions, and neither listing runs on the other machine. — The same function twice. I wrote the left side. The chip runs the right side, and I have never needed to read it.

Now look at who the next person is. More and more of the teams I see are starting to judge code on the outcome itself. A model writes it, a model reviews it, and the person reads the pull request description and the test results. Andrej Karpathy put it in one line in January 2023, that the hottest new programming language is English. If that's where things are going, the layer people read moves up again, to the intent, the spec and the tests. Whatever sits underneath becomes the new assembly, something you could read, in principle, and mostly won't. At that point I struggle to see why it should stay Python.

What we pay for readability

Quite a lot, as it turns out. I ran the sum function on my laptop over ten million numbers. A plain Python loop took 227 milliseconds. The C version took 4.1. That's about 55 times slower for doing exactly the same arithmetic, and Python's built-in sum, which is itself written in C, landed in between at 36 milliseconds.

My test is a toy, but the research says the same thing at a larger scale. A Portuguese research group measured the energy used by 27 languages on the same set of problems in 2017. With C at 1, Rust came in at 1.03, Java at 1.98, JavaScript at 4.45 and Python at 75.88. In 2020 a group led by MIT researchers multiplied two large matrices in Python, which took about seven hours, and then kept optimising until the same job took 0.41 seconds. That's more than 60,000 times faster. Switching to C gave them roughly 50 times. The rest came from tailoring the code to the exact hardware, its caches, its cores and its vector instructions, which is the kind of work people hate doing by hand and a machine might not mind.

None of that mattered much while computers kept getting faster for free. It matters more now. The International Energy Agency puts data centres at around 415 terawatt-hours in 2024, about 1.5 per cent of the world's electricity, and expects that to more than double to around 945 by 2030. A good chunk of that growth is AI itself, which makes the argument a bit circular. If the models are going to burn that much electricity, they could at least write code that burns less of it.

And there is some evidence they can work down there. In 2023 DeepMind's AlphaDev searched for sorting routines directly in assembly and found ones that were up to 70 per cent faster for short lists, and about 1.7 per cent faster for lists of more than 250,000 elements. They went into LLVM's standard C++ library, the first change to those routines in over a decade. A 2025 paper went further and trained a 7-billion-parameter model to rewrite assembly that gcc had already optimised at its highest standard level. On average the rewrites ran about 1.46 times faster.

Six lines in, 47 out

My own example is also the best argument against me, so it's fair to spend some time on it.

I didn't try to beat those 47 lines, and I doubt I could. Clang had already unrolled the loop, used the vector registers and handled the leftovers at the end, and the loop spends most of its time waiting for memory anyway. The 55 times I measured is the gap between an interpreted language and a compiled one. The gap between good C and hand-written assembly is much smaller, and often it's zero, because the compiler wrote the assembly in the first place. So the honest version of my claim is "back towards the metal", not necessarily "back to assembly".

Then there's the second chip. Those 41 Intel lines don't run on my Mac and the 47 ARM lines don't run on an Intel server. Not having to write everything twice is half of what FORTRAN was invented for. A model could just generate both, and regenerate them for the next chip, but that is a lot of code that needs to be right in two places, and I haven't made up my mind about it.

Tokens cost something too. Six lines of C became 47 lines of assembly, and every one of them has to be generated, which uses electricity. For a function that runs a billion times a day that's an easy trade. For a settings page that gets opened twice a week it isn't.

The big one is trust. We read code to believe it does what we think. If nobody reads it, the belief has to come from somewhere else, so from tests, specs, benchmarks and maybe formal proofs, and I don't think most teams have that in place today. The same 2025 paper is a good example. Its model was faster than gcc on average, and about one in twenty of its rewritten programs failed the tests. A compiler that did that would be thrown out the same day.

Where I'd put my money

I think the layer people read keeps moving up, and the layer underneath drifts down towards the machine. Not hand-written assembly everywhere. More likely the hot paths, the small parts of a system where most of the time is spent, get written and rewritten by models in assembly or something close to it, while the rest goes to languages that compile to fast code and are easy to check automatically, like Rust or C. Python stays exactly as long as people want to read it.

Elon Musk told xAI staff in February 2026 that maybe by the end of this year nobody will bother coding, and the AI will just create the binary directly. I think that skips a step. Even the compiler pipeline we have now goes through readable stages, and those stages are where bugs get caught.

What I don't know is who signs off on code nobody can read. Today it's the reviewer. In ten years I genuinely don't know, and I haven't seen a good answer yet.

Sources

Backus, The History of FORTRAN I, II and III (1978): how programmers saw hand coding, and the compiler as the real problem.
Matt Godbolt, Happy birthday Compiler Explorer (2022): the first commit in May 2012.
Karpathy on X, 24 January 2023: the hottest new programming language is English.
Pereira et al., Energy Efficiency across Programming Languages (SLE 2017): normalised energy per language, table 4.
Leiserson et al., There's plenty of room at the Top (Science, 2020): the matrix multiplication example, table 1.
IEA, Energy and AI (2025): data centre electricity in 2024 and 2030.
Mankowitz et al., Faster sorting algorithms discovered using deep reinforcement learning (Nature, 2023): AlphaDev and libc++.
Improving Assembly Code Performance with Large Language Models via Reinforcement Learning (arXiv, 2025): speedup over gcc -O3 and the test pass rate.
Reuters, 11 February 2026: Musk says xAI was reorganized: the comment about AI creating binaries directly.
PEP 8, Style Guide for Python Code: code is read much more often than it is written.
The sum benchmark is my own, run on an Apple M5 laptop with Python 3.14.6 and Apple clang 21 at -O2, summing ten million integers and averaging 3 Python passes and 10 C passes.

If you write compilers for a living, or have hand-tuned assembly that a model couldn't touch, I'd like to hear about it at [email protected].