# klaassen-teach-ai-think-senior-engineer-every-2025-11-07

## Veille

8 KI-Planungsstrategien - Parallele Recherche-Agenten - Codebase-Grounding - Git-Historie - Vibe-Prototyping - Style-Agenten - Compounding Engineering - Every Source Code - Kieran Klaassen

## Titre Article

Teach Your AI to Think Like a Senior Engineer

## Date

2025-11-07

## URL

https://every.to/source-code/teach-your-ai-think-like-a-senior-engineer

## Keywords

Planungsstrategien, Recherche-Agenten, parallele Operationen, Cora E-Mail-Bankruptcy, Reproduzieren und Dokumentieren, Best-Practices-Grounding, Codebase-Grounding, Libraries-Grounding, Git-Historie, Vibe-Prototyping, Synthese mit Optionen, Style-Review-Agenten, Compounding Engineering, institutionelles Gedächtnis, CLAUDE.md, Docs-Wissensdatenbank, AppSignal-Logs, RubyLLM-Gem, EmailClassifier, Event-Tracking, spezialisierte Reviewer, SDLC, Softwarelebenszyklus, agentischer SDLC

## Authors

Kieran Klaassen (General Manager, Cora)

## Ton

**Profil:** Fortgeschrittenes Praktiker-Tutorial | Praktiker-Perspektive in der Ich-Form | Präskriptiv-systematisch | Experte

Klaassen nimmt die Stimme eines erfahrenen Praktikers an, der ein konkretes taktisches Playbook teilt, im Anschluss an seinen früheren, eher philosophischen Artikel. Die Struktur der 8 Strategien (Reproduzieren → Best Practices → Codebase → Libraries → Git → Vibe → Synthese → Review) demonstriert das systematische Denken, das für einen Senior Engineer typisch ist. Die Sprache eines Praktikers im Feld (AppSignal-Logs, das RubyLLM-Gem, Helper-Methoden, Denormalisierung, Pull Requests), gestützt auf Produktionsbeispiele von Cora, schafft Glaubwürdigkeit. Der selbstbewusste, präskriptive Ton („You can avoid building the wrong thing, too“) spiegelt Meisterschaft wider. Direkte GitHub-Links und das quelloffen veröffentlichte Planungssystem zeigen ein Bekenntnis zum offenen Teilen von Wissen. Die Betonung von „how to make this compound“ nach jeder Strategie verstärkt die zentrale These der Wissensakkumulation. Typisch für die fortgeschrittenen Tutorials von Everys Source Code (Klaassen, die technischen Beiträge von Dan Shipper), gerichtet an Praktiker, die sofort umsetzen wollen, statt auf konzeptionelles Verständnis abzuzielen.

## Pense-betes

- **Anschluss an den vorherigen Artikel**: Stop Coding and Start Planning (2025-11-06)
- **Zentrale These**: Parallele Recherche-Operationen vermitteln der KI schneller deine Denkweise als sequenzielles menschliches Planen
- **8 Planungsstrategien** nach Fidelity-Level (One: schnelle Fixes, Two: klarer Scope, Three: unsichere Anforderungen) **Strategie 1: Reproduzieren und dokumentieren**
- Fidelity: One & Two, Bugfixes
- Rolle des Agenten: Schritt-für-Schritt-Anleitung zur Reproduktion
- Cora-Beispiel: 19 Nutzer bei der E-Mail-Bankruptcy blockiert, AppSignal-Logs enthüllten verschluckte Rate-Limit-Fehler, stille Fehler
- Compounding: @kieran-rails-reviewer-Checkliste aktualisiert — „Background Jobs, die externe APIs aufrufen: werden Rate Limits behandelt?“ **Strategie 2: In Best Practices verankern**
- Fidelity: alle, besonders bei unbekannten Mustern
- Agent: @agent-best-practices-researcher
- Anwendungsfälle: technische Architektur, Copywriting, Pricing-Recherche, Upgrade-Pfade
- Beispiel: ein Gem, das 2 Versionen hinterherhinkt; der Agent fand den offiziellen Guide + 3 Blogposts mit Edge Cases; 3 Minuten Recherche ersparten Stunden des Debuggings
- Compounding: Erkenntnisse gespeichert in docs/*.md (pay-gem-upgrades.md, pricing-research.md); der Agent prüft die lokale Dokumentation vor dem Web **Strategie 3: In deiner Codebase verankern**
- Fidelity: alles, was riskiert, ein bestehendes Feature zu duplizieren
- Rolle des Agenten: den bestehenden Code nach verwandten Implementierungen durchsuchen
- Beispiel: Event-Tracking-Feature; der Agent fand ein vergessenes bestehendes Tracking-System mit Helper-Methoden
- Compounding: Erstellung eines @event-tracking-expert-Agenten, der alle Tracking-Muster destilliert und automatisch bei relevanten Features läuft **Strategie 4: In deinen Libraries verankern**
- Fidelity: sich schnell weiterentwickelnde oder schlecht dokumentierte Libraries
- Rolle des Agenten: den Quellcode analysieren, um die Fähigkeiten zu verstehen
- Beispiel: Das RubyLLM-Gem entwickelt sich ständig weiter, die Dokumentation hinkt hinterher; der Agent las den Quellcode und fand die undokumentierte Streaming-Unterstützung von v1.9
- Compounding: Das Wissen aktualisiert sich automatisch bei jedem Dependency-Update, nie veraltete Informationen **Strategie 5: Git-Historie studieren**
- Fidelity: Refactorings, Fortführung früherer Arbeit, Verständnis des „Warum“
- Rolle des Agenten: vergangene Entscheidungen und ihren Kontext recherchieren
- Beispiel: EmailClassifier v1 vs. v2; der Agent fand einen 3 Monate alten PR, der zeigte, dass der Wechsel zu v2 versucht worden war, defekte Edge Cases aufwies und bewusst zurückgesetzt worden war
- Compounding: institutionelles Gedächtnis bleibt erhalten und durchsuchbar, neue Teammitglieder erben die Begründung **Strategie 6: Vibe-Prototyping zur Klärung**
- Fidelity: Three, UX-Unsicherheit, explorativ
- Rolle des Agenten: schnell wegwerfbare Versionen bauen, mit denen interagiert werden kann
- Beispiel: Redesign des Brief-Interface, 5 Prototypen zu je 5 Minuten, Nutzerfeedback „Archivieren-Button oben links — von Gmail übernommener Reflex“
- Compounding: vibe coding verwandelt Unsicherheit in konkrete Spezifikationen, Nutzerreaktionen werden dokumentiert **Strategie 7: Mit Optionen synthetisieren**
- Fidelity: Ende der Rechercephase vor der Implementierung
- Rolle des Agenten: 2-3 Lösungswege mit ehrlichen Vor- und Nachteilen präsentieren
- Beispiel: Gmail-Inbox-Sync, 3 Optionen (Aufpfropfen auf Bestehendes / Echtzeit / Mirror-Cache), Tradeoffs (schnell, aber unsauber / sauber, aber langsam / anfänglicher Aufwand, aber langfristig besser)
- Compounding: Die Entscheidung offenbart Präferenzen („Ich bevorzuge weit verbreitete Lösungen gegenüber Cutting-Edge“), kodifiziert für ähnliche zukünftige Entscheidungen **Strategie 8: Review mit Style-Agenten**
- Fidelity: letzter Planungsschritt vor der Implementierung
- Rolle des Agenten: Abweichungen von Code-Style und Architektur erkennen
- Drei Review-Agenten:
- Simplification: markiert Over-Engineering
- Security: prüft Schwachstellen
- Style-Kieran: persönliche Präferenzen (einfache Queries vs. komplexe Joins, Denormalisierung)
- Compounding: Die Agenten sammeln im Laufe der Zeit Geschmack an, jedes „Das gefällt mir nicht“ macht das System klüger **Praktischer Einstiegsleitfaden**:
- Ein Fidelity-Two-Feature auswählen (mehrere Dateien, klarer Scope)
- 15-20 Minuten Recherche: Best Practices (Web), Muster (Codebase), Library-Fähigkeiten (Docs/Quellcode)
- Die KI synthetisieren lassen: Problem (1 Satz), 2-3 Ansätze (Vor-/Nachteile), Abgleich mit bestehenden Mustern, Edge Cases/Security
- Deine Review-Reaktionen festhalten: „zu komplex“ oder „besserer Weg“ notieren — das WARUM aufschreiben
- Das Feature ausliefern, die Umsetzung mit dem Plan vergleichen, die Abweichungen notieren
- 1 Learning kodifizieren: es zu CLAUDE.md hinzufügen („Wenn X, dann Y prüfen“ oder „A gegenüber B bevorzugen, weil C“)
- Spezialisierte Agenten erstellen: Event Tracking Expert, Security Checker
- Wiederholen: in der folgenden Woche auf die Notizen zurückgreifen; der zweite Plan ist besser als der erste **Open Source**: Everys GitHub-Marketplace, /plan-Befehl + einsatzbereite Recherche-Agenten

## RésuméDe400mots

Kieran Klaassen stellt 8 konkrete Strategien vor, die Planungsphilosophie in operative Systeme verwandeln, um einer KI beizubringen, wie ein Senior Engineer zu denken. Im Anschluss an seinen vorherigen Artikel über Planung vs. vibe coding beschreibt dieser taktische Leitfaden im Detail, wie sich parallele Recherche-Operationen schneller durchführen lassen als sequenzielles menschliches Planen.

**Framework der 8 Strategien**

**1. Reproduzieren und dokumentieren**: Bevor ein Bug behoben wird, wird er reproduziert und dokumentiert. Beispiel von Coras E-Mail-Bankruptcy: 19 Nutzer blockiert; der Agent durchsuchte die AppSignal-Logs → Rate-Limit-Fehler wurden stillschweigend verschluckt. Kein Rätselraten mehr. Compounding: dauerhafte Aktualisierung der @kieran-rails-reviewer-Checkliste.

**2. In Best Practices verankern**: @agent-best-practices-researcher durchsucht das Web danach, wie andere das Problem bereits gelöst haben. Anwendungsfälle: Architektur, Copywriting, Pricing, Upgrades. Ein Gem, das 2 Versionen hinterherhinkt: 3 Minuten Recherche fanden den offiziellen Guide + 3 Blogposts zu Edge Cases und ersparten Stunden des Debuggings. Compounding: Erkenntnisse werden in docs/*.md gespeichert, der Agent prüft zuerst die lokale Dokumentation.

**3. In der Codebase verankern**: Vor dem Neuaufbau wird nach bestehenden Mustern gesucht. Event-Tracking-Feature: Der Agent fand ein vergessenes bestehendes System mit seinen Helper-Methoden und verhinderte so den Aufbau eines zweiten, inkompatiblen Systems. Compounding: Der @event-tracking-expert-Agent destilliert alle Muster und läuft automatisch.

**4. In Libraries verankern**: Bei sich schnell weiterentwickelnden, schlecht dokumentierten Libraries wird der Quellcode gelesen. RubyLLM-Gem: Der Agent entdeckte die Streaming-Unterstützung von v1.9, undokumentiert, aber in der Test-Suite vorhanden. Compounding: automatische Aktualisierung bei jedem Dependency-Versionssprung.

**5. Git-Historie studieren**: Das „Warum“ hinter vergangenen Entscheidungen verstehen. EmailClassifier-Upgrade: Der Agent fand einen 3 Monate alten PR, der zeigte, dass v2 bereits versucht worden war, defekte Edge Cases aufwies (Inbox→Archiv und Archiv→Inbox vertauscht) und mit ausführlicher Begründung bewusst zurückgesetzt worden war. 5 Minuten Recherche verhinderten die Wiedereinführung eines bereits debuggten Bugs. Compounding: institutionelles Gedächtnis bleibt erhalten und durchsuchbar.

**6. Vibe-Prototyping zur Klärung**: Fidelity Three, unsichere UX. Brief-Interface: 5 Prototypen zu je 5 Minuten, konkretes Nutzerfeedback („Archivieren-Button oben links — Gmail-Reflex“). Die Prototypen werden verworfen, das Wissen fließt in den Plan ein. Compounding: Unsicherheit wird zu dokumentierten, konkreten Spezifikationen.

**7. Mit Optionen synthetisieren**: Die gesamte Recherche wird zu 2-3 Ansätzen mit ehrlichen Tradeoffs zusammengeführt. Gmail-Inbox-Sync: Option A (Aufpfropfen auf das bestehende System — schnell, aber unsauber), B (Echtzeit — sauber, aber langsam), C (Mirror-Cache — anfänglicher Aufwand, aber langfristig besser). Der Agent übernimmt die Recherche, der Mensch urteilt. Compounding: Die Entscheidungen offenbaren Präferenzen, die für ähnliche zukünftige Entscheidungen kodifiziert werden („weit verbreitete Lösungen gegenüber Cutting-Edge bevorzugen“).

**8. Review mit Style-Agenten**: 3 spezialisierte Reviewer im letzten Durchgang. Simplification-Agent (markiert Over-Engineering), Security-Agent (prüft Schwachstellen), Style-Kieran-Agent (persönliche Präferenzen: einfache Queries vs. komplexe Joins, Denormalisierung). Compounding: Die Agenten sammeln im Laufe der Zeit Geschmack an.

**Ein aufschlussreicher E-Mail-Bankruptcy-Fall**: Zunächst als einfach eingeschätzt („53.000 E-Mails per Bulk-Archivierung, wie schwer kann das schon sein?“). 20 Minuten Arbeit des Recherche-Agenten holten die Realität zurück: Gmail-Rate-Limits griffen bereits bei 2.000, System-Timeouts, lange Wartezeit für den Nutzer. Aus dem einfachen Feature wurde eine 3-tägige architektonische Herausforderung. Planning verhinderte den Bau von etwas komplett Falschem.

**Praktische Umsetzung**: Ein Fidelity-Two-Feature auswählen → 15-20 Minuten Recherche (Best Practices im Web + Codebase-Muster + Library-Fähigkeiten) → die KI synthetisiert den Plan (Problem/Ansätze/Muster/Edge Cases) → das WARUM hinter den Review-Reaktionen festhalten → ausliefern → die Umsetzung mit dem Plan vergleichen → 1 Learning in CLAUDE.md kodifizieren → spezialisierte Agenten erstellen → in der folgenden Woche wiederholen.

**Open-Source-Beitrag**: Klaassen hat sein Planungssystem auf Everys GitHub-Marketplace als Open Source veröffentlicht, mit dem /plan-Befehl und einsatzbereiten Recherche-Agenten. Philosophie: nicht bei null anfangen, sondern bestehende, bewährte Systeme anpassen.

Jede Strategie enthält einen Hinweis „how to make this compound“, der die zentrale These verdeutlicht: Parallele Recherche-Operationen vermitteln der KI institutionelles Wissen, das sich schneller anhäuft als bei sequenzieller menschlicher Planung.

## GrapheDeConnaissance

- Kieran Klaassen —a_créé→ Compound Engineering (METHODOLOGIE, 0.95)
- Kieran Klaassen —dirige→ Cora (ORGANISATION, 0.98)
- Kieran Klaassen —travaille_chez→ Every (ORGANISATION, 0.98)
- Compound Engineering —est_basé_sur→ opérations de recherche parallèles (CONCEPT, 0.95)
- opérations de recherche parallèles —remplace→ planification séquentielle humaine (CONCEPT, 0.9)
- Kieran Klaassen —utilise→ Claude Code (TECHNOLOGIE, 0.97)
- Cora —utilise→ Gmail API (TECHNOLOGIE, 0.92)
- Gmail API —mesure→ limite de débit à 2000 emails (MESURE, 0.95)
- AppSignal —permet→ diagnostic logs production (CONCEPT, 0.9)
- Cora —utilise→ RubyLLM (TECHNOLOGIE, 0.88)
- CLAUDE.md —référence→ préférences architecturales (CONCEPT, 0.92)
- git history —permet→ mémoire institutionnelle (CONCEPT, 0.9)
- vibe coding —permet→ transformation des incertitudes UX en spécifications (CONCEPT, 0.88)
- Every —publie→ planning system open-source (TECHNOLOGIE, 0.93)

---
Canonical: https://www.thekb.eu/de/fiches/klaassen-teach-ai-think-senior-engineer-every-2025-11-07/