Vibe coding is now in the dictionary. Collins named it Word of the Year for 2025. Andrej Karpathy coined the term to describe writing software based on intuition and pattern matching rather than specification, letting AI tools generate large blocks of code and accepting the output as long as it seems to work.
For solo projects and rapid prototypes, this approach produces real value. For open source, it is creating a category of problems that did not exist before and making several that did worse.
The reason comes down to what open source projects actually are. They are shared codebases maintained across time by rotating groups of contributors who do not know each other and do not always share context. Deliberate development practices exist precisely because that context is hard to transfer. When vibe coding replaces deliberate development in an open source environment, the effects compound in ways they do not in a solo codebase.
The Meaning of Vibe Coding
Vibe coding means writing software based on intuition, pattern matching, and feeling rather than documented specifications. It relies on what seems right rather than what is proven to work. In its AI-assisted form, it means accepting generated code because it passes surface-level checks rather than because you understand what it does and why.
The assumption underneath vibe coding is that code that works in one context will work everywhere. That assumption fails constantly in production, and it fails even more consistently in shared codebases where other people will extend, modify, and rely on your work.
How it differs from manual development
Deliberate development involves designing before implementing, documenting decisions, understanding existing codebase patterns before adding to them, and treating refactoring as essential rather than optional.
Vibe coding skips most of this. Architectural planning happens minimally or not at all. Decisions are made in the moment and rarely written down. The existing codebase is read just enough to find a place to attach the new code. The result often works well enough to pass review and then becomes a problem for whoever touches that part of the codebase next.
How Vibe Coding is Affecting Open Source
1. Inconsistent code patterns
The most visible sign of vibe coding in an open source project is the same problem solved differently in three different parts of the codebase. A contributor who did not read the existing patterns closely enough added a feature using an approach that technically works but contradicts how everything else is built. Someone else did the same thing later. Now the codebase contains multiple competing patterns with no clear reason to prefer one over another.
New contributors trying to understand the project cannot tell which approach is correct. Maintainers review pull requests that follow none of the established patterns because the patterns were never documented clearly enough to be obvious.
2. Weak testing and validation
Code written by vibe gets tested by vibe. If the happy path works and the developer does not feel like edge cases are a problem, the tests reflect that. The result is test coverage that measures the lines of code that run, not the conditions that could cause failure.
"It works on my machine" is the testing equivalent of vibe coding. Production behavior on real data volumes, with real user inputs including the unexpected ones, is a different environment from a local development setup, and the gap between them is exactly where vibe-coded edge case assumptions break.
3. Missing documentation
The most lasting damage from vibe coding is the absence of a record explaining why decisions were made. When someone writes code based on feel and it works, they rarely go back to explain the reasoning, because they did not start with explicit reasoning.
Six months later, a maintainer finds that code, does not understand why it was written that way, changes it to something that seems more correct, and introduces a regression. The time spent finding and fixing that regression is the direct cost of the missing documentation.
Risks Vibe Coding Creates
Security vulnerabilities
Security flaws in vibe-coded contributions follow a predictable pattern. Input validation gets skipped because it felt unnecessary for the use case the developer had in mind. Dependencies get added without reviewing what they do or what they depend on. Authentication flows get implemented based on what seems right rather than what the specification requires.
The most dangerous part is not that these flaws exist. It is that they are invisible. Vibe-coded security decisions look like deliberate decisions when reviewed superficially. The flaw is not in the code that is there. It is in the consideration that is missing.
Open source projects face heightened exposure here because the code is public. A security researcher looking for vulnerabilities can read every commit. So can an attacker. The transparency that makes open source trustworthy becomes a liability when the code contains security decisions made by intuition rather than expertise.
Maintainability breakdown
A codebase accumulates vibe coding the same way a house accumulates clutter. Each addition seems fine at the time. The collective effect creates an environment where adding anything requires navigating around a growing number of undocumented decisions and inconsistent patterns.
Contributors leave projects at this stage. Not always because the project lost their interest, but because working in the codebase stopped feeling productive. High rejection rates for pull requests that do not match unstated conventions, frustration with reviewers who seem to enforce rules that were never written down, and the cognitive overhead of a codebase that does not explain itself all push contributors away.
Maintainers burn out here too. Spending more time reviewing and fixing vibe-coded contributions than building features is not sustainable.
Performance and scalability problems
Code that performs fine in development sometimes fails badly in production not because the developer made an obvious mistake, but because the assumptions behind the implementation did not account for scale.
A database query written by feel might be perfectly fine for a hundred records and unacceptably slow for a hundred thousand. A memory management approach that works in a test environment might leak steadily under production load. These problems are invisible until they are not, and by the time they surface, the vibe-coded code is woven into enough of the codebase that fixing it requires either a partial rewrite or working around the limitation indefinitely.
Consequences of Vibe-coded Programs on Open Source Resources
Failed migrations are among the more painful outcomes. A project that accumulated vibe coding over several years attempts to move to a new architecture or framework. The migration is harder than expected because nobody can explain why certain things were done the way they were. Some of it cannot be migrated safely because the behavior was never documented. Users end up with deprecated code they cannot safely update.
Project abandonment follows a consistent pattern. Maintainers step back because the codebase is too difficult to work in. New maintainers are hard to attract because the project has a reputation for quality issues. Users who depended on the project find themselves maintaining a fork or switching to an alternative.
Also Read: Why Python Became the Default Language for AI?
Security incidents leave permanent marks. A vulnerability discovered years after a vibe-coded commit was merged erases the trust that took years to build. Users lose confidence not just in the specific feature that failed but in the project's overall reliability.
Conclusion
Open source projects outlast others when they make deliberate decisions, document those decisions, and build processes that carry them forward even as contributors change.
Vibe coding is the opposite approach. It is faster in the short term and expensive in every term after that. In a closed-source context with a stable team, a company can absorb the cost. In an open-source project maintained by volunteers across years, the cost lands on whoever is left.
The projects that resist vibe coding do not do it by being less welcoming to contributors. They do it by being clear about what the project is, how it is built, and what it expects. That clarity protects the codebase and, counterintuitively, makes the project more accessible to contributors who want to do good work and just need to understand what good work looks like in this context.
Top comments (0)