Vibe Coding: How Not to Drift into Absurdity on the Wave of Hype

Maya Batyrbekova, PhD, MIT Digital Transformation AI Professional
Not long ago, to validate an automation idea, a company needed a team to define requirements, estimate the workload, and approve the budget. Today, an employee can describe a task to an AI tool and receive a functional application within a few hours. For business, this looks almost like magic: instead of months, it takes just a few days; instead of a team, one person is enough; instead of a substantial budget, a $200 subscription suffices.

Using AI in development and vibe coding are not the same thing. An engineer might delegate a significant portion of the coding to a model but then checks the architecture, dependencies, security, and logic. In vibe coding, the person primarily looks at the result: if the application runs, they move on, even without fully understanding what is happening inside.

I lead a team that, in three months, rewrote a monolithic system covering more than 10 process areas using AI. AI helped with routine tasks and accelerated the transition from idea to solution, but we spent a significant amount of time restoring context, checking connections between processes, and finding changes outside the original task. This experience revealed the boundaries of the technology. Within the MIT Digital Transformation program, I also analyzed international practices for implementing AI. It shows that sustainable effects appear where processes are already established, data quality is ensured, and responsibility for results is defined.

A $200 subscription is not a panacea that can cure all of a company’s ailments. When there is chaos within a business, technology does not eliminate it but helps turn that chaos into code faster. This is where, in my opinion, the main problem of the current fascination with vibe coding begins.

There is more code, but development has not become simpler
An application assembled over the weekend is perceived as a success, and a team that releases twice as many features seems twice as efficient. This leads to the idea of reducing experienced engineers and assigning more tasks to junior specialists. In my practice, the CEO of one company froze hiring for experienced engineers because he believed that a junior with a subscription becomes a mid-level developer. However, an engineer’s level is determined not by the volume of code but by the ability to understand the consequences of their decisions and spot risks before launch. AI will help a junior write a function faster, but it will not transfer several years of experience along with the subscription.

The amount of code does not equal the amount of value. Ten internal applications might mean ten systems, each requiring access, updates, an owner, and support. In the short term, reducing senior engineers might show savings, but the bill will come when it is necessary to figure out generated code, fix a systemic error, or develop a product whose architecture no one consciously chose. AI does not know why the company chose a specific data structure five years ago, what exception was agreed upon by the financial and operations directors, or which process area cannot be split, even if it looks correct from a code perspective. This context can be partially recorded in instructions, but only what the team has already managed to formulate will end up there. An engineer is needed to notice situations for which there are no rules yet.

Detailed manifests and rules for the model do not solve another problem: AI reproduces common solutions well. For standard authorization or an admin panel, this is a plus, but for unique business logic, this approach can be a trap. The danger of stamped code is not that it looks like other code, but that along with a technical template, the company gets a template solution to its problem. This is precisely why development has not become simple with the advent of vibe coding, although getting the first working version is indeed much easier now.

When a prototype subtly becomes part of the business
The problem with vibe coding often appears later: an employee assembles an internal tool, colleagues start using it, then it is connected to production data and other platforms. No one made a separate decision to put the prototype into operation, but soon it becomes impossible to finish the workday without it. At the same time, the application may not have a technical owner, documentation, or a backup plan, and its creator may not always be able to explain how the generated code works.

In my practice, there were risks where AI could affect development environment settings and passwords, as well as spontaneously change already implemented process logic because it saw only part of the context. Such a change might look like a normal fix externally, but to understand its consequences, the team had to re-analyze related areas, test the process, and review the code. On average, we went through this cycle at least three times, and sometimes more, so the time saved on the first generation was partially spent checking and correcting the result. In the end, we got working functionality, but its quality did not always match the level expected from a finished product. This is exactly how a technical experiment turns into an operational risk, since vibe coding allows creating systems faster than the company has time to learn how to manage them.

It works, but that does not mean it is reliable
Code created with AI has a feature that simultaneously makes such tools convenient and dangerous. It knows how to look convincing, so a bad solution does not necessarily look bad, because AI code can be neatly formatted, commented, and successfully pass the main scenario. The most dangerous are not those products that crash immediately, because such a failure is usually noticed quickly, but those that continue to work but gradually distort numbers, lose some data, or give users extra rights. A company may not see the problem for a long time because the process will look correct externally. AI does not bear responsibility for the result and can confidently explain a solution that it itself proposed incorrectly. Moreover, asking it to check its own code does not guarantee an independent assessment, because the model can repeatedly fail to notice the same error.

Are you ready to hand over your business to this?
Imagine that an owner hired someone to create an internal system, and that person assembled it quickly using AI. The buttons work, the data is displayed correctly, but the executor cannot explain why the model chose this architecture and how the system will behave in an abnormal situation. Essentially, the business received a product whose mechanisms are understood by neither the owner nor the hired executor. Is the owner ready to entrust such a system with payments, customer data, inventory levels, or payroll calculations? If the system makes a mistake, the company, not the model, will be held accountable. Generated code itself does not mean that an engineer does not understand it. The boundary lies between understanding and blind trust. If an employee can explain the solution, name its limitations, safely modify it, and restore it after a failure, AI remains a tool. If they can only input new requests and hope for the next fix, the business gets a system without a real owner.

Why engineers are still needed
The value of an experienced engineer has never been solely in the speed of writing code, but in the ability to foresee in advance how a simple function will affect security, load, and future product support, as well as to understand when a quick solution is acceptable and when the company will pay for its consequences for years. Sometimes their most valuable contribution is checking before development even begins whether a hypothesis has value and whether a new system needs to be created at all.

A young employee usually offers more options, and it is by checking ideas and observing their consequences that they gain experience. An experienced engineer has already gone through similar situations, so they understand faster which option will solve the problem and which will create a new one. With the advent of AI, this ability becomes even more important because code can now be produced almost without limits. An engineer is increasingly valued as someone who manages technical decisions, not just writes lines of code. Perhaps soon it will become common for one team to quickly create a product using AI, while another comes in to figure out how it works, prepare it for operation, or completely rewrite it. The business will first pay for speed, and then for restoring engineering understanding, and in some cases, such a rework will turn out to be more expensive than development from scratch.

So, implement it or not?
It is one thing to give employees subscriptions, and quite another to build company processes in which AI is truly integrated into work. In international digital transformation cases we analyzed at MIT, it was clearly visible that
an AI-native company does not emerge after purchasing licenses. For this, you need prepared people, quality data, clear processes, and responsibility for results. The more decisions a company delegates to AI, the more important control becomes, not the other way around. All of this costs money. In addition to subscriptions, the business will pay for training, process restructuring, security, integrations, reviews, and support. Therefore, the expectation that AI will allow quickly reducing staff and immediately cutting costs is mistaken. Savings may appear later, but first, the company will have to invest in the foundation, without which the tools will remain a set of disjointed experiments.

What a manager should do
It is worth starting not with mass purchasing of subscriptions or with the decision to train all employees in vibe coding, but with a specific business problem. Therefore, before launching the use of AI, a manager should answer five questions.

1. What will the company lose if the system makes a mistake?
2. What data and services will it have access to?
3. Is there someone who understands how it works?
4. Who will restore the process after a failure?
5. Can the system be safely disconnected and return to previous work?

If there is no answer to at least one of these questions, AI is not yet ready to be responsible for a critical part of the business.

When the hype will end
The IT industry has already gone through similar waves. A few years ago, a similar feeling arose around low-code. This technology gave a person without development experience the ability to assemble a simple process in a system in an evening, so at some point, it might have seemed that the business would no longer need analysts, developers, and entire teams responsible for digital products. This did not happen because the low-code technology found its place. With vibe coding, the same thing will most likely happen. Companies will go through the stage of fascination with applications created over the weekend and start looking not only at launch speed but also at the cost of further operation, the possibility of development, and the presence of people who understand the system. AI will not disappear anywhere; it will remain part of the IT landscape and significantly change the work of all company employees, but gradually the expectation will disappear that it is enough to buy a subscription to replace experience, processes, and responsibility.

The first wave of vibe coding showed how cheap it is now to get a working prototype, and the next one will show how much it costs to turn it into a reliable product and then own that product. And here, the winners will be not those companies that created more applications and distributed more subscriptions, but those who learned to use the speed of AI and did not lose engineering understanding of their own business.