I looked at the Github page and of course it's vibe coded. This is the sort of project that someone would have spent a few months doing as a learning exercise while they were reading through something like Crenshaw's "Let's Build a Compiler" series. I don't see the point of vibe coding it. You still end up with a toy compiler that nobody will actually use, except now you haven't learned anything about how compilers work. It's pointless.
I imagine I’d learn a fair bit about how to go about vibe-coding developer tools by implementing this, so it hardly seems pointless? It seems like an interesting exercise.
In particular, I’d want to experiment with how to get coding agent to generate more readable code and better documentation. I can get it to make the code somewhat readable, but haven’t really solved yet.
Vibe code means the human did not look at the code: how do you know that's true?
It's easily to spot a code base that's build LLM-assisted. But to know that no human actually took interest in the code is hard to know without talking to the humans that prompted the LLM.
The blogpost about the compiler is AI written, the README file in the Github repo is AI written, all the documentation is AI written, the reverse engineering analysis of Borland Turbo C++ is AI written, all the comments in the code are AI written, and every single commit in the repo was done by Claude. I don't think it's reasonable to say that the author took any serious interest in the code. I suppose they might have glanced over it before telling Claude to commit, but you don't get much out of that vs. writing a toy compiler yourself.
Exactly. Some "Prolog interpreter in Tcl" is a prompt away in LLMs but what's the point of inferring and dumping it on github? Same goes for any vibe-coded project.
Yep, and the code is an eyesore to look at. Almost no logical separation of code blocks (everything mashed-up together) I was really expecting LLM to annotate every line of code with (useless) comments, considering many vibecoded js projects are like that.
Either my C skills are getting rusty and that is how a C codebase normally looks like, or LLM was trained on some suspicious codebases.
I checked a few source files at random and it looked fine to me overall. It's broken down into small-to-medium sized functions, contrary to what you suggest. If your issue is just the size of the individual source files, then you can find much larger in non-vibe-coded C projects like QuickJS.
Wait, I had a look and this looks really like any other C code base to me. I even think it's unlikely this is LLM-generated?! The presence of some large functions, for example, is a sign of human-generated code, LLMs tend to be strongly opposed to that, unlike C programmers.
No you're right, this code is terrible. Running a linter like clang-tidy would surface many issues. Not sure why the LLM didn't think of ever doing that.
Clearly chibicc derived.
The testsuite is a bit primitive, that's why I wouldn't trust it to compile much. Maybe I'll add to my small C compiler comparison tables.
This is really neat, I'll have to give it a try. I grew up on QuickBASIC, then Turbo Pascal and Turbo C later on. For my own personal hands on coding time solving mathematical challengers or working on hand coded personal projects to relax in our increasingly agent driven world I've taken to using the text mode Free Pascal ide that is bundled in with the fpc compiler, built on an open-source implementation of Borland's TurboVision DOS TUI libraries. I always wished it had a mode to emulate Turbo C as well.
The only bummer I'm seeing with fcc is not having a linker mean not being able to use external libraries. So you're really limited to what you can include in your own project, but if it truly is C89 compliant there are plenty of useful single header libraries you could use for various things.
I'm not willing to whitelist whatever bullshit malware this thinly veiled advertisement wants to run on my computer before it will allow me to see the page. Can someone share a précis?
The Adafruit post is just an LLM recap of the author's blog post, which is an LLM summary of the project, which was vibe coded with Claude. The signal:noise ratio is dropping off exponentially.
Why is everyone calling LLM generated code "written from scratch" with almost no clue that they didn't write one line of code themselves? Yeah, it was written from scratch, but not by you!!
Projects like these are defiling the programmer's guild.
ArtCraft lies. It makes extensive use of crates, which to me defeats the "from scratch" argument. The whole point of doing it from scratch is that you get full control of every line of code in the compiled binary.
This is an example of a true "from scratch implementation" (as long as you target the freestanding compile option, hosted still depends on pthread for threading). Absolutely zero external code or references anywhere outside the stated repo. (Not even compiler builtins or includes are needed). You can drag and drop it wherever you'd like hit compile and you're done.
"Written from scratch" just means that no external code or existing libraries were used in producing something. Nowadays it's preferable to reusing code/crates/whatever because a) you avoid supply side attacks b) the implementation is likely going to be more correct and performant than alternatives c) it's actually easier to write your own thing than to download an existing lib and wrangle it into your project.
Why does it matter? Tbh at this point if frontier models are used I would place more trust in the average codebase than the average pre-AI codebase.
There are outliers where an excellent team of devs produce great quality, better that even frontier LLM code now. SQLite comes to mind. But it's easy to forget that is the 0.x%.
If you hired a chef to come to your house and make a pie from scratch, would you then share the pie with your friends and tell them that you made it from scratch?
No I wouldn't, but that is not really what happened here. If someone used a bread making robot and put the ingredients in there and it made bread most people would have no problem saying they made bread from scratch. In the same vein people say "I did the laundry" or "I did the dishes" but in both cases the real work is often done by a laundry machine or dishwasher.
In the same way a program manager is free to say "We build X from scratch" even though they made no code contribution to it. The we is replaced with I since no other person was involved in this case.
> most people would have no problem saying they made bread from scratch
That's fine for bread, but for people that see code more like art, they have a preconceived notion that "from scratch" means writing the code yourself.
Some people code to solve a problem and they don't care how it gets done. They have no problems using AI and see other methods as prehistoric. That's fine for them, carry on.
For me, the journey is more important than the destination.
Being able to code "by hand" is what strokes my sense of worth and accomplishment... knowing I can do something that not just anyone can. Pushing a button or prompting an AI isn't the same for me, that's more like a project manager and something I never want to be.
When people bash on the anti-AI crowd, they just don't understand that people code for different reasons, and neither is more right or wrong.
I agree that people can write code for whatever they want, and that is valid.
Code can be art, making food can also be art. So I'm don't agree with your distinction that code is materially different from baking in that aspect.
The terminology "from scratch" and "by hand" are really not interchangeable in my opinion. "By hand" implies something about the process. "From scratch" implies something about the state before you started, not anything about the process.
In this context I think they are interchangeable and that many people do interchange them, whether you agree with them or not.
It's fine to disagree, I don't think you're "wrong", and I don't think I'm "right" either. We just have different perspectives and definitions of words, and that's ok.
I think the more important thing is understanding the intent of the person speaking, instead of just trying to win an argument, as that's derailing the conversation/topic anyways. And in this context, all I was trying to convey by using "by hand" and "from scratch" was the notion of coding without using an LLM.
A more apt analogy is heating up a frozen packaged pie, then saying it was made from scratch. Yes _you_ bought from the store, but somewhere ingredients were assembled and it was made "from scratch".
On the other hand: many managers love to claim to have been deeply involved in the development of some product when the actual work was done at least by their underlings, or sometimes even a completely different team.
If people were similar confrontive in calling out such managers ...
Or any project of any size -- scientists running a lab rarely do the experiments or data analysis themselves -- they have graduate students and postdocs for that. Their job is to decide what those people work on.
With the same argument, you can argue that it is the programmer's job to decide which LLM shall work on the problem, and the programmer still gets the credit for the work. :-)
500kB source for the compiler and half of it is for the optimizer. Could it be a nice basis for putting a new vibe coded syntax on top? Move it to Zig or Rust first?
People who think this do not understand LLMs. LLMs thrive in abstractions just like humans. Assembly code introduces far too much entropy, requires far too much context and documentation, and is far too easy to get horribly wrong. Even after generating large amounts of synthetic training data, it will never be practical.
But if the LLM can use decompilers in the process? It already uses many tools (grep, python, sed, etc...); so why not a decompiler and then take it from there?
I've seen this approach already in practice: LLM+decompiler give better code than the original code that the binary was compiled from.
I think you're right, but rather surprisingly I have some experimental data on this question that is inconclusive at best. My hobby project is symbolasm, which is intended to close exactly the gaps you describe: by naming variables and introducing types, it re-adds much of the context that assembly language erases. I ran a quick'n'dirty experiment to see if it would make the LLM more efficient at writing code than raw assembler.
The task was rewriting an MP3 decoder from Rust into ARM assembly language, Cortex-M33 flavor specifically, optimizing for both speed and code size. The output is approx 3k instructions. The tl;dr is that Opus 5.5 nailed the task, whether writing assembly or symbolasm. It took approximately 2x tokens for the latter, which I think is largely explained by the fact that it was dealing with a novel language nowhere represented in its training set.
The quality of the result was comparable; the raw asm was slightly faster and slightly less dense, which I consider insignificant because I think you can get the same effect just by tuning the prompt. In particular, if I were re-running the experiment, I might set a strict code size budget and then ask it to optimize for speed within that budget, allowing comparison on a single scalar.
The experiment was compelling in another way: the code was 3x denser and 1.5x faster than -O3 output from Rust. So for certain applications, going to assembler will be worth it, especially as the cost of generating the code goes to zero.
And there is the following critical advantage: you decouple your code from any compilers. Some compilers are sane of course, and their devs are doing an amazing job (look at cproc/qbe/etc), unfortunately the mainstream ones are c++ abominations (gcc and clang/llvm) which we should depart from.
If all this AI thingy is true, the decompiling and recompiling directly from the machine code is a sort of proof that what's the most important is the data model. Additionnaly, when I get into some software which I did not write, I must focus on this data model in order to understand it, and guess what, the direct memory one from 'human' assembly/C is usually much better than those giga-convoluted object oriented abstracted ones (I think the worst one was llvm, usually everything c++ is).
Some are generating "human" assembly code for their everyday software (I am following some of those projects I found here, on HN). Again, if all that is true, the killer feature: you could generate "human" assembly for several ISAs fitting one data model, for instance the IP UNlocked RISC-V (vectorized or not)!
> The result of the study is only a description of how the IDE looks and behaves: which menus exist and in what order, which options each dialog holds, how the Message window tracks errors, and what the diagnostics say.
LLM-generated blogpost. The stench is all over it.
That's true but LLMs are a massive time saver when generating unit tests and other useful things for your work, leaving you free to write what really matters.
Stop whining. LLMs are available to everyone. If you think you can do better, then go ahead and do it instead of criticizing people who are actually getting things done.
This is not "getting things done", it is not a useful project. It is one of the interesting projects that one would do to show mastery of a hard technical topic (compiler), to learn, and to impress fellow programmers.
Doing it with an LLM makes it just completely useless
> Doing it with an LLM makes it just completely useless
There can be other valid perspectives than your own.
Different people code for different reasons.
Some see it as a means to an end... "I want X as an end result and I don't care how I get it."
Others see it as an art form and something special to them; their sense of worth is tied to their knowledge and experience in something that not just anyone can do (without an AI).
OP uses an LLM because they just want the end result. You might write code for different reasons entirely. Neither is "wrong" or "useless."
The whining will continue until boosters get it. If the things you're "getting done" are even remotely valuable then you can spare the brainpower to use your words.
I looked at the Github page and of course it's vibe coded. This is the sort of project that someone would have spent a few months doing as a learning exercise while they were reading through something like Crenshaw's "Let's Build a Compiler" series. I don't see the point of vibe coding it. You still end up with a toy compiler that nobody will actually use, except now you haven't learned anything about how compilers work. It's pointless.
Agree, I worked through 'Writing a C Compiler' book (I used Zig) and it was enlightening and fun. Asking AI to do it is pointless.
I imagine I’d learn a fair bit about how to go about vibe-coding developer tools by implementing this, so it hardly seems pointless? It seems like an interesting exercise.
In particular, I’d want to experiment with how to get coding agent to generate more readable code and better documentation. I can get it to make the code somewhat readable, but haven’t really solved yet.
Vibe code means the human did not look at the code: how do you know that's true?
It's easily to spot a code base that's build LLM-assisted. But to know that no human actually took interest in the code is hard to know without talking to the humans that prompted the LLM.
The blogpost about the compiler is AI written, the README file in the Github repo is AI written, all the documentation is AI written, the reverse engineering analysis of Borland Turbo C++ is AI written, all the comments in the code are AI written, and every single commit in the repo was done by Claude. I don't think it's reasonable to say that the author took any serious interest in the code. I suppose they might have glanced over it before telling Claude to commit, but you don't get much out of that vs. writing a toy compiler yourself.
It's not hard to know - vibe-coding is the default mode for all LLM coding so one can just assume as much absent evidence to the contrary.
Exactly. Some "Prolog interpreter in Tcl" is a prompt away in LLMs but what's the point of inferring and dumping it on github? Same goes for any vibe-coded project.
Yep, and the code is an eyesore to look at. Almost no logical separation of code blocks (everything mashed-up together) I was really expecting LLM to annotate every line of code with (useless) comments, considering many vibecoded js projects are like that.
Either my C skills are getting rusty and that is how a C codebase normally looks like, or LLM was trained on some suspicious codebases.
This is how a C codebase looks like.
LLMs are very good at copying best practices.
I checked a few source files at random and it looked fine to me overall. It's broken down into small-to-medium sized functions, contrary to what you suggest. If your issue is just the size of the individual source files, then you can find much larger in non-vibe-coded C projects like QuickJS.
Wait, I had a look and this looks really like any other C code base to me. I even think it's unlikely this is LLM-generated?! The presence of some large functions, for example, is a sign of human-generated code, LLMs tend to be strongly opposed to that, unlike C programmers.
> I even think it's unlikely this is LLM-generated?!
The commits were done by Claude.
Doesn’t mean humans didn’t write anything.
No you're right, this code is terrible. Running a linter like clang-tidy would surface many issues. Not sure why the LLM didn't think of ever doing that.
Clearly chibicc derived. The testsuite is a bit primitive, that's why I wouldn't trust it to compile much. Maybe I'll add to my small C compiler comparison tables.
This is really neat, I'll have to give it a try. I grew up on QuickBASIC, then Turbo Pascal and Turbo C later on. For my own personal hands on coding time solving mathematical challengers or working on hand coded personal projects to relax in our increasingly agent driven world I've taken to using the text mode Free Pascal ide that is bundled in with the fpc compiler, built on an open-source implementation of Borland's TurboVision DOS TUI libraries. I always wished it had a mode to emulate Turbo C as well.
The only bummer I'm seeing with fcc is not having a linker mean not being able to use external libraries. So you're really limited to what you can include in your own project, but if it truly is C89 compliant there are plenty of useful single header libraries you could use for various things.
I'll check it out!
I'm not willing to whitelist whatever bullshit malware this thinly veiled advertisement wants to run on my computer before it will allow me to see the page. Can someone share a précis?
Yet another vibecoded compiler.
The Adafruit post is just an LLM recap of the author's blog post, which is an LLM summary of the project, which was vibe coded with Claude. The signal:noise ratio is dropping off exponentially.
Damn. I'm reading Nils Holm's book on a C subset compiler and was hoping this would be a neat supplement. Into the trashbin it goes
https://github.com/fosslinux/live-bootstrap
May have what you're looking for. Steps & tools used are in the "parts.rst" file.
Why is everyone calling LLM generated code "written from scratch" with almost no clue that they didn't write one line of code themselves? Yeah, it was written from scratch, but not by you!!
Projects like these are defiling the programmer's guild.
ArtCraft says it’s all written from scratch as well.
ArtCraft lies. It makes extensive use of crates, which to me defeats the "from scratch" argument. The whole point of doing it from scratch is that you get full control of every line of code in the compiled binary.
https://github.com/rfgplk/micron.cpp
This is an example of a true "from scratch implementation" (as long as you target the freestanding compile option, hosted still depends on pthread for threading). Absolutely zero external code or references anywhere outside the stated repo. (Not even compiler builtins or includes are needed). You can drag and drop it wherever you'd like hit compile and you're done.
"Written from scratch" just means that no external code or existing libraries were used in producing something. Nowadays it's preferable to reusing code/crates/whatever because a) you avoid supply side attacks b) the implementation is likely going to be more correct and performant than alternatives c) it's actually easier to write your own thing than to download an existing lib and wrangle it into your project.
Why does it matter? Tbh at this point if frontier models are used I would place more trust in the average codebase than the average pre-AI codebase.
There are outliers where an excellent team of devs produce great quality, better that even frontier LLM code now. SQLite comes to mind. But it's easy to forget that is the 0.x%.
the comment isn't even about the quality, it's about the "from scratch" aspect (used to 'market' it)
But isn't that correct? It doesn't seem to be based on anything, or am I missing something?
Or is it "To make an apple pie, you must first invent the universe" kind of deal. Which doesn't make sense to me either.
If you hired a chef to come to your house and make a pie from scratch, would you then share the pie with your friends and tell them that you made it from scratch?
No I wouldn't, but that is not really what happened here. If someone used a bread making robot and put the ingredients in there and it made bread most people would have no problem saying they made bread from scratch. In the same vein people say "I did the laundry" or "I did the dishes" but in both cases the real work is often done by a laundry machine or dishwasher.
In the same way a program manager is free to say "We build X from scratch" even though they made no code contribution to it. The we is replaced with I since no other person was involved in this case.
> most people would have no problem saying they made bread from scratch
That's fine for bread, but for people that see code more like art, they have a preconceived notion that "from scratch" means writing the code yourself.
Some people code to solve a problem and they don't care how it gets done. They have no problems using AI and see other methods as prehistoric. That's fine for them, carry on.
For me, the journey is more important than the destination.
Being able to code "by hand" is what strokes my sense of worth and accomplishment... knowing I can do something that not just anyone can. Pushing a button or prompting an AI isn't the same for me, that's more like a project manager and something I never want to be.
When people bash on the anti-AI crowd, they just don't understand that people code for different reasons, and neither is more right or wrong.
I agree that people can write code for whatever they want, and that is valid.
Code can be art, making food can also be art. So I'm don't agree with your distinction that code is materially different from baking in that aspect.
The terminology "from scratch" and "by hand" are really not interchangeable in my opinion. "By hand" implies something about the process. "From scratch" implies something about the state before you started, not anything about the process.
In this context I think they are interchangeable and that many people do interchange them, whether you agree with them or not.
It's fine to disagree, I don't think you're "wrong", and I don't think I'm "right" either. We just have different perspectives and definitions of words, and that's ok.
I think the more important thing is understanding the intent of the person speaking, instead of just trying to win an argument, as that's derailing the conversation/topic anyways. And in this context, all I was trying to convey by using "by hand" and "from scratch" was the notion of coding without using an LLM.
A more apt analogy is heating up a frozen packaged pie, then saying it was made from scratch. Yes _you_ bought from the store, but somewhere ingredients were assembled and it was made "from scratch".
The plotline of at least one Hallmark romcom movie, as I recall. (-:
What does a vibe-coder say when he orders a dish at a restaurant and the waiter brings it to the table? "Look at the food I made!"
On the other hand: many managers love to claim to have been deeply involved in the development of some product when the actual work was done at least by their underlings, or sometimes even a completely different team.
If people were similar confrontive in calling out such managers ...
Or any project of any size -- scientists running a lab rarely do the experiments or data analysis themselves -- they have graduate students and postdocs for that. Their job is to decide what those people work on.
With the same argument, you can argue that it is the programmer's job to decide which LLM shall work on the problem, and the programmer still gets the credit for the work. :-)
Yes, that's my point -- assuming the programmer actually spent some time thinking it through.
It's fun to see the comments about vibecoding.
Pretty much everyone developing software for a living is using AI. This basically outs you as not having any recent tech involvement.
No amount of nostalgia and wishful thinking overcomes reality.
500kB source for the compiler and half of it is for the optimizer. Could it be a nice basis for putting a new vibe coded syntax on top? Move it to Zig or Rust first?
Neat, but I would keep an eye on the trend: with all this AI coding (if true) some are now going directly to assembly.
People who think this do not understand LLMs. LLMs thrive in abstractions just like humans. Assembly code introduces far too much entropy, requires far too much context and documentation, and is far too easy to get horribly wrong. Even after generating large amounts of synthetic training data, it will never be practical.
But if the LLM can use decompilers in the process? It already uses many tools (grep, python, sed, etc...); so why not a decompiler and then take it from there?
I've seen this approach already in practice: LLM+decompiler give better code than the original code that the binary was compiled from.
I'd imagine it's just a lot less token efficient than having it write the code in a high level language.
I think you're right, but rather surprisingly I have some experimental data on this question that is inconclusive at best. My hobby project is symbolasm, which is intended to close exactly the gaps you describe: by naming variables and introducing types, it re-adds much of the context that assembly language erases. I ran a quick'n'dirty experiment to see if it would make the LLM more efficient at writing code than raw assembler.
The task was rewriting an MP3 decoder from Rust into ARM assembly language, Cortex-M33 flavor specifically, optimizing for both speed and code size. The output is approx 3k instructions. The tl;dr is that Opus 5.5 nailed the task, whether writing assembly or symbolasm. It took approximately 2x tokens for the latter, which I think is largely explained by the fact that it was dealing with a novel language nowhere represented in its training set.
The quality of the result was comparable; the raw asm was slightly faster and slightly less dense, which I consider insignificant because I think you can get the same effect just by tuning the prompt. In particular, if I were re-running the experiment, I might set a strict code size budget and then ask it to optimize for speed within that budget, allowing comparison on a single scalar.
The experiment was compelling in another way: the code was 3x denser and 1.5x faster than -O3 output from Rust. So for certain applications, going to assembler will be worth it, especially as the cost of generating the code goes to zero.
[1]: https://github.com/raphlinus/symbolasm
And there is the following critical advantage: you decouple your code from any compilers. Some compilers are sane of course, and their devs are doing an amazing job (look at cproc/qbe/etc), unfortunately the mainstream ones are c++ abominations (gcc and clang/llvm) which we should depart from.
If all this AI thingy is true, the decompiling and recompiling directly from the machine code is a sort of proof that what's the most important is the data model. Additionnaly, when I get into some software which I did not write, I must focus on this data model in order to understand it, and guess what, the direct memory one from 'human' assembly/C is usually much better than those giga-convoluted object oriented abstracted ones (I think the worst one was llvm, usually everything c++ is).
Some are generating "human" assembly code for their everyday software (I am following some of those projects I found here, on HN). Again, if all that is true, the killer feature: you could generate "human" assembly for several ISAs fitting one data model, for instance the IP UNlocked RISC-V (vectorized or not)!
> The result of the study is only a description of how the IDE looks and behaves: which menus exist and in what order, which options each dialog holds, how the Message window tracks errors, and what the diagnostics say.
LLM-generated blogpost. The stench is all over it.
That's true but LLMs are a massive time saver when generating unit tests and other useful things for your work, leaving you free to write what really matters.
Building useful tests are probably one of the things that LLMs are the worst at tbh. You end up with tests checking `2 * 2 == 4` and similar.
Having a LLM also generate your unit tests defeats the purpose of checking whether a LLM generated piece of code is sound.
There will always need a human on the end to check if the LLM didn't hallucinate anything on it, including manually writing the unit tests.
Stop whining. LLMs are available to everyone. If you think you can do better, then go ahead and do it instead of criticizing people who are actually getting things done.
This is not "getting things done", it is not a useful project. It is one of the interesting projects that one would do to show mastery of a hard technical topic (compiler), to learn, and to impress fellow programmers. Doing it with an LLM makes it just completely useless
> Doing it with an LLM makes it just completely useless
There can be other valid perspectives than your own.
Different people code for different reasons.
Some see it as a means to an end... "I want X as an end result and I don't care how I get it."
Others see it as an art form and something special to them; their sense of worth is tied to their knowledge and experience in something that not just anyone can do (without an AI).
OP uses an LLM because they just want the end result. You might write code for different reasons entirely. Neither is "wrong" or "useless."
[flagged]
The whining will continue until boosters get it. If the things you're "getting done" are even remotely valuable then you can spare the brainpower to use your words.
[dead]