Methodology · 3 MIN

Vibe coding: where it helps, where it bites

Vibe coding is a tool, not a method. The line runs between throwaway code and software that ships to production.

Vibe coding: where it helps, where it bites
LOCATION
Rhineland-Palatinate
AUTHOR
Aashwin Shrivastava
PUBLISHED
Jun 25, 2026
IMAGE
AI-GENERATED

This translation was produced automatically using AI. The German version is the editorially reviewed original.

Vibe coding is a tool, not a method. Andrej Karpathy coined the term in early 2025 for a way of programming where you give yourself over fully to the vibes and forget the code even exists. For the right task, that is great. For the wrong one, it is a liability. The decisive question is not AI yes or no, but a much simpler one: are you building something to throw away, or something that ships to production and gets seen by customers, auditors, and the Cyber Resilience Act? That line is where everything gets decided.

01. Where it helps

Vibe coding shines wherever speed matters and the code is allowed to disappear afterwards. The prototype built in an afternoon, the internal tool for a small team, the click dummy for a client presentation, the first 70 percent of an idea: this is where it delivers real value. Karpathy's original example was exactly that, throwaway software for a weekend project.

Demand confirms this. Tools such as Cursor, Claude Code, Lovable and Bolt have grown at record speed, with Lovable reaching around 200 million dollars in annual revenue by the end of 2025. In my own work the benefit is concrete too: a subject-matter expert without a programming background can get an idea running themselves, instead of first describing it and then waiting two weeks. As long as the result stays an experiment and nobody bases their business on it, that is a gain in speed that should not be underrated.

02. Where it bites

As soon as the code ships, the picture flips, and the evidence is uncomfortably concrete. Veracode reviewed over 80 tasks and more than 100 models in 2025: 45 percent of the generated code contained a security vulnerability, and newer or larger models did not perform any better. A study by METR found that experienced developers using AI tools were 19 percent slower, yet believed themselves to be faster.

Then there are the incidents that stick in memory. In July 2025 a Replit agent deleted a production database, ignored the explicit instruction not to change anything, and afterwards claimed that a restore was impossible (it was not). Roughly one in five AI-suggested packages does not exist at all, and 43 percent of these invented names recur repeatedly, opening a new supply-chain gap for attackers. Addy Osmani calls it the 70 percent problem: the AI gets you to 70 percent fast, while the last 30 percent, made up of edge cases, security and integration, remains classic engineering work. And legally the position is clear: liability for shipped software stays with the company that builds and sells it, not with the AI provider.

03. The line: throwaway versus shipped

The most useful distinction is not about tools but about purpose. A script that one person uses once is a different thing from software that your customers, your auditors and, from December 2027, the EU Cyber Resilience Act will judge. Even Gartner, which expects a 40 percent share of vibe coding in enterprise software by 2028, explicitly calls the raw output throwaway code, not production-ready.

For the Mittelstand this means: the question is not whether your team may use vibe coding, but for what. Throwaway and experiment: go ahead, fast, without ceremony. Anything that touches customer data, gets shipped, or has to withstand an audit: never unread. This single sorting rule saves most of the later pain.

04. The mature path: controlled vibe coding

The good news is that the professional answer already exists for 2025 and 2026, and it is not called a ban. It is called controlled vibe coding, or AI-assisted development: the AI as a very fast junior, with a responsible senior alongside. That is how we approach it.

🔸 Specification before the prompt. The countermovement is called spec-driven development, with tools such as GitHub Spec Kit: specification, plan and tasks first, then code. That makes the result verifiable instead of arbitrary.

🔸 Review and tests before production. No AI code goes live unread. Code review, automated tests and a security scan are the condition, not an optional extra, especially for anything that touches data or money.

🔸 Licence and supply chain in view. Unreviewed AI code can smuggle in GPL-licensed snippets or invented packages. Both belong in the review process before they become a compliance problem.

Vibe coding is a brilliant tool for the right task and a risk for the wrong one. The difference lies in knowing, before the first prompt, which side of the line you are standing on. Which side is your next project on?

← Signals

Wayne Dyer

“If you change the way you look at things, the things you look at change.”