Most people in IT have at least heard of assembly language. Some even saw it during university - just enough to know it exists, but not enough to use it for anything real.
Assembly used to be the secret behind high-performance code. Games like Quake, graphics engines, and device drivers often had big chunks written in assembly for one simple reason: speed.
But times changed. Modern developers rarely touch assembly anymore, and for good reasons. Until recently, it simply didn't make sense for most projects.
Well, at least, that's what I thought - until I tried something on my Mac a few days ago.
Why Assembly Disappeared
Assembly slowly vanished from mainstream software development because it was too much work for humans to handle.
- It's not portable - an assembly routine that runs on x86 won't work on ARM, RISC-V, or a GPU.
- It's not maintainable - every line depends on the quirks of a specific CPU.
- It's also not forgiving - one wrong instruction and you crash the process or corrupt memory.
Higher-level languages like C, Java, or Python fixed that. They gave us portability, readability, and safety. We stopped thinking about registers and flags, and started thinking about business logic.
Compilers got so good that we forgot there was assembly underneath. For human developers, this was a big win. For LLMs, though, those constraints don't really apply.
Humans Have Limits. LLMs Don't - at Least Not the Same Ones
Humans forget things. We can't hold every detail of a large project in our head. That's why complex systems end up consuming too much memory, leaking resources, or deadlocking.
LLMs, on the other hand, can "see" entire codebases at once. With enough context tokens, they can process hundreds of files, reason about dependencies, and never lose focus.
So I started thinking: if an LLM can understand requirements directly in English, why do we still need to go through a high-level programming language at all?
Why not just ask the model to write assembly code directly for the target hardware?
From English to Assembly on My Mac
Each CPU architecture - x86, ARM, RISC-V, GPUs - has its own instruction set. But that's not really a problem anymore. You can simply be explicit in your prompt.
In my case, I told Copilot something like this:
## Target Platform
- **Hardware**: MacBook Pro 16-inch (November 2024)
- **Processor**: Apple M4 Max (ARM64 architecture)
- **Operating System**: macOS
- **Execution Environment**: Terminal applications
That's it. No compilers, no C, no libraries. Just plain English. Copilot produced a short, valid assembly routine for my Mac. Then I asked it to write a test harness to verify it. It chose Python automatically, wrote the code to load and call the routine, and checked that 3 + 5 returned 8. It worked.
It was simple - just adding two numbers - but it proved the point: I didn't need to know the registers, calling conventions, or even the assembler syntax. The AI handled all of it.
Why Assembly Might Make Sense Again
For humans, assembly was too low-level to manage. For LLMs, it's just another language - no harder than Python or JavaScript.
They could:
- Generate code directly optimised for the target CPU or GPU.
- Adapt automatically to architecture differences.
- Explore micro-optimisations that compilers might miss.
Imagine asking:
"Generate an ARM64 routine for matrix multiplication optimised for Apple's M-series cache layout."
The LLM could write it, benchmark it, refine it, and repeat - all automatically. That's something no human could realistically do across multiple hardware targets.
Of course, there are risks. LLM-generated assembly might not be deterministic or reproducible. It may fail silently or produce slightly different code for the same request. And debugging machine code generated by a neural network sounds like a nightmare.
But then again, we already trust compilers we don't fully understand. This is just one level deeper.
Requirements in Plain English
One of the most exciting parts of all this is how LLMs turn requirements into code.
It's like Behaviour-Driven Development (BDD), but without the intermediate steps. You describe what you want:
"The function should return the sum of two integers and store the result in memory."
The LLM translates that into assembly, or C, or Python - whatever fits the goal - and can even test it immediately. In theory, product managers could write requirements that are executable from day one, without developers writing scaffolding or boilerplate.
Languages would become more like intermediate representations - still useful for humans, but optional for machines.
What Comes Next
Here's where I think this could go in the next few years:
- LLMs trained per architecture - ARM, x86, RISC-V, CUDA, etc.
- AI-driven compilers - translating English or pseudocode straight into optimised machine code.
- Semantic debugging - where you ask "why is this logic wrong?" instead of inspecting registers.
If that happens, the boundaries between design, coding, and compiling could blur completely. Developers will focus on describing intent, not syntax. LLMs will handle the low-level reality. And maybe, just maybe, assembly will make sense again - not because we understand it better, but because our tools finally do.
If you'd like to see the tiny "add two numbers" experiment I mentioned, I've shared it on GitHub: github.com/ionionascu/llm-to-assembly
This is not a production-ready project - it's a simple proof of concept. The code focuses only on the happy path and is not designed to be fault-tolerant or cover all possible test cases. Invalid inputs or edge conditions may cause segmentation faults or crashes, and that's expected.The goal was never to build robust software, but to explore whether an LLM could generate functional assembly code directly from plain English.
TL;DR: This project isn't about "vibe coding" or skipping engineering discipline. It's a small, controlled experiment meant to explore what happens when large language models can reason directly at the hardware level - not a suggestion that we should replace careful software design with AI prompts.
Note: As I'm not a native English speaker, I used ChatGPT to review and refine the language of this article while keeping my original tone and ideas.
Originally published on Medium.
Top comments (12)
Interesting consideration.
One argument. What if you ask your LLM to write a whole operating system or a web browser for you, or something just as complex?
Abstractions (including high-level programming languages) have been created to reduce the amount of code to manage which also happens to reduce the overall bug surface.
Unless your LLM is flawless, the more code it writes, the more bugs it can introduce.
Suppose it's intelligent enough to create some abstractions, then. What it will come up with is going to be something like a standards library, a framework, or something very close to another high-level programming language. Consider features like asynchronous I/O, multithreading, UI logic, etc, which are a strong requirement and a recurring problem.
Next consideration: If you repeatedly get your LLM to create such large applications, it might come up with a different "framework" every time, or possibly converge to the same one and start reusing that for future projects. It may reinvent libraries, higher-level abstractions, etc. It would make sense, as it's much less work to do, much more computationally efficient, which is a big deal.
What do you think?
That is a really thoughtful comment. Thank you for raising those points!
So far, I have tried a couple of small experiments related to this idea and suggested by others:
Both worked, but only for small applications. I agree that building something as complex as an operating system is far beyond what LLMs or tools like GitHub Copilot can do today. Still, with proper planning, prompt-engineering workflows and strong test harnesses in place, the code they produce can be surprisingly solid, often with fewer flaws than expected.
With the right guidance and iterative refinement, I think it’s only a matter of time before AI systems move closer to handling more complex builds. We are living through a fascinating time in software development.
This article lets me reminisce on my college days when I was struggling to learn assembly languages on embedded systems, be it Intel's x86 ASM or RISC assembly. Unless we're talking about optimisation at the lowest level, from increasing the number of transistors to creating an efficient ALU unit, it's highly doubtful that the use of assembly language would go mainstream.
Do you think it's feasible and worth trying to implement vibe coding in writing firmware or similar, sophisticated code in the future?
Thank you for reading the article and sharing your thoughts. In my view, requirements always start in plain English (or another natural language), while the actual work is ultimately done by hardware that understands assembly instructions. The programming languages and abstractions we use in between are just tools that help bridge that gap, useful today, but easily replaced by new ones tomorrow.
Lets skip straight to compiled hex! 🛠️
Assembly is really just a human-readable way to represent what eventually becomes machine code. Nothing’s stopping you from asking Copilot to go one step further and output bytecode directly — in my case, it basically invokes tools like Clang under the hood anyway.
This is more of a "toy example" than a "proof of concept". Adding two numbers is within the cognitive capacity and focus of a human being on the first day that they learn how to write any assembly language. There's no demonstration that LLMs can successfully handle assembly language routines of greater complexity, You started with a claim that LLMs could deal with memory management in assembly over hundreds of files, and finished with writing an addition function.
Thank you for taking the time to read the article and share your thoughts. As mentioned in the piece, this was never intended as a production-ready project, but rather as a small proof-of-concept experiment. I completely understand why it might feel too simple and that a stronger demonstration would involve a more complex, real-world scenario. That said, I tried to be transparent about the limited scope, and I think it still highlights something very interesting about what LLMs are already capable of today. The article also looks ahead at how LLMs and related tools might evolve to handle more complex, large-scale tasks in the future.
Although I didn't anticipate assembly making a resurgence, it would be revolutionary if LLMs could manage it. Simply outlining your requirements and making it compatible with various hardware? Coding will soon look very different if this trend continues.
This is a very interesting observation. I'm no LLM expert, but this does seem pretty reasonable, especially as LLMs get more advanced.
One thing i do disagree with is to have ONLY assembly. I'd draw a barrier at C honestly given that I wouldn't just yankee-doodle assembly code straight away to an architecture without reviewing it at least once. C is pretty blazing fast and fast enough, which seems perfect for speed and readability.
Since the emergence of LLMs this thought never crossed my mind. I think we do need big techs or atleast few good players & labs to fine tune or train some LLMs on as much assembly data as they can get their hands on. Probably good data though. Its difficult to identify & pick “good” low level code & that leaves a very few set of people competent enough to assist in this.
That's what I think too. I believe we need to train some assembly language-based models specifically for assembly-level software. Many software programs sacrifice performance for versatility.