Insights
Le problème des 80 % et le vrai coût du vibe coding
L’agent écrit vite les 80 % faciles. Le coût réel se joue sur les 20 % restants, la dette et le harness qu’on n’a pas payé une fois.
Le papier d’Osmani, Saboo et Kartakis (mai 2026) décrit un piège que les équipes reconnaissent vite. L’agent écrit environ 80 % d’une fonctionnalité sans peine. Les 20 % qui restent sont les cas limites, les erreurs, les jointures avec le reste du système, la justesse métier. Le code a l’air bon. Il passe parfois les tests évidents. L’erreur a changé de nature : ce n’est plus une syntaxe fausse, c’est une hypothèse fausse sur le métier, un cas non demandé, une décision d’architecture qui coûtera dans six mois.
Où mettre l’attention humaine
La parade n’est pas d’aller plus vite en acceptant tout. C’est de réserver l’attention humaine à ce que le modèle rate : exigence ambiguë, arbitrage d’architecture, vérification. Deux postures coexistent dans la journée. Le conducteur est dans l’éditeur, au fil de l’eau, sur la logique difficile. L’orchestrateur délègue une tâche bien spécifiée et relit plus tard. Le mauvais réflexe est de traiter les deux comme la même chose, et de laisser partir en arrière-plan ce qui n’était pas spécifié.
L’économie suit
Le vibe coding a l’air gratuit : un abonnement, quelques prompts, peu d’investissement au départ. Le coût glisse après. Tokens brûlés à recoler des erreurs, dette que personne ne sait relire, maintenance d’un code que l’équipe n’a pas vraiment compris. L’ingénierie agentique coûte plus cher au début, specs, tests, harness, et moins ensuite, parce que la correction est une boucle et pas une surprise. Le papier le dit en CapEx et OpEx. Pour un dirigeant, la métrique n’est pas le nombre de lignes par semaine. C’est le coût total pour une tâche qui reste juste.
Deux leviers déjà connus
Deux leviers reviennent, et ils recoupent ce qu’on écrit déjà sur le FinOps. Le contexte : tout jeter dans la fenêtre coûte cher et dégrade la réponse. On ne charge que ce que la tâche exige, et des skills réutilisables plutôt qu’un prompt géant. Le routage : un petit modèle pour le geste simple, un modèle qui réfléchit quand l’erreur coûte. La vitesse d’écriture n’est pas le sujet. Le sujet est de ne pas payer un raisonnement long pour reformuler un message.
Par où commencer
Un développeur : un agent dans l’éditeur, un dans le terminal, et le fond seulement pour une tâche qu’on peut décrire en un paragraphe. Un responsable d’ingénierie : une porte de qualité avant d’accélérer, pas l’inverse. Une organisation : le harness et les permissions comme standard d’équipe, pas comme préférence personnelle.
Position YOWE
Les 80 % faciles ne sont pas le gain. Le gain est de savoir qui vérifie les 20 % qui restent, et de payer le harness une fois plutôt que la dette chaque semaine.