TL;DR

• Le vibe coding, c'est coder "au feeling" avec l'IA : decrire ce qu'on veut, accepter le code genere sans forcement le comprendre.
• 25% du batch Winter 2025 de Y Combinator a des codebases generees a 95% par l'IA. C'est un fait, pas un fantasme.
• Ca marche pour les MVPs, le prototypage, les apps CRUD simples. Ca casse quand il faut de la securite, de l'architecture, ou du scale.
• L'etude METR montre que les devs experimentent sont 19% PLUS LENTS avec l'IA sur des taches complexes.
• Ma these : l'IA augmente les bons devs et rend les mauvais plus rapides a produire de la dette technique.

"Just vibe with it"

Le terme vient d'Andrej Karpathy, ancien directeur IA chez Tesla. En fevrier 2025, il tweet : "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."

L'idee : tu ne lis plus le code. Tu decris ce que tu veux, l'IA le genere, tu testes, ca marche ou pas, tu iteres. Le code est un artefact intermediaire, pas quelque chose que tu comprends ou maintiens. Tu "vibes" avec le resultat.

Six mois plus tard, le terme est partout. Des startups l'affichent fierement. Des bootcamps le vendent comme methode. Et Y Combinator, l'incubateur le plus selectif au monde, annonce que 25% de son batch Winter 2025 a des codebases generees a 95% par l'IA.

C'est une tendance reelle. La question, c'est : est-ce que c'est une bonne idee ?

Ce qui marche (vraiment)

Soyons justes : le vibe coding a des cas d'usage legitimement puissants.

Le MVP en 48 heures. Tu as une idee, tu veux la tester sur le marche. Tu decris ton app a un agent de code, il genere une landing page, un backend CRUD, une base de donnees. En deux jours, tu as un produit fonctionnel que tu peux mettre devant des utilisateurs. Avant l'IA, ca prenait deux semaines. Le gain est reel et massif.

Le prototypage rapide. Tu explores une architecture, tu veux tester une integration avec une API tierce, tu veux voir a quoi ressemble un flow utilisateur. Le vibe coding excelle pour generer du code jetable rapidement. Et le code jetable, par definition, n'a pas besoin d'etre maintenu.

Les non-devs qui construisent. Des product managers, des designers, des entrepreneurs sans background technique peuvent maintenant construire des outils internes, des dashboards, des automations. C'est la democratisation de la creation logicielle. Et ca, c'est genuinement positif.

Les taches mecaniques. Boilerplate, CRUD, formulaires, pages de listing, migrations de schema. Le genre de code ou il n'y a pas de decision architecturale, juste de la plomberie. L'IA fait ca tres bien et les devs n'aiment pas le faire.

Ce qui casse (silencieusement)

Mais le vibe coding a un probleme fondamental : il remplace la comprehension par la confiance. Et la confiance dans du code qu'on ne comprend pas, c'est exactement la definition d'une bombe a retardement.

La securite. L'IA genere du code qui marche, pas du code securise. Un formulaire de login genere par l'IA va fonctionner -- mais est-ce qu'il hash les mots de passe correctement ? Est-ce qu'il protege contre l'injection SQL ? Est-ce qu'il gere le rate limiting ? Si tu ne lis pas le code, tu ne sais pas. Et quand tu le decouvriras, ce sera probablement trop tard.

L'architecture. Le vibe coding produit du code qui resout le probleme immediat. Il ne produit pas du code qui resout le probleme de maniere maintenable. La separation des responsabilites, les patterns de communication entre modules, la gestion de l'etat -- tout ca demande une vision globale que l'IA n'a pas. Elle genere fichier par fichier, pas systeme par systeme.

Le debugging. Quand ca casse (et ca casse toujours), tu dois comprendre le code pour le reparer. Si tu as vibe-code 95% de ta codebase, tu as 95% de code que tu ne comprends pas. Bonne chance pour trouver pourquoi ta page de paiement duplique les transactions le vendredi soir.

Le scale. Un MVP qui gere 100 utilisateurs et une app qui en gere 100 000 ne sont pas la meme chose. Les problemes de performance, de concurrence, de gestion memoire -- tout ca emerge a l'echelle. Et l'IA qui a genere ton MVP n'avait aucune idee de ces contraintes.

L'etude qui fait reflechir

En 2025, METR (Model Evaluation and Threat Research) publie une etude rigoureuse. Ils mesurent la productivite de developpeurs experimentent (moyenne 15 ans d'experience) utilisant des outils IA de code (Cursor avec Claude) sur leurs propres projets open-source.

Le resultat : les devs sont 19% PLUS LENTS avec l'IA.

Oui, plus lents. Pas plus rapides.

Pourquoi ? Plusieurs facteurs :

• Le temps de review. Verifier que le code genere est correct prend du temps. Souvent plus que de l'ecrire soi-meme quand on connait bien le projet.
• Les allers-retours. L'IA genere du code qui ne compile pas, qui ne respecte pas les conventions du projet, qui utilise les mauvaises abstractions. Corriger et re-generer coute du temps.
• La distraction. Evaluer des suggestions de code interrompt le flow de reflexion. Au lieu de penser au probleme, tu evalues des propositions.
• La surconfiance. Les devs acceptent du code genere qu'ils n'auraient pas ecrit eux-memes, puis passent du temps a debugger des problemes qu'ils n'auraient pas crees.

Le point important : ces devs etaient experts sur leurs propres projets. Pour un nouveau projet, ou pour des taches mecaniques, les resultats seraient probablement differents. Mais ca demolit le narratif du "10x developer grace a l'IA" sur les taches complexes.

Le vrai probleme : le prompt engineering ne remplace pas l'engineering

Il y a une confusion fondamentale dans le discours ambiant. Savoir formuler un prompt, c'est une competence utile. Mais ca ne remplace pas la connaissance de l'ingenierie logicielle.

Un dev senior qui utilise l'IA sait :

• Quand le code genere est correct et quand il ne l'est pas.
• Quelles parties il peut deleguer et lesquelles il doit ecrire.
• Comment structurer les prompts pour obtenir du code dans les conventions du projet.
• Quand abandonner l'IA et coder a la main parce que c'est plus rapide.

Un vibe coder qui n'a pas ces fondamentaux ne sait pas ce qu'il ne sait pas. Et c'est ca le danger : pas l'IA elle-meme, mais l'illusion de competence qu'elle cree.

C'est comparable a la difference entre quelqu'un qui parle une langue et quelqu'un qui utilise Google Translate. Les deux produisent du texte comprehensible. Mais un seul des deux peut detecter quand la traduction est fausse.

La dette technique comme service

Voici ce qui m'inquiete pour l'ecosysteme : on est en train de creer une generation de codebases que personne ne comprend.

Les startups YC qui codent a 95% avec l'IA vont lever des fonds, recruter des equipes, et demander a ces equipes de maintenir du code genere. Ces equipes vont decouvrir :

• Pas de tests (l'IA ne les ecrit pas spontanement, et le vibe coder ne les demande pas).
• Pas de separation des responsabilites (tout est dans des fichiers monolithiques).
• Des patterns inconsistants (chaque session de generation a ses propres conventions).
• Des dependances obsoletes ou inutiles (l'IA utilise ce qu'elle connait, pas ce qui est optimal).
• Des failles de securite non detectees (pas de review, pas d'audit).

Le CTO qui herite de cette codebase va passer les 6 premiers mois a tout reecrire. J'espere que les investisseurs ont budgetise ca.

Ma position : ni utopie ni apocalypse

Apres un an d'utilisation quotidienne de l'IA pour coder, voici ma these :

L'IA augmente les bons devs et rend les mauvais plus rapides a produire de la dette technique.

Un dev qui comprend l'architecture, la securite, les patterns de concurrence et les trade-offs de performance utilise l'IA comme un multiplicateur. Il delegue les taches mecaniques et se concentre sur les decisions. Son code est meilleur et produit plus vite.

Un non-dev (ou un dev junior sans mentorat) qui vibe-code produit du logiciel qui marche a court terme et qui coute tres cher a moyen terme. C'est la meme dynamique que le no-code : puissant pour le prototypage, dangereux pour la production.

Le vibe coding n'est pas l'avenir du developpement. C'est un outil parmi d'autres. Comme l'autocomplete, comme Stack Overflow, comme les frameworks -- ca augmente la productivite des gens qui savent deja ce qu'ils font.

Et pour ceux qui ne savent pas ? Le vibe coding est le meilleur moyen de construire quelque chose qui marche aujourd'hui et qui coute une fortune demain. C'est un pari acceptable si tu es un MVP qui cherche du product-market fit. C'est un risque majeur si tu construis un produit que des gens vont utiliser en production.

Ce qu'il faut retenir

Le vibe coding existe, il est la, et il ne va pas disparaitre. La question n'est pas "pour ou contre" mais "quand et comment".

Utilise-le pour prototyper, pour explorer, pour generer du boilerplate. Mais ne confonds pas "ca marche sur mon ecran" avec "c'est pret pour la production". Et surtout, ne confonds pas "je sais decrire ce que je veux" avec "je sais construire du logiciel".

Les meilleurs devs que je connais utilisent l'IA massivement. Et ils relisent chaque ligne generee. Les deux ne sont pas contradictoires -- ils sont complementaires.

Ressources

• Andrej Karpathy - "Vibe Coding" -- le tweet original qui a lance le terme
• METR Study - AI Coding Assistants -- l'etude montrant le -19% de productivite chez les devs experts
• Y Combinator Blog -- statistiques sur l'IA dans le batch W25
• Cursor -- l'IDE IA le plus populaire actuellement
• Simon Willison - AI-assisted coding -- analyses equilibrees sur l'IA et le code par un expert respecte