Nobody Writes Assembly Anymore

Every raise in abstraction retires a rung. This one retires the last rung below deciding.

Eric Garcia, PhD

Eric Garcia, PhD

October 14, 2026 · 10 min read

An empty wooden director's chair with a dark canvas back, standing alone on a riveted iron gantry high above an enormous machine hall. Rolled plans and a loose sheet of line drawings — schematics with no legible labels on them — lie across one arm of the chair. On the platform beside it sit two stacked unlettered books and a plain metal mug. Below and beyond the railing, lit by shafts of dusty light from windows high in the far wall, is a cathedral-sized works of brass and iron: toothed gears taller than a person, drive shafts, couplings, catwalks and tiered galleries receding into haze. No person appears anywhere in the picture, and no text is legible in it.
The chair is on the gantry, the plans are on its arm, and nobody is in it.

There used to be a job that consisted of telling a processor where to put a number. Not what the program was for, not what it should do when the input was wrong — which register, which address, one instruction at a time, in the order the machine would execute them. It was skilled, hard to learn, and you could build a career in it.

That job is gone. A small number of people still write assembly — compiler backends, the inner loop of a cipher, a device driver with no room to spare — and they're specialists in a way that somebody writing assembly in 1975 simply wasn't, because then it was an ordinary part of the job rather than a specialty. The rung didn't empty out. It got narrow, and it stopped being where the work happens.

Nobody mourns it. The thing that killed that job is the thing we're told to be afraid of now.

The field only ever got bigger

The obvious reading of a disappearing job is grim, and in this case it's wrong — wrong in a way that's worth more than the easy version of it.

Every raise in the level of abstraction has made software cheaper per unit, and each time so far demand has eaten the surplus. When one programmer could do with a compiler what had taken a team, the answer was never to keep one programmer. It was to build more software — and then to build software for people who'd never have been able to afford any. There are more people working in software today than at any point when assembly was an ordinary skill.

So the assembly programmer wasn't fired by the compiler. They were promoted by it. The ones who'd spent years learning which register to use spent the next years deciding what the program should do instead. The same thing happened again from C to the managed languages, and again from there to a world where a working application is a few hundred lines of somebody else's library calls. Each time, the people who'd been doing the lower job moved up to the higher one, and each time there turned out to be more room up there than anyone expected.

That history is the strongest argument against the fear, and it deserves to be stated the way its believers state it: automation of a layer has never once shrunk this profession, and there's no reason to think the mechanism has changed. The mechanism hasn't changed.

The ladder has.

A raise retires a rung

The pattern underneath is mechanical. A raise in abstraction does two things: it retires a rung, and it shifts that rung's occupants up one. Assembly retires, its people land on C. C retires as the ordinary place to work, its people land somewhere garbage-collected. And so on up, each generation convinced the one below them understood the machine better, each generation correct about that and building more anyway.

The shift-up is what makes the history benign. It's also what everyone is quietly assuming will happen again, and it depends on a fact nobody states: that there's always another rung above.

There isn't. The ladder has a top.

Above any description of a program sits a more compact description of the same behavior — that's what a rung is, a way of saying the same thing with less of it spelled out. Keep going and you run out of things to leave out. What's left at the end is the irreducible pair: what should this do, and how will I know it did. You can't abstract above that, because there's nothing in it that was ever detail. It's the intent itself, and intent doesn't compress. The top rung isn't a shorter account of the behavior — the only complete account of behavior is the program itself, and it always will be. It's the shortest statement of what the program is for, and of how anyone would check.

Call that the top rung. It's where the specification lives, and it's where the raise now underway is pushing everyone — because the rung it's retiring is the last one below the top.

A ladder standing on a rocky summit against a pale engraved landscape of hills, water and cloud at dusk. Its rungs are pale boards carrying the level you work at, read from the bottom up: "registers and addresses", "statements and types", "objects and library calls", and at the top "what it should do, and how I'd know". Between the lower rungs are narrower dark boards naming what does the translating — "assembler" below the first, then "compiler", then "runtime and libraries". Between the top two rungs there is no board at all, only a dashed line. Above the topmost rung the ladder stops at a solid rail, and above the rail the words "intent doesn't compress".
Every rung below the top was reached by building the thing that does the translating.

Three of those joints have a machine in them. The fourth is the one everybody is standing at.1

The claim is narrow. Not that software will need fewer people, which history says it won't: that the shift-up has one move left in it. There's a rung above the person writing the implementation, and they're going to land on it. There is no rung above that one. So the landing is terminal, and everybody who stays ends up standing in the same place — not because the rung below empties, but because it narrows the way assembly narrowed, into a specialty rather than a job most people have.

The place is deciding.

The job already exists, and it isn't a software job

Somebody will object that the models themselves get built by implementers, and that's true. The people who write the layer that retires a rung are the compiler writers of this raise. Whether their rung narrows the way assembly's did is genuinely open — the effort going into it is enormous, and growing. What isn't open is that it's one rung, and that almost everybody who ships software ships it on top of that rung rather than on it.

Software is the wrong place to look for what the terminal rung is like to work on, because software has never had many people standing there. Two other fields have had them for a century.

A film director is accountable for the work of hundreds of people whose jobs they will not do. They don't operate the camera, cut the negative, build the set or light the scene. What they hold is what the thing is: what it's about, how it moves, what it should feel like in the eleventh minute, and which of four takes is the one. A C-suite executive is in the same position with a different vocabulary, and supplies the half the director doesn't. They're accountable for outcomes produced by people they've never met, in work they couldn't personally do, and the only instrument they have for any of it is a briefing somebody else wrote. A director can walk onto the set and look. An executive mostly can't, and runs the company anyway — on summaries, about machinery they'll never see running.

There's one job title that's already both: the showrunner. A showrunner is the author of the vision and the executive accountable for the budget, the schedule and the staffing, on work that's serial rather than finished once — a roadmap, not an artifact. It comes with the unglamorous part attached, which is that a showrunner's day is mostly reading other people's drafts.

A director's authority over all those people rests entirely on craft. They can tell a cinematographer precisely what's wrong with a shot, in the cinematographer's own terms, because they've spent years learning to see it. Somebody who can only say make it better isn't directing. They're producing, and the crew works it out by Tuesday.

So the top rung isn't an escape from implementation knowledge. It's implementation knowledge spoken at altitude — and that's taste built out of having done the work, which is the one thing that doesn't arrive with the promotion. You don't get to skip the ladder you're standing on top of.

The compiler refuses; the model doesn't

A complete specification of a program's behavior is a program. That's not a slogan, it's nearly a definition: anything you leave out of a specification is behavior you haven't specified, and the only document that pins down every case is an implementation. English is far cheaper to write than code, and far more expensive to verify.

The step up is real all the same, and it's worth being exact about who it's real for. The ladder was never built for the machine. A machine reads English and code with the same ease and has no preference between them. Every rung was built for the person — each one let you say what you wanted in words a little closer to your own. Registers became statements, statements became library calls, and now the top rung can be said out loud in plain English, the way you'd say it to a colleague: what should this do, and how will I know it did. That's the largest step anybody has taken on this ladder, and it's a step up for exactly the reason every earlier one was.

So the complaint is narrower than it sounds, and it survives the concession whole.

A compiler is deterministic. It has no judgment, so there's no judgment to lose in the translation, and the same input gives you the same program forever. More than that: when your intent is ambiguous, a compiler refuses. It stops, prints a line number, and makes the ambiguity your problem. That refusal is what makes the rung above it safe to stand on.

A compiler's refusal isn't perfect. Undefined behavior is exactly the case where it assumes you meant something legal and optimizes on that assumption, silently — and that this is the most notorious thing about C is the point. It got a name, a literature and a permanent argument, because a tool that quietly decides for you is intolerable in a way that one which stops is not.

A language model does the opposite of refusing. Handed an underspecified intent, it doesn't stop — it fills the gap, plausibly, in a register indistinguishable from the parts you actually specified. Nothing prints a line number. The decision still got made; it just got made by something that will not tell you it made one.

That's a real step up with the part that says no taken out.

None of which is an argument for staying put. The rung is real and worth standing on. What it doesn't come with is the floor — a test, a type, a budget that fails the build, an eval suite, an acceptance criterion written before the work. Every climb before this one arrived with that part already built. This one you build yourself, or you stand up there with nothing underneath you.

Two of the six questions are not like the other four

A showrunner steers on briefings. What makes a briefing worth steering on is answered by the list almost anybody produces when they're asked what they'd specify:

A two-column diagram on pale paper, ruled down the middle by a fine vertical line. The left column is headed "INTENT" and holds four cards drawn as thin hairline outlines, empty of ink, reading "What does this do?", "Does it scale?", "What are the cost and performance tradeoffs?" and "What's the roadmap?". The right column is headed "CHECK" and holds two cards of the same width drawn as solid blocks of dark ink with their words reversed out in the paper color, reading "How will I know if it works?" and "How will I know if it stops working?". The two solid cards are taller than the four outlined ones, so that four light questions and two heavy ones fill the same height.
Four of these you can answer in a meeting. Two of them you have to build.

Those aren't six questions of one kind. The first four are intent — what the thing is and where it's going. They're the ones everybody can already answer, and they're nearly free, because it should scale costs you nothing to say and commits you to nothing in particular.

The last two are a different species. How will I know if it works is an acceptance criterion: a check, written in advance, that the finished thing either passes or doesn't. How will I know if it stops working is instrumentation: a signal that fires when the answer changes six months from now, with nobody watching. Neither is a statement about the product. Both are statements about the briefing — they're the specification of the summary you're going to steer on.

An executive summary is lossy compression of the engine room, and a characteristic way a large organization fails is that the compression dropped the one thing that mattered: the status was green at every level of the briefing and red at the only level that was touching the machine. Nobody lied. The summary just wasn't specified to carry that.

The difference in software is that the engine room can be instrumented. You can decide in advance which band of detail has to survive the compression, and then build the thing that makes it survive. That's what the last two questions are for, and it's why they cost something.

Which gives the rule the top rung actually runs on:

You can stand one level up exactly to the degree that you've specified how you'd learn you were wrong. No acceptance criterion, nothing underneath you. A roadmap with no falsifiable claim in it isn't a specification, it's a preference — and the thing that used to absorb the difference was a person on the rung below, who read the vague instruction, worked out what was actually wanted, and quietly supplied the judgment the document was missing.

That person is being promoted. Nothing is being promoted into their place.

What the compiler was actually for

The fear about automation is that it takes the work. The history says it takes the rung and promotes the worker, and the history is right, and it has one move left before the rungs run out. Everybody who stays is going to be standing on the top one, holding what the thing is and accountable for work they won't do — which is a showrunner's job, and has been somebody's job in rooms where nobody writes software at all.

Nobody writes assembly anymore. Somebody wrote the compiler, and what they built was a machine that refuses to guess. What's arriving now is a machine that guarantees it will. Whether you get to run the show comes down to whether you can tell those two apart when you read your own specification back.

Footnotes

  1. Both figures are generated images rather than plots. Each was made to a written specification by an image model rather than drawn by a script, and neither contains data. They illustrate the argument; they do not compute anything. ↩

Eric Garcia, PhD

Eric Garcia, PhD

Founder & Principal Consultant

PhD in Machine Learning from UW. Former Spotify ML engineer. 15+ years building production ML systems.

Learn more about Eric →

Need Help with Production ML?

We help companies build ML systems that actually work.

Learn About Our ML Consulting