The Myth of ‘Vibe Coding’: Why Enterprise Software Still Requires Senior Human Architects
10 Views
Summarize Article
Related Blogs
Summarize Article
On February 2, 2025, Andrej Karpathy coined the term “vibe coding” to describe a specific way of working with AI: describing what you want in plain language, accepting the generated code without reading the diffs, and re-prompting whenever something breaks, an approach he explicitly scoped to throwaway weekend projects and named using Cursor Composer as the example tool, according to reporting on the original post.
Almost exactly one year later, Karpathy himself declared the term passé, proposing “agentic engineering” instead, a model where a developer orchestrates AI agents while providing real oversight and scrutiny, the same reporting shows. The person who coined vibe coding is on record saying the pure, no-review version of it was never meant for professional work in the first place.
That reversal is the entire argument against vibe coding for enterprise, and it did not happen in a vacuum. A rigorous randomized controlled trial found experienced developers were measurably slower with AI coding tools despite believing they were faster, and independent security research has repeatedly found AI-generated code fails basic vulnerability checks at a rate no enterprise codebase can tolerate. This article covers what that data actually shows, what AI application development requires once real users and real data are involved, what cursor composer production apps skip that a senior architect catches, and what enterprise code governance looks like when AI is genuinely part of the toolchain rather than the entire process.
Key takeaways
|
Karpathy’s original description was specific, not a vague reference to “using AI to code.” It meant accepting AI-generated output without reading the diffs, prompting again when something broke rather than debugging it, and letting the codebase grow past what he personally understood in detail, using Cursor Composer as his working example, per the reporting that documented the original post. He was explicit that this was suited to weekend projects, not production systems building revenue-generating software.
A year later, the same reporting documents Karpathy proposing “agentic engineering” as the more accurate name for professional AI-assisted development: a model where the developer is not writing code directly most of the time, but is actively orchestrating AI agents and acting as oversight, with real engineering discipline behind it. The distinction matters enormously for vibe coding for enterprise specifically: the term’s own creator is on record separating “give in to the vibes with no review” from the kind of disciplined, human-supervised AI use that actually belongs in a production environment.
METR’s randomized controlled trial, the gold-standard method for measuring cause and effect, tested 16 experienced open-source developers across 246 real tasks in mature codebases they knew well, using Cursor Pro with Claude 3.5 and 3.7 Sonnet when AI was allowed. Before starting, developers forecast AI would cut completion time by 24%. The measured result was the opposite: tasks took 19% longer when AI tools were permitted. The gap between what developers believed and what actually happened is precisely the risk vibe coding for enterprise runs on: confidence in AI-assisted speed that the data does not support without real review discipline built around it.
Veracode’s 2025 GenAI Code Security Report found 45% of AI-generated code samples across more than 100 tested models introduced at least one OWASP Top 10 vulnerability, with cross-site scripting failing in 86% of tested cases. Vibe coding’s defining behavior, accepting output without reading it, is precisely the practice that turns this statistic from an abstract risk into a production incident. A senior architect reviewing the same output is the control point that catches exactly this class of failure before it ships.
| Trying to figure out where AI-assisted development actually fits in your build?
WebOsmotic scopes AI application development around where AI genuinely accelerates senior engineers, and where human architecture review stays non-negotiable. |
Neither the “AI makes every developer instantly faster” narrative nor a blanket dismissal of AI-assisted coding matches what the actual research shows. METR’s own trial measured experienced developers on codebases they already knew deeply, a specific, difficult scenario for any tool, AI or otherwise, to add value to. That does not mean AI-assisted development never produces genuine speed gains; it means the gains are conditional, dependent on the task, the codebase, and crucially, whether the developer using the tool still applies the same judgment and review discipline they would without it. Vibe coding for enterprise fails specifically where that judgment gets skipped, not wherever AI tools are present.
| Factor | Vibe coding (Karpathy’s original definition) | AI application development done for enterprise |
|---|---|---|
| Code review | Diffs not read; “Accept All” | Every change reviewed with senior-engineer scrutiny |
| Architecture ownership | Emerges implicitly from prompt sequence | Deliberately owned by a senior architect |
| Security posture | Inherits whatever the model generates | Tested against known AI-generated vulnerability patterns |
| Appropriate use case | Prototypes, weekend projects, throwaway tools | Production systems handling real users and real data |
| Accountability | Diffuse; nobody reads the code closely enough to own it | Clearly assigned to a named engineer or team |
The gap between vibe coding for enterprise and a properly governed AI-assisted build comes down to a short list of things a senior architect provides that no amount of model improvement replaces:
| Ready to build AI-assisted software with real architectural oversight?
WebOsmotic pairs AI-accelerated development with senior human review and enterprise code governance built in from day one, not bolted on after an incident. |
Karpathy did not walk away from vibe coding because AI tools got worse. He walked away from it because, in his own telling, professional software development was always going to require the oversight the original definition explicitly excluded. METR’s trial shows the speed benefits of AI-assisted coding are far less automatic than the marketing suggests, and Veracode’s data shows exactly what accepting AI output without review actually ships. None of this argues against AI application development. It argues against skipping the senior human judgment that has always been the difference between a fast first draft and software an enterprise can actually depend on.
Is vibe coding for enterprise ever actually appropriate?
Rarely, and only for genuinely low-stakes, disposable work, an internal prototype, a proof of concept, something explicitly not headed to production. Karpathy’s own original definition scoped vibe coding to exactly this kind of work, and his later pivot to “agentic engineering” reflects the industry’s recognition that production software, especially at enterprise scale, requires the review and oversight the original definition specifically excluded.
What does the METR study actually prove about AI coding tools?
It shows that in a rigorous randomized controlled trial, 16 experienced developers working on real tasks in codebases they knew well were 19% slower when using AI tools, despite predicting beforehand that AI would make them 24% faster. It does not prove AI coding tools are never useful; it shows a documented, measured gap between how fast developers believe AI makes them and how fast it actually does, in this specific tested scenario.
Why does AI application development still need senior architects if the tools keep improving?
Because the risk AI-generated code introduces is not primarily about model capability, it is about review discipline. Veracode’s research found 45% of AI-generated code samples introduced a known vulnerability class regardless of which model produced it. A senior architect provides the judgment to catch these issues and the system-level context to know which parts of a codebase can tolerate AI-generated speed and which cannot, a role that improving model quality does not eliminate.
What is the difference between cursor composer production apps and a properly governed AI-assisted build?
The difference is not the tool, both can use the same editor and the same models. It is whether every AI-generated change goes through the same review, security testing, and architectural scrutiny a human-written change would receive, or whether it is accepted based on the fact that it runs without producing an obvious error. Karpathy’s own original definition of vibe coding described exactly the latter pattern.
What does genuine enterprise code governance for AI-assisted development actually look like?
It looks like mandatory review of every AI-generated change with the same rigor applied to human-written code, security testing specifically calibrated to the vulnerability classes AI-generated code is known to introduce, clear ownership and accountability for every change regardless of who or what wrote the first draft, and a senior architect with the standing authority to slow down on the specific parts of a system where a mistake would be genuinely costly. Governance built this way is what actual enterprise code governance requires, and it is the practical difference between vibe coding for enterprise and AI-assisted development an enterprise can actually stand behind.
Vipul Jain is the Founder of WebOsmotic, a product-focused engineering company, with over 16 years of experience partnering with CTOs and founders globally. He leads a team of 90+ engineers specializing in Mobile, Web, GenAI, Automation, and Cloud solutions, delivering scalable and high-quality products. Known for his transparent approach and strong execution, Vipul focuses on bridging the gap between technology and business strategy, helping organizations reduce complexity and bring their ideas to market efficiently.
