Rant: Vibe-coding has to stop

I hate seeing good ideas pop up on GitHub, only to realize they are completely vibe-coded. It hurts.

These projects could probably be abandoned at any time because it poses no significant challenge to the developer. Or even worse, could have DUMB mistakes in them, making them useless. If their code is WRONG, i'm wasting server resources and my time!

I had a problem with the MooseFS distributed storage plugin regarding this exact issue, which I'll share in a minute 😄

Question for you, do you ever read 100% of the source code of every single software you use? I don't, unless it's an executable script.

The Huntarr case

There's a perfect example of why maybe we should. Huntarr is a heavily vibe-coded project and it's one of the services I run for the Gamopelis cluster. If it doesn't work it harms the Gamopelis workflow. Their own explanation on what it does is:

Huntarr is the compulsive librarian who finds missing media and upgrades your existing content. It fills in the blanks and improves what you already have.

I don't care about the repository README coming with AI-generated characters, nor that the web interface is clearly made by AI. I'm interested in the codebase, and it's one of the worst I've ever seen on a >2,500 stars GitHub project.

I'm opening only one of the source files, so you get the idea.

The code contains useless fragments from AI generation, like # ... existing code... which reduce readability, useless comments like this are a recurring problem in the entire codebase.

I seemingly picked an unused file (server.py) by random chance, but the fact that this dead code is still living in the repository speaks volumes about the lack of cleanup.

Then I open the database.py code (Code for managing the database). We can see this here:

First, 4 chained parents (parent.parent.parent.parent) is a sign of bad code smell. The entire structure feels like an anti-pattern.

Worse, every single function opens a SQLite database connection and closes it after finishing. This is inefficient, for a project of this size doesn't matter, but the project size shouldn't matter. You should write good code always, and this is not okay performance-wise.

There's also a hidden cost. Every time you call the get_connection() function, you are also calling the function above it, executing 8 SQL queries just to set up "Synology NAS compatibility", no matter what system you are actually running. Another inefficiency that is hard-coded. (I would have enabled the above function with an environment variable instead).

When the code detects an error with the database disk, can you imagine what it does? it calls this little function

def _handle_database_corruption(self):
    """Handle database corruption by creating backup and starting fresh"""

"Delete everything and start fresh". That is not a strategy I would ever recommend. If your database disk had a problem for any reason, the program should not attempt to fix itself in my opinion,

even if Huntarr's data is technically disposable, the program should not attempt to fix itself automatically by nuking the database. If the database fails repeatedly, you have a serious underlying issue.

In the case of Huntarr, refilling the database each time requires API calls to external providers ("trackers"). If your database has a corruption loop without you being notified, your server will waste API calls daily.

Note: The function's description is a bit misleading. The code can technically delete the database even if the backup has failed to create, which is kinda funny.

Also almost every function does a import time lol

The project has ceased development in August, 3 months prior to this post. Issues are piling up and there's an open pull-request on refactoring a part of the codebase here, but it never got a response from the maintainer and got abandoned.

Do you see the problem? The vibe-coded project is no longer maintained 😔

The MooseFS plugin resize inflation

I faced an issue last Wednesday, a Linux container in my Proxmox cluster ran out of space!

I checked what happened. Software updates couldn't be applied because it needed two more gigabytes. No problem, nothing that a resize couldn't fix.

I did the usual in Proxmox, pct resize 231 rootfs +2G, In English, this simply means "increase the main disk size of the container 231 by adding 2 GB".

Then I applied the updates. Before going on with life, I ran a df -h inside the container to check the available space.

My jaw instantly dropped.

The container had over 99% free space; it had 12TB free. What the...?

I went to the MooseFS Proxmox Plugin source code, and found what happened. The resize() operation took the original disk size (10GB) and the amount I wanted to add (2GB). It added them up correctly initially

In other words, 10 GB + 2 GB = 12 GB (the expected result)

But the plugin's code decided to multiply the result by 1024. The end result is the volume being 12,228 GB in size (12TB).

Why was this multiplication in place? It was a decision made by Claude Code, has no logical reason to be there. The developer missed it because the code looked syntactically correct.

facepalm This is an embarassing bug 😁 We'll sort this one out asap
Apologies! The resize code in pve-moosefs is still quite young.
- Proxmox-MooseFS plugin main developer response

Another case of vibe-coding messing with the cluster. To fix this issue, one usually has to shrink the disk back (from 12TB -> 12GB). I was lazy and simply restored a backup, then did a resize manually without involving pct resize.

The mistake in this project is not only relying on Claude Code, it's that it's missing unit tests.

In this case, I had backups. Backups are GREAT. Probably the developer was tired when this bug was introduced, but I do not approve the heavy usage of Claude Code. It could have been worse.

The pve-moosefs project looks in much better shape than Huntarr's mess, and the developer, Zorlin, answers quickly to any issues. He has a solid track record on distributed storage and knows what he's doing.

Final thoughts

So, what's the final lesson? Generative LLMs are only a tool. If well used, they can be a great time-saver. (Sometimes I use them to generate images for this blog!).

I'm sure most programmers have used an LLM at least once. What distinguishes a skilled developer from a novice is the quality of their output rather than quantity, regardless of the tools used.

We have seen today that simply vibe-coding doesn't produce good code; it needs a human to verify and correct it.

Stay safe and check your backups. From now on, I'll skim over the latest commits of any Git project to decide if I trust it, or if it's just another vibe-coded mess.

Have a good day!