Vibe coding itself isn't the problem - unreviewed, unchecked vibe coding is. That's the consensus among the people who've actually written carefully about this, not just reacted to it: the technology isn't inherently good or bad, but how it's used varies enormously, and the failure mode isn't the tool, it's skipping the review step. This page takes the real criticisms seriously one at a time, rather than defending or dismissing vibe coding wholesale.
Most existing writing on this question is a personal essay making the same nuanced point in prose, with no structure to make it easy to act on. This page covers the same honest ground, structured as a reference: each real criticism, how valid it actually is, and what to do about it.
We think the review step becomes more important at Greta.sh, as AI gets better at building software. When an app looks polished and works on the first try, it's easy to assume everything underneath it is equally solid. But a working interface doesn't automatically mean the authentication, data handling, edge cases, or integrations are production-ready.
That's why we don't see vibe coding as "prompt once and ship whatever comes back." The better model is to let AI remove as much of the technical work as possible while still building in checkpoints before something reaches real users. The goal isn't to make founders become code reviewers. It's to make the important checks happen without requiring them to understand every line of generated code.
The honest starting point: three developers who've actually written about this agree on more than you'd expect
Software engineer Waleed Kadous - who has argued publicly that "vibe-coding is a horrible idea" doesn't actually mean the technology is worthless. His real point is narrower: AI coding tools produce what he calls "10-20% random acts of stupidity" if left unchecked, and the fix isn't avoiding the tools, it's reviewing every line they generate. Used with that discipline, he reports 3-5x productivity gains and even improved code quality, comparing the tools to a chainsaw - genuinely dangerous used carelessly, genuinely useful used with respect for what it can do wrong.
A separate widely-read piece makes almost the identical point from the other direction: "vibe coding isn't the problem, developer illiteracy is." Its argument is that there isn't one "vibe coding" category at all, but a spectrum from pure conversational prompting to fully spec-driven AI development, and picking the wrong point on that spectrum for the task at hand not the existence of the spectrum is where projects go wrong.
A third take, more skeptical, argues "vibe coding isn't bad, you are" the author's position being that vibe coding requires more technical judgment to use well, not less, since you still need to recognize a bad architectural decision even if you didn't type the code yourself.
Three different writers, three different starting positions, landing in roughly the same place: the tool isn't inherently the risk. Unreviewed, undisciplined use of the tool is.
The real criticisms, one at a time
| Criticism | How valid? | What to actually do about it |
| It produces insecure code | Real - security research consistently finds a meaningful share of AI-generated code contains exploitable patterns | Review generated code, especially anything touching auth or data; pick a platform with sane security defaults rather than relying on review alone |
| It's just for toy prototypes, not production | Partially outdated - the honest version is "some outputs are production-ready, some aren't, and it depends heavily on the platform and the app" | Read our take on whether vibe-coded apps are production-ready for the full picture |
| It's hard to maintain over time | Partially true - a real, ongoing cost if the generated code isn't structured for humans to read later | Favor platforms that generate readable, exportable code; see our maintenance piece |
| It creates vendor lock-in | Real with some platforms, avoidable with others | Confirm code and data export before committing, see the lock-in and data ownership checklist |
| It's going to replace developers / hurt the job market | Overstated in both directions | The realistic middle: it lowers the bar to start building and raises the value of knowing what to check before you ship |
Where Greta.sh fits into this
We build greta.sh, so weigh this accordingly but it's also exactly why we wrote the criticism table above instead of a pure defense. Greta.sh generates a real full-stack app - frontend, backend, database, and deploy, from a plain-English prompt, not a UI mockup, which is the direct answer to the "just prototypes" criticism. It also keeps growing the site after launch with a built-in SEO/AEO layer, which most vibe-coding platforms stop offering the moment the app is deployed. Starter is $20/mo list, currently $5/mo on the welcome offer; Pro is $50/mo list, currently $20/mo; Business is $200/mo; Enterprise is custom. None of that erases the need to review what any AI tool generates, including ours that part of the criticism above is just true, for every platform in this category.
Got an idea? Build it now!
Just start with a simple prompt. No coding required — Greta.sh turns your idea into a working app in minutes.
Frequently asked questions
Is vibe coding bad for production software?
Not inherently but unreviewed vibe coding, shipped straight to production without checking what was generated, genuinely is risky. The distinction that matters is whether there's a review step, not whether AI wrote the first draft.
What do critics of vibe coding actually get right?
The security concern is legitimate - a meaningful share of AI-generated code across tools has been found to contain exploitable patterns in independent research. The maintainability and lock-in concerns are also real for some platforms. Where critics overreach is treating these as reasons to avoid the category entirely, rather than reasons to pick a platform and a review habit carefully.
Is vibe coding just for beginners, or can experienced developers use it too?
Both, for different reasons. Beginners use it to build something without first learning to code. Experienced developers increasingly use it to move faster on parts of the work that don't need their full attention - with the same review discipline they'd apply to any code they didn't personally type.
Do the people who study vibe coding professionally think it's bad?
The more careful, published takes on this converge on "not bad, but used badly it can go badly" rather than a flat yes or no. The recurring theme across independent writers is that the failure mode is skipping code review and picking the wrong point on the vibe-to-structured spectrum for the task, not the existence of AI-assisted coding itself.
