Vibe coding: the end of software engineers or a dangerous illusion?

Vibe coding is not the future. It is happening now. Millions of people are already trying it: you describe what you want, the AI writes the code, you iterate until it seems to work. Sometimes it delivers brilliantly. More often it is a ticking time bomb that nobody is watching.

We work with clients who have shipped vibe-coded tools to production, clients who are seriously considering it, and clients paying to clean up the aftermath. Our take is more nuanced than most opinions online — and considerably less enthusiastic.

What is vibe coding?

Vibe coding is a term AI researcher Andrej Karpathy introduced in early 2025. The definition is simple: building software by describing what you want in plain language, without writing or understanding the code being generated. You 'vibe' — you hit accept, you check whether it works, you adjust your prompt until the output looks right.

Tools like Cursor, Bolt.new, Lovable, and GitHub Copilot Workspace put this within reach of anyone. A product manager, a marketer, a founder with an idea — they can now 'build' a working web application without reading a single line of code. That feels like democratisation. In a certain sense, it is.

What it does well.

For specific use cases vibe coding works surprisingly well. Prototyping a product idea in an afternoon. Building an internal dashboard that would normally take a full sprint. A non-technical user assembling a simple form or data tool for personal use — these are legitimate scenarios.

The barrier to a first working prototype has dropped dramatically. If you want to test a hypothesis, show a client something concrete, or quickly validate whether an idea is worth pursuing at all, vibe coding is a real starting point. We use it ourselves for exploration. Not for production.

• Prototyping and validating product ideas without developer involvement
• Internal tools for personal use, without security requirements
• Quickly assembling a proof-of-concept for a stakeholder presentation
• Non-technical team members automating their own workflows

Where it completely falls apart.

The problem starts at exactly the point when the tool 'seems to work'. Because nobody understands what has been built.

We see it regularly: a vibe-coded application that ran fine for the first few months. Then someone wanted a small change. That change broke three other things. Nobody knew why. The codebase was generated by an AI that has never heard of architecture principles, and approved by a user who could not read the output. There is no ownership. No understanding. Just output.

Security issues that a junior developer would catch pass unnoticed. SQL injection, unprotected API endpoints, passwords stored in plaintext in the source code — we have seen all of them surface in vibe-coded projects. Not because AI necessarily writes bad code, but because nobody is reviewing it. According to Snyk research (2025), AI-generated code without code review contains 2.4 times more critical security vulnerabilities than developer-written and reviewed code.

Technical debt on steroids.

Normal technical debt accumulates slowly. You choose a quick solution, you document the trade-off, you know you need to refactor it later. You at least have a mental model of what you built.

Vibe coding debt is structurally different. You have a codebase of thousands of lines you have never read. The structure is arbitrary. There are no tests. The architecture reflects the order of your prompts, not the logic of the system. Adding a new feature requires an AI to reconstruct what the previous AI intended. Every iteration makes it less coherent.

According to a 2025 analysis of GitHub Copilot usage, AI-generated code contains on average 40% more technical debt indicators than developer-written and reviewed code. Without a review process — which pure vibe coding lacks by definition — that figure doubles. You are not just building a product. You are building a debt you will be paying off for a long time.

“The first prototype is not the final product. It is the starting point. Vibe coding can get you there fast. What comes next requires engineering.”— Productized Team, 2026

Our prediction.

Vibe coding is not going away. The tools will improve, the output will get better, and there are genuine use cases where it adds value. Denying that is naive.

But the narrative that software engineers are becoming obsolete is wrong. The opposite is closer to the truth. Vibe coding increases the amount of software in the world. It does not increase the amount of well-built software. That gap is filled by people who understand what is under the hood — engineers who can evaluate, guide, and maintain AI-generated code.

A product manager prototyping with Bolt.new: exactly the right use. A company taking that prototype into a customer-facing application without an engineer who understands the architecture: that is precisely the scenario that calls us later in the week asking for a cleanup operation.

We build for clients who understand that a working demo is just the beginning. That the real questions arrive when scalability, security, maintenance, and further development come into play. Let's talk about your situation — where vibe coding is enough, and where it is not.