What vibe coding is: programming by talking to AI, where it works and where it breaks

What you get from this article

• The term is from Andrej Karpathy, February 2025, and became the Collins word of the year in November 2025.
• The definition includes not reviewing the code: accepting without reading is part of the concept, not a deviation.
• Prototypes, internal tools and personal automation are legitimate territory.
• The red line is third-party data, money and future maintenance by somebody else.
• The hidden cost does not show up in the first week: it shows up at the first change.
• Using AI to code with review is something else, and it is what professionals do all day.

Where the term came from, and the detail that got lost

In February 2025, Andrej Karpathy, one of the most respected names in the field and former director of AI at Tesla, described in a post a way of working he was experimenting with himself: talk to the model, accept the suggestions, run it, see whether it works, ask it to fix what broke. Without reading the code carefully.

The expression caught on in a way nobody predicted. In November 2025, the Collins Dictionary chose vibe coding as word of the year, defined as software development that turns natural language into code using AI.

The detail lost in the popularization is precisely the most important part of the original definition: not reviewing is part of the concept. Karpathy explicitly described accepting code without understanding it, letting the model fix things when something broke. It was not a recommendation for serious software: it was the description of a way of working on a throwaway weekend project.

When that part disappears, the term starts being used as a synonym for "coding with AI", which is something else entirely. Professional developers use AI all day and review every line before accepting it. That is not vibe coding: it is a tool.

Not reviewing is not a deviation from vibe coding. It is the definition of it. When you review, you are doing something else, and the something else is better.

Why it works so well at the start

The initial experience is genuinely impressive, and it is worth acknowledging rather than sneering at. You describe a screen, it appears. You ask for a button, it works. In one afternoon you have something running that would previously have taken a week and somebody who knew how to code.

That happens because most ordinary software is a variation on a known pattern. A form that saves to a database, a filtered listing, a login screen, sending email, a shopping cart. Those patterns appeared millions of times in the training material, and the model reproduces them very well.

The second reason is that the start of a project is the moment with the fewest constraints. There is no old code not to break, no users not to disturb, no production data not to corrupt. Everything is possible because nothing has been decided yet.

The illusion comes from there: the ease of the start is read as the ease of the whole, and the person projects the speed of the first week onto the next twelve. That is exactly where the arithmetic changes.

Where it breaks, and when that shows up

The break almost never happens during construction. It happens at the first change, and that distinction explains why so many people are caught by surprise.

When you ask for an alteration in a twenty-file system you have not read, you do not know what else depends on it. The model does not know everything either, because it sees what fits in its window. The change works in what you tested and breaks somewhere you did not even know existed. And because you do not understand the code, you cannot investigate: you can only ask for a fix, which generates another change you also do not understand.

The second breaking point is security, and it is the most serious because it is silent. Code that works and code that is secure are different things. A login screen can work perfectly and still let anybody into somebody else account by changing a number in the URL. The system throws no error, the test passes, the client uses it. The problem shows up when somebody goes looking, and sometimes the person looking is not you.

The third is dependence on whoever built it. Software with nobody who understands it is an asset only the original author can touch, and sometimes not even them, because they did not read it either. When that somebody leaves, or loses interest, the system becomes a block that can only be replaced whole.

The line worth drawing

There is a practical cut that settles most doubts, and it is not about project size or about who is building.

Legitimate territory is everything throwaway, internal and reversible. A prototype to show an idea before investing. A clever spreadsheet only you use. A script that organizes your files. Personal automation that saves two hours a week. If it breaks, the worst that happens is you lose time.

Not territory is anything holding somebody else data, moving money, taking a decision with legal effect, or needing maintenance by somebody other than you. Customer records, payments, medical records, contracts, payroll. Here the consequence of an error leaves your lap and lands in somebody else.

The question that settles it immediately, and it is more useful than any technical rule: if this leaks, breaks or calculates wrong, who pays? If the answer is you, and the loss is your time, go ahead. If the answer involves customers, other people money or personal data, you need a different approach.

• Fine: prototypes, your own internal tool, personal automation, proof of concept, learning.
• With care: a tool used by the team, with non-sensitive data and a backup.
• No: anything with customer data, payments, health, contracts or legal obligations.

The middle ground, which is where the results are

The public debate polarized between "AI will replace developers" and "this is rubbish". Both positions ignore where things genuinely work well today, which is in the middle.

The productive way to work is to use AI like somebody very fast and occasionally distracted: it writes, you read before accepting, it explains what it did when you do not understand, you test what matters. The speed is still much greater than before, and the understanding is not lost.

That changes the nature of a developer work: less time writing the obvious, more time deciding architecture, reviewing and testing. Tools built for that flow, such as Claude Code, exist exactly for this, and they work across the whole project rather than suggesting line by line.

And there is a use of vibe coding that is legitimate inside serious work: using it to discover what you want. Building three throwaway versions of a screen in an afternoon to decide which makes sense is cheap and useful. What cannot happen is the third version going to production without anybody reading it.

If you own a business and you are hiring

It is worth knowing what to ask, because the difference between a system built with AI and reviewed and one built with AI and accepted blind does not show up in the demo. In both, the screen works.

Ask who reviewed the code and what happens if the person who built it leaves. Ask where the data sits, who has access and whether there is a tested backup, not just a configured one. Ask what happens if two users do the same thing at the same time, which is the kind of problem unreviewed generated code almost never handles.

And ask the simplest thing of all: ask them to explain a part of the system. Somebody who understands can explain in plain language why that decision was taken. Somebody who just accepted what appeared cannot, and that becomes obvious in two minutes.

None of this is an argument against using AI to build. It is an argument for knowing what you are buying. ROO3 builds with AI every day, in its own products and in client projects, and the difference lies entirely in the review and the tests nobody sees. If you are assessing a project right now, that is the kind of conversation that opens AI consulting, and the website part itself is in web design.

Frequently asked questions

Who invented the term vibe coding?

Andrej Karpathy, in February 2025, describing a way of coding where you talk to the AI, accept the suggestions and let the model fix what breaks, without reviewing the code carefully. In November 2025 the Collins Dictionary chose the expression as word of the year.

Is vibe coding the same as coding with AI?

No. The original definition includes not reviewing the generated code. A developer who uses AI and reads every line before accepting is using a tool, not vibe coding. The difference seems small and it is precisely what defines whether the result is maintainable.

Can you build a professional website with vibe coding?

You can get something live fast, and the arithmetic changes at the first alteration. A simple brochure site usually survives; anything with customer records, payments or a logged-in area accumulates security risks that do not appear on screen and are only discovered when somebody goes looking.

What is the biggest risk of vibe coding in a company?

Silent security failure. Code can work perfectly and still let one user access another user data. The system throws no error, the test passes and the problem only shows up when somebody looks for it, and sometimes that is not you.

How do I know whether my project can be done this way?

Ask one question: if this leaks, breaks or calculates wrong, who pays? If the answer is you and the loss is your time, go ahead. If it involves customer data, other people money or legal obligations, the project needs review and tests done by somebody who understands the code.

Will I have to rebuild everything later?

Not always, but it is common. A system nobody understands tends to be replaced rather than evolved, because every change breaks something unpredictable. It is worth counting on that cost from the start, and treating what was built that way as an expensive prototype rather than a definitive base.

Sources

• Collins Dictionary: word of the year 2025
• CNN: vibe coding named word of the year by Collins

Rodrigo Fávaro

Founder of ROO3, a marketing and technology agency in São José do Rio Preto, Brazil. Builds AI products running in production (Tobia, gerar.app, Pense Mercado) and maintains the AI Benchmark, a public ranking of AI models. See ROO3 AI consulting.

X @rodmf LinkedIn rodrigofavaro