Vibe coding promises easy AI-generated software but creates massive shadow IT risks for enterprises. Learn why this trend threatens security, compliance and scale.
Vibe coding is a trending buzzword for conversationally prompting an AI agent to produce software. Its creator, Andrej Karpathy, described the process as “not really coding — I just see things, say things, run things, and copy-paste things, and it mostly works,” and he found it “not too bad for throwaway weekend projects.”
One key distinction between vibe coding and other forms of AI-assisted coding is the acceptance of the code generated by the agent without inspection. When you’re vibe coding, you don’t need to read code or understand how anything works, making it possible for citizen developers to create small-scale applications without learning to code.
There has been a long-anticipated dream of defining software using plain English as the programming language, and vibe coding fits this vision. Solving small challenges with software can be satisfying, like completing a self-repair at home. In the context of Enterprise, vibe coding is less like software development and more like traditional shadow IT.
Vibe Coding Is Spreading Like Shadow IT
Shadow IT happens when business units become frustrated waiting for software they believe will make them more effective. Under pressure to manage increasing workloads and with their IT project slipping further out, it usually falls to a business hero to create an interim solution using tools like Excel, Access, Google Docs, or skipping around the official procurement process.
While shadow IT provides temporary localized pain relief for the business unit, it doesn’t offer a long-term solution. Very often, the main success of such projects is that they result in the urgent reprioritization of the original project when the shadow IT solution blows up.
Software development isn’t just about creating features. Consideration is given to the fitness of the software against non-functional requirements. This includes scalability, legal and regulatory obligations, security, user experience, accessibility, and disaster recovery. Vibe coding, like shadow IT, is largely free from these concerns as the citizen developer is less likely to know or prompt for these concerns.
When the system collapses, the business hero who delivers a shadow IT project quickly becomes the story’s villain. In the meantime, they are trapped in a constant build-and-fix cycle as they try to keep the lights on. We can expect the same from vibe coded applications.
One of the collective delusions that surrounds software development is that someone knows exactly what the software needs to do; they just need someone to code it. As Fred Brooks explained in his paper No Silver Bullet in 1987, “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.”
The Hidden Enterprise Risks of Conversational Code Generation
Let’s get specific about the four reasons vibe coding isn’t appropriate for Enterprise organizations. You may think of many more once you start considering the implications of running on code generated by a computer in response to a conversation, which nobody has read or understood.
Think of this as a starting point for that thought process. All four start with an “S” and we can pronounce the collection “ssss”, like the sound of a metaphorical tire deflating unexpectedly:
- Specification
- Scaling
- Software design
- Security and compliance
1. Specification
We have learned over many decades that it’s hard to specify what a software system should do. We often know the primary use cases but discover plenty of scenarios we hadn’t anticipated as we build the system.
You’ll find two routes to success when creating software that works. The first is building a deep understanding of what users need. The other is to deliver small, rapid changes and experiment your way to success. The best software teams combine both, and the organizations they work for hit more goals than their competition.
By its very nature, vibe coding amplifies specification weakness. Functional and non-functional requirements are missed, and when they are later remembered, there is potential for previously satisfied requirements to be broken when changes are made. In this respect, vibe coding takes us back to the ad-hoc code-and-fix era of software delivery.
In many cases, explaining why a software system works the way it does is essential. When you created it through a conversational vibe-coded approach, the only way to describe the software is by reading the conversation, which may not reflect how the code works. To satisfy regulations around automated decision-making, someone will eventually have to read and understand the code to explain a decision.
2. Why Specification Problems Make Vibe Coding Dangerous at Scale
Skilled software engineers have learned that a few crucial system areas often dictate the ability to scale. Rather than optimizing every function and module, they identify where the investment will meaningfully improve the whole system’s performance.
When vibe coding, there is little expectation that the human will be able to prompt for improved performance, aside from politely asking the agent to make things fast or scalable. As most lines of code in the training data are not optimized for scale, or were optimized for a different profile, the effectiveness of such prompts will be questionable.
Aside from the system itself, there is a need to scale the software delivery process. Enterprise software demands more than one developer to reduce risk, increase understanding, and grow the software’s capabilities over the long term.
This scaling ultimately requires developers to build a shared understanding of the system. This is enabled by documentation but very often depends on the facts evidenced by code written using a programming language.
A modern software development team writes code that is easy to understand, and they’ll prove the system’s behavior with executable specifications. These artifacts provide the ultimate documentation of what the software does. They also contain the cost of maintenance, which is usually many times more than the cost of implementation.
To scale vibe coding, the citizen developers would have access to the conversation streams and AI summaries of the system. Neither of these would provide a precise description of what the system does.
Technically, they would have access to the code, but even a programmer may struggle to understand the source code produced by vibe coding. There is also the question of how collaboration works or how merge conflicts might be resolved by individuals who are unfamiliar with the code produced during this process.
With vibe coding, neither the software nor the process scales.
3. Software Design Is Not A Vibe Coding Priority
The design of the software is always important and occasionally becomes a crucial competitive advantage. Novel architectural choices often provide powerful opportunities for the organization to do something unique.
The decisions made at the software design level are not part of the software’s functional requirement specifications. However, they often impact how easily the software can adapt to future needs.
In vibe coding, design is not a consideration. As you might expect the entire system to be rewritten by an agent if the design is invalidated by a new requirement, this would require some mechanism to ensure all previous instructions are taken into account.
There’s a party game where players must repeat items from a shopping list before adding a new item to the end, creating an ever-longer list to be remembered as play continues. This is the game we will ask our coding agents to handle, and it will challenge current limits on the volume of instructions we can supply while still getting a working result.
For throwaway projects, design need not be too concerning. If you intend to keep the project over the long term, the maintenance cost will be many times higher than the cost of writing the system. Taking steps to control the cost curve is essential to keep software economically viable.
In the future, software consultants will raise their Champagne glasses to the moment Enterprises decided they could vibe code their software. It will pay for these consultants’ super-yachts and kitchen staff for many years.
4. Security and Compliance Nightmares: When AI Writes Your Code
Enterprises have a significant security and compliance burden. Software developers working in large organizations have learned what it takes to secure access, protect data, and meet audit and compliance requirements as part of their work. Every developer I’ve worked with has been familiar with at least ISO:27001 and usually many other standards.
Throughout the delivery pipeline, from repository access and code reviews to deployment and operations, tools and techniques help technical teams meet their compliance needs.
It isn’t easy to reconcile the process of vibe coding with these audit requirements. Indeed, significant additional work would be needed to evidence how the generated code has been checked in the same way as code written by a developer and reviewed by a peer, based on requirements from a product manager.
Some economic model must be built to compare the saved developer time against the increased validation needed to ensure the code is secure, has no unexpected additions that could compromise the system’s privacy, security, and integrity, and meets the original specifications. The cost of compiling the requirements from the conversation will likely outweigh the development cost for Enterprise software.
At the same time, the risk of data loss, breaches, and reputational damage increases dramatically.
How to Protect Your Enterprise from the Vibe Coding Trap
A wicked combination of false assumptions may cause Enterprises to adopt vibe coding to accelerate projects. The imagined economic model is about reducing development costs, but this is incorrect.
Dan Garfield, VP of GitOps and Open Source at Octopus explains it this way: “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 de-risking software delivery while simultaneously increasing the volume of changes past the breaking point.”
We can uncover several assumptions that are not unique to vibe coding, but certainly apply.
Assumption vs. Reality in Software Development
Assumption: The value created during software development is the code.
Reality: The value is the knowledge represented by code and the developers.
Assumption: Creating an application is expensive.
Reality: Maintaining an application is expensive.
Assumption: Generating code saves time.
Reality: Generating code shifts burden from coding to other activities like testing, reviewing, and auditing.
In Enterprise software delivery, these assumptions lead only to future pain.
This article was originally published on The New Stack.
Top comments (0)