Der KI beibringen, wie eine Senior Engineer zu denken

• Eine Methodik, bei der KI-Coding-Tools vor dem Schreiben von Code zuerst einen Plan erstellen, kann Fehlimplementierungen verhindern und die Entwicklung beschleunigen
• Acht Planungsstrategien werden je nach Schwierigkeitsgrad angewendet; jede Strategie ist so aufgebaut, dass bestimmte Agenten parallel recherchieren und der Entwickler anschließend Urteilsvermögen und Entscheidungen einbringt
• Die einzelnen Strategien umfassen Bug-Reproduktion, Recherche zu Best Practices, Analyse der bestehenden Codebase, Untersuchung der git-Historie usw.; dabei werden von den Agenten gelernte Präferenzen und Muster automatisch angesammelt
• Das als Open Source veröffentlichte System lässt sich in Claude Code installieren, oder man startet mit einer einzelnen Funktion und bringt der KI schrittweise die Denkweise des Entwicklers bei

---

KI-zentrierte Entwicklungsweise mit Fokus auf Planung

• Vorstellung eines Ansatzes, bei dem die KI vor dem Schreiben von Code einen Plan erstellt
  • Dieser Ansatz beschleunigt die Implementierung von Funktionen und reduziert Fehler, statt nur einfach Code zu erzeugen
• Als Beispiel wird der Entwicklungsprozess der Funktion „email bankruptcy“ der E-Mail-Management-App Cora vorgestellt
  • Bei der Implementierung einer Funktion, die 53.000 E-Mails ohne Verlust wichtiger Nachrichten aufräumt, führte ein KI-Recherche-Agent vorab eine Analyse durch
  • So wurden das Gmail-Limit von 2.000 Vorgängen, System-Timeouts und Probleme mit der Wartezeit für Nutzer im Voraus erkannt und Fehlimplementierungen verhindert

Acht Planungsstrategien

Strategie 1: Bugs reproduzieren und dokumentieren

• Zweck: Bugs vor dem Fix reproduzieren und eine Schritt-für-Schritt-Anleitung erstellen
• Einsatzzeitpunkt: Fidelity 1–2, insbesondere bei Bugfixes
• Direkt nach dem Release der Funktion für „email bankruptcy“ trat ein Problem auf, bei dem 19 Nutzer in einem fehlgeschlagenen Status festhingen
  • Bei der Diagnose durch das Durchgehen der AppSignal-Logs zeigte sich, dass Gmail-Rate-Limit-Fehler in Produktion ignoriert wurden
  • Wenn ein einzelner Batch fehlschlug, stoppte der gesamte Job, ohne den Nutzer zu informieren, sodass dieser nur einen endlosen Lade-Spinner sah
• Bei der Reproduktion wurde erkannt, dass Batch-Verarbeitung und das Wiederaufnehmen von Jobs nötig sind; ein einfaches Retry reicht nicht aus
• Zinseszinseffekt: Zur Checkliste des Agenten @kieran-rails-reviewer wurde der Punkt hinzugefügt: „Bei Background-Jobs mit Aufrufen externer APIs prüfen, ob Rate Limits behandelt werden, Retries vorhanden sind und kein Teilstatus liegen bleibt“

Strategie 2: Best Practices recherchieren

• Zweck: Im Web nach ähnlichen Lösungsansätzen suchen
• Einsatzzeitpunkt: Für alle Schwierigkeitsgrade, besonders bei unbekannten Mustern
• Beim Upgrade eines gem, das zwei Versionen zurücklag, suchte der Agent nach „Upgrade-Pfad von Version X auf Y“, „Breaking Changes zwischen den Versionen“ und „typischen Migrationsproblemen“
  • Er fand den offiziellen Upgrade-Guide sowie drei Blogposts von Engineers, die dasselbe Upgrade durchgeführt hatten
  • Drei Minuten Recherche verhinderten stundenlanges Trial-and-Error-Debugging
• Auch für nichttechnische Entscheidungen nutzbar: etwa „Best Practices für SaaS-Preisstaffelungen“, „Conversion-Copy für E-Mail-Drip-Kampagnen“ oder „Retry-Strategien für Background-Jobs“
• Zinseszinseffekt: Wenn nützliche Muster gefunden werden, werden sie automatisch in Dateien unter docs/*.md gespeichert und bei ähnlichen Fragen künftig vor einer Websuche zuerst geprüft

Strategie 3: Die Codebase untersuchen

• Zweck: In bestehendem Code nach ähnlichen Mustern suchen
• Einsatzzeitpunkt: Bei allen Aufgaben, bei denen es Überschneidungen mit vorhandener Funktionalität geben könnte
• Bevor zu einer neuen Funktion Event-Tracking hinzugefügt wurde, durchsuchte der Agent die Codebase: „Wie wird Event-Tracking aktuell umgesetzt?“, „Welche Muster gibt es für Analytics-Aufrufe?“ und „Wo werden Events verschickt?“
  • Dabei wurde ein bestehendes Tracking-System inklusive Helper-Methoden entdeckt (das der Autor selbst vergessen hatte)
  • Wenn die KI die Codebase nicht referenziert, versucht sie oft, alles von Grund auf neu zu bauen
• Statt ein neues Tracking-System zu erstellen, wurde das bestehende Muster erweitert, wodurch der Aufbau eines zweiten inkompatiblen Systems verhindert wurde
• Zinseszinseffekt: Es wurde ein Agent „@event-tracking-expert“ erstellt, der bei der Planung aller Funktionen mit Tracking-Bedarf automatisch ausgeführt wird

Strategie 4: Den Source Code von Bibliotheken untersuchen

• Zweck: Den Source Code installierter Pakete und gems direkt lesen
• Einsatzzeitpunkt: Wenn schnelllebige oder schlecht dokumentierte Bibliotheken verwendet werden
• Beim RubyLLM-gem werden ständig neue Modelle, Parameter und Funktionen ergänzt, aber die Dokumentation hinkt hinterher
  • Der Agent analysierte den RubyLLM-Source-Code: „Welche Modelloptionen sind verfügbar?“, „Welche Parameter können übergeben werden?“ und „Welche undokumentierten Funktionen gibt es in der neuesten Version?“
  • Er lieferte etwa: „Streaming-Support wurde in Version 1.9 hinzugefügt, aber nicht dokumentiert“, inklusive Parameternamen und Nutzungsbeispielen aus der Test-Suite
• Zinseszinseffekt: Bei jedem Dependency-Update wird auch das Wissen automatisch aktualisiert, sodass nicht mit veralteten Informationen gearbeitet wird

Strategie 5: Die git-Historie erforschen

• Zweck: Über die Commit-Historie die Absicht früherer Entscheidungen verstehen
• Einsatzzeitpunkt: Bei Refactorings, beim Fortsetzen laufender Arbeit oder wenn das „Warum“ verstanden werden muss
• Als die Nutzung einer alten Version von EmailClassifier auffiel, wurde vor einem Upgrade-Versuch die git-Historie durchsucht: „Warum nutzen wir v1?“, „Gab es schon einmal einen Upgrade-Versuch auf v2?“
  • Es wurde ein PR eines anderen Teammitglieds von vor drei Monaten gefunden: Nach dem Upgrade auf v2 landeten Inbox-E-Mails im Archiv und Archiv-E-Mails in der Inbox
  • In der PR-Diskussion war dokumentiert, dass bewusst zurückgerollt wurde, inklusive detaillierter Begründung
• Zinseszinseffekt: Institutionelles Gedächtnis bleibt erhalten und durchsuchbar; neue Teammitglieder erben die Logik hinter früheren Entscheidungen

Strategie 6: Anforderungen per Prototyping schärfen

• Zweck: Anforderungen durch schnelles Prototyping in einer separaten Umgebung präzisieren
• Einsatzzeitpunkt: Fidelity 3, UX-Unsicherheit, explorative Arbeit
• Beim Redesign der E-Mail-Brief-Oberfläche wurden in Claude fünf verschiedene Layout-Prototypen mit jeweils fünf Minuten Aufwand erstellt
  • Durch direktes Klicken konnten Schwachstellen erkannt und einigen Nutzern die beste Variante gezeigt werden
  • Feedback eines Nutzers: „Das Layout wirkt überwältigend und ich weiß nicht, wie ich E-Mails archivieren soll“
• Diese Erkenntnis floss als Anforderung in den eigentlichen Plan ein: „Der Archiv-Button muss in die obere linke Ecke – die Muskel-Erinnerung der Nutzer erwartet diese Position aus Gmail“
• Zinseszinseffekt: Prototyping verwandelt Unsicherheit in konkrete Spezifikationen und dokumentiert Nutzerreaktionen

Strategie 7: Mit Optionen zusammenführen

• Zweck: Die gesamte Recherche zu einem Plan mit Trade-offs zusammenführen
• Einsatzzeitpunkt: Nach Abschluss der Recherchephase, vor der Implementierung
• Nach der Ausführung von Strategie 1–6 fasst der Agent zusammen: „Schlage auf Basis dieser Recherche drei Wege zur Lösung des Problems vor. Für jeden Ansatz: Implementierungskomplexität, Performance-Auswirkungen, Wartungsaufwand und passende bestehende Muster“
• Beispiel Gmail-Inbox-Synchronisierung:
  • Option A – bestehendes Synchronisierungssystem verwenden: schnelle Implementierung, aber Code-Duplizierung und schlechtere Trennung von Verantwortlichkeiten
  • Option B – Echtzeit-Synchronisierung: saubere Architektur, aber potenziell langsam und möglicherweise unzuverlässig
  • Option C – ein Mirror-Caching-System aufbauen: beste langfristige Lösung, sauberste Trennung, aber größter initialer Aufwand
• Nach dem Vergleich ist in 30 Sekunden eine informierte Entscheidung möglich
• Zinseszinseffekt: Die Auswahl offenbart Präferenzen; wenn z. B. „Kompatibilität zuerst“ bevorzugt wird, gewichtet das System bei ähnlichen Entscheidungen künftig Kompatibilität stärker

Strategie 8: Review durch Stil-Agenten

• Zweck: Den fertigen Plan an spezialisierte Reviewer weitergeben, die Entwicklerpräferenzen prüfen
• Einsatzzeitpunkt: In der finalen Planungsphase, vor der Implementierung
• Drei automatisch ausgeführte Review-Agenten:
  • Vereinfachungs-Agent: markiert Overengineering, etwa „Braucht diese Funktion wirklich drei Datenbanktabellen? Wäre nicht eine Tabelle mit einem Typ-Feld ausreichend?“
  • Sicherheits-Agent: prüft auf gängige Schwachstellen, etwa „Dieser Plan erlaubt Benutzereingaben direkt in Datenbankabfragen – Input-Sanitization muss ergänzt werden“
  • Kieran-Stil-Agent: setzt persönliche Präferenzen durch, etwa „Hier werden komplexe Joins verwendet; Kieran bevorzugt einfache Queries, Denormalisierung erwägen“
• Zinseszinseffekt: Die Agenten sammeln mit der Zeit den Geschmack des Entwicklers; Markierungen wie „mag ich nicht“ oder „gut erkannt“ werden vom System gelernt

Einstieg

Was man noch heute ausprobieren kann

• Das Planungssystem wurde als Open Source im Github Marketplace von Every veröffentlicht
• Nach der Installation in Claude Code stehen sofort der Slash-Command /plan und Recherche-Agenten zur Verfügung
• Das Plugin kann in Claude Code oder Droid verwendet werden

Einfach anfangen

• Wähle eine Fidelity-2-Funktion, die du diese Woche baust: eine Aufgabe mit klar abgegrenztem Umfang über mehrere Dateien hinweg (z. B. eine neue View hinzufügen, ein Feedback-System implementieren oder eine Komponente refactoren)
• Vor der Build-Anfrage an Claude Code oder Cursor 15–20 Minuten Recherche einplanen:
  1. Best Practices: Wie lösen andere das? Im Web nach Blogposts, Stack Overflow und Dokumentation suchen
  2. Eigene Muster: Wie hast du es bisher gelöst? In der bestehenden Codebase nach ähnlichen Funktionen suchen
  3. Bibliotheksfunktionen: Was unterstützt das eingesetzte Tool tatsächlich? Die KI Dokumentation oder Source Code lesen lassen
• Die KI soll die Recherche zu einem Plan zusammenführen, der Folgendes enthält:
  1. Das zu lösende Problem (ein klarer Satz)
  2. Zwei bis drei Lösungsansätze (mit ehrlichen Vor- und Nachteilen)
  3. Bestehende Code-Muster, zu denen es passen muss
  4. Edge Cases oder Sicherheitsaspekte
• Den Plan prüfen und auf die eigene Reaktion achten: Wenn du denkst „zu kompliziert“ oder „es gibt schon einen besseren Weg“, ändere nicht nur den Plan, sondern halte fest, warum du so denkst
• Die Funktion auf Basis des Plans ausliefern und die finale Implementierung mit dem ursprünglichen Plan vergleichen: Wo gab es Abweichungen? Warum? Was hätte den Plan besser gemacht?
• Zehn Minuten investieren, um eine Erkenntnis zu formalisieren: Sie in eine Datei CLAUDE.md schreiben, etwa als Regel wie „Bei Aufgaben vom Typ X an Check Y denken“ oder „Wegen Grund C wird Ansatz A gegenüber B bevorzugt“
• Nach dem Sammeln von Erkenntnissen spezialisierte Recherche-Agenten oder Commands erstellen: etwa „Event Tracking Expert“ (kennt deine Muster) oder „Security Checker“ (markiert gängige Fehler)
• Nächste Woche wiederholen, die Notizen heranziehen, prüfen, ob der zweite Plan besser ist als der erste, und über Monate ein System aufbauen, das die Denkweise des Entwicklers kennt