NOXENGINE

Les machines travaillent la nuit.
On les surveille.

[ DÉCRYPTAGES ]

Le vibe coding s’arrête là où tu relis le code

Le terme a un auteur, une date et un texte fondateur. Ce texte dit l'inverse de ce qu'on lui fait dire, et son auteur l'a redit un an après.

RUN #406 20 AOÛT 2026 11 MIN DE LECTURE

Le vibe coding est présenté à peu près partout comme la nouvelle façon de développer. IBM lui consacre une page pédagogique, Cloudflare aussi, et les écoles françaises en vendent déjà des formations. Le terme a pourtant un auteur, une date de naissance et un texte fondateur de quelques lignes. J’ai lu ce texte en entier, ce que presque personne ne fait, parce que la citation qui circule s’arrête à sa première phrase. La suite dit à peu près l’inverse de ce qu’on lui fait dire.

Ce que Karpathy a écrit le 2 février 2025, en entier

Andrej Karpathy, ancien directeur de l’IA chez Tesla et cofondateur d’OpenAI, publie le 2 février 2025 un message sur X. Le voici, dans les passages qui comptent.

There’s a new kind of coding I call « vibe coding », where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like « decrease the padding on the sidebar by half » because I’m too lazy to find it. I « Accept All » always, I don’t read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I’d have to really read through it for a while. Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away. It’s not too bad for throwaway weekend projects, but still quite amusing. I’m building a project or webapp, but it’s not really coding, I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

Traduction des quatre passages décisifs : je clique toujours sur « tout accepter », je ne lis plus les différences ; le code dépasse ma compréhension habituelle ; quand le modèle n’arrive pas à corriger un bug, je demande des changements au hasard jusqu’à ce qu’il disparaisse ; ce n’est pas mal pour des projets jetables de week-end.

Relis la dernière. Elle est dans le texte d’origine, pas dans un repentir ultérieur.

Le test qui tranche : « I don’t read the diffs anymore »

Il y a dans ce paragraphe une phrase qui sert de définition opérationnelle, et c’est celle-là. Pas « donner dans les vibes », qui ne veut rien dire de vérifiable, mais le fait de valider sans lire. Karpathy décrit un mode de travail où la relecture du code produit est explicitement abandonnée, où le bug se contourne au lieu de se comprendre, et où le programme finit par échapper à son auteur.

Ça donne un test simple, et je ne l’ai vu formulé nulle part ailleurs. Si tu relis les différences avant de valider, tu ne fais pas de vibe coding. Tu développes avec un assistant, ce qui est une autre pratique, plus ancienne et plus banale.

Le test a un mérite : il est binaire. On sait toujours si on a lu ou non.

« Throwaway weekend projects » : le périmètre était écrit dès la première heure

C’est le point que les pages pédagogiques du secteur passent sous silence, et c’est celui qui change tout. L’auteur du terme borne lui-même son usage à des projets jetables, et il ajoute que ce n’est pas vraiment du code. Sa conclusion n’est pas « ça marche », elle est « ça marche à peu près ».

Ce que le texte source établit : un développeur chevronné s’amuse à construire des petites applications sans relire ce que la machine produit, et il trouve le résultat suffisant pour cet usage. Ce qu’il n’établit pas, et ne prétend nulle part établir : que la méthode convienne à un logiciel qu’on met entre les mains d’utilisateurs. On confond souvent les deux.

Sur ce point précis, il faut lui reconnaître une chose : il n’a rien survendu. La restriction est dans le message d’origine, en clair, à deux phrases de la fin.

Schéma comparant le texte d'origine de Karpathy du 2 février 2025 avec la définition du vibe coding qui circule aujourd'hui
Le message d’origine du 2 février 2025, mis face à la définition qui circule. Relevé du 20 août 2026.

Non, coder avec l’IA n’est pas du vibe coding

L’usage courant a fait du terme un synonyme de « développement assisté par IA ». C’est cet élargissement qui pose problème, parce qu’il vide la définition de la seule chose qui la rendait utile. Un développeur qui fait écrire une fonction à un modèle, la relit, la teste et la corrige ne fait pas ce que Karpathy décrit. Il fait ce que faisaient déjà les gens avec un assistant, en plus rapide.

La différence n’est pas de degré, elle est de responsabilité. Dans un cas quelqu’un a lu le code avant qu’il parte en production. Dans l’autre, personne.

Et c’est exactement pour ça que la confusion coûte cher. Quand une école vend une formation au vibe coding à des professionnels, elle vend soit un mot mal employé, soit une pratique que son inventeur réservait à ses samedis après-midi. Les deux méritent d’être signalés.

Un an après, l’auteur ne se corrige pas, il se répète

Le 4 février 2026, deux jours après le premier anniversaire du message, Karpathy publie une rétrospective. Beaucoup y ont vu un rétropédalage. Ce n’en est pas un, et la nuance a son importance.

Il commence par relativiser son propre geste : le message de 2025 était, dit-il, « a shower of thoughts throwaway tweet that I just fired off without thinking », un jet de pensées sous la douche envoyé sans réfléchir. Il note au passage, amusé, que le vibe coding figure désormais sur sa page Wikipédia comme contribution majeure, et que l’article du terme est plus long que le sien.

Puis il redit ce qu’il avait déjà écrit. À l’époque, précise-t-il, les modèles étaient assez limités pour qu’on réserve la méthode à des « fun throwaway projects, demos and explorations », et il ajoute : « it almost worked ». Un an plus tard, la programmation par agents devient un flux de travail par défaut chez les professionnels, mais, écrit-il, « except with more oversight and scrutiny ».

Avec davantage de contrôle et d’examen. C’est-à-dire l’exact opposé de « forget that the code even exists ».

Il n’y a donc pas eu de revirement. Il y a eu un contresens collectif, et une mise au point que personne n’a plus lue que le message d’origine.

Le mot qu’il emploie aujourd’hui : agentic engineering

Dans cette même rétrospective, Karpathy propose un autre terme pour la pratique professionnelle, et il prend la peine d’en justifier les deux moitiés. « Agentic », parce que tu n’écris plus le code directement dans quatre-vingt-dix-neuf pour cent des cas : tu orchestres des agents qui le font, et tu exerces une surveillance. « Engineering », pour insister sur le fait qu’il y a là un art et une science, quelque chose qui s’apprend et où l’on progresse.

Il y revient trois mois plus tard, le 30 avril 2026, dans le résumé qu’il publie sur son blog après un échange chez Sequoia. La formule y est plus ramassée : « Vibe coding raises the floor. Agentic engineering is about extrapolating the ceiling. » Le vibe coding relève le plancher, l’ingénierie agentique repousse le plafond. Et il définit la seconde comme la préservation du niveau de qualité du logiciel professionnel.

Note l’ordre des dates, il compte : le terme de remplacement apparaît en février, pas en avril. La scène chez Sequoia n’a rien inventé, elle a formalisé. Je le précise parce que plusieurs reprises situent l’épisode en mai 2026, ce qui est faux : le message qui annonce l’échange est daté du 30 avril, et il indique que la rencontre avait eu lieu une semaine plus tôt.

Petite précision de méthode, parce qu’elle explique comment je date ces messages. X n’affiche pas toujours l’horodatage complet, mais l’identifiant d’un message l’encode : ses bits de poids fort portent le nombre de millisecondes écoulées depuis une date de référence fixe. Un calcul de trois lignes rend l’heure exacte. J’ai vérifié la méthode en la comparant à une source indépendante, le billet publié le même jour sur le blog de l’auteur. Les deux tombent sur le 30 avril 2026.

Ce que Wikipédia n’a toujours pas écrit

J’ai regardé, le 20 août 2026, ce que disent les deux pages Wikipédia consacrées au terme, celles que Google place en deuxième et en treizième position sur la requête française. Pas la page telle qu’elle s’affiche, mais son code source, récupéré par l’interface de programmation du site : c’est le seul moyen d’affirmer qu’un mot est absent plutôt que simplement pas vu.

Aucune des deux n’emploie l’expression « agentic engineering ». Aucune des deux ne mentionne la rétrospective de février 2026. Sur ce point, la référence encyclopédique a six mois de retard sur son propre sujet, dans les deux langues.

Ensuite les deux divergent, et c’est là que le lecteur francophone est le plus mal servi. La page anglophone reproduit le message d’origine en entier : on y trouve « throwaway weekend projects » et « I don’t read the diffs anymore », donc les bornes que l’auteur avait posées. La page française, elle, ne contient ni l’un ni l’autre. Elle ouvre sur une définition de son cru, « une technique de programmation utilisant l’intelligence artificielle générative pour écrire du code informatique », qui est exactement la version large que Karpathy n’a jamais donnée.

Autrement dit : lis l’article en anglais, tu as au moins les restrictions sous les yeux. Lis-le en français, tu ne les as pas.

Et cette page française n’est pas un vieux brouillon oublié. Sa dernière modification date du 18 août 2026 à 16h59, deux jours avant mon relevé. Elle est à jour au sens des contributeurs, et muette sur l’essentiel.

Je ne fais pas le procès des bénévoles de Wikipédia, qui écrivent ce que les sources secondaires publient. Je constate seulement que la référence encyclopédique francophone, mise à jour hier, est en retard d’une année entière sur son sujet. Et que les pages d’IBM, de Cloudflare, de Red Hat et de Salesforce, qui occupent le reste de la première page, ne le disent pas davantage.

Ce que ça change quand tu ouvres ton éditeur

Rien, si tu construis un prototype pour toi le samedi. C’est l’usage pour lequel le terme a été inventé, il n’y a aucune raison de s’en priver, et son auteur trouvait déjà le résultat honorable.

Tout, si le code part en production. Non pas parce qu’une IA écrirait du mauvais code, question sur laquelle je n’ai pas de chiffre à opposer ici, mais parce que la méthode que Karpathy décrit consiste explicitement à ne pas relire. Ce n’est pas un effet secondaire, c’est la définition. Le jour où tu réintroduis la relecture, tu es sorti du vibe coding et tu fais autre chose, que l’auteur appelle désormais l’ingénierie agentique.

Deux mots pour deux pratiques, dont une seule a jamais prétendu tenir un niveau de qualité professionnel. La confusion entre les deux ne vient pas de lui.

Reste une question que je laisse ouverte, faute de données publiques permettant de trancher : personne n’a mesuré, à ma connaissance, ce que produisent réellement des équipes qui valident sans relire, sur une base de code durable et à échelle réelle. Tant que ce travail n’existe pas, les deux camps s’affrontent à coups d’anecdotes. J’attends de voir une étude indépendante.

Voir aussi : ce que donne le vibe coding grand public sur un vrai brief d’artisan, chronomètre et compteur de tokens en main, testé sur Bolt.new

Les sources de cet article

Toutes les citations de cette page proviennent des publications de leur auteur, jamais d’une reprise de presse. Les traductions sont les miennes et l’original figure entre guillemets.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *