What is vibe coding: what you can build by talking to AI and where it breaks

Vibe coding: a phrase from one post that dictionaries adopted

People ask what is vibe coding because the phrase arrived fast and from a single place. On 2 February 2025 Andrej Karpathy, a co-founder of OpenAI and former head of AI at Tesla, wrote on X about a new kind of coding in which you give in to the vibes and forget that the code even exists. Wikipedia’s article on the term treats that post as the origin. It adds that Merriam-Webster listed the phrase as slang and trending in March 2025.

Collins went further. In November 2025 it named vibe coding its Word of the Year, describing it as the use of artificial intelligence, prompted by natural language, to write computer code. Its announcement puts the idea in everyday words: telling a machine what you want rather than painstakingly coding it yourself. It also notes that tech experts still argue over whether the practice is revolutionary or reckless.

Accepting code unread is what sets vibe coding apart from AI help

Karpathy’s post is specific about the method. He talks to the tool instead of typing, always presses Accept All and no longer reads the diffs, the changes the model proposes. Error messages go back to the model without comment, and that usually fixes them. He admits the code grows beyond his usual comprehension and that some bugs he simply works around. He called the whole thing not too bad for throwaway weekend projects.

That remark is the line that matters. Wikipedia describes the practice as AI-assisted development that may involve accepting generated code without thorough review. A developer who asks a model for a function, then reads, tests and understands it, is using an assistant, and the code is still theirs. In vibe coding the person hands over the understanding along with the typing. The tools are the same; the difference is whether anyone has read the result.

What a non-programmer can really build by describing it to AI

Wikipedia gives a modest early example. In February 2025 the New York Times journalist Kevin Roose, who is not a professional developer, used the approach to build small applications he called software for one, and found the results often limited and prone to errors. That is a fair map of the territory. The method suits tools for one person or a small team, where a mistake costs an afternoon rather than somebody’s personal data.

Replit is one of the products built around this idea. Its documentation says the Agent turns your ideas into apps from plain language, setting up the project, configuring databases, checking its work and fixing problems. With a tool of this kind, an owner can get a clickable prototype for a partner or an investor, or a page that measures interest in a new offer. Small internal tools fit as well: a price calculator, a booking table for the team, a form that sorts incoming requests.

These projects share a short life or a small circle of users. A prototype exists to be looked at, discussed and thrown away. An internal tool is used by colleagues who will say at once when it misbehaves. No card number passes through either of them, and if one stops on a Monday morning, someone opens a spreadsheet and carries on.

Where vibe-coded apps break first: access rules and customer data

The OWASP Top 10, which its authors call a standard awareness document for web application security, puts Broken Access Control first in its 2025 edition. Access control, in OWASP’s words, makes sure users cannot act outside their intended permissions. Typical failures include viewing or editing another person’s account by supplying its identifier, and an API that does not check who is changing or deleting data. OWASP reports that every application it tested had some form of this weakness.

This is the kind of fault that someone who never reads the code cannot see. In a demo the app looks right: you log in and see your own orders. Whether changing a number in the address bar shows a stranger’s orders stays hidden until somebody tries it on purpose. Wikipedia records that in May 2025, 170 of 1,645 web apps made with one popular vibe-coding app had a flaw that let anyone reach personal information.

The lesson is not that generated code is always worse. Rules about who may see what simply never appear in a demonstration, so nobody notices when they are missing. A prototype with three invented customers can live without them. An app with real customers cannot, and checking those rules takes someone who reads code and knows which doors to try.

Payments, upkeep and code that nobody on the team understands

Money brings its own rules. The PCI Security Standards Council says its PCI DSS standard applies to entities that store, process or transmit cardholder data. A home-made checkout that touches card numbers pulls a business into that territory without anyone deciding to go there. The usual practice is to send card details to a payment provider’s own page and let the app receive only the result. Whether that covers your case is a question for the provider and a specialist.

Upkeep comes next, because software is rarely finished. Wikipedia quotes the engineer Simon Willison: vibe coding your way to a production codebase is clearly risky, since most real work means changing existing systems, where clear and sound code matters most. Karpathy himself said his code outgrew his understanding. In an app that takes orders, that means every new request to the model can quietly break something that worked yesterday.

Then there is the human side. When the person who prompted the app moves on or forgets how it was built, nobody holds the knowledge. There are usually no tests, no documentation and no record of which instruction produced which part. A developer who inherits the project must read all of it before changing a line, and that reading is the slow, costly part of any rescue.

How to vibe-code a prototype without real data or exposed keys

Start with scope. Write three sentences on what the prototype must show, who will see it and when it will be retired, and keep it inside that. Fill it with invented data: made-up names, test email addresses, sample orders. Never paste in a real customer list to see how it looks. Once real personal data is inside, the prototype is a system that must be protected, and data protection law may apply, so check your case with a specialist.

Keys need the same care. Replit’s documentation warns that secrets such as API keys and tokens written straight into the code can leak when the code is shared publicly, pushed to a public repository or shown on a screen share; its Secrets tool encrypts them and passes them to the app as environment variables. GitHub’s documentation explains that its secret scanning searches the entire Git history on all branches, a reminder that a deleted key still sits in older versions. If a real key ever lands in the code, replace it with the service that issued it.

Keep a way back and test the prototype like a stranger would

Replit’s documentation describes checkpoints: complete snapshots its Agent makes at key milestones, database contents included. The same page says a rollback does not change the database by default, and that a production database is restored through a separate point-in-time process. An undo button for code is not automatically one for data. Wikipedia also records a July 2025 case in which Replit’s AI agent deleted a database despite explicit instructions not to change anything. Whatever the tool, keep your own copy of the code in a repository and your own export of the data.

Then test the prototype as a curious stranger would. Log in as two test users and check that neither sees the other’s records. Change numbers in the address bar, send empty and absurdly long forms, close the tab in the middle of a save. Keep a written list of what each screen must do and tick it off by hand after every large change, because a model asked to fix one screen may rewrite another.

When a vibe-coded prototype needs a developer to become a product

The signal is easy to remember: real people, real data or real money. A tool that stays internal, serves a few colleagues and holds nothing personal can stay in your hands, with the habits above. Once it is about to store customer accounts, take payments, connect to your accounting or stay in daily use for months, it needs someone who reads code. Sometimes the prototype can be cleaned up and kept; sometimes it is wiser to treat it as a detailed specification and rebuild. A developer can tell which only after looking inside.

Before that conversation, gather what you already have. That means access to the prototype and its code, a list of what each screen must do, who will use it, what data it stores and where that data comes from, the planned payments and integrations, and your prompts or notes. With this on the table, a studio such as VITON13 can estimate the work instead of guessing. And the question of what is vibe coding becomes a practical one: which part of your prototype is worth keeping.