points by ndiddy 19 hours ago | 0 comments
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.
[–] skybrian 18 hours ago
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.
[–] flossly 16 hours ago
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.
[–] ndiddy 15 hours ago
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.
[–] krapp 16 hours ago
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.
[–] zerr 17 hours ago
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.
[–] flykespice 18 hours ago
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.
[–] fooker 15 hours ago
This is how a C codebase looks like.
LLMs are very good at copying best practices.
[–] foldr 18 hours ago
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.
[–] brabel 17 hours ago
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.
[–] lelanthran 17 hours ago
> I even think it's unlikely this is LLM-generated?!
The commits were done by Claude.
[–] brabel 2 hours ago
Doesn’t mean humans didn’t write anything.
[–] q4y2u35uk 18 hours ago
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.
[–] small_model 18 hours ago