Vibe Coding Isn't Your Problem—Your Prompts Are

There's a term floating around tech circles now: "vibe coding." It means writing code by describing what you want to an AI in natural language, then iterating on the results until something works. It sounds chaotic. It is chaotic. But the chaos isn't coming from the AI—it's coming from how we're actually using it.

The real issue is that we've spent decades training people to think in vague terms while managing in the same language, and now we're surprised when that translates poorly to machine instructions. The fault line runs deeper than AI capability. It's about communication, governance, and the fact that managers have been vibe coding all along.

We've Always Been Fuzzy on Specs

Let's start with the uncomfortable truth: management has operated as vibe coding for years. A manager hands off a vague requirement ("make it faster," "improve user experience," "reduce technical debt") to an engineering team, who then has to reverse-engineer the actual intent through meetings, Slack threads, and educated guesses. Sometimes it works out. Often it doesn't.

When that same manager now sits down with Claude or ChatGPT and says "build me a dashboard that shows what my team is up to," they're using the exact same communication pattern. The difference is the AI won't push back in a Slack DM at 4 PM asking clarifying questions. It will just generate something, and that something will reflect the ambiguity of the input.

The problem isn't the AI—it's the prompting. Poor prompts produce poor outputs, but the gap between "I know what I want" and "I can describe what I want precisely" has always been vast in technology. We're just feeling it differently now because the feedback loop is instantaneous.

Precision Is the Real Lever

When someone sits down with an AI and produces garbage code, the instinct is to blame the tool. "AI hallucinated," "it doesn't understand context," "we can't trust it." Sometimes that's true. More often, though, the problem is that the person asking the question hasn't done the cognitive work of actually specifying what they want.

This isn't new. It's the same reason most software projects fail—unclear requirements. The AI just makes the failure obvious faster.

A vague prompt like "write code to process customer data" will produce something generic and probably wrong. A precise prompt that specifies data structure, validation rules, error handling, and the actual business logic needed produces something substantially more useful. The quality of the output is almost entirely dependent on the quality of the specification.

That specification work—really thinking through what you need, not just gesturing at it—is where the actual value lives. It's also where most people skip out.

Shadow IT Gets Real When You Skip the Specs

Here's where vibe coding becomes a business problem rather than just a tech problem.

When individual contributors, specialists, or even teams start using AI to build tools without going through formal specification, architecture review, or governance processes, you get shadow IT. KPMG has noted that vibe coding is creating genuine risks around uncontrolled shadow IT, particularly in specialized departments where people have domain expertise but no formal software development training.

The scenario is predictable: an accountant builds a little tool to automate report generation. A marketer writes a script to process campaign data. An analyst creates a dashboard using AI-generated code. Each one solves a real problem. None of them go through IT review. None of them document their dependencies. None of them are backed up or maintained. Two years later, someone's promoted, the tool breaks, and now you have dead code running in production that nobody understands.

The risk compounds when these tools handle sensitive data or integrate with critical systems. A well-intentioned specialist with AI-powered coding ability is still a specialist without security training, without knowledge of compliance requirements, without DevOps discipline.

The solution isn't to ban vibe coding. It's to make specification and governance parts of the expected process, not optional gates you skip to move faster.

The Actual Framework

If vibe coding is here to stay—and it is—then the move is to make it slightly less vibes-based. That means:

Specification first. Before you talk to the AI, write down what you're actually trying to do. Not in natural language prose (that's still vague), but in requirements. What data goes in? What comes out? What should happen if something breaks? What compliance or security constraints exist? This is work, but it's work that prevents worse work later.

Iterate on spec, not on code. Most people get this backwards. They throw a half-formed idea at the AI, get back some code, then iteratively modify the code until it works. Better approach: iterate on the specification until it's clear, then generate code. Once code generation is involved, most of the iteration should be testing and refinement, not conceptual redesign.

Default to architecture review for anything that touches systems or data. Vibe coding is fine for throwaway scripts. It's not fine for things that integrate with production databases, APIs, or sensitive customer information. Simple filter: if you wouldn't feel comfortable having someone with no context inherit this code, it needs review.

Treat AI-generated code like contractor code. It works, but you own it. That means documentation, tests, and an understanding of what it actually does. If you can't explain the code to someone else, you don't really understand it.

The Uncomfortable Part

The real problem with vibe coding isn't that it exists. It's that it's cheap, which means more people can build more things, which means the difference between "technically works" and "should exist" gets blurrier.

A developer building vibe code has to care about it working and being maintainable. A specialist with AI tools just needs it to work now. The debt gets kicked downstream.

The solution isn't to prevent people from using these tools. That's both technically impossible and strategically stupid. It's to build actual governance around what gets shipped, who maintains it, and what happens when it breaks. That looks like:

• A lightweight specification requirement (30 minutes of thinking beats 3 hours of debugging)
• Clear ownership and maintenance expectations
• A sensible definition of what requires formal review (anything touching prod data: yes)
• Training that teaches people how to ask better questions

What This Actually Costs

None of this is expensive in absolute terms. It's mostly about process and expectations. The cost is in saying no sometimes, or saying "not yet—let's spec this out first."

The alternative cost is higher. Shadow IT that breaks in the middle of quarter-end close. Compliance violations because nobody realized the tool was processing PII. Tribal knowledge locked in someone's laptop because the code was too clever and too poorly documented.

The AI part is doing what it was designed to do. The problem is that we're using it to accelerate bad habits—vague thinking, skipped steps, decision-making by iteration—rather than as a tool for executing clear plans.

Fix the specification. Fix the process. Keep the AI. That's how vibe coding becomes something less chaotic: not by changing the tool, but by being more intentional about what you ask it to do.