# klaassen-stop-coding-start-planning-every-2025-11-06

## Veille

Planning vs Vibe Coding - Compounding Engineering - Three Fidelities - AI Agents - Cora Email Bankruptcy - Plans Teach Systems - Every Source Code

## Titre Article

Stop Coding and Start Planning

## Date

2025-11-06

## URL

https://every.to/source-code/stop-coding-and-start-planning

## Keywords

planning, vibe coding, compounding engineering, AI agents, three fidelities, Cora, email bankruptcy, Figma to code, planning agents, institutional knowledge, Claude Code, research phase, prototyping, vibe planning, View Components, GitHub plans, Puppeteer review, teaching AI systems, SDLC, software lifecycle, agentic SDLC

## Authors

Kieran Klaassen (General Manager, Cora)

## Ton

**Profil:** Praktiker-Tutorial | Praktiker in der Ich-Perspektive | Erzählerisch-pädagogisch | Expertenhaft-zugänglich

Klaassen (GM von Cora) nimmt die Stimme eines erfahrenen Praktikers an, der hart erarbeitete Lektionen aus dem Aufbau eines E-Mail-Produkts teilt. Die narrative Tutorial-Struktur (Problem → Erkenntnis → Lösung → Beispiel) veranschaulicht eine auf Storytelling basierende Pädagogik. Die praktikernahe Ingenieurssprache (Rate Limiting, Cache-Layer, Queue-System, Race Conditions), verankert im konkreten Beispiel von Coras Email Bankruptcy, schafft Glaubwürdigkeit. Der ehrliche und reflektierte Ton, der eigene Fehler eingesteht ("I did it, too"), bevor Lösungen vorgeschrieben werden, schafft Vertrauen. Persönliche Anekdoten (5 Figma-Bildschirme, ein Wochenend-Deadline, verworfene Prototypen) humanisieren die technischen Konzepte. Der Fokus auf systemisches Denken ("teaching the AI how you think") statt auf taktische Ausführung spiegelt die Perspektive eines Senior-Engineers wider. Typisch für Every.to's Source-Code-Kolumnisten (Dan Shipper, Nathan Baschez), die praktische Tutorials und strategische Frameworks für ein Publikum von Buildern verbinden, das nachhaltige KI-Workflows jenseits des Hypes sucht.

## Pense-betes

- **Zentrale These**: "AI made us sloppy because it made us forget how to plan"
- **Vibe Coding**: "Make this feature work" → in der Hoffnung, dass die KI den richtigen Weg einschlägt → 3 Std. Debugging statt 10 Min. Planung
- **Planung mit KI**: Codebasis recherchieren, Library prüfen, Best Practices konsultieren, Plan mit 3 Ansätzen + Tradeoffs erstellen
- **Pläne lehren Systeme, Code löst Probleme**: Pläne = institutionelles Wissen, Code = einmalige Lösung
- **Compounding Engineering**: jede Arbeitseinheit erleichtert die nächste, indem sie die KI etwas lehrt
- **Das Three-Fidelities-Framework**:
- **Fidelity One (Quick Fix)**: einzeilige Änderung, Tippfehler, offensichtlicher Bug. Leichtgewichtige Planung. Claude Sonnet 4.5 erweitert diesen Umfang (Preisänderungen, E-Mail-Normalisierung, Test-Fixes)
- **Fidelity Two (Sweet Spot)**: mehrere Dateien, Refactoring, klarer Umfang, nicht offensichtliche Implementierung. Massiver ROI durch Planung. Beispiel: abfragebasiertes Archivierungs-Tool
- **Fidelity Three (groß und unsicher)**: größere Features, vager Umfang, unsichere Anforderungen. Vibe Planning = schnelles Prototyping + rigorose Planung. Beispiel: Email Bankruptcy, 53.000 E-Mails
- **Fall Cora Email Bankruptcy**: 5 Figma-Bildschirme → pixelgenau in einem Wochenende dank Planungsagenten
- **Zwei-Agenten-Workflow**: Agent 1 (Figma-Analyse → Plan), Agent 2 (Puppeteer-Vergleich → iterieren bis Übereinstimmung)
- **Wissensakkumulation**: über 50 Plan-Reviews → das System lernt Präferenzen und architektonisches Denken
- **Kritische Recherchephase**: abfragebasierte Archivierung deckte ein bestehendes Such-Tool und Gmail-API-Kontingente auf
- **Vibe Planning**: wegwerfbare Prototypen zur Klärung der Anforderungen vor der eigentlichen Implementierung
- **Aufteilung von Fidelity Three**: 3 Lösungen prototypisieren (Echtzeit, einfacher Cache, Queue) → lernen → in Fidelity-Two-Teile aufteilen
- **Präferenz für View Components**: in Agentenanweisungen kodifiziert → automatisch für alle künftigen Designs
- **Pläne bleiben bestehen, Prototypen werden verworfen**: Wissen wird extrahiert, dann wird der Prototyp aufgegeben
- **Künftige Modelle profitieren automatisch**: GPT-5/Claude verbessern Pläne, aber institutionelles Wissen akkumuliert sich separat

## RésuméDe400mots

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.

## GrapheDeConnaissance

- Kieran Klaassen —dirige→ Cora (ORGANISATION, 0.98)
- Kieran Klaassen —travaille_chez→ Every (ORGANISATION, 0.98)
- Kieran Klaassen —recommande→ planification avec IA (METHODOLOGIE, 0.97)
- vibe coding —s_oppose_à→ planification avec IA (METHODOLOGIE, 0.95)
- Compound Engineering —est_basé_sur→ plans enseignant le système (CONCEPT, 0.95)
- Three Fidelities —s_applique_à→ travail d'engineering (CONCEPT, 0.93)
- Fidelity Two —améliore→ Compound Engineering (METHODOLOGIE, 0.88)
- Fidelity Three —utilise→ vibe planning (METHODOLOGIE, 0.9)
- agent de planification Figma —utilise→ Puppeteer (TECHNOLOGIE, 0.92)
- Claude Code —améliore→ planification Fidelity One (CONCEPT, 0.9)
- Cora —a_créé→ email bankruptcy feature (CONCEPT, 0.97)
- Gmail API —s_applique_à→ opérations bulk (CONCEPT, 0.93)
- plans —permet→ connaissance institutionnelle (CONCEPT, 0.92)

---
Canonical: https://www.thekb.eu/de/fiches/klaassen-stop-coding-start-planning-every-2025-11-06/