On 2 February 2025 Andrej Karpathy, an AI researcher and one of the founders of OpenAI, wrote a post on X that gave a name to a whole phenomenon. He described a new way of programming: give in completely to the “vibe”, dictate tasks to a neural network by voice, barely touch the keyboard, accept all of its edits and forget that the code exists at all. In the same post he himself added that for throwaway weekend projects this is “not too bad”, and admitted that he no longer reads diffs — the lists of changes in the code.
The word stuck. Now “vibe coding” is the name for almost any development where a neural network writes the code from a description in ordinary language. For a business this really did open new possibilities: a landing page, an internal tool or a prototype can be assembled without a team of developers. But Karpathy’s caveat about weekend projects has not gone away. I will sort out what a business can assemble on its own and where a project has trouble reaching launch without a developer.
What vibe coding is
Vibe coding is when you describe in words what you want to get, and a neural network writes the code. You look at the result, say what to fix, and go round again. You do not have to look into the code: you judge what you see on the screen.
For this people use chats such as ChatGPT or Claude, AI agents for code, and special services that assemble an application from a description and show the result at once.
The strong side of the approach is the speed of the first version. What used to take a noticeable amount of a developer’s work is now assembled much faster. The weak side is everything that happens after the first version. When you do not read the code, you do not know how what you got is built, and each next edit can break something in an unexpected place.
In practice a vibe-coding session looks like this. You write: “Make a page with a form for booking a consultation.” The neural network produces code, you open the result and see that the button is the wrong color and the phone field accepts letters. You write about that, get a corrected version and look again. After several rounds the page looks the way it should. What exactly changed in the code over those rounds, you do not know, and that is the whole point of the approach. And its main risk.
It also matters that a neural network almost never refuses. Ask it to add payment, a personal account or an integration with a CRM, and it will write the code. The question is not whether it will write it, but whether that code will be reliable when real clients start using it.
Vibe coding and Tilda’s vibe block are not the same thing
Tilda has a vibe block: a block in the library that generates its contents with AI from a request in the chat. The result can be refined — change the content, the style or the code — and also converted into a Zero Block (a feature in beta testing). This is a tool inside the builder: it creates a separate block on a Tilda page, while hosting, forms and the rest of the infrastructure stay with the platform. Vibe coding in the broad sense is the development of a whole site or application, where all of these questions have to be solved on your own. I do not use vibe blocks myself: for a developer it is an easy path, but for the client it is a mine under the later maintenance of the site, because he and his managers get something incomprehensible in the editor. My principle is that a page in the editor, in a Zero Block, should look as close as possible to the published one, and that it should be possible to edit it clearly. Besides, the feature is still in testing: Tilda itself warns that editing the code of a vibe block needs basic knowledge of HTML, CSS and JavaScript, support does not consult on the code, and conversion to a Zero Block is in beta.
What a business can assemble on its own
A landing page
A one-page site is the clearest option. The structure is simple, there is little logic, and the result is easy to check by eye. A neural network will assemble a page with blocks, texts and adaptive layout, and then it has to be placed on hosting and a form connected.
Where problems wait: a form that looks working but does not send requests anywhere; a page that looks good on a computer and breaks on a phone; texts where the neural network added promises you did not make. All of this can be solved if you check.
A reasonable order for a landing page is this: first the structure and the texts that you checked yourself, then the code, then a check on a phone, then placement and a test request. If at some step it becomes clear that the task is more complicated than it seemed — for example, you need booking with a choice of time, or payment — that is a good moment to stop and think whether to take a builder or a developer.
An internal tool
The most successful area for vibe coding in a business is tools for yourself. A calculator for managers, a request log with a convenient interface, a generator of commercial proposals from a template, a simple panel of key figures from a table.
Why this area works: the users are your own employees, who will report an error; the data often does not leave the company; if something breaks, it is unpleasant but not critical for clients. And the main thing: such tasks often do not reach developers for years, because they are too small. Vibe coding lets you solve them on your own.
One caveat: “internal” does not mean “without personal data”. If your request table contains clients’ names and phone numbers, then the internal tool works with personal data too. Then it is worth thinking about where it is hosted, who has access to it, and whether it might accidentally be open to everyone by a link.
A prototype of a service
A prototype is a working model of an idea that can be shown to clients, partners or developers. Not for launch, but for a check: whether people need it, how they use it, what is unclear.
For a prototype, vibe coding fits perfectly: speed matters more than the quality of the code, and throwing it away and remaking it is not a pity. A prototype of a mini app, a personal account or a catalog can be assembled and checked on real people before you invest in full development.
Where a developer is needed
Client data and access
As soon as client data appears in the project — names, phones, addresses, order history — a mistake stops being small. A data leak from a wrong setting, access to someone else’s personal account, passwords in plain text in the code: a neural network can make any of these mistakes, and in vibe coding there is no one to notice them.
Access belongs here too: keys to services, database passwords, tokens. A neural network can write them straight into code that later ends up in the open. A developer knows where to keep such things and how to check that they have not leaked.
Payment and integrations
Accepting payments, a link with a CRM, exchanging data with a delivery service, sending receipts — each such integration has its own rules, limits and ways to break. A mistake in payment means lost money or unhappy clients. A mistake in an integration means lost requests or wrong data in another system.
A neural network will write integration code from the documentation, but checking that it handles errors, repeats and edge cases correctly is hard without understanding the code.
Changes six months later
The most underestimated part. The first version works, everyone is happy. Six months later you need to add a function, change the logic, update an outdated library. And it turns out that nobody knows how the code is built. The neural network you describe the new task to does not know either: it sees the code for the first time and may suggest a change that breaks something elsewhere.
The longer a project lives and the more edits it has, the stronger this shows. Code that nobody read becomes, over time, code that nobody can change safely.
| Task | On your own | With a developer | Why |
|---|---|---|---|
| A landing page without complex forms | Yes | If you want | Little logic, easy to check |
| An internal calculator or table | Yes | If you want | Your own users, data stays inside |
| A prototype to test an idea | Yes | Not required | The goal is a test, not a launch |
| A personal account with client data | A prototype | Yes | Safety of data and access |
| Accepting payment | No | Yes | Mistakes cost money |
| Integrations with a CRM and services | A prototype | Yes | Handling of errors and repeats |
| A project that will keep growing | The first version | Yes | The code has to be understood in order to change it |
How to tell that a prototype should be handed to development
A prototype has done its job if the idea could be tested on it. Next it is worth looking honestly at the signs that it is time to call a developer.
The first sign is that real users and their data have appeared. While colleagues use the prototype on test data, mistakes are not frightening. When clients arrive with real phones and addresses, the responsibility changes.
The second is that payment or integrations with external systems are needed. This is the place where mistakes cost money or requests.
The third is that each new edit breaks something old. If you notice that you fix one thing and another breaks, the code has become too tangled to run blind.
The fourth is that you are afraid to change something. That is a sure sign that you no longer control the project.
The fifth is that the project is needed for a long time. If a tool must work and grow for years, its code must be clear to a person, not only to a neural network.
Handing a prototype to development does not mean admitting failure. The opposite: a working prototype is the best brief for a developer. It shows what needs to be done, how it should look and how users work with it. That is much clearer than any text description.
There is also a middle option: show the prototype to a developer for an audit. He will look at the code and mark what can stay, what is dangerous and what will have to be rewritten. Sometimes it turns out that the base is quite workable and only safety and integrations need to be finished. Sometimes — that it is simpler to write it again, using the prototype as a sample. In both cases the decision is made from an understanding of the code, not from hope.
If your prototype has reached this point, look at custom development. If it is an application inside Telegram — at Telegram Mini App development. And what to do with the prototype can be discussed through the quiz on mara-craft.com: I will look at what in it can stay and what is better remade.