Le "vibe coding" est-il déjà en train de dégoûter les développeurs ?
Le vibe coding promet de créer une application en décrivant ce que l’on veut à une intelligence artificielle. Pourtant, dans certaines communautés techniques, le discours enthousiaste laisse place à une forme de lassitude. Des développeurs disent ne plus avoir l’impression de programmer, mais de relire, auditer et corriger du code généré par des LLM. Le rejet ne porte donc plus seulement sur la qualité du code produit. Il concerne la manière dont ces outils transforment le métier.
Pourquoi le vibe coding divise-t-il autant les développeurs ?
Le terme vibe coding désignait au départ une manière légère et expérimentale de programmer avec une IA. L’utilisateur décrit une fonctionnalité, laisse le modèle produire le code, teste le résultat puis demande des corrections jusqu’à obtenir quelque chose qui fonctionne.
Cette méthode est efficace pour créer un prototype, automatiser une tâche ponctuelle ou découvrir une technologie inconnue. Elle devient plus controversée lorsqu’elle est utilisée sur des projets complexes, maintenus par plusieurs personnes ou destinés à rester en production.
Le débat ne porte plus uniquement sur la capacité des IA à écrire du code. Il porte sur la responsabilité de celui qui devra comprendre, corriger et maintenir ce code plusieurs mois plus tard.
Pourquoi certains développeurs ont-ils l’impression de devenir des auditeurs de LLM ?
Une frustration revient régulièrement dans les discussions techniques : le développeur ne produit plus directement la solution. Il formule une demande, attend la proposition du modèle, vérifie le résultat puis cherche les erreurs introduites.
Le travail suit alors une nouvelle boucle :
1. décrire la fonctionnalité attendue ;
2. laisser le LLM générer une solution ;
3. relire le code produit ;
4. détecter les erreurs et les effets de bord ;
5. demander une correction ou reprendre le code manuellement.
Cette manière de travailler peut faire gagner du temps. Elle peut aussi remplacer une tâche de conception par une longue phase de contrôle. Certains développeurs ont alors le sentiment de devenir des auditeurs de code généré, plutôt que des personnes qui construisent directement un système.
Que révèlent les discussions communautaires autour du vibe coding ?
Sur le board technologique /g/ de 4chan, plusieurs fils récents montrent une forte polarisation autour du sujet. Leur ton est souvent agressif, caricatural et volontairement provocateur. Ils ne représentent pas l’ensemble des développeurs, mais ils permettent d’observer des frustrations difficiles à repérer dans les communications plus lisses de LinkedIn ou des entreprises spécialisées dans l’IA.
Un développeur explique devoir « baby-sitter un développeur junior et son AI slop ». Un autre résume son malaise ainsi : si la programmation moderne consiste uniquement à prompter puis auditer un LLM, il n’est plus certain de vouloir exercer ce métier.
Ces réactions ne prouvent pas que le vibe coding est rejeté par la profession. Elles montrent toutefois qu’une partie des développeurs associe désormais l’IA à une perte de contrôle, de plaisir et de sens.
Qu’est-ce que le code slop ?
Le mot slop est de plus en plus utilisé pour désigner du contenu généré en masse, fonctionnel en apparence, mais pauvre, répétitif ou difficile à exploiter. On parle d’AI slop pour les images, les textes et désormais le code.
Dans le développement, le code slop ne désigne pas nécessairement un programme qui ne fonctionne pas. Il peut s’agir d’un code qui produit le bon résultat, mais dont la structure est inutilement complexe, incohérente avec le reste du projet ou fragile face aux changements futurs.
Le problème apparaît surtout lorsque personne ne comprend réellement la solution générée. Une application peut alors accumuler des dépendances inutiles, des fonctions dupliquées, des corrections locales et des choix techniques contradictoires. Chaque nouvelle demande ajoute une couche à un système que l’équipe maîtrise de moins en moins.
Pourquoi les développeurs seniors craignent-ils de devoir corriger le code des juniors ?
L’IA permet à un développeur débutant de produire rapidement une quantité importante de code. Cette vitesse ne garantit pas qu’il puisse expliquer les choix effectués, identifier les risques ou corriger le système sans l’aide du modèle.
Le rôle du développeur senior change alors. Au lieu de transmettre une méthode de réflexion, il doit parfois vérifier une solution générée dont le junior ne connaît ni l’architecture ni les limites. Le mentorat se transforme en contrôle qualité.
Cette situation peut créer une tension dans les équipes. Le junior estime avoir terminé rapidement une fonctionnalité. Le senior découvre ensuite le coût caché : tests insuffisants, erreurs silencieuses, problèmes de sécurité, architecture difficile à maintenir ou code incompatible avec les conventions du projet.
Le code généré par l’IA est-il forcément mauvais ?
Non. Les outils comme Codex, Claude Code ou Antigravity peuvent produire du code propre, corriger des bugs, écrire des tests et accélérer des tâches répétitives. Leur utilité dépend toutefois du contexte et de la capacité de l’utilisateur à évaluer le résultat.
Un développeur expérimenté peut utiliser un LLM pour automatiser une migration, comprendre une bibliothèque inconnue ou produire une première version d’une fonctionnalité. Il dispose ensuite des compétences nécessaires pour vérifier la cohérence de la solution.
Le risque apparaît lorsque la génération remplace entièrement la compréhension. Le code fonctionne alors comme une boîte noire. Tant que le résultat reste conforme à la demande, le problème est invisible. Il apparaît au premier bug complexe, au premier changement d’architecture ou au départ de la personne qui pilotait le modèle.
Le vibe coding fait-il gagner du temps ?
Le vibe coding réduit souvent le temps nécessaire pour obtenir une première version fonctionnelle. Il ne réduit pas toujours le temps total consacré au projet.
Le gain dépend de plusieurs facteurs : la taille du code, la qualité du contexte fourni au modèle, la présence de tests, la stabilité des exigences et le niveau technique de la personne qui supervise la génération.
Une fonctionnalité créée en quelques minutes peut nécessiter plusieurs heures de correction lorsqu’elle doit s’intégrer à un système existant. À l’inverse, une tâche précise et bien délimitée peut être automatisée sans générer de dette technique importante.
Le temps économisé pendant l’écriture peut donc réapparaître pendant la relecture, le débogage ou la maintenance.
Mon expérience avec Codex et le coût caché de l’automatisation
J’utilise régulièrement Codex sur mes propres projets. L’outil peut produire rapidement des modifications importantes et prendre en charge des tâches qui auraient demandé plusieurs heures de travail manuel.
Cette vitesse ne dispense pas de comprendre ce qu'il se passe. Sur un de mes projets, j’ai par exemple constaté que des connexions SSE restaient actives et généraient un grand nombre de requêtes vers mon hébergement Vercel. Le code pouvait sembler fonctionner, mais son comportement réel avait un coût technique et financier invisible depuis l’interface.
Ce type de problème résume bien la limite du vibe coding. Une IA peut livrer une solution cohérente à première vue. Le développeur reste responsable des connexions ouvertes, des requêtes, de la sécurité, des performances et de la maintenance. L’agent accélère l’exécution, mais il ne récupère pas la responsabilité du système.
Le métier de développeur est-il en train de perdre son intérêt ?
Pour certains développeurs, le plaisir du métier vient de la résolution directe d’un problème : comprendre un système, concevoir une architecture puis écrire une solution. Lorsque l’essentiel du travail devient la formulation de prompts et la validation de réponses, cette satisfaction peut disparaître.
D’autres apprécient au contraire de quitter les tâches répétitives pour se concentrer sur les décisions, les tests et la conception générale. La même évolution peut donc être vécue comme une libération ou comme une perte de sens.
Le rejet actuel du vibe coding ne signifie pas nécessairement que les développeurs refusent l’IA. Il montre surtout qu’ils ne veulent pas tous devenir les superviseurs permanents d’un outil qui écrit à leur place.
Qu’est-ce que le vibe coding ?
Le vibe coding consiste à créer ou modifier un programme principalement en décrivant le résultat attendu à une intelligence artificielle, puis en testant et corrigeant le code généré.
Pourquoi certains développeurs rejettent-ils le vibe coding ?
Certains développeurs estiment que le vibe coding transforme leur métier en travail de relecture, d’audit et de correction de code généré, avec une perte de contrôle et de satisfaction.
Qu’est-ce que l’AI slop dans le développement ?
L’AI slop désigne du code produit rapidement par une IA, parfois fonctionnel, mais difficile à comprendre, incohérent, répétitif ou coûteux à maintenir.
Le vibe coding convient-il aux projets professionnels ?
Il peut être utile dans un projet professionnel si le code est relu, testé et compris par l’équipe. Il devient risqué lorsque la génération remplace entièrement la conception et la validation humaines.
L’IA va-t-elle remplacer les développeurs ?
Les outils d’IA modifient déjà le travail des développeurs, mais ils ne suppriment pas le besoin de comprendre l’architecture, la sécurité, les performances et la maintenance d’un logiciel.
