Kieran Klaassen, General Manager de Cora (produit email d'Every), argumente que l'IA générative nous a rendus "sloppy" en nous faisant oublier comment planifier. Le vibe coding initial ("Make this feature work") génère rapidement du code mais conduit souvent à 3 heures de debugging qu'une session de 10 minutes de planification aurait évitées, tout en repartant de zéro à chaque feature au lieu que l'IA s'améliore avec chaque requête.
Planification vs Vibe Coding
Le contraste est frappant. Vibe coding : "Add email validation to the signup form" → espérer que l'IA prenne la bonne route. Planning avec IA : "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." Une approche ship une feature. L'autre ship une feature ET enseigne au système comment vous pensez pour la prochaine fois.
Framework des Three Fidelities
Klaassen propose un framework pour catégoriser le travail d'engineering :
- Fidelity One (Quick fix) : changements one-line, typos, bugs évidents. Planning lightweight suffit. Avec Claude Sonnet 4.5, cette catégorie s'étend : changements pricing cross-codebase, normalisation emails, reorganisation code, migration dépendances - du travail multi-heures devenu 10 minutes avec plan well-constructed.
- Fidelity Two (Sweet spot) : features multi-files, refactoring requis, scope clair mais implémentation non-évidente. C'est ici que compounding engineering brille. Exemple : ajouter capacité "archive by query" pour Cora. Plutôt que prompt direct, phase de recherche révèle tool existant réutilisable et quotas stricts Gmail API. 20 minutes de compréhension saved heures de debugging production failures.
- Fidelity Three (Big uncertain) : features majeures avec requirements épiques, scope flou. Planning seul insuffisant. Requiert "vibe planning" = prototypage rapide disposable pour clarifier, puis planning rigoureux pour build properly. Email bankruptcy feature (53,000 emails) semblait Fidelity Two, devint Fidelity Three quand découverte complexité rate limiting, caching, queue systems. Solution : 3 prototypes ascending difficulty → learn what works → break into sequential Fidelity Two pieces.
Cas concret : Email Bankruptcy
Klaassen avait 5 écrans Figma designs et un weekend. Au lieu de coder manuellement, il créa deux agents : Agent 1 analyse Figma screenshot → output detailed plan grounded in patterns/components. Agent 2 compare Figma vs built (Puppeteer screenshots) → iterate until match. Résultat : 5 screens pixel-perfect, including mobile layouts jamais designés, en un weekend. Plan guida work, pixel perfection émergea.
Compounding Knowledge
La vraie puissance : chaque plan review accumule institutional knowledge. Code enseigne "Here's how to solve THIS problem." Plans enseignent "Here's how to THINK about problems like this." Après 50+ plan reviews, plans returned reflètent automatiquement préférences architecturales (ex: View Components by default pour design system). Next models (GPT-5, Claude Sonnet 4.5+) amélioreront plans automatically, mais institutional knowledge compounds séparément.
Fastest way to teach
Klaassen conclut : planning est highest-leverage activity en AI-assisted development. Une heure investie improving planning system makes every future hour more productive. Fastest way to teach AI n'est pas through code you write, mais through plans you review.