The Cost of Vibe Coding Nobody Puts in the Demo
The honest case for building software by conversation, the costs nobody puts in the demo, and the structure that separates a fast prototype from something you can hand to a user.
TL;DR
- –Vibe coding is not a toy. It collapses the distance between having an idea and having something a user can click.
- –The speed isn't the problem. Nothing in the loop asks whether what you just generated is correct, necessary, or safe.
- –Slop is not a bug: it's correct and worthless. A model returns the most probable output, which is the average one. No test catches it. Only taste does.
- –The fix is not less AI. It's a spec before the prompt, one hand-built slice, and a human gate wherever being wrong costs a user something.
What vibe coding is
You describe what you want, an AI writes the code, you glance at the result, and describe the next thing. You are steering by feel, not reading every line. The reaction splits along a predictable line: one camp sees a toy producing plausible garbage, the other the end of software engineering. Both are wrong the same way: arguing about the code, when the interesting change is to the process around it.
What it is undeniably good at
Crossing the gap between designing a thing and having a thing
The most expensive distance in product work is between a design file and something a user can click. Vibe coding collapses it. Ideas that would have died as “nice, but who is building that” become a route you can open in a browser the same afternoon.
Repetition, which is most of an application
A real product is not clever. It is the same vertical slice repeated: a table, a form, some validation, a save, a refresh. Once that pattern exists, describing the twelfth version takes minutes. This is the part of software AI is close to perfect at, because it’s exactly the part that’s compressible.
Vibe coding removes the labour of building. It does not remove the judgment. It just makes it much easier to skip.
Where it quietly costs you
1. The verification gap
Ask most people how they verify their work and the honest answer is: the build passes. But a typecheck doesn’t confirm an invoice totals correctly, or that one customer can’t read another’s data. Writing code by hand, you carry a rough model of what could break, because you suffered through building it. Generate it, and that model never forms. The code works on the happy path you demoed, and edge cases become somebody else’s discovery.
2. AI is most fluent exactly where it should be least trusted
Fluency and correctness are not the same signal, and we’re wired to read one as the other. A confident, well-structured answer feels true: fine for a card component, dangerous for authorisation or money. A wrong colour token costs you a redeploy. A wrong access check costs your users their privacy. The generator treats both requests identically. Only you know they’re not.
The rule worth adopting
Wherever being wrong costs a user, not you (money, personal information, anything irreversible), that code gets read line by line, not generated and glanced at.
3. Slop, which is not the same thing as a bug
A bug is wrong. Slop is correct and worthless: the hero section with a gradient and the words “Elevate your workflow.” It isn’t a model failure. The model is trained to produce the most probable next thing, and the most probable thing is, by definition, the average one. Ask for a landing page and you get the median landing page, assembled from every landing page. Competent. A template, because statistically, it is one.
Generation regresses to the mean. If you supply no taste, the mean is what you ship.
This is why vibe-coded sites are so recognisable at a glance, and why that’s fatal for anything whose job is to be distinctive. Slop is comfortable: it never looks broken in review, so nobody says stop. No test catches it either: the only instrument that detects slop is a person with taste, willing to say “this is fine, and I hate it.”
The tell
Could a competitor paste your product’s text onto their site without changing a word? If yes, it was written by the average of the internet.
How to make it better
None of this argues for typing everything by hand. It argues for putting structure around a loop that has none by default.
Write the specification before the prompt
Keep two documents: intent (what this is, who it’s for, what “done” looks like) and the engineering contract (stack, non-negotiable rules). If you can’t describe done, the AI will invent a version for you: plausible and wrong.
Hand-build one vertical slice, then let AI repeat it
Build the first version of the repeating pattern yourself, understanding every layer. It becomes the reference the AI imitates and the map you use to debug everything after, the most valuable hour in the project.
Build a verification gate that is not the typechecker
Decide, before you generate, what would prove this works: a test, driving the flow end to end, a script that renders the output. Something outside the generation loop has to be able to say no, or you’re shipping compiled guesses.
Put the guardrail where the harm is, and don't regenerate it
Safety-critical text and permission checks should be fixed, reviewed, and excluded from the parts of the system that regenerate. Then put a human in the loop by design: someone who reviews the output before it reaches whoever it can hurt.
Supply the taste, because the model will not
The defence against slop is specificity: not “make it look modern” but “monochrome, no gradients, motion that implies weight.” A generator handed a strong constraint executes it faithfully; handed a vague one, it hands you the average. Deleting is a design activity too. Cutting the section that’s merely fine is the work. It always was.
The reframe that helps most
Stop thinking of the AI as a developer you are managing. Think of it as an extremely fast junior who has read everything and remembers nothing about your project. Give it the spec, the pattern to copy, and a reviewer. Skip one and you get exactly what you paid for.
The honest scoreboard
The useful question isn’t whether to vibe code. It’s which side of the line a given piece of work sits on, decided before you start typing.
✓ Generate freely
- –Layout, styling, and component scaffolding
- –The repeated CRUD slice, once one exists by hand
- –Migrations, seed data, throwaway scripts
- –Copy drafts, empty states, loading states
- –Anything you would happily delete and redo
⚠ Generate, then read every line
- –Auth, permissions, and tenant scoping
- –Money: totals, taxes, refunds, invoices
- –Anything a user acts on medically or legally
- –File uploads and other trust boundaries
- –Anything irreversible, including deletes
A note on the right-hand column
Nothing there says “do not use AI.” It says the output stops being a draft and starts being a proposal. You still write the WHERE clause. You just read the one it wrote first, and know why it’s right.
The interesting question was never whether AI can write a website. It obviously can, and will write yours faster than you can read it. What you’re still responsible for hasn’t changed: knowing what should exist, what must not be got wrong, and being the person who checks.