What is vibe coding? It is building software by describing what you want to an AI in plain English, letting it write the code, and judging the result by running it instead of reading it. Andrej Karpathy coined the term in early February 2025 [1]. The method that keeps a vibe-coded app working is short: build in small slices, test every change, keep a version you can return to, keep secrets out of your prompts, and check who can see the data before anyone else signs in.
What is vibe coding, and what it isn't
Karpathy described a way of coding where you give in to the vibes and forget the code even exists. In his post he accepted every change without reading the diffs, pasted error messages back with no comment, and asked for random changes when a bug would not go away. His own verdict was that it was not too bad for throwaway weekend projects. Collins English Dictionary later named it its Word of the Year for 2025 [1].
Simon Willison drew a useful line. Vibe coding means building software with an AI without reviewing the code it writes. If you review the output, test it thoroughly and can explain how it works, that is ordinary software development with an AI helper [2]. Most people who build their first app this way will not read every line. That is fine, as long as checks you can actually run take the place of the reading.
One more boundary. If you are a developer picking an AI assistant inside your code editor, that is its own world with its own trade-offs. This guide is for the founder, freelancer, ops lead or agency owner who needs a working app and has no developer time to spare.
Where vibe coding shines and where it bites
It shines on software for one team: a quote calculator, a job tracker for a small crew, a page that tests whether an idea gets sign-ups, a dashboard over numbers you already have. Willison's test is simple. Keep the stakes low. Ask how much harm a bug or a security hole could do, and to whom. If the honest answer is nobody, let the AI rip and enjoy the speed.
It bites when other people's data, money or logins enter the picture. Veracode's spring 2026 tests found that AI models now write syntactically correct code more than 95% of the time, yet only about 55% of the generation tasks produced secure code when nobody asked for security [3]. That gap is the trap. A vibe-coded app looks finished because it works. Whether strangers can read your customers' records is a separate question, and the preview never answers it.
Have the AI describe what it will build and change before it writes code. Correcting a plan is faster than undoing a finished screen.
How to vibe code an app that keeps working
The habits below replace line-by-line reading with checks anyone can run. They work in a free chat canvas and in a full app builder alike.
- Write a one-paragraph brief first. Who uses the app, what they do in it, what data it keeps, and who may see which records.
- Ask for a plan before any code. Read the plan, correct it, then let the AI build. A wrong assumption costs far less to fix in a plan than in a finished screen.
- Build one slice at a time. A form, then a list, then sign-in. Never the whole app in one prompt.
- Test each change like a user. Click through the new part, enter wrong values, refresh the page, try it on a phone.
- Save a working version before every risky change. Find out what a restore brings back. In many builders it restores the code but not the data, so export your records before you change how they are stored.
- Read what the AI says it changed. If it touched parts you never mentioned, stop and ask why before you continue.
- Break fix loops early. After two failed fixes, restore the last version that worked and ask again with a smaller request.
If you want to try this today with nothing to install, our step-by-step guide to vibe coding a one-page tool walks through a free chat canvas from the first prompt to the point where it stops.
Prompt for one slice, click through it like a user, then save a version. Only then ask for the next slice.
Vibe coding prompts that hold up
Good prompts read like a short work order. Name the goal, the person using the screen, the data involved and what done looks like. Then add two guardrails: ask the AI to list what it will change before it changes anything, and tell it which parts it must leave alone. Short follow-ups beat long rewrites. When something breaks, describe what you clicked, what you expected and what happened instead.
| Instead of | Try |
|---|---|
| Build me a CRM | Build a contact list for a two-person agency: name, company, stage, next step. Only the list and an add form for now. |
| Fix it | When I click Save on an empty form, the page goes blank. It should show a message under the name field. |
| Make it secure | List who can read and edit each table right now, then explain how a signed-out visitor would see this page. |
| Add everything from the plan | Do step 2 of the plan only, then tell me which files you changed. |
The slices look like this in practice, shown as an illustration with invented inputs. A six-person cleaning crew wants a job-request app. Slice one is a request form and a shared list. Slice two adds a status for each job: new, scheduled, done. Slice three adds sign-in, so each cleaner sees only their own jobs. Slice four adds a weekly summary for the owner. Each slice gets tested and saved before the next one starts.
Vibe coding security: checks before anyone else signs in
Catching the most common problems takes no code reading. You need to look at the app the way a stranger would.
- Keep keys out of the chat. API keys and passwords belong in the builder's secrets store, never pasted into a prompt or written into the page.
- Find out what is public by default. Ask the AI which pages and tables a signed-out visitor can reach, then check for yourself.
- Test sign-in as a stranger. Open a private browser window, create a second account and try to open the first account's records.
- Treat hidden as visible. Hiding a button or a column does not stop anyone from reading the data behind it. Access rules on the data do.
- Run the built-in scan, then keep thinking. Builders that offer a security scan describe it as a first check, not a full security review.
- Watch anything billed by use. An AI feature or paid service wired into a public page can run up charges when strangers find it.
Sensitive data needs extra care. Lovable and Base44 both say they are not HIPAA compliant and sign no BAA, so check that before any health records go near an app built there. If clients' confidential material is involved, get a second pair of experienced eyes before launch.
In many builders, rolling back a version brings back the code but leaves the live database as it is. Export your records before risky changes.
Common vibe coding mistakes
Most failed vibe-coded apps fail in the same few ways. None of them needs coding skill to avoid. They need patience and a habit of checking.
- One giant prompt. The AI fills every gap with guesses, and you cannot tell which guess broke what.
- Accepting everything on an app other people use. Karpathy's style was meant for weekend experiments, not for client data.
- Fix-it spirals. Each new fix adds code on top of the last broken attempt. Restoring is faster.
- Forgetting the data in a rollback. The code goes back. Records you deleted or changed may not.
- Launching without a stranger test. Your own account sees everything, so it can never show you a leak.
When it gets hard, and tools that do it for you
A chat canvas runs out of road when the app needs a real database several people share, sign-in, its own web address and a way to undo changes safely. Prompt-to-app builders add those layers around the same habits. Lovable lines up most closely with habit 2: its Plan mode is where you correct the plan before it touches any code, so a wrong guess about which cleaner sees which jobs gets caught before it is built.
You describe the app; Plan mode inspects the project and writes an editable plan before any code changes, every change is saved as a version, and a Quick scan checks database access rules at each publish.
Replit carries more of the testing load on its own. Its Agent plans, builds and tests the app in a real browser, which takes part of habit 4 off your hands, though the stranger test with a second account is still yours to run.
Replit's Agent plans, writes and tests the app, then publishes it; checkpoints save files, conversation and database state, and an API key pasted into a prompt is redirected to encrypted Secrets.
Bolt.new suits anyone prone to fix-it spirals. Because it saves a version after every prompt, going back to the last build that worked is quicker than a third attempt at a fix.
Plan Mode asks questions before changing code, a version is saved after every prompt so you can restore a working build instead of retrying fixes, and keys kept in Secrets never reach browser code.
One caveat runs through all three: restoring code does not roll back the live database, so export first, exactly as habit 5 says. The method stays the same whichever builder you pick. For how each one covers the code, the data, sign-in and hosting, see our comparison of vibe coding tools.
Frequently asked questions
Do you need to know how to code to vibe code?+
No. You describe what you want and test the result. What you do need is the habit of checking: small steps, testing each change, and looking at the app the way a stranger would.
Is vibe coding the same as no-code?+
Not quite. Vibe coding has an AI write real code from your prompts. Classic no-code tools have you assemble an app from visual blocks, and some now add an AI that builds those blocks for you.
Can a vibe-coded app go into production?+
It can, if you add what production needs: a shared database, sign-in, access rules on the data, a way to undo changes and a security check before launch. Without those, keep it as a prototype or a tool for yourself.
Can you vibe code for free?+
Yes. A chat assistant's build canvas is enough for a one-page tool you use yourself. Once several people need shared data, sign-in or their own web address, move to a prompt-to-app builder; Lovable and Bolt.new have a Free plan and Replit has its free Starter plan.
From weekend experiment to an app strangers can sign in to
Describing an app, letting the AI write it and judging it by running it is a real way to build. It turns risky the moment strangers, money or private data arrive, because a working preview says nothing about who can read your records. Keep it safe with small slices, a plan before code, a saved version before every risky change, keys out of prompts and a sign-in test as a stranger. Do that, and a vibe-coded app can keep working long after the first weekend.
- [1] Wikipedia (Nov 2026) https://en.wikipedia.org/wiki/Vibe_coding
- [2] Simon Willison's Weblog (Nov 2026) https://simonwillison.net/2025/Mar/19/vibe-coding/
- [3] Veracode (Nov 2026) https://www.veracode.com/blog/spring-2026-genai-code-security/