Is vibe coding bad?
Vibe coding is not bad. Stopping at the demo is. The thing people call bad is a specific failure mode: you prompt an AI until the screen looks right, ship it, and never harden, secure, or test what it wrote. Done that way, the criticism is fair. Roughly 40 to 45 percent of AI-generated code has been found to contain security vulnerabilities, AI code carries more major issues than human-written code, and it fails the moment real users, real data, and real edge cases arrive. But that is a story about where people stop, not about the tool. Used as the first draft of real software, followed by hardening and shipping discipline, vibe coding is one of the fastest ways to build that has ever existed.
So the honest answer is: vibe coding is bad when it is the whole process, and good when it is the first third of the process. The people getting burned are not building wrong, they are quitting three steps too early.
I am Mahmoud Zalt, an independent senior AI systems architect. I have shipped production software for 16 years, since 2010, and I am the founder of Sista AI, where I run a workforce of autonomous AI agents in production. I am not anti-AI. I bet my company on it. That is exactly why I am blunt about where the AI stops and the engineering has to start. I have watched confident-looking AI code fall apart under load, and I have watched the same code become solid once someone did the boring work the demo skipped.
The criticism that is actually fair
Let me steelman the critics before I defend the practice, because most of what they say is true. If you have read that vibe coding is bad and quietly agreed, here is why you were right.
AI writes code in isolation, not in your system
An AI model answers the prompt in front of it. It does not know your auth flow, your deployment config, your rate limits, or how data moves across your app. So it produces code that works perfectly in a snippet and breaks the moment it touches your real environment. Each prompt gets solved, but the pieces never add up to a coherent whole. That is not a bug you can prompt away. It is the shape of the tool.
The security numbers are real
Independent studies keep landing in the same range: a large share of AI-generated code ships with exploitable flaws. Hardcoded secrets, missing input validation, broken authentication, outdated packages with known CVEs. A beginner cannot spot these, because the code looks professional. Looking right and being safe are different things, and AI is very good at the first one.
The false sense of competence
This is the sharpest criticism. Vibe coding can make a beginner feel like a senior engineer right up until the app hits a wall, and then they have no idea why, because they never understood what was written. There is even research showing developers using AI can be slower while feeling faster. The illusion of productivity is the trap.
It stalls at about 70 percent
Almost everyone who builds this way hits the same wall. The AI gets you most of the way to a working thing fast, and then every new feature starts breaking two old ones. Without structure underneath, the codebase becomes a house of cards. This is real, and it is why so many vibe-coded projects die at the prototype stage.
Every one of these is a legitimate reason to be skeptical. None of them is a reason to never vibe code. They are a reason to not only vibe code.
Is vibe coding dead? Why is it so hated?
You have probably seen the headlines: vibe coding is dead, even Andrej Karpathy has moved on. Here is the honest version. Karpathy, who coined the term, did start describing his own workflow as more structured, with more oversight and scrutiny, and the industry started using words like agentic engineering instead. That is real. But read what actually changed. Nobody went back to typing every line by hand. The shift was toward AI that writes, tests, and debugs under human direction, with a human as the overseer. That is not the death of vibe coding. That is vibe coding growing up.
The hate comes from timing. Vibe coding got popular as a promise that you could skip learning anything and still ship production apps. That promise was false, a lot of shaky software got shipped, and experienced engineers who had to clean it up got loud about it. What they are actually mad at is not AI-assisted building. It is the it just works and you never have to understand it marketing around it. So when someone tells you vibe coding is dead, hear what they mean: the lazy version is dead. The disciplined version is now the mainstream way to build.
Three places people stop, and which one you are at
The difference between a vibe-coded toy and a vibe-built product is entirely about where you stop. Here is the map.
| Where you stop | What you have | What it is good for | What breaks |
|---|---|---|---|
| Stop 1: the demo | It looks right on your screen | Learning, weekend experiments, throwaway prototypes, validating an idea | Real users, real data, security, anyone else touching it |
| Stop 2: it works for me | Runs on your machine, happy path only | Internal tools, personal automation, low-stakes single-user apps | Edge cases, concurrent users, untrusted input, maintenance over time |
| Stop 3: hardened and shipped | Tested, secured, error-handled, deployed with monitoring | Real products, paying users, anything holding real data | Much less, because you did the work the critics said you would skip |
The critics are describing people who stopped at Stop 1 and called it done. The honest builder treats Stop 1 as a first draft. Everything valuable happens between Stop 1 and Stop 3, and that gap is learnable.
How to avoid the bad version
You do not fix vibe coding by vibe coding harder. You fix it by adding the three things the demo skipped: hardening, security, and testing. None of these require a computer science degree. They require knowing they exist and refusing to skip them.
Harden it
Hardening is making your app survive contact with reality. The AI wrote the happy path. Now handle the unhappy ones. What happens when the network drops, the input is empty, the user double-clicks, the API returns an error, two people save at once? Add real error handling with messages a human can act on, not silent failures. Validate every input at the boundary, because anything from a user or an external API is untrusted until you check it. Ask your AI specifically: what are the failure modes here and what breaks under load. It will tell you, but only if you ask.
Secure it
This is the non-negotiable one. Before anything with real users, sweep for the classics. No hardcoded API keys or passwords in the code, they belong in environment variables. Never trust data from the browser on the server. Use parameterized database queries so nobody can inject SQL. Never render unsanitized HTML. Check that a logged-in user is actually allowed to do the thing they are asking to do, not just that they are logged in. AI will happily write code that skips every one of these, because the skipping version still looks like it works.
Test it
Tests are how you stop new features from breaking old ones, which is exactly the 70 percent wall everyone hits. You do not need 100 percent coverage. You need the critical paths covered: can a user sign up, log in, do the main thing, and pay if money is involved. Ask the AI to write tests for the flows you care about, run them, and watch them actually pass. Once you have tests, you can change code without holding your breath.
Stay accountable to what ships
The single habit that separates a good vibe coder from a dangerous one: you own every line that goes to production, no matter who or what wrote it. You do not have to have typed it. You do have to be able to read it, question it, and know roughly what it does. If AI hands you something you cannot follow at all, that is your signal to slow down and ask it to explain, not to paste and pray.
The case for learning to do it right
Here is the reframe. Every criticism of vibe coding is really an argument for the same thing: learn the part the demo skips. The critics are not telling you to go memorize algorithms and write everything by hand. They are telling you that the leverage of AI is real, but it only pays off if you can supervise it. The developer who can direct AI, spot the bad suggestion, and harden the output is worth far more than either a pure hand-coder or a pure prompter. That is the whole game now.
That is exactly why I wrote The Vibecoder's Handbook. It walks you through the full arc: Plan, Set Up, and Build are free and get you to a working first draft the way vibe coding promises. Then the Harden, Ship, Operate, and Scale parts are where you learn everything in this article properly, the security sweep, the testing discipline, the deployment and monitoring, all the stuff that turns a demo into something real people can rely on. It is written for people who are builders, not career engineers.
If you are building something with real stakes and you want a second set of eyes on the architecture or the security before you ship, that is what I do as an AI consultant. Sometimes one review saves you from shipping the exact thing the critics warned about.
Frequently Asked Questions
Is vibe coding bad for beginners?
No, it is one of the best on-ramps ever made for beginners, as long as they treat the working demo as a first draft rather than a finished product. The danger for beginners is the false sense of competence: the code looks professional, so they ship it without hardening or security. Beginners should use vibe coding to build and learn, then follow a checklist to secure and test anything that touches real users or real data.
Why does vibe coding fail?
Vibe coding fails because AI writes code in isolation without understanding your whole system, so the pieces solve individual prompts but never form a coherent, maintainable whole. It also fails on security, since a large share of AI-generated code ships with exploitable flaws that a non-expert cannot spot. Most projects hit a wall around 70 percent complete, where every new feature breaks an old one, because there is no architecture or test coverage underneath.
Is vibe coding dead?
The lazy version is dead, the disciplined version is now mainstream. Even Andrej Karpathy, who coined the term, moved toward a more structured workflow with more oversight, which the industry now calls agentic engineering. But nobody went back to hand-typing every line. The shift is toward AI building under close human direction, which is vibe coding with the hardening and testing steps added back in, not its replacement.
Why is vibe coding so hated?
It is hated mostly because of the marketing around it, not the practice itself. Vibe coding got sold as a way to ship production software without ever learning anything, that promise was false, and experienced engineers who had to clean up the resulting insecure, unmaintainable code got vocal. The valid complaint is about people who stop at the demo and skip security and testing, not about using AI to build.
Is AI-generated code actually insecure?
Often, yes, if you ship it unreviewed. Multiple independent studies have found exploitable vulnerabilities in roughly 40 to 45 percent of AI-generated code, including hardcoded secrets, missing input validation, and broken authentication. The fix is not to avoid AI, it is to run a basic security sweep before shipping: move secrets to environment variables, validate all input server-side, use parameterized queries, and confirm authorization on every sensitive action.
How do I vibe code without the downsides?
Add the three steps the demo skips. Harden it by handling errors and validating every input so it survives real-world edge cases. Secure it by sweeping for hardcoded secrets, injection risks, and missing authorization checks before any real user touches it. Test the critical paths so new features stop breaking old ones. And stay accountable to every line that ships, even the ones you did not type, so you can read and question what the AI produced.
The honest verdict
Vibe coding is not bad. It is a powerful first draft that a lot of people mistake for a finished product. The criticism, all of it, is really one message wearing different clothes: do not stop at the demo. Harden it, secure it, test it, and own what ships. Do that, and you get all the speed the hype promised with none of the disasters the critics warned about. Skip it, and you become the cautionary tale.
The good news is that the gap between the demo and something real is completely learnable, and I laid the whole path out step by step. Start free, and when you are ready to turn what you build into something people can actually trust, keep going. Read the free handbook ->
