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...
For further actions, you may consider blocking this person and/or reporting abuse
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.