Vibe Coding: AI's Hidden Shadow IT Threat to Enterprises

Vibe coding, a burgeoning buzzword in the tech world, describes the process of generating software by conversationally prompting an artificial intelligence agent. Its proponent, Andrej Karpathy, famously characterized this approach as “not really coding — I just see things, say things, run things, and copy-paste things, and it mostly works,” deeming it suitable for “throwaway weekend projects.” A key differentiator of vibe coding from other AI-assisted methods is the uncritical acceptance of the agent-produced code. This allows “citizen developers,” those without formal programming training, to create small-scale applications without needing to understand the underlying code or how it functions.

This vision aligns with a long-held ambition: defining software using plain English as the programming language. While solving minor challenges with software can be satisfying, akin to a successful home repair, its application within an enterprise context bears a striking resemblance not to traditional software development, but to the problematic phenomenon known as shadow IT.

Shadow IT emerges when business units, frustrated by the slow pace of official IT projects, take matters into their own hands. Under pressure to manage escalating workloads, they often turn to “business heroes” who cobble together interim solutions using readily available tools like spreadsheets or databases, frequently bypassing official procurement processes. While these ad-hoc solutions offer localized, temporary relief, they rarely provide a sustainable long-term answer. More often than not, their “success” lies in compelling the urgent reprioritization of the original project, usually after the shadow IT solution inevitably fails.

True software development encompasses far more than merely creating features; it necessitates a rigorous consideration of non-functional requirements. These include crucial aspects such as scalability, legal and regulatory obligations, security, user experience, accessibility, and disaster recovery. Vibe coding, much like shadow IT, largely sidesteps these critical concerns, as citizen developers are unlikely to be aware of them, let alone prompt the AI to address them. When such systems inevitably falter, the very “business hero” who championed the shadow IT project often becomes the villain, trapped in a ceaseless cycle of fixes as they struggle to keep the system operational. The same fate awaits applications born from vibe coding.

A pervasive misconception in software development is the belief that someone knows precisely what the software needs to do, requiring only a coder to implement it. As Fred Brooks elucidated in his seminal 1987 paper, “No Silver Bullet,” “The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”

For enterprise organizations, vibe coding introduces four critical areas of risk, often summarized by four “S” words: Specification, Scaling, Software Design, and Security/Compliance. Together, they sound like a metaphorical tire slowly deflating.

Firstly, Specification: Decades of experience have taught us the immense difficulty in precisely defining a software system’s requirements upfront. We often grasp primary use cases but discover a multitude of unanticipated scenarios during development. Successful software creation typically involves either cultivating a deep understanding of user needs or iteratively delivering small, rapid changes to experiment towards success. The best teams combine both. Vibe coding, by its very nature, exacerbates specification weaknesses, leading to missed functional and non-functional requirements. When these are later identified, subsequent changes can inadvertently break previously working features, effectively reverting software delivery to an ad-hoc “code-and-fix” era. Furthermore, explaining how a system works is often essential, especially for regulatory compliance concerning automated decision-making. With vibe-coded software, the only “documentation” might be the initial conversational prompts, which may not accurately reflect the generated code’s true behavior, ultimately requiring human inspection and understanding.

Secondly, Scaling: Beyond the direct performance of the system, enterprise software demands a scalable development process. This necessitates collaboration among multiple developers to mitigate risk, foster shared understanding, and ensure long-term capability growth. This shared understanding is built through documentation and, crucially, through code written in a human-readable programming language. Modern development teams craft code that is easy to comprehend and validate system behavior with executable specifications, which serve as the ultimate documentation and largely dictate maintenance costs—often many times the initial implementation cost. Vibe coding, however, offers only conversational streams or AI summaries as “documentation,” neither of which provides a precise system description. While the raw code is accessible, even experienced programmers may struggle to decipher AI-generated source code, posing significant challenges for collaboration, code reviews, and resolving merge conflicts among individuals unfamiliar with its idiosyncratic structure. Neither the software nor the development process scales effectively with vibe coding.

Thirdly, Software Design: The architectural design of software is always important and can even become a critical competitive advantage, enabling unique organizational capabilities. These design decisions, distinct from functional requirements, profoundly influence how easily the software can adapt to future needs. In vibe coding, design is largely an afterthought. The expectation might be that the entire system could be regenerated by the AI if design principles are invalidated by new requirements. However, this would necessitate a mechanism to ensure all prior instructions are accurately carried forward, akin to a party game where players must recall an ever-growing list of items. For “throwaway” projects, design concerns are minimal, but for long-term systems, maintenance costs will dwarf initial development. Ignoring design makes controlling this cost curve nearly impossible, making the software economically unviable.

Finally, Security and Compliance: Enterprises face immense security and compliance burdens. Developers in large organizations are well-versed in securing access, protecting data, and meeting audit requirements (e.g., ISO:27001). Throughout the development pipeline, from code repositories to deployment, tools and techniques ensure compliance. Reconciling vibe coding with these rigorous audit requirements is profoundly difficult. Significant additional work would be required to demonstrate that AI-generated code has been vetted with the same rigor as human-written, peer-reviewed code based on product specifications. The economic model of “saved” developer time must be weighed against the dramatically increased validation needed to ensure the code is secure, free of hidden vulnerabilities, and compliant. The cost of compiling requirements from conversational prompts alone could easily outweigh any perceived development savings, while simultaneously escalating the risks of data loss, breaches, and reputational damage.

The lure of vibe coding for enterprises stems from a dangerous combination of false assumptions, particularly the notion that it will reduce development costs. As Dan Garfield, VP of GitOps and Open Source at Octopus, aptly puts it, “The biggest challenge with vibe coding in the Enterprise has nothing to do with the quality of models, or the potential inexperience of engineers. It’s that vibe coding exponentially increases the importance of testing and derisking software delivery while simultaneously increasing the volume of changes past the breaking point.”

The underlying assumptions are common but fundamentally flawed:

• Assumption: The value created during software development is solely the code itself.

• Reality: The true value lies in the knowledge embodied by the code and, crucially, by the developers who understand and maintain it.

• Assumption: Creating an application is the most expensive part.

• Reality: Maintaining an application over its lifecycle is often far more costly.

• Assumption: Generating code saves time.

• Reality: Generating code merely shifts the burden from coding to other, often more complex, activities like intensive testing, thorough reviewing, and stringent auditing.

For enterprise software delivery, these false assumptions pave a direct path to future pain, transforming a perceived shortcut into a costly detour.