It finally happened to me. About two weeks ago, someone opened the first vibe-coded Pull Request to the Zettlr repository. What has cast its shadows long ago in memes on the more programming-affiliated parts of Reddit has reached my own work. I’m not entirely sure if I should see it as a badge of honor that my app is well-regarded enough to attract this kind of person, or see it for the frustration it causes. What I do know is that I was not prepared for this first encounter with the new reality of programming.
But this article is not about vibe coding. Being a sociologist, I don’t want to reiterate the Unkenrufe1 of a vibe-coded future and why it is bad. Instead, I want to tell a story about the vibe coder as a social phenomenon. One that focuses on the social dynamics of what makes vibe coder, and what happens when vibe coders interact with the outside world.
If you want to learn more about how vibe coding is inefficient, dangerous, and not going to replace programmers anytime soon, a quick Google search has got you covered. Here, I want to rather focus on the individual who performs vibe coding. A form of cultural thing that has a profound social component, and one that is indeed quite in line with how sociology has conceived society in the past few decades.
I believe that vibe coding is (one of) the final form(s) of the hyper-individualism that social scientists have been concerned with ever since the rise of neoliberalism in the 1980s. After having experienced it first-hand, I believe that vibe coding is a simple, natural extension of existing trends in which the individual is being made productive through a process entirely disconnected from society. A vibe coder, essentially, is an extremely productive individual whose productivity has no tangible impact on the world, and whose action can feel meaningful only in a reality in which there is no society, only individuals. Vibe coding is what David Graeber once called a “bullshit job.”
What is Vibe Coding?
In case this trend has completely eluded you, let me begin this article with a quick summary of what vibe coding is. Vibe coding is a phenomenon in which a person with little or no experience with programming, but with a more or less hazy vision of some tool sets out to make that tool a reality. Since they have little experience with coding, they rely on chatbots — generative AI — to write the necessary code for that.
Vibe coding, therefore, only occurred after capable GPT models were being released by OpenAI and other companies. The first GPT models were generalists, since nobody really found an appropriate use-case for them yet. They were impressive in their own right, simply because they generated text really well in response to user queries.
It took about three months after the launch of ChatGPT until the first, good use-cases slowly emerged from the mountains of playful interactions with the model. I wrote about them here. Since then, companies with large GPT models running on expensive servers have tried to monetize these models to the best of their abilities. People realized that some models were really good at producing syntactically correct code. From there, it was only natural to start producing models that were tuned to help explicitly with writing code. Microsoft’s Copilot, which started out as OpenAI’s Codex model (ChatGPT’s little brother) is probably the most famous one.
With a few additional improvements such as giving these models information on the codebase more generally, or allowing it to directly modify files, it became easier to write some instructions using natural language, and wait for the model to generate corresponding code. The essential structure of GPT models has not changed throughout the past three years. But what has changed is how these models are integrated, and the tooling that surrounds them. Microsoft’s Copilot model is now deeply integrated in VS Code. Anthropic’s Claude is being lauded as a highly capable model to generate code. And, to some degree, utilizing GPT models to produce boilerplate code, or reason about code is really helpful. I use it myself quite often.
But vibe coding is not about programmers using code-focused GPT models to help in their own work. Vibe coding is about the empowerment of individuals with big ambitions and little experience opening up the gates to producing software. In a positive reading, the arrival of GPT models on the world stage has democratized access to programming. But in a — in my humble opinion — more realistic reading, GPT models encourage people with little experience to contribute in the software development world that is guarded by rules, norms, and traditions, disrupting well-functioning workflows and wreaking havoc.
In essence, vibe coding is a practice of inexperienced people writing code so complex that it appears as if it is worthy of inclusion in some of the world’s important pieces of software. And this is what I would like to focus on today.
The Encounter
Let me begin with a subjectively faithful reproduction of my encounter with above-mentioned pull request. One thing that some users of Zettlr have asked for in the past is a better support for right-to-left (RTL) languages, such as Hebrew or Arabic. Since I am a boring European only capable of writing Latin letters, I am hesitant to address this issue, because I don’t want to make it worse than it already is. I acknowledge this as a limitation. But this also means that I am very excited to see someone with more experience with RTL languages jump in and help out.
And so, when I read the title of this PR, I was excited: Finally, someone has started taking this issue upon themselves! I clicked on the link, opened the PR summary page and … immediately saw the hallmark indicator of vibe coding: +16,555 and −1,510 lines of code. To give you some context (please notice what I am doing here, it’s going to become important later), usually PRs aim to fix or add a single thing, and they usually work with maybe 500 changed lines at most. Usually, it’s more in the range of a dozen lines of code. Seeing more than a thousand, let alone more than ten thousand changed lines is very unusual and typically means something is very, very wrong.
A PR is not like a paper review. Each PR needs to be reviewed, but because code is very sensitive to typos and logical errors, a review of a PR involves literally reading every single character. It’s not like when you receive comments, and fully rewrite a paper before re-submitting it.
But I felt like dismissing this PR outright would be unfair. After all, there is the reasonable assumption that vibe coding is not just “idiots who write dangerous code,” but it can also be someone who is really motivated and is trying to use whatever help they can get in order to help. So my mindset was extremely committed to trying my best to help this guy shape the PR until it is actually reviewable and, hopefully, able to be merged into the codebase.
I started reading the (obviously AI generated) PR description to get a sense of what I was dealing with. It starts off very promising:
This PR introduces comprehensive Arabic language support for Zettlr, demonstrating what it takes to make Zettlr truly accessible to Arabic-speaking users.
What’s not to love! Exactly what I needed! I continued reading.
This fork addresses this gap by providing a complete implementation that can serve as a foundation for upstream RTL support.
This wording sounds odd. Why would he speak about a fork, talk about a “complete implementation” and then “serve as a foundation for”? This sounded odd. But, undeterred, I continued.
Note: This is a proof-of-concept fork meant to:
- Demonstrate the feasibility of comprehensive RTL support in Zettlr
- Provide a reference implementation for upstream integration
- Showcase innovative solutions like the dual-cursor system for connected scripts
- Serve Arabic-speaking users immediately while upstream considers RTL support
Wait, what? I’m sorry, but first, nobody has to demonstrate the feasibility of that; we’ve done this over years of debating this issue. Second, “reference implementations” are nothing for a PR; those only exist to help adoption of some protocol by various programming languages. Third, nobody wants a “showcasing [of] innovative solutions like the dual-cursor system.” Your PR either fixes something, or it doesn’t. And lastly, “while upstream considers RTL support” — we don’t consider it, we want it.
All of this was more than bizarre. But of course, I wasn’t even halfway done with the description. It goes on to show some screenshots, explain some more things, confabulate obviously wrong things (“Maintains full compatibility with upstream Zettlr”? GitHub already reported about a thousand merge conflicts. “No breaking changes to existing functionality”? My, my, you have literally destroyed the entire existing tooling on the repository.), and so on.
But I was still undeterred. So I started to look at the files. Besides a whole lot of AI-generated context documentation that appears to be primarily intended to keep the GPT-model aligned with the goals while it generated more code, the PR appears to have rewritten entirely unrelated features and demonstrated a complete lack of awareness for how the repository works.
Meanwhile, the person continued to add more commits, change more files, and dump more stuff into this already unreviewable mess of a PR. So I asked him to stop committing and give me a second while I was trying to come up with the words I was lacking to describe what I just saw. But then I found something just plain insulting: Apparently he decided to design a completely new icon for no reason. That hurt.
But anyways: This is likely an inexperienced user, and if he really is committed, I surely can talk reason into him.
And so I started typing. I began with an elaborate first response on why this PR is not mergeable, and tried to explain to him the steps necessary to bring this into a somewhat reviewable state. After a few hours, I have seen that he has added more commits, meaning that he clearly has seen my message, but not yet responded. So I told him to stop producing more code, and instead respond to my message. Which he did. Kind of. Most of his following response was a rehashing of the previous explanations in the original description, bundled with a request to me to read through his changes. To me, it implied that he wanted me to “pick and choose” things of what he did that I liked. But this is not how PRs, or any of this, really, work.
So I try again, this time with actionable items, in the hopes that, instead if piling up more code, he’d start deleting some clearly unrelated stuff. He responds, requesting that I book some meeting with him to discuss this. Excuse me? You want something from me, and I am not going to “book a meeting time” with you just to tell you once more that I will not be spending countless hours scouring the depths of whatever Claude has generated there. But he doubles down. He really insists I read through it, and is unwilling to change anything on his part. From his perspective, he has done his work, and now it’s on me to respond.
I realized that nothing would likely change his perspective, and so I closed the PR, and locked the discussion.
A few days later, after having discussed this encounter with friends and colleagues, and doubting whether I made the correct decision, a friend sent me a link to this PR on the OCaml compiler. The PR, and the ensuing discussion, looked eerily familiar. It was also a vibe coded PR changing humongous amounts of code, oftentimes unnecessarily, and a complete unwillingness of the creator of the PR to engage in a meaningful discussion. The maintainers of OCaml tried their best to steer the PR and its creator in a more productive direction, to no avail.
Software Development as a Cultural Practice
After having stared at that disaster of an interaction for a few days like the angelus novus stared at history, I tried to categorize and analyze what has just happened. There are two parts to an answer. The first is that software development is really a cultural practice, like many others, such as science, lawmaking, or creating a product. There are certain ways things are done. You don’t get to be a researcher just because you feel like it, you become one through years of training. You also don’t get to just start making laws unless you pass through a few stages of becoming an elected parliamentarian. And, before any new product is launched, there is a checklist you have to go through, lest the launch becomes a disaster. With software development, it’s the same thing, and Open Source is no exception.
Software development is surrounded by unwritten rules and cultural norms. When you start contributing to a repository, you first tread carefully. After all, you want to literally change something someone else has done. And thus, you would want to treat this endeavor with respect. First contributions to any Open Source project thus often comprise opening issues. Sometimes, if you feel confident, you can directly open a PR and fix something. But you usually don’t add some new feature at first. By doing PRs, you start interacting with the people behind the project, the maintainers whose job is to — well — maintain the program.
Every software project is different. Some people want you to discuss everything first on their issue tracker, or even on their Discord. Other projects have extremely rigid policies surrounding even the creation of issues, and others again are much more lenient. But while exploring the repository typically gives you some hints, there remains some insecurity, and so nothing can replace the first encounter with the maintainers.
Another, more explicit rule is the purpose of pull requests. Pull requests are intended to add functionality to some repository. The idea is that you make a copy of the software, set everything up on your own computer, change the thing you want to change, and ensure it works as intended. And, once it does, you propose your changes by creating a PR. That is the sole purpose of a PR: Moving some code you wrote to fix something into the general code base (“upstream”) from which you copied the code.
Third, one norm that is usually heavily enforced is that the maintainers are doing all of their work in their free time, and as such are not required to engage with anyone, including you. The common understanding is that maintaining an entire software project is a huge amount of work, and if you want to contribute to a project, you’ll have to play by the maintainer’s rules and shall make no demands. While this might sound as if it diametrically opposes the spirit of Open Source, this is not the case. If anyone had unrestricted access to software code, all kinds of dangerous things could happen (looking at you, Sha1-Hulud); starting from the software breaking, and ending with serious security flaws. By enforcing a strict ruleset over what gets permitted into the code base, and what not, maintainers ensure that whatever they maintain remains safe for users to use. Once maintainers stop understanding every single inch of the code base, this is no longer the case. And this is why they are essentially forced to enforce very strict rules about how the software is built.
Fourth, this leads to a rule that many people often forget, but that is quite central to the social function of software maintainers: they carry the sole responsibility. If the software breaks, they are the ones to take the responsibility of fixing it. Nobody will demand that from some random, unknown contributor who may have introduced the bug in the first place. The maintainers are the public facing people behind the code; the ones people usually know. In order to guarantee that, and in order to ensure they can indeed carry that responsibility, they have to not just understand the entire code base in and out, but in addition understand every single character that is being changed by contributions in PRs.
Vibe coded PRs break all of these rules and norms at once.
Vibe Coders Disrupt Open Source Development
By definition, vibe coders are those people who not just use GPT models as tools to help generate some code, but people who use GPT models to write the code for them. They rarely understand much of what these models do, and primarily judge the code quality by its output, that is: does the software break when they themselves test it out? No one in their sane mind would change over ten thousand lines of code before realizing that they should probably just change one thing at a time, lest they break something elsewhere.
This sidesteps most of the rules that have developed around Open Source Development. And this is a problem. Because while institutionalism tells us that many rules are likely very inefficient, they serve a crucial role. Rules and regulations safeguard against dangers and issues. The idea that a PR should change only one thing at a time is because this is the most efficient way for some outside contributor and maintainer to communicate. This way they communicate a single fix (something the contributor wants), and confirm that it is also safe to merge (something the maintainer wants). When you change ten thousand lines of code, this cannot be guaranteed anymore.
Also, vibe coded PRs are full of obvious mistakes once you take into account the broader context in which the software exists. For example, every single vibe coded PR I’ve seen so far rewrites or changes part of the tooling around a software; often to fix errors which the tooling produces because something is deeply wrong with the code. Do not misunderstand me: PRs that change tooling around a software are perfectly fine. But changes to the tooling of a software inside a PR that aims at fixing something else are unacceptable. And I have seen many times that vibe coded contributions have changed some feature and some of the safeguards, because the safeguards were working correctly and actually flagged something wrong with the code. And, GPT models being GPT models, instead of fixing their own code, they “fix” the errors by removing the safeguards that were flagging the dangerous code in the first place.
I believe this is sufficient to understand how dangerous it is to ignore the rules of the game of contributing to Open Source software. A friend gave me the correct term for this: vibe coding is the performative act of working without actually producing anything.
But there’s more to it.
The Tragedy of the Vibe Coder
Vibe coding is not intentionally malicious. No vibe coder wants to hurt anybody or cause problems with the software they contribute to. They genuinely want to improve the software. And they do it the only way they can: by letting a GPT model generate the code, instead of understanding the software first, and trying to slowly move towards fixing the bug. And I don’t believe that it’s their fault.
I believe that a vibe coder is a phenotypical example of an individual that is fully enmeshed in the current state of individualized digital capitalism. A vibe coder looks to me like an individual that is just trying to produce something; have an impact in the world. This is something that gets hammered into our brains every day. But, at the same time, we also are stressed, chased by the fear of becoming unemployed, of being a burden to society. So we can’t think, do unproductive work, such as engaging with a community of people.
To an extent, the vibe coder is the dream worker that corporations have wanted for so many years. But because we couldn’t automate everything yet, we had to push employees through school, college, trainings, and workshops. We have to spend a non-trivial amount of our lives just learning. GPT models and the current wave of AI models has finally opened up a possibility for employees to skip all of that. Instead of having to learn how to do things, they just need to imagine a product, and describe it to some generative AI model which then proceeds to generate it.
And the worst is: Initially, it indeed works. AI models can produce working code. And that is what prompts so many companies – but also students whom I teach – to uncritically adopt AI to a far greater extent than what is safe.
A vibe coder is an individual who has eliminated all the seemingly “unproductive” work around work: the training, the understanding, the listening. Vibe coding is what the protestant work ethic looks like when pushed to its logical end. An individual who takes nothing as input, and produces, all day long. Code, apps, entire services.
And this is what makes a vibe coder a very lonely, isolated individual. Because it turns out, a lot of the seemingly unproductive work that we all do every day – learning things, reading, contemplating, and care work – is what we require to live fulfilling lives. And this is also what can enable us to actually make an impact. But it doesn’t generate money. And so it has been branded as “unproductive” and has a negative connotation to it.
The person who opened the PR on my repository has never talked to either me or anyone in the community before. He likely read through some discussions, identified the need for RTL-support, and then just prompted away. He didn’t comment on issues, asked people, engaged with the community. And now, his first interaction, by being so overbearing, has left a mark on both him and me. And all his relentless productivity was for nothing. (And Zettlr still has no proper RTL-support.)
Conclusion
What should we do with this new and coming trend? I really don’t see this ending before the AI bubble bursts. It’s just too fitting. Vibe coding is the perfect work in an age of cut through capitalism that needs to produce at breakneck speed. And I can’t blame the people who do it. But, personally, it makes me sad.
What vibe coders certainly have is motivation and eagerness to do something great. But because they were pushed through the same capitalist pipeline as all of us, and are probably even more afraid of plummeting into meaninglessness, they utilize this energy for meaningless work. I know many people probably have to look this up, but an apt metaphor that was constantly on my mind while writing this article is that vibe coding seems to me like writing mountains upon mountains of code, but echoing it all to /dev/null.
I surely hope that the AI bubble will burst sooner rather than later. Not just for all the other benefits that will come from it, but also because it will free vibe coders from the shackles of having to produce for production’s sake. That – even in capitalist conditions – there is no way for them but to meaningfully engage with communities before producing. What they will produce then will have a far, far greater impact than any amount of vibe coded PR will ever have.
1 Totally unrelated, but I couldn’t think of an appropriate translation. I later looked this up, because from my childhood I only remember that “Unkenrufe” means “Someone says something will become disastrous.” Turns out, “Unke” is the German name for a toxic frog from Europe and Asia, the fire-bellied toad. Imagine that great doom is foreshadowed by ominous croaking.