The Structure Spectrum: Finding the Middle Ground Between Vibe Coding and Enterprise Theater

After Andrej Karpathy coined "vibe coding" in February 2025, the AI development world split into two camps.

On one side: developers shipping code by feel, no specs, no planning, just prompting until something works.

On the other: enterprise frameworks with constitution documents, multi-phase workflows, stakeholder review gates, and more ceremony than a royal wedding.

Most of us need something in between.

The Spectrum

Vibe coding ←─────────────────────────────────────────────→ Enterprise theater
    │                      │                       │                    │
 Raw Claude          GSD (TÂCHES)          Conductor/Spec Kit       Kiro/BMAD
    │                      │                       │                    │
 No guardrails      "Just enough"          Formal phases         Sprint ceremonies
                    Solo-dev focus         Team-oriented         Stakeholder syncs

The extreme left has zero overhead but also zero guardrails. Context degrades, the AI forgets earlier decisions, and you end up debugging hallucinations.

The extreme right has maximum accountability but also maximum friction. You're writing specs for features before you know if the approach even works.

The Over-Structure Problem

GitHub's Spec Kit wants you to create: Constitution → Specify → Plan → Tasks → Implement → PR. That's five-plus phases, multiple markdown files, and team review gates.

Google's Conductor requires: product.md + techstack.md + workflow.md + plan.md + checkpoints.

For enterprise teams with compliance needs and stakeholder handoffs, this makes sense. For a solo developer or small team? You're playing enterprise theater with yourself.

More time writing specs than shipping. Ceremony for ceremony's sake.

Why the Middle Ground Matters

The core principle of spec-driven development is simple: specifications don't serve code—code serves specifications. You define what you want before you build it, then the spec becomes the source of truth.

But there's a difference between "enough spec to prevent drift" and "enough spec to satisfy a compliance audit."

Solo developers and small teams need:

• Enough planning to prevent the AI from hallucinating requirements
• Not so much planning that the overhead exceeds the benefit
• Session continuity so you can stop and restart without losing context
• Fresh context so the AI doesn't degrade over long conversations

Tools That Occupy the Middle

GSD (Get Shit Done)

Created by Lex Christopherson (TÂCHES), GSD takes a different approach:

• One command to start (/gsd:new-project)
• Asks questions until it has enough—no upfront template filling
• Outputs one file (PROJECT.md)—not a folder structure
• Phases happen naturally, not through enforced gates
• Fresh subagents for each atomic task—200k tokens, zero accumulated garbage

The structure is in the system, not in your workflow.

GSD's docs:code ratio in our testing: 0.89:1. Moderate overhead, but it delivers atomic commits and session continuity via STATE.md.

Ralph Loops

The Ralph Wiggum technique (named after the Simpsons character) addresses a specific problem: agent persistence.

while true; do
  claude --prompt "Complete items from plan.md"
done

Memory doesn't live in the LLM's context window—it lives in files and git history. When context fills up, a fresh agent picks up where the last left off. The plan file is the handoff mechanism.

Ralph's docs:code ratio: 0.46:1. Minimal overhead, but it requires you to manage the plan file yourself.

The Trust Question

Here's the uncomfortable part: the most popular middle-ground tool (GSD) was created by a music producer, not a software engineer.

Lex Christopherson describes himself as: "I don't write code—Claude Code does... I'm just a creative person trying to build great things that work."

The "trusted by Amazon, Google..." claims on the GSD website are unverifiable marketing copy. The 3.8k GitHub stars indicate real usage, but the creator's credentials are unconventional.

And yet: the underlying technique is sound. Context engineering, fresh subagents, spec-as-conversation-output—these are legitimate patterns. The approach is open source and fully auditable.

Sometimes the right tool comes from unexpected places.

Making the Choice

The key question isn't "which methodology is best?" It's "how much structure do I actually need?"

If you're building something you'll maintain for years, you need more structure than you think. If you're spiking a prototype to validate an idea, you need less than the enterprise frameworks want to give you.

The middle ground exists. The challenge is finding where you belong on the spectrum.

---

Need help finding the right development methodology for your team? Book a free consultation and let's figure out what level of structure fits your context.