CLAUDE-SPEC-GESTÜTZTER ARBEITSABLAUF

Der genaue dreistufige Arbeitsablauf, den ich bei jedem von Claude unterstützten Build durchführe: vom Brainstorming über die Spezifikation bis zur Umsetzung – mit Kontrollpunkten, die Fehler frühzeitig erkennen.

CLAUDE-SPEC-GESTÜTZTER ARBEITSABLAUF
Individualsoftware & Architektur Guide 3 Min. Lesezeit geprüft 3. Mai 2026

← Alle Guides Alle Guides zu diesem Thema

Auf dieser Seite
  1. Warum die Spezifikationsorientierung wichtig ist
  2. Phase 1: Strukturiertes Brainstorming
  3. Phase 2: Technische Entscheidungen
  4. Phase 3: Spezifikationsgestützte Umsetzung
  5. Die Gates, die Fehler abfangen
  6. Wenn ein spezifikationsorientierter Ansatz nicht funktioniert

Warum die Spezifikationsorientierung wichtig ist

Die Codegenerierung mit Claude ist so schnell, dass das Tippen nicht mehr den Engpass darstellt. Der Engpass besteht vielmehr darin, genau zu wissen, was man will, bevor Claude es schreibt. Bei einem spezifikationsgesteuerten Arbeitsablauf wird das Nachdenken vorweggenommen, sodass die Implementierungsphase eher aus Ausführung als aus Erkundung besteht.

Die Teams, die gut mit Claude zusammenarbeiten, sind diejenigen, die bereits vor der Einführung der KI-Tools eine strenge Spezifikationsdisziplin etabliert haben. Die Teams, die Schwierigkeiten haben, sind diejenigen, die versuchen, die Spezifikationsphase zu überspringen, indem sie Claude bitten, die Lösung selbst zu finden.

Phase 1: Strukturiertes Brainstorming

Ich schildere Claude das Problem in drei oder vier Sätzen. Dann bitte ich Claude, fünf Fragen zu formulieren, deren Antworten das Design verändern würden. Ich beantworte diese Fragen. Anschließend bitte ich Claude, die daraus resultierende Produktspezifikation in 200 Wörtern zusammenzufassen.

Diese Phase dauert 30 bis 60 Minuten und führt zu einer schriftlichen Spezifikation, auf der der weitere Arbeitsablauf aufbaut. Die fünf Fragen sind in der Regel genau diejenigen, die ich übersprungen hätte, wenn ich direkt mit dem Programmieren begonnen hätte; sie im Rahmen der Brainstorming-Phase zu erarbeiten, macht den gesamten Mehrwert aus.

Phase 2: Technische Entscheidungen

Mit den Spezifikationen in der Hand bitte ich Claude, die Architekturentscheidungen zu identifizieren, die im weiteren Verlauf am häufigsten zum Einsatz kommen. Datenbankstruktur, API-Oberfläche, Rendering-Strategie, Bereitstellungsmodell. Für jeden dieser Punkte schlägt Claude zwei oder drei Optionen mit den jeweiligen Vor- und Nachteilen vor.

Ich treffe die Entscheidungen. Diese werden in dasselbe Dokument aufgenommen, sodass für die Entwicklungsphase eine einzige verlässliche Informationsquelle besteht. Entscheidungen, die in dieser Phase getroffen werden, lassen sich zehnmal kostengünstiger überarbeiten als solche, die erst während der Umsetzung festgestellt werden.

Phase 3: Spezifikationsgestützte Umsetzung

Die Codegenerierung ist der letzte Schritt und verläuft am schnellsten, da die Spezifikation bereits vollständig ist. Claude schreibt das Schema, die Abfragen, die Komponenten, die Routen und die Tests – in etwa in dieser Reihenfolge. Ich überprüfe jeden Commit.

Bei den meisten Überprüfungen fallen lediglich kleine Umstrukturierungen oder ein fehlender Randfall auf; vollständige Neuprogrammierungen sind selten, wenn die Spezifikation klar war. Das Tempo ist zwei- bis fünfmal höher als bei der eigenständigen Entwicklung von Grund auf.

Die Gates, die Fehler abfangen

Drei Überprüfungsphasen zwischen der Ideenfindung und dem ausgelieferten Code:

Spezifikationsprüfung: Bevor auch nur eine Zeile Code geschrieben wird, wird die 200 Wörter umfassende Spezifikation von Anfang bis Ende durchgelesen. Alles, was mehrdeutig ist, wird geklärt. Alles, was zu ambitioniert ist, wird gestrichen.

Architektur-Check: Bevor eine Datenbankmigration durchgeführt wird, werden die Architekturentscheidungen anhand der Spezifikation überprüft. Alles, was nicht den Anforderungen der Spezifikation entspricht, wird erneut geprüft.

Commit-Gate: Jeder von Claude erstellte Commit wird vor dem Mergen einer Überprüfung durch einen Menschen unterzogen. Die Überprüfung geht schneller als das eigenständige Schreiben des Codes, kann jedoch nicht übersprungen werden. Claude genehmigt seine eigenen Pull-Anfragen nicht.

Wenn ein spezifikationsorientierter Ansatz nicht funktioniert

Explorative oder forschungsorientierte Arbeit, bei der es darum geht, herauszufinden, was möglich ist, anstatt etwas Bekanntes zu entwickeln. In solchen Fällen führt die Spezifikationsphase zu vagen Vorgaben, die Claude unnötig einschränken. Stattdessen ist ein iterativer Austausch mit konkreten Artefakten das richtige Vorgehen.

Fehlerbehebungen, deren Ursache unbekannt ist. In der Spezifikationsphase wird davon ausgegangen, dass Sie das Ziel kennen; beim Debuggen geht es darum, herauszufinden, wo Sie sich gerade befinden. Springen Sie beim Debuggen direkt zum Muster des systematischen Debuggens (reproduzieren, isolieren, diagnostizieren, beheben) und überspringen Sie die Spezifikation.

UI-Optimierung, bei der jede Iteration klein ist und visuelles Feedback als Rückmeldung dient. Hierfür ist Claude in Cursor mit Hot-Reload und Side-by-Side-Diff das richtige Werkzeug – nicht eine schriftlich festgehaltene Spezifikation.

WENN SIE SPRECHEN MÖCHTEN