Le mirage du vibe coding
Un an après la formule de Karpathy : six paramètres qui décident où le vibe coding tient et où il casse, et une grille pour les lire avant de commencer.
Andrej Karpathy a inventé le terme de vibe coding en 2025. Il le décrivait comme un nouveau type de codage « où l’on se laisse entièrement porter par le feeling, où l’on mise sur la croissance exponentielle, et où l’on oublie que le code existe », avant de terminer par « Ce n’est pas mauvais pour des projets jetables du week-end ».
Le problème, c’est que l’industrie n’a lu que la première partie, et que le vibe coding a pris de l’ampleur jusqu’à devenir une sous-culture entière du développement par IA.
Dans un contexte de hype IA, la promesse est séduisante au premier abord : développer n’importe quel outil en tapant quelques phrases, sans plus aucune limite à la créativité. Elle a séduit beaucoup de personnes qui jusque-là dépendaient d’un développeur.
Un an après, cette promesse a-t-elle porté ses fruits ?
Oui, sur le périmètre que Karpathy avait tracé. Non partout ailleurs.
Les paramètres en jeu
Pourquoi le vibe coding marche chez l’un et explose chez l’autre ? Parce que six paramètres entrent en jeu, et que c’est leur combinaison qui fait le résultat.
Les deux premiers viennent du modèle lui-même et sont les mêmes pour tout le monde. Les quatre autres dépendent du projet.
Le modèle ne fait jamais deux fois la même chose
Un LLM tire chaque mot au sort dans une liste de probabilités. Le même prompt envoyé deux fois donne deux réponses différentes, et une simple mise à jour du modèle suffit à changer la sortie.
Pour du code, ça veut dire que rien n’est reproductible. La correction obtenue lundi peut disparaître mardi, parce que le modèle a pris un autre chemin. Et la fonction juste dix-neuf fois de suite sera fausse la vingtième, sans prévenir.
Ce paramètre ne bouge pas. Ce que le projet peut encaisser, si : un script jetable absorbe une erreur sur vingt, un moteur de facturation non.
Le modèle a la mémoire courte
La fenêtre de contexte, c’est tout ce que le modèle sait du projet à un instant donné, et elle est finie. Trois choses en découlent.
Quand la conversation déborde, le début est tronqué : c’est le context overflow. Le modèle oublie les contraintes posées au départ, les fichiers qu’il a lus, les décisions prises. Il ne le dit pas, il continue avec ce qui lui reste.
Le context rot arrive bien avant le débordement. La qualité baisse à mesure que le contexte se remplit : une consigne donnée au message 3 est respectée au message 5, et la même consigne, toujours là, ne l’est plus au message 60.
Quand une erreur entre dans le contexte (une API inventée, un test lu comme réussi alors qu’il échoue), le modèle construit dessus, et chaque tour suivant la renforce parce qu’elle fait désormais partie des faits de la session. C’est le context poisoning.
Ces trois limites grandissent avec la taille du projet et la durée de la session. Un projet de week-end tient dans une fenêtre de contexte. Un projet de six mois n’y tiendra jamais.
La complexité métier
Combien de règles, d’exceptions, d’invariants le logiciel doit-il respecter ? Une landing page : zéro. Un outil de facturation avec TVA par pays, prorata, avoirs et relances : des centaines, dont la plupart ne sont écrites nulle part.
Le modèle est excellent sur le générique. Formulaires, CRUD, authentification, appels d’API : il en a vu des millions à l’entraînement. Mais il ne sait rien des règles du métier tant que personne ne les lui a dites. Et les lui dire précisément demande de les connaître précisément : ce travail-là s’appelle une spécification.
Or le vibe coding consiste justement à ne pas relire le code. Sur un domaine générique, ça passe : le modèle fait ce que tout le monde fait. Sur un domaine spécifique, personne n’a vérifié que la règle est là.
Greenfield ou brownfield
Un projet greenfield part de zéro, sans code existant ni conventions. Un projet brownfield s’insère dans une base de code qui a déjà ses habitudes, ses zones mortes et son savoir implicite.
En greenfield, le modèle choisit tout, et ses choix sont cohérents entre eux. Au début du moins. En brownfield, il doit respecter des conventions qu’il ne voit jamais en entier, et il produit du code qui marche mais ne s’intègre pas : un helper en double, un invariant cassé que personne ne lui avait signalé.
Et tout greenfield devient brownfield. Le projet vibe-codé de mars est le brownfield de juin, généré par un processus qui n’avait jamais prévu qu’on y reviendrait.
Les guardrails de départ
Les guardrails, c’est tout ce qui contraint le code sans passer par un humain : les types, le linter, les tests, la CI, la validation de schémas, les règles d’architecture, les hooks de pre-commit, et les fichiers d’instructions que l’agent lit avant de travailler.
C’est la seule chose déterministe dans toute la boucle. Sans eux, la seule vérification est la relecture humaine, exactement ce que le vibe coding supprime. Avec eux, le code passe ou ne passe pas, peu importe ce que le modèle pense avoir fait, et l’erreur remonte tout de suite, pas trois semaines plus tard.
Enfermé dans des contraintes déterministes, un modèle non déterministe produit du code contraint ; sans contraintes, il produit ce qui passe.
Qui touche au code
Qui est capable de lire le code généré ? Combien de personnes y touchent ? Y a-t-il une relecture avant la mise en production ? La réponse dépend de l’équipe.
Le non-technique seul, c’est la cible de la promesse initiale : personne ne lit le code, il n’existe que par ses effets. Le fondateur technique sait lire, mais n’a pas le temps, et la relecture saute dès que le rythme monte. Un ou deux développeurs multitâches lisent le code entre le produit, le support et l’infra, sans revue croisée. L’équipe de PME relit, sous pression produit. Les équipes spécialisées front/back ont l’ownership, la revue systématique et les conventions écrites.
D’un profil à l’autre, le code passe d’artefact privé à support de communication. Une personne seule peut ne jamais relire son code, dix personnes ne le peuvent pas.
Ces six paramètres se combinent. Le même non-déterminisme est indolore sur un prototype greenfield sans règle métier et fatal sur un brownfield de facturation sans tests. La grille de lecture qui suit rend cette combinatoire lisible.
Lire le projet avant de le vibe-coder
Les deux paramètres du modèle ne se négocient pas. Reste à lire ce que le projet leur oppose : ce qu’une erreur va coûter, combien de temps le code va vivre, ce qu’il doit savoir du métier, sur quoi il s’appuie, qui le vérifie et qui le lit.
| Le vibe coding tient | Le vibe coding casse | |
|---|---|---|
| Ce qu’une erreur coûte | Elle se voit à l’écran et se relance | Elle part en production, touche des données ou de l’argent |
| Durée de vie | Un week-end, jeté après la démo | Des mois, des sessions qui reprennent le code de la veille |
| Complexité métier | Générique : formulaires, CRUD, authentification, appels d’API | Des règles, des exceptions et des invariants écrits nulle part |
| Terrain | Greenfield | Brownfield, le greenfield d’il y a trois mois compris |
| Guardrails | Types, tests, linter, CI et règles d’architecture posés au départ | Aucun : la seule vérification serait la relecture, et elle a sauté |
| Qui touche au code | Une personne, un code privé que personne d’autre ne lira | Plusieurs personnes, une mise en production, un code lu par d’autres |
Les deux premières lignes sont les paramètres du modèle vus depuis le projet : le non-déterminisme coûte ce que coûte une erreur, et la mémoire courte coûte d’autant plus que le projet dure.
La grille ne s’additionne pas. La complexité métier et les guardrails pèsent plus que le reste, parce qu’ils décident si une erreur sera vue avant la production ; une case à droite sur l’une de ces deux lignes, et les quatre autres ne mesurent plus que la vitesse de la chute.
La colonne de gauche n’est pas stable non plus. La durée de vie glisse à droite dès que le prototype survit à sa démo, le terrain la suit quelques mois plus tard, l’équipe le jour où une deuxième personne ouvre le dépôt. Les guardrails, eux, ne glissent pas : ils se posent au départ ou après une relecture complète du code produit, et cette relecture est exactement ce que le vibe coding avait supprimé.
Deux lectures. Le non-technique qui monte le site d’un événement pour le mois prochain : six cases à gauche, le périmètre de Karpathy, et le vibe coding y est le bon outil. Le même non-technique qui remplace le tableur de facturation de sa boîte : l’erreur coûte, le projet doit durer, le métier est plein de règles que lui seul connaît, personne ne relit. Quatre cases à droite avant même d’ouvrir l’éditeur, et un logiciel qui n’existe que par ses effets, jusqu’au premier effet faux.
Entre les deux, le fondateur technique qui a lancé son produit en mars. En mars, tout à gauche. En juin, le produit a des clients, donc une durée de vie et un coût d’erreur ; trois mois de code derrière lui, donc un terrain ; une première recrue, donc une deuxième personne dans le dépôt. Quatre cases ont glissé sans qu’une seule décision soit prise. Reste la ligne des guardrails, la seule sur laquelle il avait la main en mars.
Repousser l’échéance
Le vibe coding n’est pas mauvais en soi. Pour une maquette qui doit convaincre vendredi ou un script jeté après usage, rien ne va plus vite, et Karpathy n’avait pas dit autre chose.
Sur la durée, le vibe coding pur va toujours au même endroit, à une vitesse que la grille donne à peu près. Le non-déterminisme fournit les erreurs, la mémoire courte les laisse passer, l’absence de relecture les laisse s’installer, et le greenfield devient un brownfield que plus personne ne sait modifier sans casser autre chose.
Cette date se repousse. Pas en relisant le code, ce serait arrêter de vibe-coder, mais en décidant avant la première session ce que le modèle n’aura pas le droit de faire : une architecture posée d’avance, avec des frontières écrites dans le fichier d’instructions que l’agent lit ; des types stricts ; des tests qui tournent à chaque changement ; une CI qui refuse ce qui ne passe pas ; un schéma validé à chaque entrée. Un non-technique ne les écrira pas lui-même, mais il peut les exiger dès le premier prompt, et sur ce terrain-là le modèle se trompe rarement : une configuration de linter, une CI ou un schéma de validation, c’est le code le plus générique qui existe.
La nature du vibe coding reste la même ; sa date de péremption recule. Un projet contraint dès le départ casse plus tard, et casse à un endroit où la CI le dit tout de suite plutôt qu’un client trois semaines après. Le jour où il faudra quand même relire le code, il y aura une architecture à relire. Le mirage, c’est de croire que ce jour n’arrivera pas.