Is There a Middle Ground Between Vibe Coding and Spec Driven Development?

Source: Dev.to

Spec‑Driven Development vs. Vibe Coding

Spec‑Driven Development has become increasingly popular when working with AI coding agents—especially for complex applications with detailed technical and user requirements.

On the other side, vibe coding thrives on speed: one prompt, immediate feedback, iterate until it works.

But what if you’re building something and you genuinely don’t know how complex it will become?

Is there a middle ground between Vibe Coding and Spec‑Driven Development?

• Not too reactive.
• Not too formal.
• Not too heavy.

I recently ran into this exact problem.

You can watch the full video on my YouTube channel (CodeLess Developer)

The Scenario: Building an AI‑Generated Game Arcade

I wanted AI to build a browser‑based arcade of classic games:

• Tetris
• Pac‑Man
• Space Invaders
• A fourth classic

Previously, I completed this challenge using GitHub Copilot inside Visual Studio 2026, powered by Claude Sonnet 4.5. At the time, Sonnet 4.5 felt like the best AI coding model for that workflow.

This time I tried something different:

• 👉 Use GPT‑5.3 Codex inside VS Code
• 👉 Avoid pure vibe coding
• 👉 Avoid heavy Spec‑Driven Development

Instead of prompting interactively, I started with an instructions.md file. The instructions were simple:

1. Create 4 games.
2. Each game in its own feature folder.
3. Use .NET 10.
4. Use C# Blazor.
5. Apply best practices (separation of concerns, modular structure).

This should have been straightforward. It wasn’t.

When “Simple” Isn’t Simple

Even the first step—creating the .NET solution and projects—took 13–15 minutes. GPT‑5.3 Codex struggled to scaffold the solution correctly.

That was surprising; I would have assumed automated .NET solution creation is a common enough task that modern AI coding agents would handle it effortlessly.

Eventually Tetris was generated, but when I ran the solution in Visual Studio:

• ❌ The game wasn’t playable.
• ❌ The implementation failed.

The first attempt was an outright failure.

Where Vibe Coding Would Have Won

Ironically, if I had just vibe‑coded this—“Create Tetris in JavaScript and HTML”—I likely would have had a playable version almost immediately.

By explicitly choosing Blazor and C#, I pushed the AI into a weaker execution path. This is where things got interesting.

Instead of forcing fixes through repeated reactive prompting, I tried something different.

Step Back: Ask the AI to Think First

I asked GPT‑5.3:

What technology stack is most appropriate for building browser‑based arcade games?

That changed everything. Rather than forcing it into my initial assumption (.NET Blazor), I let the model reason about:

• Rendering performance
• Game loops
• Canvas handling
• Browser‑native capabilities
• Framework suitability

Then I went further and asked it to:

• Propose high‑level specs
• Define an architecture
• Create a docs folder with planning context
• Outline orchestration before writing code

Now we were no longer vibe coding, but we also weren’t doing heavy Spec‑Driven Development. This felt like something in between.

Defining the Middle Ground

Here’s what I’ve observed so far.

❌ It’s Not Vibe Coding

• We generate structured planning documents.
• We define architecture before implementation.
• We increase context before execution.
• We reduce randomness.

❌ It’s Not Full Spec‑Driven Development

• We are not formally reviewing specs for every change.
• We are not enforcing change proposals.
• We are not using structured spec frameworks like OpenSpec or SpecKit.
• We are not locking into governance workflows.

So what is it?

Context‑First Development

If I had to name it right now, I’d call it Context‑First AI Development.

Core idea

1. Before writing code, generate structured thinking.
2. Let the AI propose architecture.
3. Clarify stack decisions.
4. Establish execution boundaries.
5. Then build.

No heavy process. No formal spec review cycles. No reactive chaos. Just enough structure to prevent expensive misdirection.

The Real Tension

What happens when changes are required?

The moment you introduce:

• Updates
• Feature additions
• Refactors
• Corrections

you start drifting toward change proposals, then versioned specs, then review cycles. Suddenly your “middle ground” becomes full Spec‑Driven Development.

If you don’t use a proper framework like OpenSpec or SpecKit, you end up inventing a lightweight version of one. That’s the paradox.

Takeaways

• Start with context. Give the AI space to think before it codes.
• Keep the process lightweight. Avoid formal spec frameworks unless the project truly needs them.
• Be ready to pivot. If the scope expands, you may need to adopt more rigorous spec practices.

Finding the sweet spot between pure vibe coding and heavyweight spec‑driven processes can dramatically improve productivity while keeping AI‑generated code reliable.

![Diagram](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/boob0pahykfw5c2fgb8a.png)

## Why This Matters

**Most non‑technical users:**

- Don’t want formal spec workflows.  
- Don’t understand architectural modeling.  
- Prefer “vibe coding” because it feels immediate.

**But vibe coding becomes inefficient once:**

- The app grows.  
- State management becomes complex.  
- Modules interact.  
- Bugs compound.

Spec‑Driven Development solves this — but at the cost of overhead.

So the real question isn’t:

> Which approach is better?

The real question is:

> At what stage does structure become necessary?

---

## The Working Hypothesis

Right now, my working model looks like this:

### Stage 1 — Exploration  
Use vibe coding to discover direction.

### Stage 2 — Context Formation  
Generate architecture, stack decisions, and high‑level specs.

### Stage 3 — Controlled Execution  
Build within defined boundaries without heavy governance.

### Stage 4 — Formalization (Optional)  
Introduce structured spec workflows only if complexity demands it.

That might be the cleanest middle ground.

![Workflow Diagram](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wgs3pa8muz6yvcnifpu7.png)

---

## The Ongoing Experiment

In the next phase of this experiment, I’ll rebuild the arcade based on the planning documents generated by **GPT‑5.3 Codex**.

The real test isn’t whether it builds Tetris.

The real test is:

- Does this reduce iteration loops?  
- Does it reduce misdirection?  
- Does it outperform pure vibe coding?  
- Does it avoid the overhead of formal Spec‑Driven Development?

I’m still searching for a clean definition of this methodology, but I’m convinced of one thing:

> The future of AI‑assisted development isn’t binary.  
> It’s not “Vibe Coding vs. Spec‑Driven Development.”  
> There’s a middle ground—we just need to define it.