When Vibe Coding Hits a Wall

This post is a discussion of AI-Driven Development: From Vibe Coding to Structured Methodologies by Aakash Kavuru. Worth reading in full.

Vibe coding is fun. You describe what you want, the AI writes it, you ship. It works great for the first two weeks. Then the codebase grows, the AI starts misunderstanding context, and you spend more time fighting the output than building.

This is not an AI problem. It is a documentation problem you ignored because the AI made it easy to ignore. The original article puts it well: the root cause of almost every failure in AI-driven development is that “what needs to be created remains undocumented.”

Why Vibe Coding Works at First

Vibe coding means no spec, no formal plan. You describe what you want and iterate on the output. It is fast because everything fits in your head.

Picture a weekend project. Three files, one feature, all context in one conversation. You prompt, you get code, you ship. Done in three days.

Now imagine six months in: thirty files, two contributors, requirements that changed four times. You ask the AI to add a feature and it technically does, but something else shifts. You fix that, something else shifts again. You are no longer building. You are chasing drift. The AI did not get worse. The problem is that intent was never written down, so there was nothing to keep the output anchored.

Where It Breaks

The breakdown has a specific feel. The code works. Tests pass. But the behavior is subtly wrong in ways that are hard to explain.

For example: you prompt “add a notifications feature.” To you, that means email digests once a day. The AI builds real-time push notifications. Both are valid interpretations of the prompt. The AI is not wrong. The prompt was just ambiguous.

At small scale, the AI guesses right often enough that it does not matter. At larger scale, every wrong guess compounds. The article calls this “implementation drift from specification.” A simpler way to say it: you never wrote down what you were building, so the AI could not stay aligned with it.

SDD: Write Down What You Want Before You Prompt

Spec-Driven Development is not a big process. It is just one rule: before giving the AI an instruction, write a minimal spec for what that instruction should produce.

Not a fifty-page document. A paragraph. Enough to remove the ambiguity.

Instead of this prompt:

Add user authentication.

Write this spec first, then prompt:

Feature: User authentication
- Email + password only (no OAuth for now)
- Passwords hashed with bcrypt, min 8 characters
- JWT tokens, 7-day expiry
- No "remember me" option
- Rate limit: 5 failed attempts per 10 minutes, then 15-minute lockout
- Out of scope: social login, 2FA, account recovery

The AI output becomes dramatically more predictable because the ambiguity is gone. More importantly, you now have something to check the output against.

Use SDD for any project past MVP stage, or any feature that touches existing code.

VSDD: Check the Output Against the Spec

Verified SDD adds one step: after the AI generates code, verify it against the spec before moving on. That is the whole idea.

Most people skip this. They read the code, it looks reasonable, they commit. Two weeks later they find the edge case in the spec was never implemented because the AI quietly ignored it.

The verification does not have to be automated. A simple checklist works:

Auth feature checklist:
[x] Email + password only
[x] bcrypt hashing
[x] JWT 7-day expiry
[x] No "remember me"
[ ] Rate limit at 5 attempts  <-- AI used 10, not 5
[ ] 15-minute lockout         <-- not implemented

Two items missed. You catch them in five minutes instead of in a production incident.

For team projects or anything going to production, automate this. Write tests derived directly from the spec before you run the AI. If the spec says “rate limit at 5 attempts,” write a test that checks exactly that number. A vague integration test will not catch the AI quietly using a different value.

CoDD: Keep Multiple Specs Consistent

Coherence-Driven Development is for systems where multiple specs depend on each other. Change one, and everything that depends on it needs to update too.

A payment system is a good example. The “create order” spec depends on “payment processing,” which depends on “refund policy.” If the refund window changes from 30 days to 14 days, every spec downstream needs to reflect that.

Without CoDD, what happens is: you update the refund policy spec, prompt the AI to implement it, and the AI does. But the “create order” flow still references 30 days because you did not update that spec. Now two parts of your system disagree about the rules.

CoDD is overkill for a solo project. It matters when you have multiple engineers, multiple services, and a subtle inconsistency between two components that takes three days to trace.

The Honest Take

SDD, VSDD, and CoDD form a progression. Start with SDD when vibe coding breaks down. Add VSDD when you need verification. Add CoDD when the system grows large enough that consistency becomes a problem.

That is a useful frame. But none of this is new.

Good teams were writing specs, verifying implementations, and managing dependencies long before AI existed. What AI did was make it possible to skip all of that and still ship something. For a while. Then the debt came due faster and in a more confusing form.

The article’s real contribution is the reframing: “AI surpassed humans in code-writing speed, yet defining intent remains fundamentally human work.” That is the same shift from a different angle as the previous post on software getting cheap. The cost moved from writing code to knowing what to write, and then writing it down clearly enough for the AI to stay aligned with it.

What Changes in Practice

Three workflows, compared:

Before AI:      define intent -> implement -> review
Vibe coding:    describe ->  AI implements -> ship
SDD + VSDD:     write spec -> AI implements -> verify against spec

The middle step got faster. The first and last steps got more important. Invest in the spec and the AI output becomes predictable. Invest in verification and drift gets caught early. Skip both and you get a fast start and a painful middle.

The skill that compounds now is not creative prompting. It is writing a clear, minimal spec that removes ambiguity without over-engineering. That is a writing skill, and also a thinking skill. You cannot write a clear spec for something you do not understand.

Closing

Vibe coding is a fine starting point. It is a bad steady state.

The teams that do well with AI are not the ones who prompt most creatively. They are the ones who got disciplined about writing down what they want before asking the AI to build it.

Source: AI-Driven Development: From Vibe Coding to Structured Methodologies by Aakash Kavuru on Qiita.