Vibe Coding

The code becomes a black box: it fulfils its purpose at the moment of execution, but no one in the team can reliably explain how it does this.

The term was coined on 2 February 2025 by Andrej Karpathy, one of the best-known representatives of machine learning and co-founder of OpenAI. In his original article, he described a programming style in which one "fully surrenders to the vibe" and even "forgets that the code even exists". Within a few months, "vibe coding" became a collective term for the practice of creating software almost entirely through prompts to coding agents such as Cursor, Claude Code or GitHub Copilot.

How vibe coding differs from AI-supported development

Vibe coding is not the same as the general use of AI in software development. The difference lies not in the tool, but in the attitude towards the generated code. Anyone who pairs with a model, reads every proposal, specifically requests tests, asks safety questions and consciously makes architectural decisions themselves is carrying out AI-supported development - but not vibe coding. Vibe coding, on the other hand, skips the human evaluation instance: The model writes, the human accepts.

This distinction is crucial because it determines what quality ends up on a system. An experienced developer makes dozens of small design and architecture decisions in a single hour - for example, pulling a database query out of a loop before it slows down the system with large amounts of data. Vibe Coding does not replace these decisions, it skips them.

Typical features

• Target description instead of implementation: The human formulates the desired behaviour, not the solution path.
• Untested adoption: The proposed diff is accepted without reading it in full.
• Error ping-pong: Error messages are passed back into the model until it runs.
• Code as a black box: The result works, but cannot be explained in the team.

Where vibe coding makes sense

Vibe coding is not the opposite of good software development, but a tool with a clearly defined area of application. It is useful wherever the software never reaches the phase in which it should be maintainable:

• Discard prototypes, whose express purpose is to validate an idea and then be discarded.
• Internal scripts and one-off tools with no external impact and no long-term maintenance.
• Explorative data analyses, in which the insight counts and not the code.
• Quick UI mockups, which are later rebuilt anyway.

A second legitimate area of application is to speed up experienced developers: anyone who evaluates the generated code in seconds because they could write it themselves anyway is using the model as a keyboard, not as an architect. This is a reality in many engineering teams - and is no longer vibe coding in the narrower sense because the human review is retained.

Where vibe coding becomes dangerous

Vibe coding becomes critical as soon as the resulting software goes live and touches business processes or customer data. Studies from 2024 and 2025 show a consistent picture: AI-generated code has significantly more security vulnerabilities on average than purely human-written code, the number of vulnerabilities discovered each month in large companies has risen dramatically in a short space of time, and code maintenance (refactoring) has decreased measurably, while duplicated code blocks have multiplied. What looks like speeding up is often technical debt brought forward: the bill comes later, in the form of expensive maintenance.

The reason is structural: if you don't read code, you can't evaluate it. The very quality features that determine the cost-effectiveness of a system over many years - maintainability, testability, security, performance under real load, observability and compliance suitability - are invisible in the first few weeks after delivery and are systematically not addressed in vibe coding.

Practical example: The MVP that lives too long

A concrete example from practice: In insurance IT, existing and billing systems regularly run for ten to fifteen years. A vibe-coded Minimum Viable Product that goes into production untested in three weeks goes through hundreds of changes by changing teams over this time. Without architecture documentation, without automated tests and without clear responsibilities in the code, each extension becomes more expensive than the previous one - until a trivial adjustment costs several man-weeks and the only remaining answer is "better to build from scratch". This is how the throwaway mentality returns at system level.

Securing vibe coding in the corporate context

Companies do not have to ban vibe coding, but they should frame it in organisational terms. Three measures have proven their worth:

• Inquire about the proportion of unread code: When a system is accepted, it is legitimate to ask what proportion of the code has been read by a human before it reaches the repository. The answer says more about the subsequent risk than any demo date.
• Acceptance criteria beyond "works": Documented architecture, automated tests on the core paths and a check against common security standards (such as the OWASP Top 10) are part of the acceptance process - regardless of whether AI was involved.
• Separate playground and production: A clear promotion level between prototype and production system (own repository, own review obligation, own security check) is the most effective measure, which can also be arranged without an engineering background.

Conclusion

Vibe Coding is an honest description of how much software is created today: fast, prompt-based, untested. For experiments and throwaway code, this is a huge productivity gain. For software that is intended to endure and be commercially viable, the following still applies: it is created by people who know what they are doing and why. AI shortens their paths, but does not replace them. Anyone who gets this wrong is buying speed on credit - and the interest is hidden in the source code.

Further reading: Andrej Karpathy's original coining of the term is publicly documented (Original article on X, 2 February 2025).