What Is Vibe Coding? (And When It Works)
Vibe coding means describing what you want in plain language and letting an AI build it, accepting the code without reading every line.
Key takeaways
Vibe coding means describing what you want in plain language and letting an AI build it, accepting the code without reading every line.
On this page
The term "vibe coding" went viral in 2025, and like most viral terms it gets used to mean three different things depending on who's talking. So let's pin it down.
Vibe coding is building software by describing what you want in natural language and letting an AI assistant generate and iterate on the code, while you accept most of that code without reading every line. You steer by feel. You run the thing, look at the result, and describe the next change. You are coding by vibes, not by carefully tracking every function the model wrote.
That last part is what makes it distinct. Using an AI assistant to write a function you then read, understand, and edit is just modern development. Vibe coding is the mode where you deliberately stop reading closely and trust the loop to converge. That trust is exactly what makes it powerful in some places and reckless in others.
How it works in practice#
The loop is simple, which is most of the appeal:
- Prompt: You describe what you want in plain language.
- Generate: The assistant writes the code.
- Run: You execute it and see what happens.
- Describe the next change: You tell the assistant what's wrong or what to add, and it revises.
Then you go back to step 2 and repeat until the thing behaves the way you want.
Here's a concrete example. Say you want a script to rename a folder of photos by their capture date:
Tweet this ↗You: Write a Python script that renames every JPG in a folder to its EXIF capture date, like
2026-08-21_001.jpg.Assistant: (generates a script using a library to read EXIF data)
You: It crashed on files with no EXIF data. Skip those and print a warning instead.
Assistant: (adds a try/except and a counter)
You: Good. Now also handle PNG and HEIC.
You never opened the EXIF library docs. You never checked the exact exception type. You described outcomes and the model closed the gap. For a personal script that sorts your own photos, that is a completely reasonable way to work.
Where vibe coding genuinely shines#
Vibe coding is at its best when the cost of a bug is low and the code has a short shelf life:
- Prototypes and spikes: You're testing whether an idea is worth building at all. Speed beats correctness.
- Throwaway scripts: One-off data cleanups, file renamers, quick automations you'll run once.
- MVPs and demos: Something to put in front of users or a stakeholder to get a reaction.
- Learning: Seeing a working example of an unfamiliar API or framework, then poking at it.
- Non-critical internal tools: A dashboard three people use, where a glitch is an annoyance, not an incident.
- Hackathons: Where the whole point is to ship something impressive in 24 hours.
The common thread: nobody's data, money, or safety is on the line, and you can throw the code away if it disappoints you.
Where it's dangerous#
The same loop that feels magical in a hackathon becomes a liability the moment the stakes rise:
- Production systems that real users depend on.
- Security-sensitive code: auth, payments, anything touching personal data or secrets.
- Anything you have to maintain for months or years.
The problem is structural, not a matter of prompting harder. When you accept code you didn't read, you ship flaws you don't know are there, and you can't reason about a system you never understood. The bill comes due later, usually at the worst time.
The honest risks#
Vibe coding fails in specific, repeatable ways:
- Security holes: Models happily generate SQL string concatenation, missing input validation, and hardcoded credentials. They look fine and run fine. We cover this in depth in securing AI-generated code.
- Silent bugs: The code runs, returns something plausible, and is quietly wrong. No crash to tip you off.
- Unmaintainable code: Inconsistent patterns, duplicated logic, and no mental model in your head to guide changes. The next feature takes longer than writing it fresh would have.
- "It works until it doesn't": The happy path works in the demo. The edge case that only shows up at scale takes the whole thing down.
- Package hallucination: Assistants sometimes import libraries that don't exist. Attackers have started registering those hallucinated names with malware, so a made-up
importcan become a real supply-chain attack.
Doing it responsibly#
You don't have to choose between vibe coding and never touching an AI assistant. You just have to match the method to the stakes:
- Review before merge. The moment code is headed anywhere real, read it. This is the single line that separates safe from sorry.
- Write tests. If you didn't write the logic, you need something else that checks the logic. Tests are how you trust code you didn't author.
- Scope it to low-stakes work. Keep pure vibe coding in the prototype and throwaway lane. That's not a limitation, that's using it correctly.
- Graduate to spec-driven development for anything you'll keep. Writing a clear spec first gives the assistant real constraints and gives you something to check the output against. More on that in spec-driven development.
When to vibe code vs. not#
Vibe code it: prototype, spike, throwaway script, demo, learning exercise, hackathon, internal tool nobody depends on. Low blast radius, short lifespan, your own data.
Don't vibe code it: production services, authentication, payments, anything handling user data, anything a teammate will maintain, anything with a compliance or safety dimension. High blast radius, long lifespan, someone else's trust.
The dividing line is simple: what happens when this breaks, and who has to clean it up?
The call we'd make#
Vibe coding is a real, useful mode, not a fad and not a fraud. It collapses the distance between an idea and a working thing, and for prototypes and throwaways that is a genuine superpower. Use it there without guilt.
But it is a starting mode, not a finishing one. The instant code stops being disposable, the rules change: you read it, you test it, you own it. The engineers who get burned aren't the ones who vibe code, they're the ones who forget to stop. Treat the loop as a fast first draft, pick the right assistant for the job from our roundup of the best AI coding assistants, and graduate to a spec the moment the work gets real.
Get the DevOps Troubleshooting Cheat Sheet
Subscribe and get our free one-page reference for the errors that eat an afternoon — CrashLoopBackOff, OOMKilled, Terraform state locks, and more — plus new guides as we publish them.
AI Security — Securing LLM and Agent Apps in 2026
AI apps add a new attack surface on top of the old ones. This is the map: the threats unique to LLMs and agents, and the controls that actually contain them.
How DNS Works (Explained Simply)
A developer-friendly walk through DNS resolution, record types, TTL, and the caching quirks that cause real production bugs.
More from AI
Explore more articles in this category
AI CLI Agents in CI: Claude Code vs Codex CLI vs Gemini CLI
Running a coding agent on a laptop is a preference. Running one in a pipeline is an architecture decision about credentials, sandboxing, and non-interactive failure.
Best Vector Databases in 2026: Do You Even Need One?
Most teams shipping retrieval do not need a dedicated vector database. Here is where Postgres runs out, and which specialist actually helps when it does.
Three LLM Providers, One Cloud Region: The September 3 Outage
ChatGPT, Claude, and Grok degraded together when Azure East US failed. Gemini stayed up. Multi-provider failover does not help when your providers share a substrate.
You might have missed
Evergreen posts worth revisiting.