Le vibe coding, j'ai testé (voilà ce qui est vrai)
Ce que c'est vraiment, ce que ça change dans le métier, et ce que ça ne remplace pas.
on dis que le terme vibe coding vient d'Andrej Karpathy, début 2025. L'idée de coder en faisant confiance à l'IA pour générer le code, tester, corriger par la description plutôt que par la compréhension ligne à ligne. "Viber" avec le modèle plutôt que de vraiment programmer.
Depuis, la moitié d'internet trouve ça révolutionnaire. L'autre moitié trouve ça dangereux et superficiel. Comme souvent, la réalité est entre les deux.
Ce que c'est en pratique
Une session réelle.
J'ai besoin d'un composant React pour afficher une liste d'articles avec un filtre par tag. Je sais ce que je veux. Je le décris à Claude : filtrage côté client, AnimatePresence pour les transitions, le tag actif mis en évidence avec un layout animé. Je demande aussi l'interface TypeScript.
Claude génère 80 lignes. Je lis. Je vérifie les types, la logique de filtrage, les cas limites. Il y a un problème dans la gestion de l'état actif — cliquer deux fois sur le même tag devrait le désactiver. Je décris le problème en langage naturel. Claude corrige. Je teste. Ça marche.
Temps total : 12 minutes pour quelque chose qui m'aurait pris 25-30 minutes en écrivant tout.
C'est ça le vibe coding. Pas "l'IA fait tout". "L'IA fait le scaffolding et je valide, corrige, oriente".
Ce que ça change vraiment
La friction de démarrage disparaît. C'est le changement le plus concret.
Commencer une fonctionnalité nouvelle a un coût cognitif réel. Trouver la bonne structure, choisir les patterns, gérer les imports. Cette friction existe même pour les développeurs expérimentés, et elle peut faire la différence entre "je le fais maintenant" et "je le remets à demain".
Avec le vibe coding, on commence avec quelque chose qui marche à moitié et on raffine. Psychologiquement c'est différent.
Le travail se déplace aussi. Moins de temps sur le boilerplate, plus de temps sur l'architecture, les cas limites, la maintenabilité. C'est un shift positif — si on garde la discipline de comprendre ce qu'on valide.
Ce que ça ne remplace pas
La compréhension de ce qui tourne. Si tu peux pas lire et comprendre le code généré, tu peux pas le maintenir, le déboguer quand ça casse en prod, ou l'adapter quand les specs changent. Vibe coding sans compréhension, c'est construire sur du sable.
La sécurité. Les LLMs génèrent du code qui marche — pas toujours du code sûr. SQL injection, validation insuffisante des inputs, secrets dans le code — ces erreurs apparaissent dans le code généré. Si tu les vois pas parce que tu fais confiance au modèle, tu as un problème.
Le debugging profond. Quand quelque chose de subtil ne marche pas — une race condition, une interaction entre deux systèmes complexes — l'IA peut suggérer des pistes, mais la compréhension fine reste humaine. J'ai passé deux heures sur un bug que Claude ne pouvait pas voir parce qu'il nécessitait de comprendre le comportement d'un hook React dans un contexte de rendu concurrent.
Ma position honnête
Je code plus vite. C'est factuel.
Mais vibe coding à la Karpathy — faire confiance au modèle sans vraiment lire le code — c'est pas une bonne pratique générale. Valide pour un prototype jetable, un script qu'on utilise une fois. Pas pour du code qui ira en production et que quelqu'un devra maintenir dans six mois.
La vraie compétence qui devient précieuse c'est savoir poser les bonnes questions à l'IA. Décrire précisément le problème, les contraintes, les cas limites. Et cette compétence-là se construit sur une compréhension solide du domaine.
L'IA n'efface pas le besoin de savoir programmer. Elle change ce que ça veut dire savoir programmer.