Kieran Klaassen, General Manager von Cora (Every's E-Mail-Produkt), argumentiert, dass generative KI uns "schlampig" gemacht hat, indem sie uns das Planen vergessen ließ. Anfängliches Vibe Coding ("Make this feature work") erzeugt schnell Code, führt aber oft zu 3 Stunden Debugging, die eine 10-minütige Planungssitzung vermieden hätte, während bei jedem Feature von vorn begonnen wird, statt dass die KI mit jeder Anfrage besser wird.
Planning vs Vibe Coding
Der Kontrast ist auffällig. Vibe Coding: "Add email validation to the signup form" → in der Hoffnung, dass die KI den richtigen Weg einschlägt. Planung mit KI: "Research how we handle validation elsewhere in codebase, check if our email library has built-in validation, look up best practices for user-friendly error messages, then create a plan showing three approaches with tradeoffs." Der eine Ansatz liefert ein Feature aus. Der andere liefert ein Feature aus UND bringt dem System bei, wie man beim nächsten Mal denkt.
Das Three-Fidelities-Framework
Klaassen schlägt ein Framework zur Kategorisierung von Engineering-Arbeit vor:
- Fidelity One (Quick Fix): einzeilige Änderungen, Tippfehler, offensichtliche Bugs. Leichtgewichtige Planung genügt. Mit Claude Sonnet 4.5 erweitert sich diese Kategorie: codebasisübergreifende Preisänderungen, E-Mail-Normalisierung, Code-Reorganisation, Abhängigkeits-Migration – mehrstündige Arbeit wird mit einem gut konstruierten Plan zu 10 Minuten.
- Fidelity Two (Sweet Spot): Features über mehrere Dateien hinweg, erforderliches Refactoring, klarer Umfang, aber nicht offensichtliche Implementierung. Hier glänzt Compounding Engineering. Beispiel: Hinzufügen einer Funktion "Archivierung per Abfrage" für Cora. Statt eines direkten Prompts zeigt die Recherchephase ein bereits vorhandenes, wiederverwendbares Tool sowie strikte Gmail-API-Kontingente auf. 20 Minuten Verständnisarbeit ersparten Stunden an Debugging von Produktionsausfällen.
- Fidelity Three (Big Uncertain): größere Features mit epenhaften Anforderungen, vagem Umfang. Planung allein reicht nicht aus. Erfordert "Vibe Planning" = wegwerfbares schnelles Prototyping zur Klärung, gefolgt von rigoroser Planung für die eigentliche Umsetzung. Das Feature "Email Bankruptcy" (53.000 E-Mails) wirkte zunächst wie Fidelity Two, wurde aber zu Fidelity Three, sobald die Komplexität von Rate Limiting, Caching und Queue-Systemen sichtbar wurde. Lösung: 3 Prototypen mit steigendem Schwierigkeitsgrad → lernen, was funktioniert → Aufteilung in aufeinanderfolgende Fidelity-Two-Teile.
Konkreter Fall: Email Bankruptcy
Klaassen hatte 5 Figma-Bildschirmentwürfe und ein Wochenende. Statt manuell zu programmieren, erstellte er zwei Agenten: Agent 1 analysiert einen Figma-Screenshot → erzeugt einen detaillierten, auf Mustern/Komponenten basierenden Plan. Agent 2 vergleicht Figma vs. Gebautes (Puppeteer-Screenshots) → iteriert, bis es übereinstimmt. Ergebnis: 5 pixelgenaue Bildschirme, einschließlich nie entworfener Mobile-Layouts, in einem Wochenende. Der Plan leitete die Arbeit, die Pixelgenauigkeit ergab sich daraus.
Compounding Knowledge
Die eigentliche Stärke: Jede Plan-Review akkumuliert institutionelles Wissen. Code bringt bei: "So löst man DIESES Problem." Pläne bringen bei: "So DENKT man über Probleme dieser Art." Nach über 50 Plan-Reviews spiegeln zurückgegebene Pläne automatisch architektonische Präferenzen wider (z. B. standardmäßig View Components für das Designsystem). Künftige Modelle (GPT-5, Claude Sonnet 4.5+) werden Pläne automatisch verbessern, doch institutionelles Wissen kumuliert sich separat.
Der schnellste Weg zu lehren
Klaassen resümiert: Planung ist die Aktivität mit dem höchsten Hebel in der KI-gestützten Entwicklung. Eine investierte Stunde zur Verbesserung des Planungssystems macht jede zukünftige Stunde produktiver. Der schnellste Weg, KI etwas beizubringen, führt nicht über geschriebenen Code, sondern über geprüfte Pläne.