- Der Einsatz von AI-Coding-Tools wird grundlegend neu strukturiert: Vorgestellt wird ein Workflow, der vor dem Schreiben von Code zwingend eine explizite Phase zur Überprüfung des Plans vorsieht
- Das Kernprinzip lautet: „Claude darf keinen Code schreiben, bevor der Plan freigegeben ist“. Dadurch werden strukturelle Kontrolle und ein effizienter Token-Einsatz erreicht
- Der gesamte Prozess verläuft als Kreislauf aus Research → Plan → Annotation → Todo List → Implementation → Feedback
- In jeder Phase wird rund um Markdown-Dokumente (
research.md, plan.md) zusammengearbeitet; durch Kommentare und wiederholte Überarbeitungen steigt die Qualität
- Dieser Ansatz fokussiert sich darauf, die Ausführungskraft der AI und das Urteilsvermögen des Menschen zu trennen und zugleich zu verbinden, um auch in komplexen Systemen stabile und konsistente Ergebnisse zu erzielen
Überblick über den gesamten Workflow
- Über rund 9 Monate hinweg wurde Claude Code als primäres Entwicklungstool genutzt; statt des üblichen Musters „Prompt eingeben → Code generieren → wiederholt nachbessern“ wurde ein systematisches Verfahren mit getrennter Planung und Ausführung aufgebaut
- Bevor Claude Code schreibt, darf es nur auf Basis eines vom Autor geprüften und freigegebenen Plan-Dokuments (
plan.md) arbeiten
- Dieser Ansatz reduziert unnötige Trial-and-Error-Schleifen, bewahrt die Entscheidungshoheit über die Architektur und maximiert die Qualität im Verhältnis zum Token-Verbrauch
Phase 1: Research
- Jede Aufgabe beginnt mit einer tiefgehenden Analyse der Codebasis
- Claude wird angewiesen, bestimmte Ordner oder Funktionen „gründlich zu lesen“ und detailliert zu analysieren
- Die Ergebnisse müssen stets in einer Datei
research.md festgehalten werden
- Dieses Dokument dient als Review-Oberfläche, um Claudes Verständnis zu überprüfen; Missverständnisse werden in dieser Phase korrigiert
- Da fehlerhafte Recherche zu fehlerhafter Planung und Implementierung führt, wird hier der teuerste Fehlerfaktor frühzeitig abgefangen
- So lassen sich zum Beispiel Probleme vermeiden wie das Ignorieren einer Caching-Schicht, das Nichtbeachten von ORM-Regeln oder die Erzeugung doppelter Logik
Phase 2: Planning
- Nach der Prüfung der Recherche lässt man Claude einen detaillierten Implementierungsplan (
plan.md) erstellen
- Einschließlich konkreter Code-Snippets, zu ändernder Dateipfade und Trade-offs
- Statt des eingebauten Plan-Modus wird eine selbst verwaltbare Markdown-Datei verwendet
- Wenn zusätzlich eine Open-Source-Referenzimplementierung bereitgestellt wird, verbessert sich die Qualität von Claudes Plan deutlich
- Noch wichtiger als das Plan-Dokument selbst ist der anschließende Annotation-Zyklus
Annotation-Zyklus
- Der Autor öffnet
plan.md und fügt direkt Inline-Kommentare hinzu
- Korrektur falscher Annahmen, Ablehnung von Ansätzen, Ergänzung von Domain-Wissen usw.
- Zum Beispiel: „Das muss PATCH sein“, „Caching ist unnötig“, „Das Feld
visibility sollte auf Listenebene verschoben werden“
- Anschließend wird Claude angewiesen, „das Dokument anhand der Kommentare zu aktualisieren, aber noch nicht zu implementieren“
- Dieser Kommentar-Aktualisierungs-Zyklus wird 1 bis 6 Mal wiederholt, wobei der Befehl „don’t implement yet“ eine vorzeitige Ausführung verhindert
- Das Markdown-Dokument fungiert als teilbarer Zustand, der klarer und strukturierter ist als rein dialogbasierte Anweisungen
- Durch die Iteration entwickelt sich ein allgemeiner Plan zu einer Spezifikation, die perfekt auf das reale System passt
Erstellen der Todo List
- Vor der Implementierung lässt man Claude eine detaillierte Aufgabenliste (Todo List) ergänzen
- Mit konkreten Teilaufgaben pro Schritt, um den Fortschritt nachzuverfolgen
- Da Claude erledigte Punkte markiert, bleibt der Status auch in langen Sessions leicht nachvollziehbar
Phase 3: Implementation
- Sobald alle Entscheidungen feststehen, erfolgt die Ausführung per standardisiertem Prompt
- Etwa: „Nicht anhalten, bis alle Aufgaben abgeschlossen sind“, „keine unnötigen Kommentare“, „keine Typen
any/unknown“, „fortlaufende Typechecks durchführen“ usw.
- Dieser Schritt ist eine mechanische Phase, die den Plan unverändert ausführt; kreative Entscheidungen sind dann bereits gefallen
- Wer ohne Plan direkt implementiert, baut Code auf falschen Annahmen auf; deshalb ist die Regel „don’t implement yet“ ein zentraler Sicherheitsmechanismus
Feedback während der Implementierung
- Während der Ausführung wechselt der Autor in die Rolle eines Supervisors
- Feedback wird kurz und klar gegeben: „Diese Funktion fehlt“, „in die Admin-App verschieben“ usw.
- Bei Frontend-Änderungen genügen kurze Anweisungen wie „breiter“, „2px Abstand“ oder Screenshots
- Häufige Bezugnahme auf bestehenden Code hilft dabei, eine konsistente UI/UX zu erhalten
- Läuft die Arbeit in die falsche Richtung, ist
git revert und ein neuer Versuch mit kleinerem Scope oft wirksamer als schrittweises Nachbessern
Am Steuer bleiben
- Claude erhält keine vollständige Autonomie; die endgültigen Entscheidungen trifft immer der Mensch
- Aus Claudes Vorschlägen werden nur Teile ausgewählt oder diese werden geändert, gelöscht oder technisch neu definiert
- Zum Beispiel: „Beim ersten
Promise.all verwenden“, „den vierten und fünften Punkt ignorieren“
- „Download-Funktion entfernen“, „Funktionssignatur nicht ändern“, „Methode aus einer bestimmten Library verwenden“ usw.
- Claude übernimmt die mechanische Ausführung, der Mensch Beurteilung und Priorisierung
Eine einzige lange Session
- Von Research bis Implementierung wird alles in einer einzigen langen Session durchgehend erledigt
- Während der Session sammelt Claude fortlaufend Kontext; dank Auto-Compaction bleibt genügend Zusammenhang erhalten
plan.md bleibt über die gesamte Session hinweg vollständig erhalten und kann jederzeit referenziert werden
Kernaussagen
- „Lies gründlich, schreibe einen Plan, verfeinere ihn mit Kommentaren und führe dann alles in einem Zug aus.“
- Auch ohne komplexe Prompts oder Systemanweisungen lässt sich durch eine disziplinierte Pipeline, die Thinking und Typing trennt, hohe Qualität sichern
- Research verhindert uninformierte Änderungen, Plan verhindert falsche Änderungen, und Annotation bringt menschliches Urteilsvermögen ein
- Die finale Ausführung erfolgt erst, nachdem alle Entscheidungen feststehen, als automatisierter Prozess, wodurch eine effiziente Kollaborationsstruktur entsteht
Noch keine Kommentare.