Entwickler wechselt von Spezifikationen zu Vorschlägen für parallele Claude-Code-Sitzungen

Das Problem mit dem Spezifikationen-zuerst-Ansatz

Der Entwickler stieß auf Probleme, bei denen das vorherige Erstellen detaillierter Spezifikationen dazu führte, dass KI-generierter Code zwar technisch korrekt, aber kontextuell falsch war. Die Spezifikation sagte zwar „Füge Ratenbegrenzung zu Authentifizierungs-Endpunkten hinzu“, enthielt aber keinen Kontext über zuvor abgelehnte Ansätze (wie Token-Buckets) oder Implementierungsentscheidungen (wie die Wahl von Redis gegenüber Cloudflare für Staging). Dies führte zu Situationen, in denen die KI vernünftige Entscheidungen traf, die bereits getroffene Entscheidungen wieder öffneten.

Das Aktualisieren von Spezifikationen wurde zu einem eigenen Miniprojekt, und bis die aktualisierten Spezifikationen überprüft waren, hatte sich die Codebasis bereits verändert. Die Spezifikation erfasste das „Was“, verlor aber das „Warum“ – die gesamte Argumentation, abgelehnte Alternativen und der Zeitpunkt der Entscheidungen fehlten.

Die Vorschlag-zuerst-Alternative

Anstatt zunächst Spezifikationen zu schreiben und dann Code entsprechend zu entwickeln, schreibt der Entwickler Vorschläge – kurze Dokumente, die erfassen, warum eine Änderung stattfindet, was in Betracht gezogen und abgelehnt wurde und was im oder außerhalb des Umfangs liegt. Die Spezifikation wird nach der Implementierung des Codes aktualisiert, um widerzuspiegeln, was tatsächlich gebaut wurde.

Beispielvergleich:

• Eine Spezifikation sagt: „Das System soll Ratenbegrenzung unterstützen.“
• Ein Vorschlag sagt: „Brute-Force-Angriffe in der Produktion erkannt. Füge Ratenbegrenzung über gleitendes Fenster + Redis hinzu (Cloudflare in Staging nicht verfügbar). Token-Bucket aufgrund von Burst-Verkehrsproblemen abgelehnt. Umfang: Nur Login + Passwort-Reset.“

Der Vorschlag gibt der KI (und zukünftigen Entwicklern) das vollständige Bild.

Workflow für parallele Vorschläge

Der Entwickler führt mehrere Claude Code-Sitzungen gleichzeitig aus, wobei jede an einem anderen Vorschlag arbeitet. Manchmal erstellt er konkurrierende Vorschläge, die dasselbe Problem aus verschiedenen Blickwinkeln lösen.

Typischer Workflow:

• Gleichzeitiges Arbeiten an 2–3 Funktionen/Fehlern/Problemen
• Erstellen von 1 oder 2 Vorschlägen für verschiedene Ansätze pro Problem
• Starten von Claude Code-Sitzungen für jeden Vorschlag zur parallelen Ausführung
• Jede Sitzung erstellt einen GitHub-Pull-Request (PR)
• GitHub-PRs dienen als Plattform zur Überprüfung der Vorschläge
• Gemeinsame Überprüfung von Ansatz und Code
• Wenn zwei Vorschläge dasselbe Problem unterschiedlich angehen, Auswahl des besseren und Schließen des anderen
• Sobald genehmigte PRs übernommen wurden, Anweisung an Claude, die Vorschläge zu implementieren
• Aktualisieren der Spezifikation, um Codeänderungen für schnelle Referenz in zukünftigen Vorschlägen widerzuspiegeln

Die Spezifikation wird zu einem lebendigen Dokument, das immer der Realität entspricht, anstatt zu einem ambitionierten Dokument, das sich von Anfang an entfernt.

PACE-Zyklus

Der Entwickler nennt diesen Zyklus PACE (zur Erinnerung an die Schritte):

• Vorschlagen (Propose): Einen kurzen Vorschlag mit Kontext und Begründung schreiben
• Genehmigen (Approve): Überprüfung auf GitHub-PR, Ansatz (genehmigen, überarbeiten, ablehnen)
• Programmieren (Code): KI implementiert genau das, was vorgeschlagen wurde, nichts mehr
• Weiterentwickeln (Evolve): Aktualisieren der Spezifikation, um die neue Realität widerzuspiegeln