Vibe coding is the fastest way to get from an idea to something you can click, and the fastest way to ship a security hole without noticing. Both are true at once, which is what makes it worth understanding properly rather than picking a side.
The useful framing is not whether it works. It is which parts of a build it handles and which parts it silently skips.
What Is It Actually Good At?
Four things, and they are not small.
The first is the blank page. Getting from nothing to a running skeleton used to absorb a day of setup, and now it takes minutes. That matters more than it sounds, because most ideas die in the gap between having them and seeing them.
The second is interface work. Layouts, forms, tables, empty states, responsive behaviour across 3 breakpoints. This is exactly the kind of code that is tedious to write, easy to verify by looking, and low-risk if it is wrong. You can see a broken layout.
The third is unfamiliar syntax. If you know what you want but not how a particular library expresses it, the tool closes that gap instantly and you learn the pattern by reading the result.
The fourth is throwaway work. Scripts, one-off data transforms, internal tools that 3 people will use. The cost of a subtle bug is low and the time saved is real.
Where Does It Break?
On everything you cannot see by looking at the screen.
| Area | What you see | What may be true |
|---|---|---|
| Authentication | A working login | Sessions that never expire, or tokens in local storage |
| Access rules | Your own data loads | Any logged-in user can read any other user’s records |
| Input handling | The form submits | No validation on the server, only in the browser |
| Database queries | Fast with 20 rows | A query per row, unusable at 20,000 |
| Money | The total looks right | Floating point on currency, rounding drift |
| Errors | The happy path works | A failed request leaves the user staring at nothing |
Notice the pattern. Every row produces a screen that behaves correctly during a demo. That is the specific danger: the feedback signal vibe coding relies on, does it look right, is blind to the entire category of problems that cost you later.
Access rules are the one that bites hardest. A generated app will happily fetch a record by its id, and if nothing checks whether this user is allowed that record, changing 1 digit in the URL walks straight into someone else’s data. OWASP has ranked broken access control as the number 1 web application risk since 2021. The screen looks perfect either way.
Why Does It Fail in That Particular Way?
Because it is optimising for what you asked, and you asked for the feature.
If you say “let users upload a profile photo”, a reasonable reading is a working upload. Restricting file types, capping size, stripping metadata, checking the user owns the profile and storing the file somewhere not publicly listable are all unstated. They are not the feature. They are the conditions the feature has to survive.
A senior engineer supplies those from habit without being asked. The model supplies them if prompted and often not otherwise, because nothing in the request implied them and a shorter answer looks more responsive.
So the failure is rarely the model being wrong. It is the request being underspecified in exactly the places where being underspecified is expensive.
How Do You Get Better Output?
Give constraints, not just goals. This single change improves results more than switching tools.
- State the stack and version. Otherwise you get a plausible blend of 3 eras of the same framework.
- Describe the data shape before the feature, so the model is not inventing a schema mid-answer.
- Say what must not change. Without this, refactors arrive uninvited.
- Name the failure cases. Empty state, network failure, duplicate submit, unauthorised user.
- Ask for the security assumptions to be listed, explicitly, as part of the answer.
- Work in small steps. A 400-line answer is unreviewable, so it goes unreviewed.
The last one is the discipline most people skip. Asking for a whole feature at once produces something too large to check, so you check whether it runs instead, which is precisely the weak signal you were trying to avoid relying on.
What Should You Always Check Before Shipping?
- Can a logged-in user reach another user’s data by changing an id in the URL or the request?
- Is validation on the server, or only in the browser where anyone can bypass it?
- Are secrets in the code? API keys committed into the repository are the most common single mistake.
- What happens on failure? Turn off the network and use the app.
- Does it survive volume? Load it with realistic row counts, not 5 test records.
- Is anything money-related using floating point instead of integers or a decimal type?
These 6 take under an hour between them, roughly 10 minutes each, and catch the overwhelming majority of what generated code gets wrong. None of them require you to have written the code yourself, which is the point.
How Do the Tools Differ?
They split into 3 shapes, and picking the wrong shape for the job causes more frustration than picking the wrong brand.
Chat tools give you code to paste. Good for learning and for isolated problems, weak on anything spanning 5 files, because the model cannot see your project and you become the integration layer.
Editor-integrated assistants read your codebase and edit in place. Much stronger on real work, because the context is real. They also make it easy to accept a 200-line change you did not read, which is the main way people get into trouble with them.
Whole-app builders take a description and produce a deployed application with a database and hosting attached. Genuinely remarkable for a prototype in an afternoon, and the category where the invisible-layer problems concentrate hardest, because you never see most of what was created on your behalf.
A reasonable default is an editor-integrated assistant for anything you will maintain, and a whole-app builder for anything you are willing to throw away. The mistake is using the second for the first.
How Much Should You Trust the Explanation?
More than the code, and not completely.
Asking why a choice was made usually produces a genuinely useful answer, because explaining a pattern is something these models do well. It is often the fastest way to learn a framework convention you had not met.
What the explanation will not reliably tell you is what was left out. A model describing its own output describes what is there. The 6 checks above exist precisely because absences do not announce themselves, and an omitted permission check has no line of code to point at.
So read the explanation to understand the design, and run the checks to find the gaps. They are different jobs.
Does This Mean You Should Not Learn to Code?
The opposite, though what you need shifts.
Writing code from a blank file is no longer the scarce skill. Reading code and judging it is, because generation is now effectively free and review is the only remaining bottleneck. Someone who can read a diff and say “this query runs once per row” or “nothing checks ownership here” is more valuable than they were 2 years ago, not less.
That is a different curriculum from the one most people follow. It leans on understanding systems, data, and failure modes rather than memorising syntax, because syntax is the part the tool already does.
If you want a starting point for the tools themselves, the guide to using ChatGPT from Pakistan covers access and setup. OWASP also publishes a Top 10 list of web application security risks, and it is worth 20 minutes because 4 of the 6 checks above map straight onto it.
If you can only do one thing, learn to read what the tool produced and ask why it made each choice. The explanation is usually more instructive than the code.
When Should You Not Use It At All?
Three situations where the maths does not work.
Anything holding other people’s sensitive data, unless somebody who can assess the security reviews it. The cost of being wrong is not a bug, it is a breach, and it lands on the people who trusted you.
Anything where you cannot verify the output. If you would not recognise a wrong answer, speed is not helping you, it is just producing wrong answers faster.
Anything you will have to maintain for years without understanding it. Code you cannot explain is code you cannot fix under pressure, and the pressure always comes at the worst moment.
Common Mistakes to Avoid
- Treating “it runs” as “it works”, when the gap between those is where every real problem lives.
- Requesting whole features at once, producing output too large to review.
- Prompting only the happy path and being surprised by the error states.
- Shipping to real users without checking access rules.
- Letting secrets into the repository because the generated example put them there.
- Skipping the read. If nobody reads it, nobody owns it.
Final Thoughts
Vibe coding is excellent at the visible layer and blind to the invisible one, and almost every disappointment traces back to trusting it outside its range rather than to the tool being bad.
Use it freely for prototypes, interfaces, scripts and unfamiliar syntax. Slow down the moment real data, real money or other people’s accounts are involved, and run the 6 checks before anything ships. Speed is only an advantage when you can tell whether the fast thing was correct.
Building that judgement, rather than collecting tools, is what our Catching Up with AI course is built around, including where vibe coding breaks and how to review what it produces. Details are on the apply page.
Frequently asked questions
What is vibe coding?
Describing what you want in plain language and letting an AI tool write and run the code, judging the result by whether it looks and behaves right rather than by reading the code. It is genuinely useful for prototypes and genuinely risky for anything holding real data.
Is vibe coding actually useful or just hype?
It is useful, and the hype is about scope rather than quality. It compresses the distance between an idea and something you can click, which used to take days. It does not replace knowing what the code does once other people depend on it.
What does it get wrong most often?
The invisible parts: authentication, access rules, input validation, error states, race conditions and anything involving money or permissions. These produce working screens, so nothing looks wrong until it matters.
Do I still need to learn to code?
You need to be able to read code even if you rarely write it from scratch. Reviewing is now the bottleneck skill, because generating is cheap and judging what was generated is not.
Can I use it for a client project?
For prototypes and internal tools, yes. For anything storing customer data or taking payments, only with a real review of the security and data handling first. The tool will not tell you it skipped that.
How do I get better results?
Give it constraints, not just a goal. State the stack, the data shape, what must not change, and what the failure cases are. Most disappointing output traces back to a prompt that specified the happy path and nothing else.