What Is Vibe Coding?
The definition, honest credit for what it does well, and a plain account of where it fails. Most of the code behind my own products is written by a model, so this is neither a warning against the tools nor a pitch for them.
Vibe coding is building software by describing what you want to an AI and accepting the code it produces largely without reading it. Andrej Karpathy coined the term in early 2025 for the practice of letting the model write while you judge the result by whether it runs. Oleg Sotnikov, a fractional CTO who ships production systems with AI every day, treats it as a fast way to reach a working prototype and a poor way to reach a maintainable product. Which of the two you end up with depends on the engineering discipline built around the model.
Where the Term Came From
Andrej Karpathy described the practice in early 2025: you talk to the model, take what it hands back, and barely look at the code. He was writing about his own weekend projects and said plainly that this was not how to build something serious. The name stuck anyway, because it gave people a word for something they were already doing quietly.
It spread for one reason. The models got good enough that someone with no programming background could describe a small app and watch it appear in a browser tab a few minutes later. The distance between what used to need a developer and what now needs a paragraph is exactly what the phrase names.
Two meanings now travel under the same label. There is Karpathy's original one, a quick and disposable way to explore an idea. And there is what people usually mean when the phrase comes up in a business conversation: an application that reached paying customers without anyone senior ever reading the code. The first is a technique. The second is a liability, and it is the one that ends up on my calendar.
How Vibe Coding Actually Works
You describe the outcome
A sentence or two about what the software should do: a form that captures leads, a page that shows yesterday's orders. You say nothing about file names or where the code should live. The model picks all of that.
You accept what comes back
The model returns files, sometimes dozens at once, and you press accept. Reading them is the step that gets skipped, and skipping it is precisely what makes this vibe coding rather than AI-assisted development.
You run it and paste the error
Something breaks, you copy the stack trace back into the chat, the model patches it. The loop repeats until the screen looks right. Nothing in that loop asks whether the fix was correct, only whether the symptom went away.
The Tools This Happens In
Four categories, all capable of the same loop. The differences between them matter far less than tool comparisons suggest.
AI-assisted editors
A normal code editor with a model attached, suggesting lines and rewriting files on request. The code stays in front of you, which makes this the easiest category to use responsibly and the easiest to use carelessly.
Chat assistants
A conversation in a browser tab with code pasted back and forth by hand. Slow, and slowness is the safety feature: someone has to move every file, so someone sees every file.
Prompt-to-app builders
You describe an application and the platform generates it, database and hosting included. The code exists somewhere, but nothing in the workflow asks you to open it, and most people never do.
Terminal agents
A model with shell access that plans, edits files, runs commands, and commits on its own. The most capable of the four, and the one that does the most damage when it runs unreviewed.
Vibe Coding Tools People Build With
Nearly all of it happens in one of two kinds of product, and both are good at what they do. Which one you pick matters less than what happens after the first version works.
AI app builders
Lovable, Bolt, and Replit take a paragraph of description and hand back a running application with a database, a login screen, and a public URL. For putting a first version in front of a customer this week, nothing else is close.
AI-first IDEs and coding agents
Cursor keeps the code in front of you while the model edits it. Claude Code and agents like it work from the terminal, take a task, and carry it across several files at once. Both sit closer to ordinary engineering, which helps only where someone reads the diffs.
When the builder got you to 80%
The first eighty percent shows up in an afternoon, and that part is real. What is left is the work these tools were never meant to do for you: authorization edge cases, data that stays correct when two people write at once, a schema that survives its first migration, load past a demo.
What a project rescue coversWhat It's Genuinely Good For
The dismissive take is wrong. There is real value here, and I use the same models all day.
- Prototypes. A founder can put a working screen in front of a customer on Tuesday instead of waiting three weeks for an agency quote.
- Internal tools. The script that reconciles two spreadsheets every Monday morning does not need an architecture review. It needs to exist.
- Proof of concepts. Finding out whether an idea is even possible costs a couple of days now, and killing a bad one that fast is worth more than most teams admit.
- Learning. Watching a model build what you asked for teaches more in an afternoon than a chapter of a textbook, on the condition that you read what it wrote.
- Disposable work. One-off migrations, data cleanups, glue between two systems that will both be replaced next quarter.
None of this is theoretical for me. AppMaster runs on a two-person AI-first team serving users in 190+ countries at 99.99% uptime, and we push more than 11 billion tokens a month through models that write most of our code. What sits between that and a vibe-coded app is review, tests, staging, monitoring, and a named person accountable for every line that reaches production. The amount of AI is the same on both sides.
Vibe engineering: the same speed, with accountability
There is a name going around for the disciplined version, vibe engineering. It runs the same models and produces the same volume of generated code, wrapped in tests, code review, and observability, with a person answerable for whatever reaches customers. The label is useful because what separates the two halves of this page is process, not how much of the code a model wrote.
Where It Breaks
These are the failures that surface once a vibe-coded application has real users and real data.
Secrets shipped to the browser
API keys pasted into front-end code, database credentials committed to the repository, an admin token sitting in a JavaScript file anyone can open. The model has no idea which side of a trust boundary it is writing on, and the accept-and-run loop never checks.
Authorization that was never written
Login almost always works. What almost never works is the check that stops user A from reading user B's records by editing a number in the URL. Both versions look identical on screen, so the loop never surfaces the difference.
No tests, so no safe changes
Without tests, every later change is a guess. The model will cheerfully rewrite a working file while fixing an unrelated bug, and nothing exists to tell you it did until a customer finds out.
Architecture that cannot take a second feature
The same logic copied into nine places, no boundaries between modules, business rules living inside screen components. It runs today. It cannot absorb the next requirement without a rewrite, and the rewrite costs more than the original build.
Data loss
Migrations improvised against a live database, no backups, destructive commands run to make an error message disappear. This is the failure mode that ends companies rather than sprints, and it is far more common than the security ones.
The scaling wall
Queries that read an entire table, no indexes, no caching, no background jobs, everything done inside the request. Perfectly fine for the ten users in a demo, and a very bad week when a launch brings ten thousand.
When a Vibe-Coded App Needs Rescue
It stops being a prototype the moment somebody else's money or personal data is inside it.
Signs you are past the line
- Real customers are using it and nobody has read the code end to end.
- Every fix breaks something else, and no one can predict which thing.
- You avoid deploying on Friday, and lately on any other day.
- The person who prompted it has moved on, and the prompts were not kept.
- A customer, an investor, or a security questionnaire has started asking how the data is protected.
What a professional takeover looks like
- 1
Read all of it
A full pass over the code, infrastructure, and data model, ending in a written list of what is broken, what is dangerous, and what is fine as it stands. No changes yet.
- 2
Stop the bleeding
Secrets rotated and moved out of the client, authorization holes closed, backups switched on and restored once to prove they actually work.
- 3
Put a floor under it
Version control, a deployment pipeline, a staging environment that matches production, error tracking, and tests around every path that touches money or personal data.
- 4
Decide what to keep
Part of the codebase is worth saving and part is cheaper to rewrite. I say which is which in plain language, with the cost of each option, and you make the call.
Want the code looked at before you commit to anything? Team & AI Audit — $5,000Or build the next one with AI properly
Frequently Asked Questions
Is vibe coding real programming?
It is a real way to produce working software, and it is not the same skill as programming. The output is code either way, so the usual rules about security, correctness, and maintenance apply whether or not a human read it. The difference shows up in accountability: somebody has to understand the code well enough to answer for what it does, and typing it is not what produces that understanding.
Is vibe coding bad?
Not on its own. For prototypes, internal tools, and disposable scripts it is a reasonable and often excellent choice. It turns into a problem at the point where other people's money, data, or safety depend on code nobody has read, because the failures at that point are leaked credentials and lost records rather than a broken demo.
Can a vibe-coded app go to production?
Yes, once it has been through the same gates as any other software: a security review, authorization tests, backups that have been restored at least once, error monitoring, and a deployment you can reverse. Plenty of production systems today are largely model-written, including mine. What makes them safe is the review and testing wrapped around the code. Where the code came from stops mattering once it has been through that.
Who coined the term vibe coding?
Andrej Karpathy, in early 2025. He used it for his own casual projects, where he described what he wanted, accepted the model's code without reading much of it, and judged the result by whether it ran. He was explicit that this was not a method for serious software, but the phrase spread a great deal faster than the caveat did.
How do I fix a vibe-coded app?
Start with a read-only assessment: someone senior goes through the code, the infrastructure, and the data model and writes down what is broken and what is dangerous. Then close the security holes, turn on backups and error tracking, and add tests around anything touching money or personal data. Deciding which parts to keep and which to rewrite comes last, once you know what you actually have.
Which vibe coding tools do people use?
Two categories cover most of it. AI app builders like Lovable, Bolt, and Replit turn a written description into a running application with hosting and a database attached. AI-first IDEs and coding agents, Cursor and Claude Code among them, work inside a real codebase and leave the code where an engineer can review it. Builders reach a first version faster, and teams tend to move to the second group once the app has to keep working.
A Vibe-Coded App with Real Users
If customers are already inside it, the useful next step is a straight assessment of what you have, before the next round of changes goes in.
Triage first, then a plan you can fund. You are not signing up for a rebuild.
Related reading
Notes on building with AI, and on cleaning up after it.
