Vibe coding is what happens when you treat AI as a code typewriter instead of a partner.
You skip the specs. Skip the design thinking. Skip telling the AI what your architecture actually is. Then you’re shocked when:
- Hallucinations stack — The AI guessed once. Now that guess is “the pattern.”
- Knowledge vanishes — Nobody wrote down why. Good luck when the person who prompted it moves on.
- Quality has no guardrails — You’ll find the bugs after deployment, not before.
Vibe coding is dead (but your org still does it)
Key question: If your team just prompts an AI to “build me a login form,” what actually happens? Better yet, what doesn’t happen?
Ad-hoc prompting without specs feels fast. It is fast, in the moment. You get code. It compiles. It runs. Ship it.
Then someone tries to understand why that login form handles tokens the way it does. Or why the error messages are inconsistent with the rest of the system. Or why the code nobody remembers writing now handles passwords differently than everywhere else.
That’s when vibe coding stops being fast.
The problem with “let’s see what happens”
Vibe coding is prompting without intent clarity, without specifications, without design thinking. Just ask the AI what you have in mind and see what you get.
Three things break immediately.
First: hallucination compounds. When you ask an AI to build something without clear specs, it makes assumptions. Those assumptions are reasonable. They’re just not your/our assumptions. The AI follows conventions it learned from training data, conventions that might not match your architecture, your security model, your data flow patterns. The guidlines and principles in your organisation. How would the AI agent/tool be supposed to know that, anyway? After all, it wasn’t told. Each hallucination becomes encoded in the code. Next prompt assumes those are now correct. Hallucinations stack.
Second: knowledge gets lost. When an AI generates code without a spec, nothing explains why. No design rationale. No tradeoff discussion. No “we chose this approach because.” The developer who asked can explain it, for now. But they move on. The next person who touches that code has to reverse-engineer the decisions encoded in the implementation. But not all decisions are visible in the code. That’s expensive. It’s also error-prone. You lose institutional knowledge every time you re-litigate a design decision you already made.
Third: quality has no guardrails. Without specs, there’s nothing to validate the code against. Did it do what you actually needed? No way to know except “does it work for me right now?” The generated code passes no architecture review because there was no architecture to review against. It gets no security gate because nobody checked what it should be secured against. Testing is reactive, you find bugs after deployment, not before.
Vibe coding creates a codebase that feels productive in sprint 1 or 2, but becomes unmaintainable by sprint 4 or while the initiator changes.
Why enterprises can’t afford this
For small projects, ad-hoc might work. One person. Clear mental model. Short lifespan. Go fast, throw away.
Enterprises don’t have that luxury.
Your codebase is 5 years old. And is expected to remain in active service for at least a further 5 years. Multiple teams have contributed. You have regulatory requirements. You have integrations with (of course) 42 other backend systems. You have architects who need to understand your design decisions so they can prevent conflicts with new work. You have compliance auditors asking why your code does what it does.
Vibe coding breaks all of that.
When a financial services company generates code through vibe prompting, compliance asks: “Who decided the data would be handled this way? What review gate approved this?” If the answer is “the AI decided,” that’s not governance. That’s a gap. And a risk.
When a healthcare organization has three teams vibe coding the same clinical workflow three different ways because nobody specified the expected behavior, you don’t have integration. You have silos held together by guesses. And a risk.
When your architecture team tries to prevent duplicate integrations with your payment system, they can’t, because vibe coded payment integrations exist in four places, none of which were designed to the same spec.
These are all problems and challenges that we had, after all, solved. Architecture. Modularisation. Standards. SOLID?!
The velocity trap
Here’s what makes vibe coding seductive: it feels fast.
“Write me a REST API for orders” takes 30 seconds to prompt and 2 minutes to get code back. That’s faster than designing an API, writing a spec, reviewing it with your team, and then generating code.
For one API, this math works. You save time.
For 50 APIs built through vibe coding without shared patterns, the math breaks completely.
The 51st API is now harder to build because it has to figure out which of 50 different conventions to follow. Or invent a new one. The integration team has to handle 50 different error-handling patterns instead of one. The security team now has to audit 50 different authentication implementations.
Each API was a tiny speedup. Together, they’re a massive slowdown. Plus technical debt you can’t easily fix because the debt is scattered across 50 places with no unifying pattern.
Vibe coding trades short-term velocity for long-term cost explosion.
What replaces it
The alternative to vibe coding isn’t “don’t use AI.” It’s using AI more rigorously.
Instead of: “Build me a login form”
You need: “Build a login form that implements OIDC with these constraints: [A, B, C, ..]. Error handling follows this pattern: [A1, A2, …An]. Integration with the session system: [B1, B2, …]. Security audit requirements: [S1, S2, …, Sn].”
The difference is a spec.
With a spec, the AI doesn’t hallucinate about your architecture, it follows the architecture you’ve already defined. The next person who reads the code can understand why the decisions were made, the spec explains them. When you need to change the behavior, you change the spec and regenerate, not fumble through generated code hoping you don’t break something.
Specs aren’t slower. They’re foundational. They’re what makes AI generated code reliable.
This is what spec-driven development is. We’ll dig into how it works and why harness engineering makes it possible.
But first, understand: vibe coding isn’t a feature of AI development. It’s a “bug”. A very tempting bug that feels like productivity until it isn’t.
If your team is still doing it, you have a problem you probably don’t realize yet. Give it 6 months and you will.
Key tensions this raises
- Speed now vs. speed later: Vibe coding is fastest today. Is it fastest over 12 months?
- Velocity vs. governance: Does your architecture have authority if nobody specifies the design?
- Knowledge capture vs. code generation: Who remembers why this code exists when the developer who prompted it moves teams?
What’s next
The next article shows why specs alone aren’t enough. You need something else. That something else is harness engineering.
References
- “TODO: Fix the Mess Gemini Created” — GenAI-Induced Self-Admitted Technical Debt | Documents technical debt accumulation patterns in AI-generated codebases
- DORA ROI of AI-Assisted Software Development 2026 | Metrics on quality degradation and governance gaps in unstructured AI development
Disclaimer
This article is part of a series exploring challenges and approaches in AI for SDLC and PDLC, covering architecture, methods, and sovereignty.
The AI space moves fast. What works today may feel outdated tomorrow and wrong the day after. Review these ideas critically and decide what applies to your context.
These views reflect the state of knowledge at the time of writing. No guarantee of correctness, especially as the field evolves.
Last Updated: 2026-05-03