On February 2, Andrej Karpathy published a short note that gave a name to a practice many people had already adopted. He called it vibe coding. Karpathy was part of the founding team at OpenAI and led AI at Tesla, so the terms he introduces tend to be widely adopted. He described a way of working in which you "fully give in to the vibes" and "forget that the code even exists." You tell the AI what you want, accept what it produces, paste in the error message when something fails, and continue.
Eleven days later, the expression is everywhere in our feeds. Among the developers we follow, about half react with irritation and the other half with enthusiasm.
In our view, this is not a sudden breakthrough. We have been working with language models since the GPT-3 era. It is rather a threshold that was quietly crossed over the past few months, and Karpathy was the one who stated it publicly.
What does vibe coding look like in practice?
The person opens one of the new tools: Lovable, Bolt, Replit's agent, or an editor such as Cursor. They describe what they need, for example "a page where customers can book a table for Friday or Saturday, with a confirmation email." The tool writes the code. The person evaluates the result on screen, not the code itself. If the result is wrong, they say so. If an error appears, they copy it back into the conversation.
That last step is the real change. The person no longer debugs; they describe the problem, and the machine does the debugging.
Our team spent years building Drupal and WordPress sites by hand at Raincity Studios in Vancouver, and this evolution is significant from that perspective. A large share of what a web agency billed for was the slow, meticulous layer of the work: setting up the project, wiring the forms, correcting the layout so that it held up in Internet Explorer. That layer is quickly becoming inexpensive.
Whether the name will last remains to be seen. It may seem like a passing expression, but the word "blog" initially made the same impression. It is likely to have its own Wikipedia page on vibe coding soon, if one has not already been started.
Can a prototype really be built in an afternoon instead of weeks?
Yes. This is where the approach is most effective: the first version of an idea.
Consider a roofer who wants a simple quote calculator on his site, a restaurant that wants to see what online ordering would look like before hiring anyone, or a small tourism operator testing a booking flow. Until very recently, each of these projects required a meeting, a quote, a few weeks of work, and a bill that led most owners to postpone the project to the following year. Today, a clickable version can be ready the same afternoon.
In our assessment, one of the most valuable uses is eliminating ideas that do not hold up. The tool is built in two hours and shown to three customers; if they show no interest, the business has saved a few thousand dollars and avoided investing in the wrong direction.
It also improves communication between an owner and a developer. Pointing to a rough working screen and saying "like this, but with that" is far more effective than describing a need in a long email. Our experience with such emails, both written and received, is that no two people read them the same way.
Do you still need to understand what you put online?
Yes. Karpathy's note itself states that the approach is "not too bad for throwaway weekend projects." That part of the message is shared far less often.
Code runs whether or not anyone has read it. Many of these tools can connect a database in a couple of clicks, which is convenient, until the question arises of who else can read its contents. Access rules are only considered by those who know they exist. If the person building the application has never heard of them, the AI will not always raise the subject on its own.
For a small business, the risk areas are easy to identify: anything that stores customer names, emails or phone numbers; anything that processes payments; anything that requires users to log in. If your application does any of these, the fact that it appears to work is not sufficient. Someone must understand where the data goes and who can access it. Privacy law also makes this a legal matter, and a customer whose information is exposed will not be reassured to learn that a machine wrote the faulty part.
A brochure site or a menu page is a different case. The risk and the stakes are low, and vibe coding is entirely appropriate.
The same applies to a small tool that only you will use: sorting your invoices, renaming a folder of photos, turning a spreadsheet into a printable list. This is exactly the weekend project Karpathy described, and a very good use of an evening.
Which precautions should you take before going live?
The practices that prevent problems are simple and well established.
- Keep a copy of the code somewhere the tool does not control. Most of these builders can push the code to GitHub; we recommend doing so from the first day.
- Test the application as a customer would: on a phone, with an incorrect email address, with a half-completed form, and by pressing the back button midway through.
- Record what you asked for. If the tool disappears or changes its pricing, your prompts are the closest thing you have to a specification.
- Know who owns the domain and the hosting account. It should be you.
- For anything involving personal data or payments, have the code reviewed by someone who can read it before it goes live.
None of this is new; these are the same practices that applied to websites twenty years ago. The difference is that building has become so fast that verification now seems slow by comparison, and many people skip it. We expect this year to bring some serious incidents that stem from exactly that omission.
If you run a local business and are deciding between a proper small business website and a quick AI-built page, the answer depends on what the site must handle. A page that displays your opening hours is one thing; a page that collects deposits is another.
How is vibe coding likely to evolve?
We anticipate that the practice will divide into two approaches. Some people will describe and never review the result. Others will describe, then read, test and correct. The second group is likely to produce a considerable amount of software this year; the first is more likely to end up in the news.
The skills that matter are also shifting. Typing code is becoming less important each month, while knowing what quality work looks like, and recognizing when something is wrong, is becoming more important.
That has always been the most demanding part of the work. It was simply hidden beneath the time spent typing.