The dangerous appeal of vibe coding: Know when, and when not

A working app used to take months. Now it takes an afternoon. Well… supposedly.

The thing is, looking finished and being finished have never been further apart.

Our CMO and board member, Piret Vahter, who has spent her career in B2B technology, put it better than any framework could:

“Vibe coding is lovely, do it. But if your wall is cracked and you use wall putty to hide the crack, your wall is still cracked.”

So how about fixing the wall first?

In this piece, we will cover why vibe coding produces false confidence rather than false output, what it hides, and the questions to ask before a prototype becomes something you depend on.

Key Takeaways

• Vibe coding produces working software quickly. The risk is what it teaches leaders to believe about how finished that software is.
• The confidence problem is measurable. In peer-reviewed research, people using AI assistants wrote less secure code while believing the opposite.
• What gets hidden is what was always hard: integration, data quality, ownership, security, and the cost of the second year.
• The useful test is exposure. Who gets hurt when this breaks, and how quickly would you find out?
• A demo is not evidence that an app can actually run, needless to say.

The confidence problem, measured

Andrej Karpathy coined “vibe coding” in February 2025 to describe a specific way of working. It meant accepting all suggestions, not reading the diffs, pasting in error messages without comment, and letting the code grow beyond his own comprehension. 

He literally described it as not too bad for throwaway weekend projects, and said that what he was doing was not really coding.

That nuance travelled not as far as the concept of vibe coding.

What does the research show about vibe coding?

In a peer-reviewed study presented at ACM CCS, Stanford researchers ran a controlled experiment. They asked participants to complete security-relevant programming tasks with and without an AI assistant. 

The finding is in the title, Do Users Write More Insecure Code with AI Assistants?, and the answer was yes. 

It wasn’t just that they wrote less secure code, but they were more likely to believe they had written secure code. The tool did not only lower quality. It raised confidence at the same time, and the two moved in opposite directions.

A similar gap appears in productivity. The research group METR ran a randomised controlled trial with experienced open-source developers working on their own repositories in early 2025. They found that tasks took 19% longer with AI tools, while the developers estimated they had been 20% faster.

Whether the tools make you 19% slower or meaningfully faster, people’s felt sense of their own performance was unreliable in both directions. For a leader, that is the lesson. 

Speed you can feel is not the same as speed you can measure.

What vibe coding hides

A prototype hides things by design. That is the point of a prototype, and it is a legitimate one. The problem arises when the hidden parts are mistaken for absent parts.

It hides security.

Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models across 80 coding tasks and found that 45% of generated samples introduced vulnerabilities. Cross-site scripting was missed in 86% of relevant cases. 

Models have become better at writing code that works and no better at writing code that is safe. The gap between those two things is widening.

It hides integration.

A demo runs against sample data in a clean environment. Your business runs on an ERP with fifteen years of history, a CRM with three definitions of a customer, and a finance system that only accepts a specific file format on a specific schedule.

Connecting to those systems is where the work begins: authentication, permissions, error handling, retries, mapping, and what happens when the other system is down. None of this shows up in the version that impressed the room, which is the same reason small changes carry hidden costs. 

The vibe-coded app is the tip. What about the iceberg?

It hides the state of your data.

A prototype is usually built on data someone cleaned up for the demo. Real systems run on real records and complex data points. 

Software cannot supply data quality it was never given.

This is the whole argument for minimum viable data we made. Vibe coding makes it faster than ever to build a beautiful interface on top of data nobody trusts.

It hides ownership.

Ask who owns the prototype after the person who prompted it moves on. Frequently, nobody does. The original author cannot fully explain the code, because the working method involved not reading it. There is no documentation of why decisions were made, since no decisions were consciously made.

This is the operating model question arriving through a new door. A system with no named owner for decisions, changes, support, and accountability is a system on borrowed time.

It hides the second year.

Maintenance is where costs accumulate, and this is the same pattern we described in AI is a cost-saver right until it is not. The created cost arrives later.

Gartner projects that by 2028, 40% of new enterprise production software will be built using vibe coding techniques. The same analysts warn that without governance and quality controls, prompt-to-app approaches by citizen developers could increase software defects substantially over the same period. 

It hides shadow systems.

The fastest path from an idea to a working app now runs entirely around IT. Someone in operations builds the tool they need over a weekend, it works, and colleagues start relying on it. 

This is the spreadsheet side system with a nicer interface.

Where the line actually sits

The developer community has already worked out the boundary in practice, and it is more nuanced than the discourse suggests.

Stack Overflow’s 2025 Developer Survey of more than 49,000 developers found 84% using or planning to use AI tools, while trust in accuracy fell to 33% from 43% the year before, with 46% actively distrusting output. 

Practitioners are comfortable with AI for learning, documentation, and generating starting points. They keep it away from deployment and architecture decisions.

So the useful question is not whether to vibe code. It is what you are pointing it at. Two tests make this concrete.

The exposure test. Who is harmed when this fails, and how fast would you find out? A marketing landing page fails visibly and cheaply. A pricing calculation fails invisibly, for months, in a direction that favours nobody.

The lifespan test. Is this meant to be thrown away? Genuine throwaways are excellent candidates. The difficulty is that successful prototypes are rarely thrown away, because working software creates its own gravity.

The questions to ask before a prototype becomes a system

If someone shows you an impressive demo and proposes putting it into production, six questions will tell you most of what you need to know.

1. Has anyone read this code? If nobody has reviewed it, you have output rather than software.
2. What data does it touch, and would we be comfortable if that data leaked? This one question separates the low-stakes cases from the serious ones.
3. Which systems does it connect to, and what happens when one of them is unavailable? Demos assume everything is up. Production does not.
4. Who owns this in six months? A name, not a department.
5. How would we know if it were quietly wrong? Loud failures get fixed. Quiet ones compound.
6. What is the plan when it needs to change? Software that nobody understands is software that nobody can safely modify.

None of these require technical expertise to ask, and this is exactly the ground a proper analysis phase is designed to cover. The difference now is that the prototype arrives before the analysis rather than after it, which inverts the usual order and makes the questions easier to skip.

There is a people dimension as well. When software can be produced by anyone in the organisation, the constraint stops being who can build and becomes who can judge. 

That capability has to be deliberately developed, which is what people readiness means in an environment where the tools have outrun the review processes around them.

The Net Group view: Fix the wall, then paint it

We have built software for over 30 years, through several waves of tooling that promised to make building easy. 

So far, none removed the hard parts.

The hard parts are:

• deciding what to build
• understanding the process it lands in
• agreeing what the data means
• connecting it to systems that already exist
• keeping it alive after the people who made it move on

AI left every one of those problems exactly where it was.

The wall putty is genuinely good now. It goes on fast, it is cheap, and the finish is convincing. 

That is precisely why it’s dangerous., A wall that looks repaired stops getting inspected.

Vibe code the things that deserve to be vibe coded, and let it be fun. Then, before any of it carries weight, go and look at the wall.