Why Open Source Needs to Reject Vibe Coders

Many Open Source tools do not accept contributions if they’re written with the help of GenAI.

There’s Godot, Zig the programming language, Rust the programming language, Gentoo Linux, GIMP, cURL, the list goes on.

I remember when Zig made their announcement—some were convinced it was the beginning of the end for the language. Who will want to use Zig at this point? Who will want to contribute?

But the problem is - a lot of people, because that’s not how it works. You do not pick your tool based on the fact whether people identifying themselves as vibe coders contribute or not. This is not about diversity of tools, this is about competence.

And what do I think about it? Me - the soon to become a vibe game developer?

I think it’s a good approach!

I assume you’re pretty mind blown about my stance, but hear me out.

I did not change my mind about using GenAI for games, applications and so on. Even game engines. Some of them.

But there is a big but. And I like big buts and I cannot lie 😉

Let me give you a bird’s eye view first.

There are many layers to applications.

There are Operating Systems, then there are tools you use to build other tools (and this can be a real layer cake, as you can use some tools to build other tools - there can be many layers like this 😜), and then there are the end-products - the games, the todo lists, the text editors, and so on.

There’s nothing wrong when you use GenAI to make products for the last layer. In the end, there’s not so much to break. And given Cyberpunk’s premiere - I still think we should consider this not much for the sake of this argument.

But tools can be something different. Depending on the level of their complexity. Programming languages, game engines, and the like are built by very competent people, and it should stay like that.

Imagine you are the owner of an Open Source project, like a programming language, or a game engine. And some young developer (not-experienced in making these but passionate as Greta Thunberg) wants to contribute. Unaware of his own lack of experience, he just wants to contribute. He wants to add some code he thinks is good. He makes a Pull Request and waits.

Meanwhile, from the perspective of the maintainer. He has to read EVERY pull request.

But here’s the plot twist. He doesn’t get one-two weekly. He gets more than a dozen a day (for more popular projects), and that was before vibe coding was a thing. Because now - PRs are flooding everything. Leaving him with no time for doing his tasks, securing his code, helping other people, marketing his tool, living his life. That’s because he’s the human in the loop, and he has to stay focused. This is no place for junior devs who have an idea of the direction of the product and feel entitled to be listened to. Like all the other junior devs sitting in the same line. This work requires competence. This work requires deep domain competence. Knowing how to use AI like a pro isn't just about typing prompts—it's about knowing what to ask and rigorously auditing the output. And they just don't have that experience yet. They’re indies, they can make their game using Claude Code or any of the sort. But they don’t have experience on how to do it, like a pro. And sometimes they don’t even ask the AI how to do it like a pro. They just git commit, git push, and expect to be focused on.

And the maintainer… well, that’s not the only junior he has to focus on. There are hundreds of them now. With their ideas.

Do you know what you get when you let passionate junior programmers contribute vibed code to a big project like that?

You get what you deserve Windows 11!

This meme is never getting old.

But this is in a way weird thing. It sure looks like only junior devs are building operating systems in Microsoft now. Makes you wonder - where are the regression tests? where are the automated tests?

I know a thing about projects, team work, and pull requests. And trust me, you want your tools to be as stable as possible.

When a tool used to build other tools (or games) break, all hell breaks loose soon after. Such tools require a far more rigorous approach, because all errors go further up. An error in Semi-Realistic Engine would propagate to all games made in it. Of course, they are hidden in the feature, so everything depends on how often is that feature used. And how many games are implemented in it. But imagine an error in the programming language that Semi-Realistic Engine is built with. It can potentially affect the entire engine. But also other tools written in it.

So, you might ask: how can I contribute AI-generated code to my favorite project, whose maintainers are rather reluctant to accept AI-code?

Well, I would suggest not doing it. Or doing a git fork and making an alternative. But leave the tool to the competent people. It’s not worth breaking it not only for yourself but also for everyone else.