So nutzen seriöse Entwickler Claude Code

Auf LinkedIn überschlagen sich gerade die Artikel: Spec-Driven Development, BMAD Method, Agentic Workflows. Wer noch "vibe codet", gilt als rückständig. Ich entwickle seit über einem Jahr täglich mit Claude Code, teste konsequent die neuesten Entwicklungen und Methoden, und meine Erfahrung ist differenzierter als die meisten Posts dort vermuten lassen.

Spec-Driven Development im Überblick

Spec-Driven Development (SDD) ist kein Tool, sondern ein Prinzip: Bevor ein Agent eine Zeile Code schreibt, gibt es eine vollständige Spezifikation. Requirements, Architekturentscheidungen, Akzeptanzkriterien, alles dokumentiert. Erst dann startet die Implementierung.

Die Grundstruktur:

1. Anforderungen definieren
2. Agent erstellt einen Implementierungsplan
3. Plan reviewen und freigeben
4. Implementierung mit minimalem Eingriff

Der Vorteil: Der Agent bekommt einen klaren Kontrakt, statt aus einem vagen Prompt Annahmen zu treffen.

Die BMAD Method und ihr Versprechen

BMAD (Breakthrough Method for Agile AI-Driven Development) geht weiter. Es ist ein vollständiges Framework mit spezialisierten Agenten-Personas, die ein agiles Team simulieren: Analyst, Product Manager, Architekt, Scrum Master, Developer, QA.

Der Ablauf spiegelt einen echten Produktentwicklungsprozess: Der Analyst erstellt ein Project Brief, der PM daraus ein PRD, der Architekt das System-Design. Alles, bevor der erste Developer-Agent Code schreibt.

BMAD macht Sinn, wenn die eigene Rolle auf die des Product Owners reduziert wird und ein AI-Team das gesamte Produkt übernimmt.

Wo beide Ansätze scheitern

Das klingt eleganter als es in der Praxis ist.

Problem 1: Kontextfenster-Degradation. Je länger eine Claude-Code-Session läuft, desto unzuverlässiger wird die Ausgabe. Implementierungen werden vereinfacht, Fehlerbehandlung weggelassen, Spezifikationen anders interpretiert als gemeint. Das liegt nicht an der Spezifikation, sondern daran, dass das Modell im langen Kontext anfängt, "vernünftige" Annahmen zu treffen.

Problem 2: Plan-Drift. Ein vollständiger Upfront-Plan für alle Features stimmt am Ende nicht mehr. Implementierung erzwingt Entscheidungen, die im Plan nicht sichtbar waren. Wer trotzdem am alten Plan festhält, baut technische Schuld ein.

Problem 3: Vollautonomie kostet Qualität. BMAD funktioniert nur dann gut, wenn der menschliche Eingriff auf ein Minimum reduziert wird. Wer aktiv in der Iterationsschleife bleibt, hat einen Overhead durch die Agenten-Personas ohne klaren Mehrwert.

Mein Workflow mit Claude Code

Mein Workflow ist SDD, aber ohne Framework-Overhead und mit expliziten Gegenmaßnahmen zu den Schwächen oben.

Planung findet im Gespräch statt. Vor jeder Entwicklungsphase führe ich eine ausführliche Diskussion: Anforderungen, Architekturentscheidungen, Edge Cases. Das Ergebnis wird als Spezifikation festgehalten, nicht als Folge von Prompts, sondern als strukturiertes Dokument.

Modularer Plan von Anfang an. Der Agent bekommt den expliziten Auftrag, einen Plan zu erstellen, der absichtlich in unabhängige Tasks zerlegt ist. Jeder Task hat definierte Inputs, Outputs und Akzeptanzkriterien.

Stabiler Kontrakt, rollender Stand. Architektur und Anforderungen kommen in architecture.md und requirements.md, einmal geschrieben, selten angefasst. Was sich ändert, ist current-state.md: Was wurde implementiert, wo weicht es vom Plan ab, was ist der nächste Task.

Jede Session startet mit leerem Kontext. Keine langen Mega-Sessions. Jede Session liest die drei Dokumente, plant den aktuellen Task neu basierend auf dem tatsächlichen Stand und implementiert genau das. Am Ende aktualisiert der Agent current-state.md.

Negative Constraints in CLAUDE.md. Nicht nur was gebaut werden soll, sondern explizit was verboten ist: keine Stub-Implementierungen, keine weggelassene Fehlerbehandlung, kein Bibliothekswechsel ohne Rückfrage.

Das Ergebnis: Kein Plan-Drift, kein Kontextproblem. Und der eigentliche Qualitätshebel bleibt erhalten: die eigene Präsenz bei jedem Task-Übergang.

Ausblick: Das wird sich ändern

Dieser Workflow ist der aktuelle Stand der Technik, aber er wird nicht der letzte sein. Die Coding-Fähigkeiten aktueller Modelle entwickeln sich rasant weiter.

Was heute schon ohne intensive menschliche Begleitung funktioniert: einfache Frontend-Komponenten, klar umrissene UI-Features ohne komplexe Zustandslogik, und überschaubare Backend-Endpunkte mit gut definierten Interfaces. Für diese Aufgaben ist Vollautonomie schon jetzt keine Utopie.

Was noch nicht zuverlässig funktioniert: anspruchsvolle Frontends mit komplexem State Management, datenintensive Backend-Systeme mit vielen Abhängigkeiten, oder Vorhaben, die architektonische Entscheidungen mid-flight erfordern. Hier ist Human in the Loop weiterhin der Qualitätshebel.

Es ist gut möglich, dass dieser Artikel in zwölf Monaten teilweise überholt ist. Die Empfehlung, den eigenen Workflow regelmäßig zu hinterfragen, gilt deshalb genauso wie die Empfehlung, ihn überhaupt zu haben.

Fazit