Does vibe coding have a place in the enterprise? Yes and no

There’s a long history of tools in the enterprise that shine in isolation but collapse under scale. From Visual Basic macros and embedded web scripts to sprawling Excel spreadsheets and low-code apps built on soon-to-be-obsolete platforms, the pattern repeats — systems that feel like software, behave like software, but lack the structure to survive when enterprise-level scale and complexity inevitably come knocking. And I certainly have my fair share of battle scars from rescuing critical business functions from unmanaged Access databases created by naïve but well-meaning business colleagues.

The cold sweats of those experiences return often these days when I see claims that vibe coding can take care of 95% of development work. The details might be different — but the pattern feels uncomfortably familiar. Because from my perspective, AI-based vibe coding, whether freshly minted by upstart vendors or introduced into existing low code tooling by enterprise stalwarts, looks an awful lot like that — trading the understanding, scale, integration, and maintainability critical for enterprise systems for the transitory benefits of a quick hit based on simplicity, speed, and convenience.

Because unlike vibe-coded apps, enterprise software doesn’t exist in a vacuum. It needs to be understandable not just to a single vibe coder but to whole teams of people who must maintain and evolve it over time. It also operates inside the complex web of existing processes, architectural standards, security models, regulatory constraints, vendor ecosystems, and lifecycle expectations that make up a modern enterprise. But vibe coding tools don’t know any of this because they’ve only been trained on the public Internet.

Confidence without understanding

Ask a vibe coding tool to build tests to prove that the application it’s building works and it might produce code — and outputs — that look plausible, but which simply give you the answers you want without really running any tests. Tell it to build a lead management application, and it may choose structures that are easily compromised and leak sensitive data under real-world usage. And irrespective of your intended solution, the new phenomenon of ‘slopsquatting’ now means that malicious actors can take advantage of LLM hallucinations — pre-emptively registering frequently referenced code packages that don’t exist so that vibe-coded applications can be turned into an attack vector without its creator even realizing it.

Because these systems aren’t reasoning with a comprehensive understanding of your intent and context — they’re at best approximating what they think you want based on global averages, and at worst actively misleading you by trying to give you the appearance of what they think you want without actually doing it. As Steve Jones points out, the idea that the appearance of something working is the same as something actually working is not a credible heuristic. And while ‘traditional’ low-code tools provide deterministic outputs by constraining the target solution architecture in a top-down manner, the new wave of AI-based tools have few such constraints, instead simply generating code bottom-up based on statistical models. Understanding enough to tell if the resulting solution actually works — assuming the typical vibe coder even has the technical skills necessary to continually evaluate the code — therefore means maintaining a state of constant vigilance, something that Cory Doctorow, author and digital rights advocate, points out humans are pretty bad at:

Humans are good at a lot of things, but they’re not good at eternal, perfect vigilance. Writing code is hard, but performing code-review (where you check someone else’s code for errors) is much harder — and it gets even harder if the code you’re reviewing is usually fine, because this requires that you maintain your vigilance for something that only occurs at rare and unpredictable intervals.

This is why we have evolved our complex web of policies, tools and standards in the enterprise — to build the institutional knowledge necessary to protect us from these failure modes. And in traditional development, this institutional knowledge and governance is used to prevent, catch, and reject these risks. But vibe coding tools don’t share this institutional knowledge — leading non-specialist users into dangerous waters.

No blueprint, no recovery

And even when the system ‘works’, there’s often no record of how or why. The logic lives inside a conversation that no one else can see. There’s no design artifact, no documentation, no shared understanding of why the application was built as it was — because the decisions were made by the tool. From this perspective vibe coding risks becoming the next wave of shadow IT — development that bypasses oversight in the name of speed, only to introduce future brittleness and duplication. But this time, it doesn’t run on spreadsheets or deterministic low code platforms that we can somehow understand — it runs on opaque codebases shaped by decisions we have no sight of. And unlike these familiar forms of shadow IT, there’s no easy way to spot when they’ve drifted from requirements or become too fragile to extend. The scale is faster, the opacity deeper.

In an enterprise context this is clearly an unacceptable risk: you cannot maintain, extend, or secure what you can’t explain. These black-box creations may serve a purpose briefly but when they break, they break hard — and frequently the only remedy is to start over. Recovery isn’t just inconvenient — it’s often impossible. Because while there may be some rudimentary version control in place, this only really provides the opportunity to rewind changes to a previous checkpoint before re-rolling the dice on another attempt to get what you want. And while it’s technically possible for your engineers to try and step into the generated code and fix intractable issues directly, the likelihood that they will be able to understand and fix a sprawling codebase created by a probabilistic turn-based generation machine feels remote — especially when understanding fully documented code written by other humans can often feel more difficult than starting from scratch.

For critical applications, therefore, these issues are not just a problem — they’re a disaster. Because when significant numbers of customers rely on you every day — to move their money, provide their food, clothe them, or even just entertain them when they’re bored — they expect you to be there.

But this is how small experiments gradually become systemic liabilities — fast, fragile systems that no one owns, everyone relies on, and nobody wants to touch for fear of breaking them.

A role worth reframing

But this doesn’t mean that vibe coding has no place in the enterprise. Quite the opposite. As I discovered in a recent workshop, its strength lies in rapid ideation. And so when used responsibly it can empower teams to sketch interfaces, simulate flows, and accelerate discovery — without waiting in a backlog queue or wasting scarce IT resources on experiments that may lead nowhere.

But this only works if the enterprise creates safe environments for experimentation. That means:

• Sandboxed environments with limited scope and access
• Clear boundaries for what vibe-coded tools can and cannot do
• Structured handoffs to engineering teams when prototypes show promise

And above all, it means recognising the limits of natural language as a design interface. Words alone are too vague for durable systems. We need structured abstractions — visual flows, interface patterns, domain-specific templates — that better enable us to translate aspiration into architecture while simultaneously creating a lasting and meaningful record of our intent and design decisions for those who come after.

My take

Software engineering, as practised in enterprises today, is going nowhere.

Software engineering isn’t simply about code — it’s about safely navigating the web of decisions, policies, and infrastructure that shapes the specific form and culture of any modern enterprise so that it can deliver secure, scalable, and sustainable software. And while vibe coding tools can generate code, they can’t (yet) address this critical wider context.

But when you remove real software engineering from the discussion, it’s clear that vibe coding has significant potential for supporting ideation and innovation — as long as the opportunities for rapid experimentation are balanced with the controls necessary to properly sandbox it. Being able to test hundreds of new ideas cheaply using throwaway black boxes is great. Deploying hundreds of insecure and unsupportable black boxes into production — not so much.

Because while vibe coding tools lower the barrier to innovation, they also significantly raise the risks of outages, new attack vectors, or exploding technical debt if used unchecked — much like the Access databases in that long ago company. The tools may be different, but the danger is the same — systems that start as workarounds or interesting innovations but quietly become liabilities. Left ungoverned, these systems can become hidden threats — and are often hard to spot until it’s too late.

To safely harness vibe coding, therefore, enterprises need to see beyond the illusion of simplicity and confront its operational fragility head-on. This means applying the same disciplines they’ve learned from past encounters with shadow IT — clear boundaries, sandboxed environments, and structured handoffs of promising prototypes to professional engineering teams. Vibe coding is a great sketchpad for ideas but those sketches can quickly turn into costly failures without disciplined governance.

Because at this scale it’s not enough to just sketch ideas — reliably building for scale and sustainability requires a full blueprint. So think ‘accelerated conversations’, not ‘systems of record’. But this isn’t a rejection—it’s a reframing. If we treat vibe coding as a high-speed sketchpad, we can unlock its strengths while protecting against its shortcomings.

So by all means embrace the vibe. But just don’t skip the engineering.