Vibe Coding a Prototype in One Day: When It Fits, When It Is Dangerous
Vibe coding can give you a working prototype in a day, and also a fast route to security holes and technical debt. This article says when to use it, when to stop, a one-day plan and a checklist before a prototype becomes a product.
For product people, programmers and newcomers trying to build apps with AI. Every technical term gets a short explanation.
Figures come from public sources listed at the end; many were published by security vendors or the press, so read them with care. The character "Lan" is an illustration rebuilt to be easy to picture, not a real person.
Quick summary#
- Vibe coding means letting AI write code without reading it closely. It is a good fit for a throwaway prototype made in a day.
- It becomes dangerous with real users, personal data, login or money, because bugs tend to sit exactly where nobody reads.
- Rule of thumb: who bears the consequences? Only you, relax. Other people, then read, test and check security.
- A one-day plan has five legs: ask the problem, sketch the screens, build the frame, add fake data, let real people try it.
- At day's end you must decide: drop, rewrite or harden. Do not let a prototype quietly become a product.
Hard words, plain meaning#
| Term | Plain meaning |
|---|---|
| Vibe coding | Describe what you want in words, let AI write the code, run it, ask AI to fix what breaks, without reading the code closely. |
| Prototype | A trial version to test an idea, not yet a product. |
| MVP | A version small enough to put in front of real users, but solid enough for them to trust. |
| Technical debt | What you rushed today and pay back later in fixing time. |
| Row level security (RLS) | A database rule saying each person can read only their own rows of data. |
| Throwaway | Disposable. Built to learn, not to keep. |
1. What vibe coding is, and where the line sits#
The term comes from a post by Andrej Karpathy around early February 2025: let AI write everything, go with the "vibes", and do not worry about what the code looks like. Since then many people use the word for any AI-assisted programming.
Simon Willison draws a clearer line: if you review, test and can explain the code, it is AI-assisted programming, not vibe coding. In his framing, vibe coding fits personal tools where only you bear the consequences, and does not fit code other people depend on. I am relying on his public writing and have not re-checked each original sentence.
In this article, vibe coding means running without reading. That is not bad in itself. What is bad is carrying it to a place that needs reading.
2. Why one day is enough for a prototype#
A prototype's value is not the code but the answer you get from real people: do they understand it, do they need it, where do they get stuck. When AI cuts the frame-building from weeks to hours, you can try several directions before choosing one.
This is most true when:
- The cost of failure is low, because there is no real data or money.
- The aim is to learn, not to deliver.
- You can drop it without regret.
3. When to vibe code#
| Situation | Why it is fine |
|---|---|
| Testing an idea with 5 to 10 people | Dropped after a week of trying. The goal is understanding, not keeping. |
| A demo for clients or teammates | They need to see and touch it, not rely on it. |
| A personal tool (automating your own chore) | Only you bear the consequences. |
| Exploring several interface directions | Cheaper than arguing in a meeting. |
| Learning a new idea | Watch AI do it, then read back the good parts. |
4. When it is dangerous#
| Situation | Why it is dangerous |
|---|---|
| Login and permissions | A bug here is a bug that exposes other people's data. |
| Personal or sensitive data | A leak has legal and trust consequences. |
| Payments, refunds, balances | One wrong line loses real money. |
| Many users, long life | Small bugs repeat into big ones, hard to fix because nobody understands the code. |
| Integration with company systems | One bug can spread to other systems. |
A real example. CVE-2025-48757 is a flaw tied to missing or weak row level security policies in apps generated by Lovable, an AI app-building tool. According to Superblocks' analysis, more than 170 apps were affected, with data tables readable without logging in. Researcher Matt Palmer reported it to Lovable on 21 March 2025. The count comes from a third-party vendor, so treat it as a reference figure and check the CVE record if you need to.
You can read this two ways: the tool is imperfect, and users had not read the access-control part because it does not show up when you click around. In vibe coding, the part that runs is visible, while the part about who may read what is not.
A small third-party survey (VibeWrench, March 2026, 100 vibe-coded apps) also reported many apps lacking basic protections. I have not verified it independently, so I do not quote individual figures.
5. A one-day plan, five legs#
An illustrative example with a rebuilt character.
Lan is a product manager who wants to test the idea "a team meeting scheduler with no email". She spends one day.
| Time | Work | Output |
|---|---|---|
| 8:30 to 9:30 | Ask the problem. Write three sentences: who has the problem, what they do now, what success looks like. | A one-page sheet |
| 9:30 to 11:00 | Sketch the screens. Draw three screens by hand and describe them to AI. | Three sketches |
| 11:00 to 13:00 | Build the frame. Ask AI for the main screen, with fake data. | A version running locally |
| 14:00 to 16:00 | Add fake data and a few odd cases. Empty list, long names, network errors. | A version fit to show |
| 16:00 to 17:30 | Let 3 to 5 people try it. Note where they get stuck. | Feedback notes |
| 17:30 to 18:00 | Decide. Drop, rewrite or harden. | A one-line decision |
What Lan did right: no real data, no login, no money, and she wrote "PROTOTYPE, dropped on 15 November" on the first screen. What she gained was an answer: two of five testers did not understand the word "team", and all five wanted to see the calendar on a phone.
6. From prototype to product: a checklist#
If you decide to keep it, add no users before it passes all of these.
- Login and permissions. Who can read whose data? Log in with another account and look.
- Database access. Does every table have a row-limiting policy? Try to access without logging in.
- Inputs. Is every input field checked?
- Secrets. Are API keys or passwords in the code, files or Git history?
- Tests. Are there tests for the main path and a few odd cases? Do they fail when the code is wrong?
- Libraries. Is every library real and still maintained?
- Backups and recovery. Is data backed up, and has restoring been tried?
- A reader. Has at least one person read the code and understood it?
A fuller list is in Reviewing AI-written code. Many teams choose to rewrite the core and keep the interface and the lessons from the prototype. That is often cleaner than patching spot by spot.
7. Three habits that make vibe coding safer#
- Set a deadline. Write the drop date on the screen. A prototype with no drop date becomes a product.
- Use fake data. Do not put customers' real data into an unchecked tool.
- Keep the boundary away from real systems. A prototype does not connect to a real database, payments or company systems.
8. A balanced view#
- Vibe coding is not always fast. METR's study (July 2025) of 16 experienced developers found them about 19% slower with early-2025 AI tools on familiar projects, even though they believed they were faster. The sample is small and tools have changed, but feeling fast is not a measurement.
- "Almost right" is the most annoying. The Stack Overflow 2025 survey found about 66% of users hit "almost right but not quite" solutions, and about 45% said debugging AI-written code takes longer. When you do not read the code, it is hard to know where the "not quite" is.
- The loop of "ask for a fix, then it breaks again". One blogger calls it an infinite loop of re-prompting, where each fix creates a new error. That is a sign to stop and read the code.
- The tools are improving. These limits may change, but the thinking about who bears the consequences still holds.
9. Conclusion#
Vibe coding is the cheapest way to learn whether your idea is worth building. It is most dangerous when it forgets it is only a prototype. Use it for what you can throw away, write the drop date, and use the checklist before anyone else depends on it.
Try it now: write three sentences about a problem of yours, build one screen with AI, and find three people to look at it the same day.
References#
Frequently asked questions
- What is vibe coding and how is it different from AI-assisted programming?
- In the original sense set by Andrej Karpathy in February 2025, vibe coding means letting AI write everything and not reading the code closely. Simon Willison stresses that if you review, test and can explain the code, that is AI-assisted programming, not vibe coding. The line is whether you examine it.
- When should you vibe code a prototype?
- When the product is disposable and only you or a few acquaintances bear the consequences: testing an idea, a demo, a personal tool, exploring several interface directions. With no real data, login or money, mistakes are still cheap.
- When is vibe coding dangerous?
- When there are real users, personal data, login, payments, or many people using it. For example, CVE-2025-48757 concerns missing row level security policies in apps generated by the Lovable tool, and a security firm reported more than 170 affected apps. That figure comes from a third party, so read it with care.
- How do you turn a prototype into a safe product?
- Decide clearly: rewrite or harden. If hardening, go through a checklist covering login and permissions, input checks, secrets and keys, tests, logging, backups and limited data access, then have someone who reads code review it. Many teams rewrite the core and keep the interface and the lessons.