Vibe Coding: Fast, Tempting – and Dangerous

In early 2025, Andrej Karpathy coined the term "vibe coding": you describe what you want, the AI generates the code, you accept without reading. "Forget that the code even exists," as he put it. Since then, the term has taken on a life of its own – and is now used for anything remotely involving AI and code.

Karpathy himself has since moved on, now speaking of "agentic engineering" – the deliberate orchestration of AI agents with human oversight. That's an important distinction. Because pure vibe coding and professional AI-assisted development are two fundamentally different things.

I use AI tools daily in my work as a freelancer. Cursor, Claude, ChatGPT – they're a fixed part of my workflow. But I've also learned where the line runs between productivity boost and risk.

The Clear Advantage: Speed for Validation

Vibe coding shines in one discipline: speed. When I want to validate a product idea, I can build a working prototype within hours. No writing boilerplate, no manual setup – just describe what I need and iterate.

For the following scenarios, this is invaluable:

Proof of concepts: Does the idea even work? Is there a market? Before I invest weeks into clean architecture, I want to know if anyone would actually use the product.
Prototypes for client conversations: Instead of building mockups in Figma, I can show a working demo. That convinces stakeholders significantly faster.
Scaffolding and boilerplate: Recurring structures like API endpoints, CRUD operations, or forms – here, AI genuinely saves time without major risk.

The core question is: Do you want to find out whether something should be built – or how it should be built? For the "whether," vibe coding is a legitimate tool.

This is where it gets critical. Vibe coding is especially attractive to people without a technical background – founders, product managers, designers who can finally "build things themselves." The problem: If you have no experience in software development, you don't know what's missing.

The AI generates code that works. But "it works" and "it's secure" are two entirely different things.

What typically gets forgotten:

Input validation: The AI builds a form that accepts and stores data. But does it validate inputs server-side? Are SQL injections caught? Is user input escaped before rendering in the frontend?

Authentication and authorization: A login is generated, but is the session secure? Are tokens properly invalidated? Is there clean role separation between user roles?

HTTPS, CORS, CSP: Security headers aren't glamorous. The AI rarely sets them proactively. And if you don't know they exist, you won't ask for them.

A December 2025 study by CodeRabbit showed that AI-generated code in open-source projects contained roughly 2.7 times more security vulnerabilities than human-written code. This isn't fear-mongering – it's a statistic that deserves attention.

In July 2025, SaaStr founder Jason Lemkin documented how Replit's AI agent deleted an entire database – despite explicit instructions not to make any changes. At the vibe coding platform Lovable, security vulnerabilities were found in 170 out of 1,645 generated web apps, exposing personal data publicly.

If you're using vibe coding for production software, be clear about this: The AI doesn't think about security. You have to.

The Context Window Problem

A disadvantage that's rarely discussed: Current LLMs have a limited context window. This means they can only "see" a certain amount of code and conversation simultaneously.

For small projects, this barely matters. But once an application grows – multiple modules, shared state logic, complex data flows – the following happens:

The AI loses track. It no longer knows about file A while editing file B. The result: it rewrites logic that already works. It creates duplicate implementations. It breaks existing functionality because it no longer has the context.

I've experienced this myself. Beyond a certain project size, the AI starts breaking more than it fixes. You end up spending more time reverting AI changes than you saved through them.

This isn't a temporary problem that disappears with the next model. Context windows are getting larger, yes – but the complexity of real software grows faster. A Nuxt app with 50+ components, Pinia stores, API routes, and middleware exceeds any current context window when you'd need to consider everything simultaneously.

Tests: The Neglected Safety Net

Perhaps the most critical point: Vibe coding almost never produces tests. And if you don't explicitly ask for them, it stays that way.

Unit tests: The AI writes a utility function but no test for it. Edge cases? Ignored. Null checks? Missing.

Integration tests: Do modules communicate correctly with each other? Does the API work with the actual database, not just a mock? Vibe-coded projects typically have zero coverage here.

End-to-end tests: Does the complete user flow work? From login through data entry to checkout? Without E2E tests, every change is a gamble.

The insidious part: Without tests, the project initially feels more productive. You save the time for test code. But every change becomes a risk. Every new feature can break existing functionality without anyone noticing – until a user complains.

Tests aren't optional. They're the safety net that prevents a working prototype from collapsing at the first refactoring.

Conclusion: AI as Copilot, Not Autopilot

Vibe coding isn't a bad concept. It's a powerful tool for validation and prototyping. But it's no substitute for software engineering.

The distinction is simple: If the code gets thrown away once the idea is validated – vibe coding is fine. If the code goes to production and affects real users – you need a developer who understands, secures, and tests the code.

Karpathy recognized this himself and now speaks of "agentic engineering" – the deliberate use of AI agents under human oversight. The crucial difference: you don't hand off responsibility. You use the AI's speed but maintain control over architecture, security, and quality.

My personal approach: I use AI for scaffolding, boilerplate, and as a sparring partner for solution approaches. But I read every diff. I write tests. And I don't rely on the AI knowing what my application needs – because only I know that.

AI is the best copilot developers have ever had. But a copilot you trust blindly will eventually fly into a mountain.