What to Do When Everyone's Vibe Coding

Taming the euphoria, keeping the craft, and figuring out where it fits in the enterprise stack.

If you’ve been there you understand. The euphoric state where time stands still and you eventually realize you’re hungry because you buzzed right through a meal or two. The screen, the model, the chain of fixes, the next idea, the next idea, the next idea. And then somewhere around hour five you sit back, look at what you’ve built, and feel two things at once. Triumph and confusion.

So let’s talk about it.

What Vibe Coding actually is

Vibe Coding is most commonly understood as using an AI chat-enabled software tool that lets you talk with an AI agent which, in turn, writes code based on what you describe. The term “vibe” stuck because rather than writing lengthy requirements documents or user stories, you can just type whatever whim or idea you’re feeling into the chat, and the code is written based on that “vibe.”

For example, a typical user story might look something like:

As a user, I want a webpage that allows me to upload a financial report and generates a profit and loss statement, so that I can understand how my business is performing.

You’d hand this story to a dev team. They’d bring it into their regular backlog refinement, ask clarifying questions, break it into technical requirements and sub-stories, agree on acceptance criteria, and finally estimate it with a pointing system. Then they’d pull it into the next sprint, which might be a week from now, and complete it within the next two weeks. In a typical IT context, that’s considered fast. And in many organizations, you still have to follow your ITIL change management processes, which means waiting for a change window to push it into production. That could be a couple more weeks.

Now contrast that with Vibe Coding. To get a similar outcome, you might just type into the coding app:

I want a webpage that lets me upload a financial report and generates a profit and loss statement so I can understand how my business is performing.

A few moments later, the code is written. You’re testing the webpage in a browser, uploading your financial report, and looking at the AI’s first pass at the format. From here you might continue:

Make the profit and loss statement include months and quarters with totals for each. Use a blue and white color scheme. I’ve included my company logo, put that in the top left header.

And at your whim and command, it’s done. If you run into an error or have another idea, you just keep going until you have the outcome you wanted.

The tools doing this work are typically Cursor, Copilot, Claude Code, or the corporate API tier your company just unlocked. The tools differ, but the loop is the same.

It is a real thing. It’s not a fad. And it’s not, by itself, a problem.

What I want to do here is offer a practitioner’s perspective on where it sits, particularly inside the enterprise, because I keep seeing the same pattern play out. Including, honestly, in myself.

The euphoria is real (and it’s a signal)

The first time you build a working multi-service app in an afternoon, something you’d have estimated at six weeks two years ago, you feel like a wizard. You should. That feeling is real and it’s earned.

But euphoria is a signal, not a destination. The same chemistry that makes you feel unstoppable is the chemistry that talks you out of stopping.

This is where you have to understand what this is and what it’s not.

The oil painting problem

Here’s the failure mode I see most often.

You’re working on a feature. The model fixes one thing and breaks two others. You ask it to fix those. It breaks a third. You keep going. You’re four hours deep, you’re out of tokens, you’re getting errors you don’t understand, and the only thing keeping you in the chair is the sunk-cost feeling that you’re almost there.

You are not almost there. You are overworking the painting.

When I was in art school, one of the things you learn sooner or later is not to overwork your painting. There’s a point where the composition might be right, but you just can’t get the detail of one part quite right. So you add more paint. You try to blend. And it becomes a muddy, unrecognizable area on your masterpiece. It’s time to put the brushes down, walk away for a while, let the paint dry, and come back with a clear head and fresh eyes.

Vibe Coding has no equivalent forcing function. The tools don’t tell you to stop. The euphoria doesn’t tell you to stop. So you keep mixing wet paint into wet paint, and what you end up with is a smear.

The discipline that matters here is the discipline to pause and refactor. To step back, look at what you’ve actually built, decide what’s load-bearing and what’s scaffolding, and rebuild deliberately. That’s not the LLM’s job. That’s yours.

What doesn’t change

A lot of the conversation around AI-assisted development treats the fundamentals of good, well-proven IT best practices as legacy concerns. Things we’ll automate away soon enough. I don’t buy it. Not yet, and not for the kinds of systems most enterprises actually run.

Things that haven’t changed:

• Infrastructure still has to exist somewhere other than your laptop.

• Architectural decisions still compound. The ones you made in hour two will define what’s possible in week twelve.

• UI and UX still require intention. A well-prompted interface is not the same as a well-designed one.

• Observability, security, data handling, identity. None of this gets easier because an LLM wrote the function. You still need a solid cybersecurity posture to address new threats, and if your newly “vibed” app never took that into consideration, you’re not just introducing technical debt. You’re welcoming your next breach.

The Vibe Coding tools can carry you a remarkable distance. They cannot carry you across these.

Don’t get me wrong, there are portions of each of these disciplines that absolutely should be automated with agentic AI agents. But that’s a different thing. A well-trained, purpose-built AI agent is not the same as an IDE on a laptop supercharged with an LLM.

Where Vibe Coding sits in the enterprise stack

This is the part I think gets underdiscussed.

In a large enterprise, and I mean a real enterprise, not a tech company, you now have a population of pseudo-technical builders with corporate API access to frontier models, Cursor or Copilot on their laptops, and the ability to spin up something that aggregates data in ways they’ve never been able to before. That’s powerful. It’s also a new flavor of shadow IT.

The traditional IT processes those builders are bypassing are, yes, often too slow. ITIL change management on a prototype is absurd. I’d be the first to say a lot of it should be automated, and AI is a real opportunity to do exactly that. But the processes exist for reasons. Security, sustainability, integration, the boring stuff that keeps the company running. And a prototype that “works on my laptop” is not a solution to any of those reasons. It’s a demo.

So where does Vibe Coding sit? Honestly:

• Prototyping and exploration. Excellent fit. Use it. Move fast.

• Internal tools with a known small audience. Good fit, with guardrails.

• Production systems with real users, real data, real uptime expectations. Not a substitute for engineering. A complement, at best.

The mistake I see leaders making is treating all three of those as the same thing because the output looks similar. It isn’t.

Best practices, not governance

I’ll be honest, “governance” is a word that makes me tired. In most large enterprises, you’ve already got more of it than you can carry. The instinct to wrap every new capability in another policy layer is exactly the instinct that pushes builders toward shadow IT in the first place.

What I’d argue for instead is best practices. The same fundamentals that have always separated sustainable systems from clever demos, applied with the same energy we’re bringing to the new tools. Define the outcome before you start. Know which layer of the stack you’re operating in. Pause and refactor when the painting gets muddy. Treat “works on my laptop” as a starting line, not a finish line.

That’s not governance. That’s craft.

The frame I’d offer

The leaders I talk to keep saying some version of the same thing. I see all this happening with agentic AI and Vibe Coding, but I don’t think anyone really knows what to do with it yet.

I think that’s honest, and I think the way through it is less mystical than it gets made out to be.

Vibe Coding is a tool. A powerful one. It compresses time in ways we haven’t seen before. But it doesn’t replace the parts of the work that were never really about typing. The thinking, the architectural judgment, the willingness to throw away the first three attempts because they were wrong.

You can write 1,832 lines of code in five hours. But if you’re not careful, you’ll be vibing your way out of a production outage and out of tokens at the same time.

So here’s the question I’d leave you with. In your team, on your project, in your enterprise, where is Vibe Coding actually sitting right now? And is that where it should be?

---

Next up: Keeping Your Craft. Why augmentation beats substitution, and what AI should and shouldn't replace in the work of a builder.