La ligne qui s'efface : ce que Willison admet vraiment sur l'agentic engineering

L’homme qui a créé la distinction, puis admis la violer

Simon Willison est l’un des ingénieurs les plus respectés de l’écosystème IA. Créateur de Django, auteur d’un des blogs techniques les plus lus du secteur, observateur rigoureux de tout ce qui touche aux LLM. En 2025, il popularise une distinction qui fait rapidement le tour de la communauté : vibe coding d’un côté, agentic engineering de l’autre.

La frontière semblait nette. Évidente, même.

Puis début mai 2026, il publie un billet dont le titre dit tout : “Vibe coding and agentic engineering are getting closer than I’d like”. Et dans ce texte, il écrit quelque chose d’inconfortable :

“Je n’examine pas ce code. Et maintenant j’ai cette culpabilité.”

Ce n’est pas un aveu anodin. C’est l’un des défenseurs les plus articulés de la supervision humaine qui admet, en public, qu’il ne supervise plus. Ça mérite qu’on s’y arrête.

La distinction originelle, rappel rapide

Pour comprendre ce qui se joue, il faut poser les deux concepts côte à côte.

Vibe coding : vous promptez, vous acceptez, vous lancez, vous voyez si ça marche. Pas de lecture de code, pas de revue, pas de compréhension profonde de ce qui a été généré. Acceptable pour un outil personnel, un script que vous seul utiliserez. Willison lui-même : “si c’est un bug, seul vous en souffrez, allez-y !”

Agentic engineering : des ingénieurs professionnels qui utilisent les agents de code pour amplifier leur expertise existante. Ils produisent plus vite, mais ils maintiennent les standards. Ils révisent chaque diff. Ils testent. Ils sont responsables de ce qui part en production.

La séparation repose sur un principe simple : qui porte la responsabilité du code ? L’ingénieur, pas l’agent.

Addy Osmani, ex-Chrome et Google, le formule en une ligne : “Vibe coding = YOLO. Agentic engineering = AI does the implementation, human owns the architecture.”

La normalization of deviance, ou comment le Challenger arrive

Ce qui inquiète Willison n’est pas que des non-programmeurs génèrent du code sans le comprendre. Ça, c’est attendu. Ce qui l’inquiète, c’est ce qui lui arrive à lui : la confiance qui monte au point de faire disparaître la vigilance.

Il nomme le phénomène : normalization of deviance. Le terme vient de la sociologie des organisations. Il décrit le processus par lequel des comportements risqués deviennent progressivement normaux parce qu’aucun accident ne s’est produit. La NASA l’a vécu avec les joints du Challenger. Chaque lancement réussi malgré des joints défectueux augmentait la tolérance au risque.

Avec les agents de code : chaque dépôt généré en 30 minutes qui tourne en production sans incident renforce la confiance. Jusqu’à ce qu’elle soit mal placée.

Willison l’observe sur lui-même. Claude Code crée des endpoints JSON complets avec tests et documentation, sans supervision directe. Les projets générés sont visuellement indistinguables de projets construits à la main. Et progressivement, la revue systématique disparaît.

Ce glissement est d’autant plus sournois qu’il touche les ingénieurs les plus expérimentés. Pas les débutants qui ne savent pas qu’ils devraient relire. Les seniors qui savent qu’ils devraient relire, mais qui ne le font plus parce que ça “marchait jusqu’ici”.

”But I’m not reviewing that code. And now I’ve got that feeling of guilt.”

« Mais je n’examine pas ce code. Et maintenant, j’ai cette sensation de culpabilité. »

Amazon : quand le vrai ticket arrive

Pendant que le débat se joue sur les blogs, Amazon a reçu la facture.

Mars 2026. L’assistant IA interne d’Amazon, Q, contribue à une série d’incidents sur l’infrastructure retail. Le 2 mars, 1,6 million d’erreurs et 120 000 commandes perdues. Le 5 mars, une chute de 99 % des commandes sur les marketplaces nord-américaines. 6,3 millions de commandes perdues en quelques heures.

La réponse : un reset de 90 jours sur 335 systèmes Tier-1. Doubles approbations obligatoires. Signature senior requise pour tout changement assisté par IA. Des contrôles de déploiement redessinés depuis zéro.

Le SVP e-commerce d’Amazon, Dave Treadwell, identifie le problème dans les documents internes : “désalignement entre la vitesse de production du code généré par IA et les standards de fiabilité de l’entreprise.”

Traduit : les agents produisaient du code plus vite que les humains ne pouvaient valider. Et les humains avaient arrêté d’essayer de suivre.

Ce n’est pas une anecdote. C’est une entreprise avec des milliers d’ingénieurs seniors, des process de revue matures, des pipelines CI/CD éprouvées, et une culture d’ingénierie reconnue. Si la normalization of deviance peut arriver là, elle peut arriver partout.

Osmani, plus tranchant sur les juniors

Addy Osmani tire une conclusion que Willison effleure mais ne formule pas aussi directement : les développeurs juniors sont en danger structurel.

Son argument : quand vous produisez du code sans le comprendre, vous n’apprenez pas. Vous construisez sur du vide. Et quand quelque chose casse, vous n’avez pas les outils pour déboguer, parce que vous n’avez jamais développé les réflexes nécessaires.

Ce n’est pas de la nostalgie du code écrit à la main. C’est un constat sur la transmission des compétences. Un junior qui a passé deux ans à “accepter les diffs” sans les comprendre n’a pas deux ans d’expérience. Il a deux ans d’exposition à du code qu’il n’a jamais internalisé.

Sur Hacker News, le thread “Agentic Coding Is a Trap” documente le phénomène avec une précision inconfortable. Un développeur senior témoigne : “Cognitive debt is very real, and it hurts worse than technical debt on a personal level.” Il décrit avoir été incapable, lors d’une réunion, de répondre à des questions sur son propre code, généré par IA quelques semaines plus tôt.

La dette cognitive. Vous avez mergé le code, vous avez le ticket fermé, mais vous ne portez pas la compréhension.

La ligne, telle que je la tiens

Je suis exactement ce que Willison appelle un agentic engineer. Claude Code est mon outil principal depuis 2025. Je l’utilise tous les jours pour construire et maintenir Claude Hub. Je ship en production du code que je n’ai pas écrit ligne par ligne.

Est-ce que je relis chaque diff ? Non, pas systématiquement. Est-ce que je suis dans la même situation que Willison ? Honnêtement, oui, sur certains points.

Mais voici où je situe ma ligne, concrètement :

Je possède l’architecture. Pas le code, l’architecture. Je sais pourquoi chaque couche existe, quels sont les compromis acceptés, où sont les fragilités. Quand un agent génère une feature, je sais où elle s’insère et ce qu’elle ne doit pas toucher.

Je suis l’utilisateur. Willison le dit dans ses patterns : ce qui compte vraiment, ce n’est pas d’avoir relu le code, c’est d’avoir utilisé le produit pendant plusieurs semaines. Je teste chaque feature avant de la merger. Pas pour déboguer le code, pour valider le comportement.

Je maintiens les tests comme contrainte non négociable. Les agents de code écrivent du code qui passe les tests fournis. Si les tests sont solides, le diff devient délégable. C’est la raison pour laquelle le TDD, dans un contexte agentic, devient plus important qu’avant, pas moins.

La ligne n’est pas “j’ai relu chaque ligne”. Elle est “je suis responsable de ce qui se passe en production et je peux l’expliquer.”

Ce que ça change pour vous

Si vous êtes développeur senior : la normalization of deviance vous cible autant que n’importe qui. La confiance accumulée est une ressource qui peut se retourner. Maintenir une discipline de revue non pas sur tout, mais sur ce qui compte, sur les paths critiques, sur les surfaces d’attaque, sur les intégrations externes.

Si vous êtes développeur junior : la vitesse de l’agent ne vous donne pas l’expérience. Elle vous donne du code livré. Ce n’est pas la même chose. Forcez-vous à comprendre ce que vous mergez. Pas tout, mais les patterns. Un mois à lire les diffs attentivement vous apprend plus que six mois à les accepter les yeux fermés.

Si vous construisez des processus d’équipe : Amazon vient de vous montrer que les contrôles de déploiement ne sont pas optionnels quand les agents entrent dans la boucle. La vitesse de production de code a explosé. Vos process de validation n’ont pas suivi. C’est le désalignement que Treadwell décrit.

La vraie honnêteté de Willison

Ce que j’apprécie dans le billet de Willison, c’est qu’il ne se cache pas derrière une position confortable. Il aurait pu écrire “voici pourquoi j’ai raison depuis le début”. Il a choisi d’écrire “voici l’inconfort que je ressens”.

Cette honnêteté est utile parce qu’elle dit quelque chose que les discours sur la supervision humaine ne disent pas toujours : maintenir la rigueur quand les agents sont de plus en plus fiables est un effort actif, pas une posture passive. Ce n’est pas parce que vous savez que vous devriez relire que vous le faites. La pression de la vitesse, l’accumulation des succès, la confiance qui monte : tout pousse dans la même direction.

La frontière entre vibe coding et agentic engineering n’est pas dans la définition. Elle est dans la discipline quotidienne. Et cette discipline se maintient ou elle se perd.

Willison le sait. Il l’a écrit. C’est pour ça que ça vaut la peine d’être lu.

---

Pour aller plus loin

• La Checklist Avant de Ship avec l’IA
• Harrison Chase a raison : les coding agents redéfinissent le développement
• Le Paradoxe du Claude Coder
• Tester son code IA : TDD et tests unitaires

---

Sources : Simon Willison - Vibe coding and agentic engineering are getting closer · Addy Osmani - Agentic Engineering · Simon Willison - Agentic Engineering Patterns · Amazon 90-day reset - DEV Community · Agentic Coding Is a Trap - HN