CLAUDE SPEC-GESTEUERTER WORKFLOW

Die Codegenerierung mit Claude ist schnell genug, dass die Engstelle nicht mehr das Tippen ist. Die Engstelle ist, genau zu wissen, was du haben willst, bevor Claude es schreibt. Ein Spec-gesteuerter Workflow verlagert das Denken nach vorne, damit die Implementierungsphase zur Ausführung statt zur Erkundung wird.

Die Teams, die mit Claude gut ausliefern, sind diejenigen, die Spec-Disziplin aufgebaut haben, bevor es die KI-Tools gab. Die Teams, die Probleme haben, sind diejenigen, die versuchen, die Spezifikation zu überspringen, indem sie Claude herausfinden lassen.

Ich beschreibe das Problem für Claude in drei oder vier Sätzen. Dann bitte ich Claude, fünf Fragen zu surface, deren Antworten das Design ändern würden. Ich beantworte sie. Dann bitte ich Claude, die resultierende Produktspezifikation in 200 Wörtern zusammenzufassen.

Diese Phase dauert 30 bis 60 Minuten und produziert eine schriftliche Spezifikation, von der der Rest der Arbeit ausgeht. Die fünf Fragen sind normalerweise diejenigen, die ich übersprungen hätte, wenn ich direkt zum Code gegangen wäre; sie durch die Brainstorming-Phase zu surfacen ist der gesamte Mehrwert.

Mit der Spezifikation in der Hand fordere ich Claude auf, die Architektur-Entscheidungen zu identifizieren, die die höchste Hebelwirkung nachgelagert haben. Datenbankstruktur, API-Oberfläche, Rendering-Strategie, Deployment-Modell. Für jede schlägt Claude zwei oder drei Optionen mit Trade-offs vor.

Ich entscheide mich. Die Entscheidungen kommen in dasselbe Dokument, damit die Build-Phase eine einzige Quelle der Wahrheit hat. Entscheidungen, die in dieser Phase getroffen werden, sind 10-mal günstiger zu überarbeiten als Entscheidungen, die während der Implementierung entdeckt werden.

Code-Generierung ist die letzte Phase und sie ist am schnellsten, weil die Spezifikation bereits vollständig ist. Claude schreibt das Schema, die Abfragen, die Komponenten, die Routen, die Tests, ungefähr in dieser Reihenfolge. Ich überprüfe jeden Commit.

Die meisten Reviews surfacen eine kleine Umgestaltung oder einen fehlenden Edge Case; vollständige Umschreibungen sind selten, wenn die Spezifikation klar war. Das Tempo ist zwei bis fünf Mal schneller als eigenständiges Engineering bei Greenfield-Arbeiten.

Drei Review-Gates zwischen Brainstorming und ausgeliefertem Code:

Spec-Gate: Bevor Code geschrieben wird, wird die 200-Wort-Spezifikation von oben bis unten gelesen. Alles Mehrdeutige wird geklärt. Alles Aspirationelle wird gestrichen.

Architecture-Gate: Bevor eine Datenmigration läuft, werden die Architekturbescheidungen gegen die Spezifikation überprüft. Alles, was der Spezifikation nicht dient, wird neu überlegt.

Commit-Gate: Jeder von Claude verfasste Commit erhält eine menschliche Überprüfung vor dem Merge. Die Überprüfung ist schneller, als den Code selbst zu schreiben, aber sie ist nicht überspringbar. Claude genehmigt seine eigenen Pull Requests nicht.

Explorative oder forschungsorientierte Arbeiten, bei denen das Ziel darin besteht, zu lernen, was möglich ist, statt etwas Bekanntes zu bauen. Bei diesen erzeugt die Spezifikationsphase vage Spezifikationen, die Claude unvorteilhaft einschränken. Ein iteratives Gespräch mit konkreten Artefakten ist stattdessen das richtige Muster.

Fehlerbehebungen, bei denen die Ursache unbekannt ist. Die Spezifikationsphase geht davon aus, dass du das Ziel kennst; Debugging ist herauszufinden, wo du dich befindest. Zum Debuggen springe direkt zum systematischen Debugging-Muster (reproduzieren, isolieren, diagnostizieren, beheben) und überspringe die Spezifikation.

UI-Polish, bei dem jede Iteration klein ist und visuelles Feedback das Signal ist. Hierfür ist Claude in Cursor mit Hot Reload und Side-by-Side Diff das richtige Werkzeug, nicht eine geschriebene Spezifikation.