Vibe coding without control: what you save in hours, you pay for in months

1They thought they were going faster

In early 2025, the research organization METR ran an unusual experiment: it took 16 experienced developers, assigned them real tasks in open-source repositories they knew well, and randomly decided on which ones they could use AI tools and on which they could not. Before starting, the developers estimated that AI would make them 24% faster. When they finished, they believed it had: they calculated they had gained 20% in speed. The stopwatch said otherwise. With AI, the tasks took 19% longer.¹

The result cannot be generalized, and in 2026 METR itself published preliminary data suggesting that newer tools do speed up the work, albeit with significant methodological limitations.² But the experiment exposed something that goes beyond speed: the distance between what we feel AI does for us and what it actually does. That distance is the ground on which vibe coding thrives.

It is not the only data point in that direction. In 2023, Stanford researchers found that people who programmed with an AI assistant wrote less secure code than those who did not use one and, at the same time, were more convinced that their code was secure.³ And in Stack Overflow’s 2025 survey of more than 49,000 developers, 84% say they use or plan to use AI, but only 33% trust the accuracy of what it produces; two out of three name “almost right” answers as their biggest frustration.⁴

Andrej Karpathy coined the term in February 2025 to describe a way of programming in which you describe what you want, let the AI write the code, test it and ask for adjustments, without necessarily reading what was generated.⁵ What used to take weeks can now become a working prototype in an afternoon. It is an extraordinary advance, and it would be a mistake to downplay it. But it comes with a dangerous illusion: believing that producing software that works is the same as building a robust solution.

An application can work perfectly in a demo and, at the same time, have an architecture that cannot support growth, dependencies that are hard to maintain, vulnerabilities no one sees, zero error handling, concurrency or data integrity problems, and no mechanism to recover when something fails. None of that shows up on the first run. That is why the risk is not that AI writes bad code; humans do too. The risk is that the ease of getting visible results replaces the discipline of validating the invisible ones.

2What the evidence reveals about AI-generated code

The concern is not merely theoretical. In March 2026, Veracode published its latest assessment of the code generated by language models: 80 programming tasks in four languages, designed to tempt the models with known vulnerabilities. More than 95% of the generated code was syntactically correct. Only 55% was secure. In tasks exposed to cross-site scripting attacks, barely 15% of the responses were; in Java, 29%. Not even the most advanced models, with extended reasoning, exceeded 72%.⁶ In other words, the problem will not be solved simply by waiting for the next model. Nor is it new: in 2021, a New York University study found that about 40% of the programs GitHub Copilot generated in risk scenarios contained vulnerabilities.⁷

Maintainability shows a similar trend. GitClear analyzed 623 million code changes between 2023 and 2026. Duplication of code blocks grew 81% since 2023, and the share of refactored code (reorganized to be reused rather than copied) fell from 21% of modified lines in 2022 to less than 4% in 2026. Developers today copy five times more than they refactor.⁸ GitClear is careful not to attribute the whole cause to AI, but the direction matches what any engineering team observes: more code is being written, and less of it is being tidied up.

Google reaches a similar conclusion from another angle. Its DORA 2024 report, the benchmark study on the performance of engineering teams, found that in teams that adopted AI, delivery throughput fell 1.5% and the stability of what was delivered fell 7.2%.⁹ Writing code faster did not translate into delivering better software.

None of these studies measures the full universe of software built with AI, and their figures should not be read that way. What they show, together, is a principle: perceived speed is not effective productivity, and code that compiles is neither secure nor maintainable code.

3The cost does not disappear. It shifts.

The productivity of AI-assisted development is usually measured by time to prototype or the number of features delivered. These are legitimate metrics, but they look only at the first line of the account. The cost of a system also includes validating, operating, maintaining, securing and, at times, rebuilding it. AI drastically reduces the first item. If review and comprehension are reduced at the same time, the others grow. The cost moves forward, precisely to where fixing things is most expensive.

An illustrative case makes this visible. The numbers are rounded assumptions, not measurements from a real company.

A company’s sales area needs an application that consolidates sales information from several sources and suggests which customers to contact. There are three paths.

Path A: traditional development. A small team builds it in six weeks, with architecture, testing and a security review. Development and validation cost USD 110,000, and operating and maintaining it for two years another USD 80,000.

Path B: vibe coding without control. Someone from the area builds it in three days with AI, for USD 20,000. It works so well that within a few weeks the entire sales force is using it and starts loading customer data into it. In the sixth month, a security review finds exposed credentials and data from different customers with no separation: fixing it costs USD 35,000. In the tenth month, when 200 people are already using it, it has to be rebuilt to support concurrent users and changes in the sources: USD 110,000. And because no one really knows its logic, operating and maintaining it costs USD 125,000 over two years, almost double that of path A.

Path C: vibe coding with controls from the start. The same person builds it with AI in one week, but with an engineer who defines the minimum controls from the outset: where the credentials live, how the data is separated, which automated tests run and who is accountable if it fails. It costs USD 45,000 up front, plus USD 40,000 in the sixth month to prepare it before opening it to the whole area, and USD 80,000 for operation and maintenance.

Path B is the cheapest during the first nine months, and it is the one any committee would approve looking only at the initial budget. After two years it is by far the most expensive. Path C, by contrast, captures almost all of AI’s speed and ends up being the cheapest of the three. Moreover, B and C start delivering value from the first week, while A takes a month and a half.

The conclusion is not that vibe coding is expensive. It is that vibe coding without control is expensive, and the problem hides precisely in the period when everyone is celebrating how quickly it came out.

4Comprehension debt

There is a cost less visible than vulnerabilities or rebuilding: the loss of understanding of the system.

Writing code by hand never guaranteed understanding it, but it forced explicit decisions: how to structure the components, what to do with errors, how the services communicate. With vibe coding, many of those decisions are made by the model and remain implicit. The result is systems that work, but whose internal logic no one on the team has truly reviewed.

I have seen this up close in AI agent projects for mining, in image processing systems and in sales applications. The prototype appears extremely fast and works in the demo. Months later, a part stops working, or starts failing without warning, and no one on the team can explain why. Nor does anyone really know what risks its integrations with operational systems carry. It is not a problem with the model or with the people: it is that the decisions the model made were never made, or documented, by anyone on the team.

Addy Osmani, an engineer at Google, gave it a name in April 2026: comprehension debt, the gap between how much code exists in a system and how much of that code anyone actually understands.¹⁰ It is different from technical debt. Technical debt, the metaphor Ward Cunningham proposed in 1992, describes implementation decisions that make future changes more expensive.¹¹ Comprehension debt appears when the knowledge to explain, modify, validate or rebuild a system simply is not in the team that operates it. An application can have a reasonable architecture and enormous comprehension debt if no one knows its assumptions, its dependencies or its limits. The phenomenon also has experimental support: in 2025, the MIT Media Lab found that people who wrote with the help of ChatGPT remembered less of what they had produced and showed lower brain connectivity than those who wrote unaided, an effect its authors called cognitive debt.¹²

What I want to add is its economic dimension. Comprehension debt is not an engineers’ problem: it is a deferred cost that appears in no budget and is collected at the worst moment, when something fails and no one knows why, when a change in a source breaks everything, or when you have to show a regulator how the system makes its decisions. In path B of the case, a good part of the USD 125,000 in operation is exactly that: paying, again and again, for not understanding what was built.

The question stops being technical: who really understands the decisions that led to building the solution that way?

The answer is not to review every line by hand; that would eliminate much of the gain. In Expert Validation Loop I proposed that human oversight should not be limited to approving what AI delivers, but should validate the reasoning, the assumptions and the method before a result is used. Applied to vibe coding, it means that someone with engineering judgment defines what is correct, secure and sufficiently robust, and that automation (static analysis, tests, dependency review) verifies the rest. The human does not need to write the code. The human needs to retain control over the criteria that decide whether that code is acceptable.

5A prototype is not a product

This is no longer hypothetical. In 2025, a researcher reviewed applications built with Lovable, one of the most popular vibe coding platforms, and found at least 170 that exposed their users’ data (emails, phone numbers, payment status and access keys to other services) because no one had properly configured who could read what in the database. The problem was registered as an official vulnerability, CVE-2025-48757.¹³ That same year, investor Jason Lemkin publicly recounted how Replit’s AI agent deleted the database of a project he was building, in the middle of a code freeze he himself had requested. Replit’s CEO called it unacceptable and announced that it would automatically separate development and production environments, something any engineering team takes for granted.¹⁴

Back to the sales area in the case. The prototype was ready in three days. The interface was attractive, the results looked right and the demo for management went flawlessly. The organization drew the obvious conclusion: the product is practically finished.

No one asked the questions that separate a demo from an operational capability. What happens if a source changes its structure? Where are the credentials stored? What happens when a hundred people query it at the same time? How does it recover if it fails? Who controls the versions? How do you audit why it recommended contacting one customer and not another? What guarantees that one customer’s data does not get mixed with another’s? These are not the demands of a large corporate platform. They are the minimum needed to move from a validated idea to something the company depends on.

The hidden cost appears on the day the organization discovers that what it treated as a finished product was, in fact, a proof of concept. Fred Brooks warned of this half a century ago in The Mythical Man-Month: the first system built almost always ends up being thrown away, and the only thing that can be decided is whether that is planned or discovered late.¹⁵ And that is not a failure of vibe coding. It is a failure of leadership in setting expectations, budgets and maturity criteria.

In The P&L Can Be Right I described AI Leadership Debt: the future cost that accumulates when leadership decisions about AI move faster than the organization’s capacity to sustain them. One of its six forms is architecture debt, and vibe coding accelerates it like nothing else. It can be incurred in two opposite ways: using an experimental architecture for something that later needs to scale, be secure and always be available; or demanding from day one an oversized architecture for an idea no one has yet validated. Both destroy value. The first defers rebuilding costs; the second spends capital before knowing whether there is a real need.

Why does vibe coding accelerate it? Because the speed with which a working solution appears compresses the perception of complexity. Leadership sees the result, but not the work still needed to turn it into a sustainable capability. The ease of developing ends up amplifying the cost of not knowing what is being developed.

6Building fast without mortgaging the future

The answer is not to abandon these tools or to return to rigid and needlessly slow processes. That would mean giving up one of the most important transformations in software engineering. The alternative is to harness the speed and introduce, from the start, the minimum controls so that what is built can evolve. I call it evolution-ready vibe coding: the point is not for every prototype to be ready to operate at corporate scale, but to distinguish which decisions can stay in experimental mode and which must be assessed before committing the system’s future.

Seven questions structure that distinction: what problem it solves and how we will know it solved it; how it will evolve; what it could compromise; how we know it works correctly, including edge cases; who understands the system; who is accountable when it fails; and how much it will cost to maintain and scale. Some of those controls can be automated within the generation process itself. Others are explicit decisions that should not be delegated to a model.

The key is proportionality. A temporary internal tool justifies simple controls. An application that processes personal data, supports financial operations or takes part in clinical decisions needs much more demanding standards. In Chile, moreover, Law 21,719 will require organizations to be able to explain automated decisions that significantly affect people and to respond within 30 days to anyone who requests access to their data, something very difficult to do with a system no one understands.¹⁶ Rigor should respond to the system’s risk and impact, not to the tool it was built with.

7When speed becomes a leadership decision

There is a paradox behind all this. As AI automates the writing of code, knowing how to write syntactically correct instructions is worth less. But other capabilities are worth more: architecture, systems thinking, risk assessment, understanding requirements, test design and, above all, the ability to recognize a bad technical decision when it looks good. An experienced developer and a person with no training can build applications that look equivalent. The difference appears when something fails, when requirements change, when users grow or when the system has to be shown to comply with something. At that point, understanding the software stops being an advantage and becomes the condition for controlling it.

That is why training people to use coding assistants is not enough. Organizations need the capability to specify, evaluate, govern and maintain software that, for the most part, no human wrote. AI literacy does not replace engineering, and ease of generation does not replace technical accountability.

From the perspective of AI Value Realization Theory (AVRT), the framework I use to analyze how AI becomes value, the chain does not end when AI produces code. That code has to be validated, integrated into a process, turned into a capability and produce measurable results. Each step can fail, and a solution that starts with positive results can end up destroying value if its maintenance, its risk and its rebuilding cost more than it delivers.

For a board, the question should not be how much faster the company can build software with AI. It should be this: what part of that speed is turning into reliable, maintainable systems capable of generating value over time, and what part into costs we cannot yet see?

Accelerating software production shows up in minutes. Accelerating value creation can only be demonstrated when the system is used, maintained, adapted and evaluated under real conditions. That is where the hidden cost stops being hidden.

AI can make developing software seem simpler and simpler. But simplicity of creation is not simplicity of engineering.

References

1. METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. metr.org
2. METR (2026). Uplift update, February 24, 2026. metr.org
3. Perry, N., Srivastava, M., Kumar, D. and Boneh, D. (2023). Do Users Write More Insecure Code with AI Assistants? Stanford University. arxiv.org/abs/2211.03622
4. Stack Overflow (2025). 2025 Developer Survey.
5. Karpathy, A. (2025). Post on X that coined the term vibe coding, February 2025.
6. Veracode (2026). Spring 2026 GenAI Code Security Update, March 24, 2026. veracode.com
7. Pearce, H. et al. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. IEEE Symposium on Security and Privacy.
8. GitClear (2026). The AI Code Quality Maintainability Gap. gitclear.com
9. Google Cloud (2024). DORA: Accelerate State of DevOps Report 2024.
10. Osmani, A. (2026). Comprehension debt: the hidden cost of AI-generated code. O’Reilly Radar, April 13, 2026.
11. Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA ’92.
12. Kosmyna, N. et al. (2025). Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task. MIT Media Lab.
13. CVE-2025-48757 (2025). Missing access controls in projects generated with Lovable. Reported by Matt Palmer.
14. The Stack (2025). Vibe coding CEO deletes production database, July 21, 2025.
15. Brooks, F. (1975). The Mythical Man-Month. Addison-Wesley.
16. Chile, Law No. 21,719 on the protection and processing of personal data. Library of the National Congress of Chile.

The sales area case is illustrative. The concept of evolution-ready vibe coding is the author’s proposal and has not yet been empirically validated.