Vibe coding ou agentic coding : vous n'avez pas le droit de confondre

Décembre 2025. Andrej Karpathy — co-fondateur d'OpenAI, architecte de l'Autopilot Tesla, et surtout inventeur du terme vibe coding — sort d'un break et reprend son clavier. Il observe quelque chose d'inhabituel : les blocs de code générés par les nouveaux modèles sortent juste du premier coup. Plus de corrections en boucle, plus de friction. Il n'arrête plus. Sa conclusion, qui circule depuis sur X, est aussi lucide que dérangeante : "I've never felt more behind as a programmer."¹

Ce n'est pas un cri d'enthousiasme naïf. C'est le diagnostic d'un ingénieur de premier plan qui prend acte d'une rupture, et qui est le premier à admettre que la taxonomie qu'il a lui-même forgée ne suffit plus. Entre vibe coding et agentic engineering, le fossé n'est pas de degré — c'est une divergence de finalité. Les confondre n'est pas une imprécision : c'est une faute professionnelle en gestation. Ce comparatif prolonge notre pilier sur l'agentic coding en entreprise.

Retour aux sources : qu'a vraiment dit Karpathy ?

Karpathy n'a jamais dit que le vibe coding était la destination. Il a dit que c'était une démocratisation du plancher. "Raise the floor" — n'importe qui peut désormais générer un prototype fonctionnel sans maîtriser le code sous-jacent. C'est réel, c'est précieux, et c'est limité.

L'agentic engineering, lui, a une ambition inverse : "preserve the quality bar" de l'ingénierie professionnelle. "You're not allowed to introduce vulnerabilities due to vibe coding. You're still responsible for your software just as before, but can you go faster?"¹. La distinction n'est pas dans l'outil utilisé — dans les deux cas, le LLM écrit du code — mais dans le niveau de responsabilité que l'ingénieur conserve sur ce qui sort.

Ce n'est pas une nuance philosophique : c'est une frontière opérationnelle. Le vibe coding admet l'approximation comme mode de fonctionnement normal. L'agentic engineering l'interdit. Et Karpathy, qui a construit les systèmes de sécurité d'un véhicule autonome, sait exactement ce que "responsible for your software" signifie dans un contexte de production.

Kent Beck trace la même ligne, depuis le terrain

À peu près au même moment, Kent Beck — père du TDD et de l'eXtreme Programming — publie une expérience détaillée sur Substack². Il a passé quatre semaines et 110 à 130 heures à implémenter une bibliothèque B+ Tree en Rust et Python avec un agent. Deux versions abandonnées. Une troisième qui atteint des benchmarks compétitifs face à BTreeMap de Rust et SortedDict de Python.

Sa distinction est chirurgicale. L'augmented coding (son terme pour l'agentic engineering) maintient les mêmes valeurs que le hand coding : qualité du code, tests, couverture, séparation stricte entre changements structurels et comportementaux. Le vibe coding est indifférent à ces valeurs — il se contente du comportement observable. "I feel good about the correctness and performance, not so good about the code quality. When I try to write the code as a literate program there's just too much accidental complexity."².

Beck est ici d'une honnêteté rare : même en restant vigilant, même en imposant à l'agent un system prompt TDD strict (Red → Green → Refactor, jamais mélanger changements structurels et comportementaux dans le même commit), la complexité accidentelle s'accumule. L'agent ne déteste rien autant que simplifier. Karpathy confirme depuis ses propres expériences : tenter de faire refactoriser du code par un LLM pour en réduire la complexité, "the models hate this. They can't do it. You feel like you're outside of the RL circuits. It's like pulling teeth."¹.

Addy Osmani pose le diagnostic, chiffres à l'appui

Si Karpathy et Beck tracent la frontière conceptuelle, Addy Osmani — Engineering Leader chez Google Chrome — la rend industriellement lisible³.

Sa thèse : confondre vibe coding et AI-assisted engineering est une erreur sémantique qui "dévalorise la discipline d'ingénierie" et donne aux nouveaux entrants "une illusion dangereuse" — celle qu'on peut prompter son chemin vers un produit viable sans comprendre ni l'architecture ni le code. Une équipe FAANG citée dans un post Reddit a mesuré une augmentation de 30% de la vitesse de développement — mais précisément parce qu'elle a maintenu une intégration disciplinée de l'IA dans un SDLC mature, pas parce qu'elle a abandonné l'ingénierie.

La formule d'Osmani : l'IA est un force multiplier, pas une baguette magique. "Use AI like junior dev: helpful, but never unsupervised." Ce multiplicateur ne fait gagner que si l'humain conserve la maîtrise de l'architecture, la revue rigoureuse de chaque ligne, et la responsabilité de la sécurité, de la scalabilité et de la maintenabilité. Sans cela, il accélère aussi — mais il accélère l'accumulation de dette.

La dette technique du vibe : ce qu'on ne voit pas dans les démos

La confusion entre les deux postures a un coût bien documenté. L'été 2025 en a fourni plusieurs illustrations concrètes. Kate Holterhoff (RedMonk) recense les incidents : perte d'une base de données de production chez Replit, fuites de données via le Model Context Protocol chez GitHub et Supabase, politique tarifaire de Cursor qui surprend des équipes ayant intégré le vibe coding comme workflow standard sans mesurer la consommation de tokens⁴.

Ces incidents ne sont pas des bugs de l'outil. Ce sont des conséquences directes d'une adoption sans doctrine. Shawn "swyx" Wang, cité par Holterhoff, nomme le mécanisme : la négligence. Le vibe coding encourage à s'arrêter au "suffisant", à ne pas faire les 20% difficiles — les tests d'intégration, le hardening de sécurité, la gestion des cas limites. Le code passe les cas nominaux, il est déployé, et la dette s'accumule en silence jusqu'à ce qu'un incident la révèle.

Osmani appelle ça le verification burden : le coût de supervision du code généré par l'IA est significatif. Le négliger ne supprime pas le coût — il le reporte sur la production. Ce report est le fond du problème du vibe coding mal utilisé. Ce n'est pas que les outils soient mauvais ; c'est que le vibe coding, poussé jusqu'à la production sans garde-fous, transfère le risque de l'immédiat vers le futur, du sprint vers l'incident.

« Outsource your thinking, not your understanding »

Il y a une formule de Karpathy qui mérite d'être gravée dans les process de chaque équipe : "You can outsource your thinking but you can't outsource your understanding."¹. Elle dit tout sur la ligne de partage entre les deux postures.

Le vibe coder délègue la compréhension. L'agentic engineer délègue l'exécution — la production de code, le boilerplate, la gestion du yak shaving que Kent Beck apprécie de ne plus faire manuellement — mais conserve la compréhension : architecture, intentions, cas limites, trade-offs de sécurité. "You're in charge of the taste, the engineering, the design, that it makes sense, that you're asking for the right things. The engineers are doing the fill in the blanks." (Karpathy)¹.

Cette distinction recoupe exactement ce que Beck observe dans son cycle TDD : l'IA peut écrire le code vert. Elle ne peut pas décider du bon test à écrire. Elle ne peut pas juger si l'abstraction choisie va tenir dans six mois. Elle peut translittérer Python en Rust — c'est ce que Beck a fait pour débloquer sa B+ Tree — mais elle ne peut pas décider si c'est la bonne décision architecturale. La compétence humaine qui prend de la valeur n'est plus la capacité à écrire du code : c'est le taste, le jugement, la spec, la supervision. C'est précisément ce que Karpathy désigne quand il dit que "le 10x engineer est magnifié bien au-delà de 10x" dans le paradigme agentique.

Le vibe reviewing : suite logique ou garde-fou ?

La tension entre les deux postures a engendré une troisième pratique, plus récente et plus pragmatique. Alexandre Mogère, Chapter Lead à la Software Factory de Carrefour France, la nomme vibe reviewing⁵. L'idée : appliquer les principes de génération assistée par IA non pas à la production de code, mais à sa revue.

Le retour terrain est instructif. Mogère a réduit le temps d'audit de code par un facteur 3 grâce à un système multi-agents avec cross-validation. Mais les garde-fous sont nombreux : validation humaine systématique des sorties agents, car les hallucinations techniques sont réelles (des CVE inexistantes peuvent être générées avec une apparence de vraisemblance), expertise technique humaine pour contextualiser les recommandations que l'agent ne peut pas situer dans l'historique métier. Le rapport d'audit devient un document vivant, roadmap de migration, support d'onboarding — mais il ne vaut que si un humain en valide la substance.

Le vibe reviewing est une réponse matinale au problème du vibe coding : quand une équipe a déjà du code généré sans doctrine rigoureuse, l'audit assisté par agents peut résorber la dette accumulée plus vite qu'une revue manuelle. C'est la suite logique. Mais ce n'est pas une alternative à l'agentic engineering — c'est un outil de rattrapage pour ceux qui ont fait du vibe coding sans garde-fous. Les deux coexistent dans le SDLC augmenté : l'un empêche la dette, l'autre la traite.

Quand choisir l'une ou l'autre posture ?

La question n'est pas idéologique. C'est une question de contexte et de conséquence.

Contexte	Posture recommandée	Critère décisif
Prototype, MVP jetable, exploration d'une API	Vibe coding	Vitesse prime, aucune contrainte de production
Week-end project, apprentissage, démonstration	Vibe coding	Apprentissage par expérimentation
Code de production, système avec utilisateurs	Agentic engineering	Responsabilité, sécurité, maintenabilité
Bibliothèque partagée, base de code long terme	Agentic engineering	Qualité du code et évolutivité
Audit de code existant ou migration	Vibe reviewing	Résorption de dette avec supervision humaine

L'erreur systémique n'est pas de faire du vibe coding — Karpathy lui-même l'a fait, Osmani reconnaît son utilité pour les projets jetables. L'erreur est de ne pas savoir qu'on le fait, ou de penser que la frontière est floue quand on passe en production. "Vibe coding is not the same as AI-assisted engineering" — Osmani ne dit pas que l'un est mauvais et l'autre bon. Il dit qu'ils ne sont pas substituables, et que les confondre dans les mauvais contextes fabrique de la dette, des incidents, et des illusions professionnelles.

Ce que SFEIR observe dans les équipes

Sur le terrain, les consultants SFEIR constatent régulièrement le même schéma : des équipes qui ont adopté le vibe coding pour aller vite sur un prototype, qui n'ont pas reconfiguré leur posture avant de passer en production, et qui se retrouvent à traiter en urgence une dette structurelle que le code généré a masquée pendant les sprints initiaux. Ce n'est pas une fatalité — c'est un problème de doctrine, pas d'outil.

Le framework Harness Engineering que SFEIR porte dans ses missions codifie la distinction à un niveau opérationnel : l'équation Agent = Model + Harness rappelle que la performance d'un système agentique ne tient pas au modèle seul, mais au harnais — les guides feedforward, les sensors feedback, les garde-fous qui font gagner 20 points de performance à modèle égal. Un pipeline de vibe coding sans harnais, c'est un modèle sans harnais : performant sur les cas nominaux, fragile sur tout le reste.

La progression que SFEIR documente va dans le même sens que Karpathy : prompt engineering → context engineering → harness engineering. Le vibe coding opère au premier niveau. L'agentic engineering suppose au minimum le deuxième, et dès qu'on est en production, le troisième. "Écrire du code est désormais un anti-pattern. On ne doit plus produire de code manuellement" (Didier Girard, SFEIR) — mais ne plus écrire de code manuellement ne dispense pas de comprendre ce que les agents écrivent.

Points clés

• Vibe coding et agentic engineering ne sont pas deux noms pour la même chose : le premier raise the floor (démocratisation), le second préserve the quality bar (responsabilité professionnelle). Karpathy, leur inventeur commun, trace lui-même cette frontière.
• Kent Beck documente empiriquement que même une discipline TDD stricte ne prévient pas l'accumulation de complexité accidentelle dans le code généré — la supervision active reste indispensable.
• Addy Osmani mesure le coût : le vibe coding en production sans garde-fous génère une dette technique et des vulnérabilités de sécurité. Une équipe FAANG gagne 30% de vitesse par l'AI-assisted engineering discipliné, pas par l'abandon de l'ingénierie.
• La formule de Karpathy résume la ligne : "You can outsource your thinking but you can't outsource your understanding." Le vibe coding délègue la compréhension. L'agentic engineering ne le fait pas.
• Le vibe reviewing (Mogère, Carrefour France) est la suite logique : appliquer la rigueur agentique à la revue de code plutôt qu'à sa seule génération, avec des gains de temps documentés (÷3) mais une supervision humaine non négociable.
• La question "vibe ou agentique ?" n'est pas idéologique : prototype jetable → vibe coding acceptable ; production, sécurité, maintenabilité → agentic engineering obligatoire.
• Le harness engineering — harnais feedforward/feedback, progression context → harness — est le levier opérationnel pour passer de la posture vibe à la posture agentique sans sacrifier la vitesse.

Sources

1. Andrej Karpathy, Software Is Changing (Again) — youtube.com, 29 avril 2026.
2. Kent Beck, Augmented Coding: Beyond the Vibes — tidyfirst.substack.com, 25 juin 2025.
3. Addy Osmani — linkedin.com, 1er novembre 2025.
4. Kate Holterhoff (RedMonk), The Endless Hot Vibe Code Summer — redmonk.com, 8 septembre 2025.
5. Alexandre Mogère, Exit le vibe coding, place au vibe reviewing — linkedin.com, 7 juillet 2025.