# Vibe Coding > Building software by describing what you want and letting AI write it. What vibe coding is, where it genuinely shines, and where it quietly bites. --- # Vibe Coding A year ago, building a working piece of software meant learning a language, a framework, a terminal, and a hundred small rituals that have nothing to do with your idea. Now you can open a chat window, type "build me a tool that tracks which clients owe me money," and watch running software appear. That shift has a name now: vibe coding. You describe the vibe of what you want, the AI writes the code, and you steer by reacting to what comes out rather than by reading every line. This guide is for people who are not engineers and don't want to become one - founders, operators, writers, anyone with an idea and no patience for a computer science degree. You'll learn what vibe coding actually is and where the term came from, the kinds of work where it's genuinely transformative, and the specific places it lets you down hard. The goal is clear expectations: enough to use it boldly for the right things and back away from the wrong ones before it costs you. The arc is three phases. First, what vibe coding means and what the workflow feels like from the inside - the loop of describe, run, react. Second, where it shines: prototypes, personal tools, learning, throwaway scripts - the zone where getting something running in twenty minutes beats getting it perfect in two weeks. Third, where it bites: the last-mile problem, code you can't debug when it breaks, and the security and maintenance risks that don't show up until later. By the end you'll know which side of that line your project sits on. --- # Describing Software Into Existence ## The name and where it came from The term "vibe coding" came from Andrej Karpathy, a well-known AI researcher, in a short post in early 2025. He described a way of working where you "give in to the vibes, embrace exponentials, and forget that the code even exists." You talk to the AI, accept what it produces, run it, and if something's wrong you describe the problem and let the AI fix it. You're not reading the code. You're reacting to the behavior. The phrase caught on fast because it named something a lot of people were already doing. Worth being clear, though: it's a new term, and people use it loosely. Some mean "I built a whole app without writing a line." Others mean "I let AI write most of it but I still check the important parts." When someone says they vibe-coded something, ask which one they mean. The gap between those two is the whole subject of this guide. ## What the loop actually feels like Strip away the jargon and vibe coding is one loop repeated: 1. **Describe** what you want in plain language. 2. **Run** what the AI gives you. 3. **React** - say what's wrong or what's next, and go back to step one. You never leave that loop. You don't open a textbook between rounds. The AI handles the parts that used to require years of learning: which language to use, how to structure files, what to type into the terminal. Your job shrinks down to two things you're already good at - knowing what you want, and noticing when what you got isn't it. Here's a real exchange, the kind that happens dozens of times in a session: ```text You: Make me a page where I can paste a list of names and it removes duplicates and sorts them alphabetically. AI: [writes the code, shows you a running page] You: Good, but it's treating "Anna" and "anna" as different. They should count as the same. AI: [fixes it, shows the updated page] You: Perfect. Now add a button to copy the cleaned list. ``` Notice what you didn't do. You didn't learn what "case-insensitive comparison" is called. You described the symptom - "Anna and anna should count as the same" - and the AI translated that into the fix. That translation, from human intention to working code, is the entire value of vibe coding. ## The tools people use You don't need to know how these work to start, but it helps to know the shapes they come in: | Kind of tool | What it is | Good for | |---|---|---| | Chat assistants | ChatGPT, Claude, Gemini in a browser | Scripts, snippets, learning, one-off tasks | | Browser builders | Lovable, Bolt, v0, Replit | Whole web apps, no setup, runs in the browser | | Editor agents | Cursor, Windsurf, Claude Code | Bigger projects; closer to real development | The browser builders are where most non-engineers start. You type a description, an app appears in a preview window, and you keep refining it by chatting. There's no install, no terminal, no "set up your environment" - which removes the wall that used to stop people on day one. ## What's really happening underneath The AI isn't thinking about your problem the way you do. It has read an enormous amount of existing code and learned the patterns - what a "remove duplicates" function usually looks like, how a login page is usually built. When you describe what you want, it produces the most likely-looking code for that description. Most of the time, for common requests, that's exactly right, because your request is one a thousand other people have made before. This is also the seed of every problem in phase three. The AI is great at the common case and shaky at the unusual one. It produces code that looks correct and runs - but "looks correct and runs" is not the same as "is correct and safe." For a tool only you will use, that gap rarely matters. For something handling other people's money or data, it matters enormously. For now, hold onto the good part. The describe-run-react loop genuinely collapses the distance between having an idea and holding something that works. That used to take weeks of learning. Now it can take an afternoon. The next phase is about the afternoons where that's exactly the right trade. --- # Where It Shines There's a clean line that tells you when vibe coding is the right call: **how much does it matter if this breaks, and who gets hurt if it does?** When the answer is "not much" and "only me," vibe coding is not a compromise - it's the best tool available, and it's not close. Here's the territory where that's true. ## Prototypes: making the idea visible The hardest part of a new idea isn't building it. It's getting everyone to picture the same thing. You describe an app to a co-founder, a designer, an investor, and three different pictures form in three heads. A working prototype ends the argument. Everyone clicks the same buttons and sees the same thing. Vibe coding is built for this. You can go from "an app where dog owners book walkers in their neighborhood" to a clickable thing - search, listings, a booking screen - in an afternoon. It won't actually book anyone. The payments are fake, the walkers are made up. That's fine. A prototype exists to answer one question: *does this idea feel right when it's real enough to touch?* You'll learn more from ten minutes of someone using a fake version than from a month of describing the real one. And when the feedback is "actually, walkers should set their own prices," you don't rebuild. You describe the change and watch it happen. The cheapness of changing your mind is the whole point. A prototype you're afraid to throw away has already failed. ## Personal tools: software for an audience of one This is the quiet revolution, and it's the use that surprises people most. For your whole life there's been a category of small annoyances too minor to pay a developer for and too fiddly to do by hand forever. A spreadsheet that needs the same cleanup every Monday. A way to rename three hundred photos by the date they were taken. A page that converts your messy meeting notes into a tidy summary. These were never worth building before - the effort dwarfed the annoyance. Now the effort is a paragraph of description. Because *you* are the only user, almost everything that makes software hard disappears. No need to handle a stranger's weird input, no design polish, no security to speak of, no support requests. It runs on your machine, for you, and if it breaks you're the only one inconvenienced. A few that people actually build in an evening: - A tracker for which freelance invoices are unpaid and how late. - A tool that pulls the addresses out of a pile of emails into one clean list. - A dashboard that shows your three bank balances on one screen. - A renamer that fixes a folder of inconsistently named files. None of these would survive contact with the public. They don't have to. They have to work for you, on your data, today. ## Learning: a tutor that builds while it explains If you do want to understand what's happening, vibe coding is a remarkable way in. You can build the thing first, see it work, and then ask the AI to walk you through it - "what does this part do?", "why did you write it this way?", "show me what breaks if I change this." You learn from a running example you care about, instead of from an abstract exercise about a fictional pizza shop. The trap is mistaking *it works* for *I understand it*. Getting a result with no idea why feels like learning and isn't. If learning is the goal, slow the loop down on purpose: read the explanation, change one thing, predict what'll happen, then run it. The friction is the point. ## Throwaway scripts: use once, delete A huge amount of real work is one-time grunt work. Merge forty spreadsheets. Find every customer who hasn't logged in since March. Resize a hundred images at once. Pull one number out of a thousand PDFs. These are perfect for vibe coding precisely because they're disposable. You describe the task, run the script, get your answer, and never touch it again. It doesn't need to be maintainable, secure, or elegant - it needs to run once and be right once. You can check that yourself: does the merged file have the right number of rows? Did the customer list look sane? If the answer's there and it's correct, the script has done its entire job. Throw it away. ## The thread that connects them Look at what these four have in common. The stakes are low. The audience is you or a handful of trusted people. A mistake is an annoyance, not a disaster. And you can verify the result by looking at it - you don't need to trust code you can't read, because you can see whether the output is right. That last point is the quiet test for the whole category. **If you can tell whether it worked by looking at the result, vibe coding is on solid ground.** The moment you're trusting code you can't read to do something you can't directly check - handling real payments, storing other people's data, running without you watching - you've stepped off it. That's the next phase. --- # Where It Bites Everything in the last phase was true. The bites in this one are also true, and they're the part the demos never show - because they don't appear in the first hour. They appear in week three, when the thing is live, when something breaks, or when someone you weren't expecting tries to use it. ## The last-mile problem Vibe coding gets you to eighty percent stunningly fast. The first afternoon feels like magic - a real app, working, from a paragraph. Then you spend the next three weeks on the last twenty percent, and that part doesn't feel like magic at all. Here's why. The eighty percent is the common case: the parts a thousand other apps already have, so the AI has seen them a thousand times. The last twenty is *your* specifics - the one weird rule your business has, the edge case where two users do the same thing at once, the exact thing your customer demands that nobody else needed. The AI hasn't seen those patterns as often, so it guesses, and the guesses get worse the further you are from the well-trodden path. The cruel shape of it: progress feels fast right up until it stops. You ask for a fix, the AI changes something, and now two other things are broken. You fix those, the first thing comes back. Without being able to read the code, you're negotiating with a system you can't see inside, and each round can dig the hole deeper. This is the wall most ambitious vibe-coding projects hit. Going from "impressive demo" to "thing real people depend on" is not the same kind of work as the demo, and it doesn't get the same kind of speedup. ## Code you can't debug When you can't read the code, every problem becomes a guessing game. The app was working; now it isn't; you don't know why; and your only move is to describe the symptom and hope. Sometimes the AI fixes it in one shot. Sometimes it confidently changes the wrong thing, and you can't tell, because you can't read what it did. It gets worse as the project grows. Early on the AI can hold the whole thing in view. As it gets bigger, a fix in one corner silently breaks another, and the AI loses the thread the same way you have - except you can't step in, because stepping in requires reading code. You end up in a loop where each "fix" trades one bug for another and the thing slowly degrades. A grounding fact: AI writes code that *looks* right far more reliably than code that *is* right. It's fluent. Fluent and correct are different things, and from the outside they're nearly impossible to tell apart. That's exactly why this category is dangerous - the failures don't announce themselves. ## Security and maintenance: the bites that wait These are the worst ones, because they're invisible until the damage is done. **Security.** AI happily writes code with serious holes in it, and it looks completely normal. The classic disaster: a vibe-coded app where every user's private data sits behind a check that isn't actually there, or where the "secret" password to the admin panel is sitting in plain text anyone can read. There were real, public cases in 2025 of vibe-coded apps leaking user data and racking up surprise bills because nobody checked the boring parts. You won't see these by looking at the app - it works fine. They surface when someone with bad intentions looks where you didn't. A short list of what quietly goes wrong: | Risk | What it looks like | When it bites | |---|---|---| | Exposed secrets | Passwords or keys written into the code | When the code is shared or hosted publicly | | No access checks | Any user can reach anyone's data | When a stranger pokes at the URLs | | Runaway costs | A loop that calls a paid service forever | When the bill arrives | | Unchecked input | The app trusts whatever it's given | When someone feeds it something hostile | **Maintenance.** Software is never finished - the world underneath it shifts. A service it depends on changes, a payment provider updates its rules, a security hole is discovered in a piece you used. Real software needs upkeep. With code you can't read or change yourself, every bit of upkeep means going back to the AI and hoping it doesn't break three other things on the way. A personal tool can rot quietly; nobody's watching. Anything other people rely on can't. ## When to slow down and learn None of this means don't vibe-code. It means know which thing you're building and match your caution to the stakes. A useful gut check: - **Will strangers use it?** Then someone has to understand the security. Not vibe-coded-and-shipped. - **Does it touch money, or personal data, or anyone's safety?** Slow down. Get a real developer to look, or learn enough to check it yourself. - **Will it need to keep running for months?** Someone has to maintain it. Plan for who. - **Is it only for you, or a quick experiment?** Go fast. This is exactly the right tool. Enjoy it. The plain summary: vibe coding is a genuine breakthrough for prototypes, personal tools, learning, and disposable scripts - and a quiet trap for anything important enough to hurt people when it fails. The skill isn't writing the perfect prompt. It's telling the two apart, every single time, and being clear with yourself about which one you're holding.