Le vibe code, c’est du code legacy
(blog.val.town)- Le vibe coding consiste à écrire rapidement du code à l’aide de l’IA, en se fiant à son intuition, ce qui finit par laisser du code qu’on ne comprend pas, autrement dit du code legacy
- Le code legacy est un code que personne ne comprend, ce qui entraîne de la dette technique et des problèmes de maintenance, avec un risque élevé d’erreurs lors de l’ajout de nouvelles fonctionnalités
- Le vibe coding peut être un moyen de développement rapide pour un prototype ou un projet à court terme, mais il n’est pas adapté aux projets qui doivent être maintenus sur la durée
- Lorsqu’un non-spécialiste fait du vibe coding sur un grand projet, le risque est comparable au fait de donner une carte bancaire à un enfant
- Même en 2025, lorsqu’on développe avec l’IA, il reste essentiel de faire preuve de prudence et de conserver une bonne compréhension du code
Qu’est-ce que le vibe coding ?
- Andrej Karpathy a défini le terme "vibe coding" comme une manière de programmer où l’IA écrit le code et où l’utilisateur y prête si peu d’attention qu’il en oublie presque l’existence même
- Cette approche se distingue du développement logiciel traditionnel en ce qu’elle permet d’obtenir un résultat sans que le développeur comprenne réellement l’intérieur du code produit
Les problèmes du code legacy et la dette technique
- Un code que personne ne comprend est déjà du code legacy
- Ce type de code demande beaucoup de temps pour la maintenance et multiplie fortement les problèmes liés aux bugs et à l’ajout de nouvelles fonctionnalités
- L’article souligne que l’essence de la programmation n’est pas de produire beaucoup de code, mais de construire une théorie conceptuelle
Vibe coding et prototypage
- Le vibe coding permet de démarrer rapidement le développement d’un prototype ou d’un projet jetable
- Si aucune maintenance ultérieure n’est nécessaire, ne pas connaître les détails internes du code ne constitue pas une charge majeure
- Cela permet d’accélérer fortement le développement et convient très bien à l’expérimentation de nouvelles idées
Le spectre de compréhension dans le vibe coding
- Le vibe coding se situe sur un spectre où, moins le développeur comprend le code, plus il est dans la vibe
- Fondamentalement, plus l’ingénieur comprend clairement les exigences, moins il y a de vibe coding
- Lorsqu’une personne non programmeuse demande du code sans connaître la différence entre le web et les applications natives, ni la manière dont les données sont stockées, cela conduit généralement à davantage de vibe coding
Le vibe coding à grande échelle par des non-spécialistes : comme une carte bancaire
- Pour un non-spécialiste, vouloir créer et maintenir un grand projet en vibe coding revient à donner une carte bancaire à un enfant sans lui expliquer le concept
- Au début, tout peut sembler facile, mais d’énormes coûts de maintenance et de nombreux problèmes apparaissent ensuite
- Au final, quand la « facture » arrive, le manque de capacité à résoudre les problèmes peut au contraire aggraver la situation
Développer sérieusement à l’ère de l’IA en 2025
- Andrej Karpathy insiste sur le fait que, dans le développement avec l’IA, la prudence, la vigilance et une attitude d’apprentissage continu vis-à-vis du code existant sont absolument nécessaires
- Il est important de se défendre contre l’excès de confiance de l’IA et de conserver un jugement humain capable de distinguer le bon code du mauvais
- Il ne faut pas simplement tout déléguer à l’IA : il faut impérativement lire et comprendre le code soi-même
L’usage des outils d’IA chez Val Town
- Val Town automatise la rédaction, l’exécution, la vérification et l’amélioration itérative du code grâce à un assistant IA appelé Townie
- Townie est un outil adapté au vibe coding, que l’on peut utiliser librement ou contrôler de manière stricte selon l’usage recherché
- La manière de développer avec l’IA évolue très rapidement, et l’importance des fondements théoriques dans le développement de logiciels complexes restera essentielle
Avertissement contre le vibe coding inconsidéré des non-spécialistes
- Dépenser des milliers de dollars pour qu’une personne non programmeuse fasse du vibe coding sur une idée d’application géante n’est pas une bonne approche
- En fin de compte, il faut toujours un regard humain capable de lire et d’analyser l’intérieur du code, et il est souvent plus efficace de repartir de zéro avec une bonne conception que de tenter de corriger un code legacy incompréhensible
Conclusion et conseils
- Lorsqu’on construit un logiciel complexe, les bases théoriques sont essentielles
- Même si les méthodes de programmation évoluent rapidement avec les progrès de l’IA, l’expertise des développeurs humains reste cruciale
- Si un non-spécialiste tente de créer une application de grande ampleur avec l’IA, il peut au final être préférable de relire tout le code et de tout reconstruire
12 commentaires
C’est comme donner une carte de crédit à un enfant
C’est une comparaison pertinente
Ou on pourrait aussi comparer cela au fait de donner un couteau à un enfant
Si une IA de génération de code capable d’ajouter aussi des commentaires au code généré et de dessiner des organigrammes du flux du code voit le jour, ce sera utile dans une certaine mesure.
Je suis assez d’accord avec ce constat. J’en fais d’ailleurs déjà un peu l’expérience en pratique…
Et je me demande aussi comment cet aspect va évoluer en fonction des changements de performance des modèles.
C’est tellement vrai que ça m’a fait tiquer immédiatement. Les gens qui ne connaissent pas le code disent « waouh » quand ils font du vibe coding, mais ceux qui connaissent le code se demandent plutôt : « pourquoi ? comme ça ? ».
L’état des commentaires est affligeant.
Alors, cela veut-il dire qu’on ne pourra jamais conduire une voiture tant qu’on n’en aura pas compris toute la structure interne ?
Construire une voiture sans comprendre sa structure interne = le vibe coding
On peut s’en servir. Mais on ne pourra pas le créer.
Je pense que c’est une question de méthode et de technologie. Ceux qui disent qu’il ne faut tout simplement pas utiliser l’IA et qu’il faut faire du hand-coding « organique », c’est un peu comme ceux qui diraient que la vraie voie, ce n’est pas d’utiliser une calculatrice scientifique ni les fonctions d’Excel, mais de sortir un boulier ou de tout faire à la main.
C’est une mauvaise analogie. Comme une calculatrice scientifique ou Excel, les résultats d’une calculatrice d’ingénierie sont exacts en fonction des valeurs saisies. Si l’IA produisait exactement le résultat anticipé par l’utilisateur, ce ne serait pas une technologie si différente de tant de nouvelles technologies apparues jusqu’ici. C’est aussi la raison pour laquelle les inquiétudes autour de la sécurité et des hallucinations grandissent avec le temps. Autrement dit, l’IA générative ne se contrôle pas. Il faut comprendre les limites actuelles des LLM et les utiliser là où c’est approprié.
Je pense qu’actuellement le vibe coding n’en est encore qu’à ses débuts, et qu’il deviendra d’ici un ou deux ans une méthodologie de développement mature. De la même manière que le devops devient de l’aidevops, je pense que cela évoluera vers l’aiagile ou le vibeagile.
Avis Hacker News
C’est l’histoire d’un ami non développeur. L’an dernier, il a codé lui-même un SaaS et l’a lancé, puis a commencé à générer des revenus presque sans marketing, uniquement grâce au bouche-à-oreille et à l’inbound. Il a utilisé Replit et Supabase pour le développement, et quand on voit à quel point l’application s’est complexifiée au fil des retours clients, je trouve ça vraiment impressionnant. À mon avis, il y avait déjà deux acteurs sur ce marché, et comme mon ami proposait un produit plus moderne avec un abonnement mensuel bien moins cher, ils n’ont pas dû apprécier — leurs produits existants étaient tous des logiciels desktop pour Windows. Ils ont donc engagé des hackers pour attaquer le SaaS de mon ami, et ces hackers ont attaqué sans même demander d’argent. Malheureusement, comme il codait vite et sans expérience, il y avait beaucoup de vulnérabilités. D’abord, la liste des utilisateurs était exposée dans le code frontend, ce qui a permis aux hackers d’envoyer des emails à tous les clients. Ensuite, ils ont mis la main sur les clés Stripe et ont remboursé tous les clients. Enfin, ils continuent encore à tenter des attaques XSS, et on voit parfois apparaître dans certains champs des balises comme
<script>alert()</script>. Ma conclusion, c’est que quand quelqu’un sans expérience fait du vibe-coding, il accumule immédiatement de la dette technique. Mais en même temps, le fait que cet ami ait pu démontrer en quelques mois la viabilité commerciale d’un produit sans aucune expérience d’ingénierie est remarquable. Il est maintenant en train d’embaucher des développeurs pour corriger tout ça. Il a réussi à valider une opportunité business correcte avec seulement quelques centaines de dollars investis, malgré un code fragile et bourré de failles de sécurité, donc au final je pense que le processus en valait la peineJ’ai plutôt l’impression que supposer que c’est l’œuvre de concurrents, c’est une façon d’éluder la responsabilité. En réalité, il est plus probable qu’un scanner automatisé de vulnérabilités ait repéré le site et que, comme il était trop mal sécurisé, des hackers soient entrés et aient fait n’importe quoi. Tous ceux qui voient souvent ce type de trafic d’exploit sur des services connectés à Internet le savent bien
C’est moralement comparable au fait de construire une maison sans expérience en ingénierie, puis de voir quelqu’un venir la pousser du pied jusqu’à ce qu’elle s’effondre. Le problème n’est pas le vibe coding en soi, mais le manque de connaissances nécessaires pour prendre des décisions importantes. Ce genre de problème peut même aller jusqu’à engager la responsabilité juridique
S’il y avait déjà des acteurs établis sur le marché, est-ce qu’un tel MVP était vraiment nécessaire pour prouver la viabilité du business ? En gros, si tu proposes moins cher, il n’y a pas vraiment besoin de tester si les gens vont quitter leur fournisseur actuel. La leçon qu’a tirée ton ami, c’est que certains clients accepteront peut-être de payer au début — sans qu’on ait la moindre donnée sur la rétention — mais qu’au final il faudra embaucher des gens pour construire un vrai produit, et à ce moment-là l’avantage prix risque de disparaître. Quand il faudra investir sérieusement en marketing, ça deviendra compliqué. Au bout du compte, on revient toujours au même constat : les idées n’ont aucune valeur en elles-mêmes, tout se joue dans l’exécution
Le vrai problème fondamental de ce secteur, c’est que ton ami peut continuer son activité sans quasiment aucune responsabilité. Si le logiciel était encadré aussi strictement que d’autres disciplines d’ingénierie, les développeurs ou les entreprises seraient juridiquement responsables des fuites de données clients
Même si le business a été validé, du point de vue des clients cela peut être une perte plutôt qu’un gain. Ils paient pour utiliser un produit tout en exposant des données importantes à un environnement peu sécurisé, sans même être certains que le produit fonctionne correctement. Tu dis qu’il embauche maintenant des développeurs pour corriger le tir, mais ce ne sera sans doute pas aussi simple qu’il l’imagine. Je suis favorable à l’IA comme support d’apprentissage, de documentation ou de productivité, mais sans intervention humaine, elle peut produire des résultats catastrophiques
Par le passé, des non-développeurs ou des développeurs juniors ont déjà créé et déployé facilement des applications avec Microsoft Access, Excel, etc. À l’époque aussi, il y avait des limites, des problèmes de scalabilité et des cauchemars de maintenance, mais en même temps ce mouvement a poussé les développeurs professionnels à accélérer le développement de meilleures solutions. C’était pareil lors de la démocratisation du PC : les développeurs mainframe étaient horrifiés par le code « bordélique » du monde PC
Je travaille dans l’ingénierie logicielle depuis près de trente ans et j’ai lu tous les commentaires de ce fil. Honnêtement, je pense que presque tous les arguments avancés contre le vibe coding s’appliquent tout autant à toutes les bases de code « écrites par des humains » que j’ai vues jusqu’ici — avec quelques exceptions, bien sûr
Je ne vois pas en quoi un prototype destiné à être jeté serait une mauvaise chose. C’est l’étape la plus importante au début d’un business. C’est pareil pour le code legacy. En réalité, la plupart du code qui génère effectivement du chiffre d’affaires a probablement déjà l’air legacy aux yeux des développeurs de l’organisation
Il y a cette blague qui dit que tout code devient du legacy à partir du moment où il est mergé dans le trunk
Je suis partiellement d’accord, mais le problème du vibe coding, c’est qu’il permet d’aborder les choses de façon brutale, sans vraie recherche préalable, sans étudier la structure de la base de code existante ni la nature de la solution nécessaire. Rien qu’hier, un collègue peu familier avec Rust a ajouté une nouvelle fonctionnalité en vibe coding : en apparence, « ça marche », mais en réalité c’est un désastre total — I/O synchrone dans un contexte async tokio, verrous, implémentation maison de canaux, etc. Alors qu’il existait déjà des abstractions asynchrones sûres, il a recréé de nouvelles abstractions incorrectes. S’il avait pris le temps de chercher ou simplement demandé de l’aide, il aurait pu s’appuyer sur des exemples du code existant
Tout code finit un jour par devenir du legacy. Vu mon expérience, depuis mes débuts comme junior jusqu’aux innombrables scripts de production et services que j’ai relus chez d’autres développeurs juniors, cette vision absolutiste me paraît excessive. Ce problème se répète dans la plupart des organisations. Je comprends qu’on veuille critiquer la qualité du code généré par les LLM, mais quiconque a passé sa carrière à corriger, étendre ou refactorer des systèmes écrits par d’autres connaît déjà cette réalité. Tant que le monde du software n’adoptera pas, comme en génie mécanique, des standards stricts de cohérence, de certification, de responsabilité et d’impact réel, ce débat restera assez vain. L’industrie IT moderne repose au contraire entièrement sur une philosophie inverse : « agile », « construire vite et ce n’est pas grave si ça casse ». On livre rapidement, souvent, avec peu de conception, et si ça part mal on rollback ; s’il y a une panne, on hausse les épaules. Le logiciel est traité comme un jouet. Peut-être que 1 % des gens pensent faire ça correctement, mais la plupart non
Il se passe quelque chose d’assez amusant en ce moment. Des gens qui comprennent mal l’ingénierie — et d’autres qui la comprennent un peu mais l’expliquent mal — diffusent en ligne un récit erroné. Ils affirment maintenant que les développeurs juniors sont 10 fois plus productifs et que même des PM déploient directement du code. Mais si on ferme les yeux un instant et qu’on imagine le code produit dans ce contexte, c’est du code 100 % legacy et jetable. Le vrai sujet n’est pas l’IA, ni la capacité d’un PM à sortir directement du code depuis Figma, ni les juniors qui bombardent les prompts. La vraie raison du décalage entre les attentes et la réalité, c’est qu’on ne distingue plus correctement des termes et concepts qui ont pourtant été définis au fil de plusieurs années de discussions.
Un lean prototype et un disposable prototype — même pas un MVP — ce n’est pas la même chose. On ne peut construire un MVP qu’après validation réussie d’un lean prototype. Et un produit, c’est encore autre chose qu’un MVP.
Les outils de vibe coding sont excellents pour créer rapidement des prototypes jetables, tandis qu’un IDE équipé d’un LLM est mieux adapté à la construction d’un vrai produit. À ce stade, seuls de vrais ingénieurs savent coder un lean prototype avec des prompts LLM ; les autres ne produisent que des logiciels simples fonctionnant sur du code jetable
Quand tu dis « un produit est différent d’un MVP », j’aimerais dire ça à presque toutes les entreprises où j’ai travaillé. Aujourd’hui, les boards et les dirigeants C-level sont obsédés par le « livrez juste quelque chose ce trimestre », donc les développeurs construisent un MVP puis passent aussitôt au projet suivant. Que ce soit du vrai vibe coding ou non, la réalité c’est que si ça a l’air riche en fonctionnalités, les indicateurs business montent, quelle que soit la qualité réelle. En pratique, les environnements où de vrais ingénieurs — apparemment c’est comme ça qu’on appelle désormais les « développeurs » — pilotent réellement le prototypage sont rares. On voit ça surtout dans le jeu vidéo, ou dans quelques boîtes tech particulières. La plupart ne font que du MVP en boucle. Le vibe coding accélère simplement la chaîne de production de MVP, au détriment de la qualité
La tendance à mélanger des « définitions de termes » sans véritable substance s’est nettement accentuée dans l’industrie ces dix dernières années. À l’origine, ces mots s’étaient chargés de contexte à travers d’innombrables livres, discussions et débats au long cours. Quand un développeur expérimenté utilisait un terme, il embarquait avec lui tout un historique d’expérience et de controverses. Mais les nouveaux arrivants recopient ces mots en surface, sans ce contexte, et les emploient sans même en définir le sens. Au final, plus personne ne sait ce que chaque terme voulait dire à l’origine, ni pourquoi c’était le mot adapté à la situation. Par exemple : "'agile', 'technical debt', 'DevOps' et, plus récemment, 'vibe coding'". Il y a aussi eu sur HN un billet sur la dérive sémantique. C’est un phénomène courant dans le secteur logiciel.
Un exemple technique serait l’usage interchangeable de 'object', 'JSON', 'dictionary' et 'hashmap' en JavaScript. À l’origine, chacun a un sens différent, mais pour beaucoup de développeurs JS, tout ça se résume à « object ». C’est comme si toute la résolution linguistique et conceptuelle était écrasée en un seul « pixel »
Autrefois, les développeurs disaient simplement qu’ils n’avaient pas tous la même « façon de penser » le code. Aujourd’hui, la fatigue des développeurs due à l’incapacité générale à comprendre le code a explosé. Avant, dans ce genre de situation, un ingénieur pouvait intervenir pour rendre utile une partie cassée, et un architecte réduisait la complexité. Maintenant, à l’ère des LLM, on produit 100 fois plus de code, alors que les ingénieurs et les architectes sont pratiquement exclus du processus. C’est exactement la situation qu’on vit en ce moment.
Si quelqu’un invente une méthode de test pour résoudre ce problème — serveur MCP TDD, serveur MCP DDD, ou n’importe quel workflow/architecture — il y a potentiellement une startup à plusieurs milliers de milliards à la clé. On a désespérément besoin d’outils capables d’augmenter et de scaler l’efficacité des code reviews
Je pense qu’il faut déjà mieux définir ce qu’est un « logiciel qui fonctionne ». Par exemple, les interfaces générées par LLM se ressemblent toutes et contiennent souvent de petites erreurs subtiles. Un simple test utilisateur suffit à révéler le problème. De plus, l’UI générative est déjà obsédée par les tendances et ne crée rien de vraiment nouveau
Tu as déjà vu comment le code interne est produit dans les grands groupes ? Ce n’est pas très différent du vibe coding. À la limite, si on tune un LLM pour qu’il passe un pentest, il essaiera au moins de faire quelque chose. Les grandes entreprises, elles, s’en moquent complètement
En réalité, tout code est legacy. Donc le fait que le vibe coding produise beaucoup de code rapidement n’a rien de spécial. Le « code écrit de ma propre main » que personne ne comprendrait au final est tout aussi mauvais. Tout code est, au fond, un fardeau du point de vue de la maintenance. Les bibliothèques ne font qu’alléger le problème ; celles qui changent souvent ou dont l’interface vieillit mal sont un legacy encore pire.
Plus on a écrit du code longtemps, plus on finit par conclure que la vraie solution consiste à en produire moins, c’est-à-dire à réduire le besoin dans son ensemble. Toute complexité devient tôt ou tard un « problème que mon moi futur ne se rappellera plus ». En pratique, les exigences changent sans cesse, et même des exigences données par un expert peuvent être fausses — y compris si cet « expert », c’est soi-même
Je ne suis pas d’accord avec l’idée que « tout code est legacy ». Certains bouts de code sont petits et encore totalement présents dans la tête du développeur, donc parfaitement « en temps réel ». La vraie définition du legacy, c’est plutôt un code massif dont plus personne dans l’organisation n’est réellement propriétaire. Le vibe code remplit déjà ces deux conditions au moment même où il est généré
Le legacy, c’est quand il n’y a plus de partie prenante vivante pour porter le contexte, ce qui rend la maintenance et la compréhension difficiles
J’aimerais résoudre les problèmes avec le moins de code possible. Le vrai enjeu, c’est que le code ne devienne pas mon problème. Tout dépend du degré auquel les abstractions « fuient », et celles que fabriquent actuellement les LLM sont très mauvaises. Impossible de savoir à quel point cela s’améliorera.
J’aimerais investir dans des outils qui rendent la compréhension du code plus amusante, plus simple et moins coûteuse. Mon ami Glen travaille sur un projet qui peut servir de référence : https://glench.github.io/fuzzyset.js/ui/
Comme le dit Geoffrey Litt, les LLM pourraient être bien plus utiles pour fabriquer des outils temporaires de visualisation de notre code, des débogueurs, etc., afin de nous aider à le comprendre
Tout code comporte un risque, mais tout code n’est pas legacy. Le code produit en vibe coding donne plutôt l’impression de devenir legacy instantanément, puisqu’il n’a ni contexte ni propriétaire réel dès le départ
À ceux qui contestent l’idée que tout code soit legacy : dans un projet que je comprends en profondeur, pouvoir identifier immédiatement la cause d’un bug et visualiser mentalement l’implémentation d’une nouvelle fonctionnalité, ce n’est pas du legacy
Je pense que « l’époque où l’on regardait le code comme des mathématiques » est terminée. Un logiciel suffisamment grand et connecté au monde réel ne peut pas être garanti vrai au sens d’une preuve mathématique parfaite. Les systèmes réels sont des artefacts d’ingénierie qui reposent sur des garanties formelles, du design fondé sur l’expérience, des tests empiriques, du savoir-faire et des critères de performance.
Cette tendance va s’étendre jusqu’aux scripts les plus modestes. La plupart des logiciels n’ont même pas besoin d’être mathématiquement prouvés. Il suffit qu’ils remplissent leur objectif. J’ai beaucoup de respect pour l’artisanat du développement, mais il est temps de lâcher prise sur cet aspect.
En fin de compte, l’avenir ressemble à l’un de ces deux choix :
un programme de 100 000 lignes avec 50 000 tests, garantissant toutes les exigences mais illisible pour presque tout le monde, coût total 50 000 dollars (coût des tokens API)
un programme conçu par des humains, 30 000 lignes, 3 000 tests, abstractions élégantes, répondant aux mêmes exigences, coût total 300 000 dollars (salaires des développeurs)
Si j’étais consommateur de logiciel, que je me fichais des détails internes et que je ne regardais que le prix, je choisirais évidemment l’option 6 fois moins chère
Il faut penser au moment où un changement sera nécessaire à cause de nouvelles exigences externes. Dans ce cas, si ce logiciel est au cœur du business, il faudra immédiatement changer de fournisseur. C’est pour ça que la maintenance et le support restent indispensables, en B2B comme en B2C. Le logiciel doit toujours pouvoir évoluer
D’où cette blague : « Ce code n’était compris que par moi et Copilot. Maintenant, seul Copilot le comprend »
À l’affirmation selon laquelle « un système suffisamment grand et connecté au monde réel ne peut pas être prouvé mathématiquement correct », les gens qui travaillent en vérification formelle pourraient réagir violemment — ou être secrètement d’accord
Parmi ces deux scénarios, il faut surtout demander lequel est le moins cher et le plus rapide quand il faut faire évoluer une version. Pour l’instant, j’ai l’impression que le modèle avec développeurs humains est encore moins coûteux, mais je ne suis pas certain de l’avenir
En réalité, je n’ai presque jamais vu aucune de ces deux options dans le monde réel
Le stade ultime de cette évolution, ce ne serait pas un langage de programmation totalement orienté machine, que les humains n’auraient même plus besoin de lire ? Pourquoi un LLM devrait-il se donner la peine de convertir cela en Python ou en Swift, des langages conçus pour être lisibles par les humains ? S’il suffit d’obtenir directement un résultat exécutable, la notion même de maintenance finit par perdre son sens. On n’en est pas encore là, mais j’ai l’impression qu’on ira un jour dans cette direction
Un bon logiciel est toujours en maintenance. Il y a sans cesse de nouvelles exigences. L’idée qu’on puisse livrer une fois puis en avoir fini pour toujours relève déjà de la blague. C’est pour cela que du code, des tests et de la documentation pensés pour les changements futurs sont essentiels. Si les LLM se mettent à produire en masse du code boîte noire dénué de sens, ce sera terrifiant. L’idée que les LLM atteignent un niveau de codage humain au point que plus personne ne s’en soucie relève de la science-fiction. Le codage n’est qu’une partie du processus global qui consiste à produire un logiciel réellement utile
En fait, le langage machine n’est-il pas déjà à ce niveau ? Les LLM sont optimisés pour une interface lisible par les humains, c’est pour ça qu’ils produisent du JSON et presque jamais du BSON
Je me demande vraiment quel problème cela est censé résoudre. Les problèmes que cela crée, eux, sont évidents
On a presque l’impression d’un jeu du téléphone : le LLM apprend à partir de code écrit pour les humains, recrache du code, puis on réexécute ce code pour obtenir le comportement voulu. On se demande s’il ne pourrait pas générer directement l’action elle-même
Si l’on parle d’un langage difficile à lire pour un humain, Malbolge est l’exemple classique. D’ailleurs, le tout premier programme "Hello World" a été généré par un algorithme génétique
Je suis l’auteur original. Ravi d’échanger avec vous tous
Le terme « vibe coding » est une formulation presque trop parfaite. Un peu comme « cloud computing », qui a fini par englober énormément de choses. À l’origine, cela désignait le fait de lancer des instances EC2 de manière élastique puis de les supprimer une fois le travail terminé, mais la métaphore était si intuitive que même Gmail a fini par être qualifié de « cloud ».