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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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?
45 comments
[ 6.3 ms ] story [ 42.3 ms ] threadMay have what you're looking for. Steps & tools used are in the "parts.rst" file.
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."
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.
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!
Projects like these are defiling the programmer's guild.
If people were similar confrontive in calling out such managers ...
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.
I've seen this approach already in practice: LLM+decompiler give better code than the original code that the binary was compiled from.
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.
The commits were done by Claude.
LLMs are very good at copying best practices.
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.
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.