Das Struktur-Spektrum: Die Mitte finden zwischen Vibe Coding und Enterprise-Theater

Nachdem Andrej Karpathy im Februar 2025 "Vibe Coding" prägte, spaltete sich die KI-Entwicklungswelt in zwei Lager.

Auf der einen Seite: Entwickler, die Code nach Gefühl ausliefern, keine Specs, keine Planung, einfach prompten bis etwas funktioniert.

Auf der anderen: Enterprise-Frameworks mit Verfassungsdokumenten, mehrphasigen Workflows, Stakeholder-Review-Gates und mehr Zeremonie als eine königliche Hochzeit.

Die meisten von uns brauchen etwas dazwischen.

Das Spektrum

Vibe Coding ←─────────────────────────────────────────────→ Enterprise-Theater
    │                      │                       │                    │
 Raw Claude          GSD (TÂCHES)          Conductor/Spec Kit       Kiro/BMAD
    │                      │                       │                    │
 Keine Leitplanken   "Gerade genug"        Formale Phasen       Sprint-Zeremonien
                    Solo-Dev-Fokus         Team-orientiert      Stakeholder-Syncs

Das extreme Linke hat null Overhead, aber auch null Leitplanken. Der Kontext degradiert, die KI vergisst frühere Entscheidungen, und du landest beim Debuggen von Halluzinationen.

Das extreme Rechte hat maximale Rechenschaftspflicht, aber auch maximale Reibung. Du schreibst Specs für Features, bevor du weisst, ob der Ansatz überhaupt funktioniert.

Das Überstruktur-Problem

GitHubs Spec Kit möchte, dass du erstellst: Constitution → Specify → Plan → Tasks → Implement → PR. Das sind fünf oder mehr Phasen, mehrere Markdown-Dateien und Team-Review-Gates.

Googles Conductor erfordert: product.md + techstack.md + workflow.md + plan.md + checkpoints.

Für Enterprise-Teams mit Compliance-Anforderungen und Stakeholder-Übergaben macht das Sinn. Für einen Solo-Entwickler oder ein kleines Team? Du spielst Enterprise-Theater mit dir selbst.

Mehr Zeit Specs schreiben als ausliefern. Zeremonie um der Zeremonie willen.

Warum die Mitte wichtig ist

Das Kernprinzip von Spec-Driven Development ist einfach: Spezifikationen dienen nicht dem Code—Code dient Spezifikationen. Du definierst, was du willst, bevor du es baust, dann wird die Spec zur Quelle der Wahrheit.

Aber es gibt einen Unterschied zwischen "genug Spec, um Drift zu verhindern" und "genug Spec, um ein Compliance-Audit zu bestehen."

Solo-Entwickler und kleine Teams brauchen:

Genug Planung, um zu verhindern, dass die KI Anforderungen halluziniert
Nicht so viel Planung, dass der Overhead den Nutzen übersteigt
Sitzungskontinuität, damit du stoppen und neu starten kannst, ohne den Kontext zu verlieren
Frischen Kontext, damit die KI über lange Gespräche nicht degradiert

Tools, die die Mitte besetzen

GSD (Get Shit Done)

Erstellt von Lex Christopherson (TÂCHES), verfolgt GSD einen anderen Ansatz:

Ein Befehl zum Starten (/gsd:new-project)
Stellt Fragen, bis es genug hat—kein Vorausfüllen von Templates
Gibt eine Datei aus (PROJECT.md)—keine Ordnerstruktur
Phasen passieren natürlich, nicht durch erzwungene Gates
Frische Subagenten für jede atomare Aufgabe—200k Tokens, null angesammelter Müll

Die Struktur ist im System, nicht in deinem Workflow.

GSDs Docs:Code-Verhältnis in unseren Tests: 0.89:1. Moderater Overhead, aber es liefert atomare Commits und Sitzungskontinuität via STATE.md.

Ralph Loops

Die Ralph-Wiggum-Technik (benannt nach der Simpsons-Figur) adressiert ein spezifisches Problem: Agent-Persistenz.

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

Gedächtnis lebt nicht im Kontextfenster des LLM—es lebt in Dateien und Git-History. Wenn der Kontext voll ist, übernimmt ein frischer Agent dort, wo der letzte aufgehört hat. Die Plan-Datei ist der Übergabemechanismus.

Ralphs Docs:Code-Verhältnis: 0.46:1. Minimaler Overhead, aber es erfordert, dass du die Plan-Datei selbst verwaltest.

Die Vertrauensfrage

Hier ist der unbequeme Teil: Das populärste Mittelgrund-Tool (GSD) wurde von einem Musikproduzenten erstellt, nicht von einem Software-Ingenieur.

Lex Christopherson beschreibt sich selbst als: "Ich schreibe keinen Code—Claude Code tut das... Ich bin nur eine kreative Person, die versucht, grossartige Dinge zu bauen, die funktionieren."

Die "trusted by Amazon, Google..."-Behauptungen auf der GSD-Website sind nicht verifizierbare Marketing-Texte. Die 3.8k GitHub-Stars zeigen echte Nutzung, aber die Qualifikationen des Erstellers sind unkonventionell.

Und doch: Die zugrundeliegende Technik ist solide. Context Engineering, frische Subagenten, Spec-als-Konversations-Output—das sind legitime Muster. Der Ansatz ist Open Source und vollständig prüfbar.

Manchmal kommt das richtige Tool von unerwarteten Orten.

Die Entscheidung treffen

Deine Situation	Ansatz
Enterprise-Team mit Compliance-Anforderungen	GitHub Spec Kit
Brownfield-Codebase, braucht Kontext-Persistenz	Gemini Conductor
Solo-Dev, will Struktur ohne Zeremonie	GSD
Minimaler Overhead, okay mit Plan-Datei-Verwaltung	Ralph Loops
Maximale Geschwindigkeit, akzeptiert etwas Chaos	Raw Claude + Plan Mode

Die Schlüsselfrage ist nicht "welche Methodik ist am besten?" Es ist "wie viel Struktur brauche ich tatsächlich?"

Wenn du etwas baust, das du jahrelang warten wirst, brauchst du mehr Struktur als du denkst. Wenn du einen Prototyp spikest, um eine Idee zu validieren, brauchst du weniger als die Enterprise-Frameworks dir geben wollen.

Die Mitte existiert. Die Herausforderung ist, herauszufinden, wo du auf dem Spektrum hingehörst.

Brauchst du Hilfe, die richtige Entwicklungsmethodik für dein Team zu finden? Buche eine kostenlose Beratung und lass uns herausfinden, welches Strukturniveau zu deinem Kontext passt.