Short answer: Vibe coding tools such as Lovable, Bolt, Cursor and Claude Code can produce a clickable prototype, an internal tool for a small team, or a landing page with a working form within days. They fall short when the product needs real authentication, a data model that can grow, access rules per customer, and someone accountable for the code a year from now. Use them to test an idea, and hand off before real customer data goes in.
Key takeaways
- Where the term comes from: Andrej Karpathy coined "vibe coding" in February 2025, and Collins Dictionary named it its word of the year for 2025.
- Two families of tools: Lovable and Bolt generate whole apps from a chat in the browser, while Cursor and Claude Code work inside an existing codebase.
- Security is the weak spot: Veracode's 2025 test of more than 100 language models on 80 coding tasks found security flaws in 45% of the generated samples.
- A documented incident: CVE-2025-48757 describes insufficient Row-Level Security in Lovable-generated sites through April 15, 2025, letting unauthenticated users read or write database tables; Lovable disputes the classification.
What vibe coding tools build well
Results are strongest when scope is narrow and stakes are low: an investor demo, a form that saves to a table, a dashboard over test data, a one-off script. For a founder, a working prototype replaces a slide deck in early user interviews and shows fast which screens people use. It also turns a vague brief into something an engineering team can estimate, which is the job of a specification written before development.
Cursor and Claude Code belong to a different category. With an engineer who reads every diff before merging, they shorten real product work. The risk starts when code goes live that nobody reviewed.
Where AI-built prototypes break
| Area | What usually goes wrong |
|---|---|
| Authentication | Login works in the demo, but password reset, session handling and roles are partial or missing |
| Data model | Tables shaped around the first screens; a second customer type means rewriting them |
| Database access rules | Policies missing or too broad, so one user can query another user's records |
| Secrets | API keys placed in front-end code, readable by anyone with a browser |
| Maintenance | No tests, no change history the team understands, nobody who can explain the code |
Check permissions first. For separating one customer's data from another's, see roles and permissions in SaaS, and the mobile side of the same risks in mobile app security practices.
