# What is vibe coding, and when should you use it? **Author:** Ivan Misic **Published:** 2026-01-23 **URL:** https://ivanmisic.net/blog/ai-tools/what-is-vibe-coding **In plain English** Pure vibe coding means accepting AI-generated software without reviewing or understanding the implementation. Use it for disposable experiments where failure is cheap and reversible, not for software handling money, personal data, credentials, or a business process. Once you review the plan and code, test the important behavior and security boundaries, keep version history, and can explain the result, you are doing AI-assisted software development. Someone still needs to own what ships. Vibe coding is useful for a disposable experiment you can inspect from the outside. It is a bad operating model for software that handles money, personal data, or a business process. The boundary is simple. If failure is cheap and reversible, try it. If the software matters after the experiment, someone needs to understand the important choices and own the result. ## Where the term came from In February 2025, AI researcher Andrej Karpathy described a way of building software where you “fully give in to the vibes” and forget that the code exists. You describe what you want, let the model write it, paste errors back, and keep going without reviewing the implementation. [Collins Dictionary named vibe coding its 2025 Word of the Year](https://www.collinsdictionary.com/de/woty). The phrase became broader as it spread, but the original meaning is worth keeping. [Simon Willison draws the useful line](https://simonwillison.net/2025/Mar/19/vibe-coding/): if you review, test, and can explain the generated code, you are doing software development with AI assistance. Pure vibe coding means accepting code without understanding it. That distinction changes where I would use it. ## Start where failure is cheap A disposable personal experiment is a good fit. So is a static prototype you can check in a browser and throw away when it has answered the question. Keep personal data, credentials, payments, and real customer workflows out of it. A static site reduces backend risk, but forms, third-party scripts, deployment settings, and published files still need review. Working with the model can feel a bit like a PM working with an engineer. The difference is that the model does not own the result when security, maintenance, or deployment goes wrong. For anything you intend to keep, someone must understand the important choices, review the code, and own the result. ## Know what changes the risk The first version is usually the easy part. Risk appears when the experiment collects real data, receives users, connects to another system, or becomes something a business depends on. Access control is one example. In 2025, a researcher reported missing or insufficient row-level security across more than 170 Lovable-built apps in a scan of 1,645. [CVE-2025-48757](https://nvd.nist.gov/vuln/detail/CVE-2025-48757) describes unauthorized access in affected generated sites and records that the supplier disputed responsibility. The lesson is narrower than “AI code is insecure.” Generated applications still need explicit access-control and security review. Lovable's own [security guidance](https://docs.lovable.dev/features/security) says its scanners cannot guarantee complete security and recommends professional review for sensitive or critical applications. If you are working in Claude Code, some of that review is one command away. `/security-review` checks the current changes for vulnerabilities and reports what it finds. It is not a substitute for someone who understands your threat model, but it catches the ordinary mistakes, and running it costs less than the argument about whether you needed to. Vibe coding your payment processor? Please don't. Use pure vibe coding where failure is cheap and reversible. Once the software matters, move to a reviewed workflow with tests, version control, and someone who can explain the implementation. ## From vibe coding to a reviewed build Once you review the plan, test the result, and keep recoverable versions, you have moved beyond pure vibe coding. Good. Keep working that way. The label matters less than knowing when the experiment became software you intend to maintain. 1. **Plan:** Decide what you are building and what is outside the first version. 2. **Build:** Describe the result, constraints, and files the model may change. 3. **Review:** Inspect the output and give specific feedback. 4. **Test:** Check the behavior, security boundaries, and failure cases that matter. 5. **Save:** Use version control so you can inspect and undo changes. 6. **Ship:** Publish only the version you reviewed. By this point, you know how to give Claude Code a bounded task, add project rules, and review what it changed. You do not need to write every line yourself. You do need a way to decide whether the result is correct. Claude Code wrote the first versions of this site's code. I decided what to build, reviewed the changes, tested the result, and kept correcting it. By Willison's definition, that is AI-assisted software development rather than pure vibe coding. I am comfortable with that distinction.