Vibe Coding

As a professional software developer, I've encountered a lot of people defending vibe coding, with claims that the code produced is higher quality than a novice could write and faster to write than an experienced dev could.

I think those claims are wrong. I think we're already seeing buggier releases across the board since these practices were adopted, and it stems from companies turning their employees into reverse centaurs who have to quickly and tirelessly check the outputs of AI for errors, a skill humans are unavoidably bad at doing. This article goes over how engineers, over-confident in their own intelligence and reasoning skills, can essentially dupe themselves into sincerely believing the LLMs are better than they are.

I’ve also seen people argue, including Doctorow above, that AI can help people who have the agency to choose when and how to use it (making them “regular” centaurs). I'm still skeptical this has long term advantages and not lead to skilled developers atrophying. That said, I'm certainly more okay with a project that has been designed and architected by a human, and only used AI to be a smarter autocomplete or to write the boilerplate, than I am with a project that’s been made from top to bottom by AI.

Software Biodiversity

By their nature of being trained on a fixed set of data, there will always be a crystallization of biases present in these models. Unless we have a foundation model for every individual (which we shouldn’t aim for even if that was feasible), this is unavoidably going to mean a more homogeneous environment of software. Much like actual ecology, a lack of “biodiversity” in software will cause immense problems beyond the superficially stale/bland UIs.

In the same way a single virus can tear through an entire monoculture, software written with all the same biases is all vulnerable to the same exploits, once discovered. I’ve seen how LLMs reuse the same language structure, I’ve seen how vibe coded interfaces use the same design patterns, and I’ve seen vibe coded utilities use similar code style and design patterns too - so there is no doubt in my mind they would introduce the same vulnerabilities in similar contexts.

I would also worry about a monoculture of thought similarly vulnerable to the same exploits, but that moreso applies to non-coding use of LLMs. But if vibe-coded games always being about one of 2 topics (space and AI) is anything to go by, this is a very real concern.

Games

Ever since starting plusone, I’ve seen a LOT of vibe coded games, and can attest to their immediate “clockability” (at least at time of writing), and that it tends to be more novice devs doing it. Which has the side effect of meaning vibe coded games have routinely worse game design than human made games, as LLMs are not (yet?) good at game design, and neither are the novice devs. But the “fancy” (now bland through their overuse in a similar fashion to bootstrap) graphics a vibe coded game has then feels deceptive - like it's trying to be a polished product rather than someone’s first foray into game design - in a way that an “ugly” game by a novice developer doesn't. Unlike a novice dev, AI generated games don’t benefit from the feedback that has led Incremental Games to be so appealing to developers.

Open Source

Many open source projects have detailed their issues with vibe coded PRs, especially from drive-by contributors, but one in particular, from the maintainer of SilverBullet, a program I use many times a day, describes the practical reasons for discouraging LLM use in PRs or community posts here. This is still something the various open source projects are tackling in different ways, and time will tell what actually works best.

Barefoot Developers

Barefoot Developers, or non-developers who use AI to solve their problems too niche to have pre-existing solutions, are a reasonable edge case for vibe coding to me. When Codeberg banned vibe-coded projects, they specifically carved out an exception for projects too niche to have alternatives within the open source community.

My Own Use

I vibe code at work, and struggle to not to on personal projects. It's really hard to resist because it's so much easier to just let the AI do all the thinking instead. Being a parent that can only find very very limited time to be on a desktop also makes AI more compelling because I will rarely have enough uninterrupted time to properly get in the flow nor get enough coding context surrounding a feature/bug in working memory. But I’m compelled to feel productive (thanks Capitalism! I should just be coding because I enjoy it rather than valuing the output so much) so I’m not satisfied with the very very slow progress I would make without the use of something like OpenCode, so I’ve been using it on some personal projects too. I’d like to list which specific projects out of transparency.

I’ve been making different prototypes for a project called Campfire, and several of these prototypes have been partially or entirely vibe coded. None of these are public and imo fall under the barefoot developers exception. I plan to do a full write-up on the different iterations and the lessons learned from each, but I believe I’ve given up on the idea of Campfire being a useful universal tool for everyone - it’s better as a mere write-up on what worked for me to inspire people to build their own equivalents tailored to their needs.

For plusone, part-way through development I started using OpenCode to implement some features, like parts of the refactor to support multiple queues that came out around the 1 yr anniversary. But the UI was originally implemented completely by hand and I can honestly say any similarities to the vibe coded look just come from me using Nuxt UI and tailwind, which it seems influenced a lot of LLMs’ training data.

For my personal website, I used it for a pass on fixing issues flagged by PageSpeed Insights.

For my SilverBullet library for rendering discord embeds, the bookmarklet and discord plugins were largely vibe coded.

As a non-example, I’d like to mention I made fully human contributions to roomy, an existing open source project. It does not feel right vibe coding contributions to other peoples’ projects, so I’ve drawn that line for myself (at least as of this writing).