Vibe engineering

• « Vibe Engineering » est un nouveau terme pour désigner une manière professionnelle de développer avec des outils de codage IA. Contrairement au « vibe coding », rapide et irresponsable, il décrit une approche où des ingénieurs expérimentés utilisent les LLM tout en maintenant la qualité du code et la responsabilité
• Avec l’arrivée d’agents de codage comme Claude Code, OpenAI Codex CLI et Gemini CLI, l’usage des LLM dans les projets réels a fortement augmenté, et certains ingénieurs font tourner plusieurs agents en parallèle pour travailler simultanément
• Pour exploiter efficacement les LLM, il faut déjà disposer des meilleures pratiques établies en ingénierie logicielle : tests automatisés, planification en amont, documentation complète, gestion de versions, culture de revue de code
• Les outils IA ont pour effet d’amplifier l’expertise existante : plus un ingénieur senior possède de compétences et d’expérience, plus il peut obtenir des résultats rapides et de qualité avec les LLM
• Le terme marque une distinction nette avec le « vibe coding » et souligne une forme d’usage de l’IA plus difficile et plus sophistiquée pour développer du logiciel de production ; l’association paradoxale entre engineering et vibe a en plus l’avantage d’être mémorable (et met en lumière l’évolution des processus de développement et l’importance de l’expertise à l’ère des outils IA)

---

Différence entre vibe coding et vibe engineering

• Le vibe coding désigne une façon rapide, relâchée et irresponsable de développer avec l’IA, entièrement guidée par les prompts, avec peu d’attention portée au fonctionnement réel du code
• À l’autre extrémité du spectre, il existe une manière de travailler où des professionnels expérimentés accélèrent leur travail grâce aux LLM tout en assumant pleinement, avec fierté et confiance, la responsabilité du logiciel produit ; c’est ce qui est appelé vibe engineering
• Une vérité moins connue, c’est que travailler de manière productive avec des LLM sur de vrais projets, et non sur de simples projets jouets, en tant qu’ingénieur logiciel, est difficile : il faut une compréhension approfondie des outils et il existe de nombreux pièges à éviter

L’arrivée des agents de codage et leur impact

• Des outils d’agents de codage comme Claude Code, lancé en février 2025, Codex CLI d’OpenAI, lancé en avril, et Gemini CLI, lancé en juin, ont fait leur apparition, augmentant spectaculairement l’utilité des LLM pour des problèmes de développement concrets
  • Ces outils modifient le code de manière itérative et testent activement jusqu’à atteindre l’objectif demandé
• Des ingénieurs logiciel expérimentés et fiables font tourner plusieurs agents en même temps afin de traiter plusieurs problèmes en parallèle et d’élargir le périmètre du travail possible
  • L’auteur était d’abord sceptique, mais après avoir lui-même exécuté des agents de codage en parallèle, il a constaté que c’était mentalement épuisant mais étonnamment efficace
• La majeure partie de la collection tools.simonwillison.net a été construite selon une approche classique de vibe coding, mais travailler en boucle avec des agents de codage pour produire un code de qualité production maintenable à long terme donne l’impression d’un processus totalement différent

Les pratiques d’ingénierie logicielle existantes que les LLM renforcent

• Tests automatisés : disposer d’une suite de tests robuste, complète et stable permet aux outils d’agent de codage d’aller vite ; sans tests, l’agent peut prétendre qu’une fonctionnalité marche sans vraiment la tester, ou de nouveaux changements peuvent casser des fonctions sans rapport
  • Le développement piloté par les tests est particulièrement efficace avec des agents capables d’itérer dans une boucle
• Planification en amont : quand on commence par un plan de haut niveau avant de bricoler quelque chose, tout se passe beaucoup mieux, et c’est encore plus important avec des agents
  • On peut d’abord itérer sur le plan, puis confier à l’agent l’écriture du code
• Documentation complète : comme les programmeurs humains, les LLM ne peuvent garder en contexte qu’une partie du code à la fois ; fournir la documentation pertinente leur permet d’utiliser les API d’autres zones sans devoir d’abord lire tout le code
  • En écrivant d’abord une bonne documentation, le modèle peut construire une implémentation correspondante à partir de cette seule entrée
• Bonnes habitudes de gestion de versions : si un agent de codage a pu modifier des choses, il devient encore plus important de pouvoir annuler des erreurs et de comprendre quand et comment un changement a eu lieu
  • Les LLM sont très bons avec Git : ils peuvent explorer l’historique eux-mêmes pour retracer l’origine d’un bug, et utilisent souvent mieux git bisect que la plupart des développeurs
• Automatisation efficace : intégration continue, formatage et linting automatisés, déploiement continu vers des environnements de preview… tout cela aide aussi les outils d’agent de codage
  • Les LLM facilitent l’écriture rapide de scripts d’automatisation, pour répéter ensuite une tâche avec exactitude et constance
• Culture de revue de code : si l’on est rapide et efficace en revue de code, travailler avec des LLM devient beaucoup plus agréable
  • Si vous préférez écrire le code vous-même plutôt que relire la même chose écrite par quelqu’un d’autre (ou quelque chose d’autre), cela risque d’être difficile
• Une forme de management très étrange : obtenir de bons résultats d’un agent de codage ressemble, de manière presque inconfortable, au fait d’obtenir de bons résultats d’un collaborateur humain
  • Il faut fournir des consignes claires, garantir le contexte nécessaire et donner des retours exploitables sur la production
  • C’est bien plus facile qu’avec de vraies personnes parce qu’il n’y a pas à se soucier de les vexer ou de les décourager, mais l’expérience managériale existante s’avère étonnamment utile
• Un très bon QA manuel : au-delà des tests automatisés, il faut être vraiment compétent pour tester manuellement le logiciel, notamment en anticipant et en explorant les cas limites
• Solides compétences de recherche : il existe des dizaines de façons de résoudre un problème de code donné ; identifier la meilleure option et valider une approche a toujours été important, et cela reste un obstacle avant de laisser un agent écrire du vrai code
• Capacité à déployer vers un environnement de preview : quand un agent construit une fonctionnalité, disposer d’un moyen de la prévisualiser en toute sécurité, sans la déployer directement en production, rend la revue bien plus productive et réduit fortement le risque de livrer quelque chose de cassé
• Intuition sur ce qu’il faut externaliser à l’IA et ce qu’il faut traiter manuellement : à mesure que les modèles et les outils gagnent en efficacité, cette intuition continue d’évoluer
  • Une grande partie du travail efficace avec les LLM consiste à garder une forte intuition sur les moments où ils s’appliquent le mieux
• Sens réactualisé de l’estimation : estimer la durée d’un projet a toujours été l’un des aspects les plus difficiles, mais aussi les plus importants, du rôle d’ingénieur senior, surtout dans les organisations où le budget et la stratégie dépendent de ces estimations
  • Le codage assisté par l’IA rend cela encore plus difficile : des choses autrefois longues deviennent beaucoup plus rapides, mais les estimations dépendent désormais de nouveaux facteurs que nous sommes encore tous en train d’appréhender

La nature et l’importance du vibe engineering

• Pour réellement tirer parti de ces nouveaux outils, il faut jouer au plus haut niveau, ce qui implique :
  • ne pas seulement être responsable de l’écriture du code, mais aussi de
  • la recherche sur l’approche,
  • les décisions d’architecture de haut niveau,
  • la rédaction des spécifications,
  • la définition des critères de réussite,
  • la conception des boucles d’agents,
  • la planification du QA,
  • la gestion d’une troupe toujours plus nombreuse d’étranges stagiaires numériques enclins à tricher dès qu’on leur en laisse l’occasion,
  • et passer beaucoup de temps en revue de code
• Presque tout cela correspond déjà aux caractéristiques d’un ingénieur logiciel senior
• Les outils IA amplifient l’expertise existante : plus vous avez de compétences et d’expérience comme ingénieur logiciel, plus vous pouvez obtenir des résultats rapides et meilleurs en travaillant avec des LLM et des agents de codage

« Vibe engineering », vraiment ? : réflexion sur le choix du terme

• Le nom « vibe engineering » est-il idiot ? Probablement, et la notion de « vibe » dans l’IA semble déjà un peu usée à ce stade, tandis que le « vibe coding » lui-même est souvent employé de façon méprisante par de nombreux développeurs
  • Mais je suis prêt à réapproprier la vibe pour quelque chose de plus constructif
• Je n’ai jamais aimé la distinction artificielle entre « codeur » et « ingénieur », qui m’a toujours semblé constituer une forme de barrière à l’entrée, mais dans ce cas précis, une petite barrière à l’entrée est exactement ce qu’il faut
  • Le vibe engineering établit une distinction claire avec le vibe coding, et signale qu’il s’agit d’une autre manière, plus difficile et plus sophistiquée, de travailler avec des outils IA pour construire du logiciel de production
• J’aime le fait que cela puisse paraître insolent et controversé ; tout cet espace reste encore absurde à bien des égards
  • Pendant que nous cherchons la façon la plus productive d’appliquer ces nouveaux outils, nous ne devrions pas nous prendre trop au sérieux
• J’ai déjà tenté d’imposer des termes comme programmation assistée par l’IA, avec un succès proche de zéro ; cette fois, frotter un peu de vibe dessus pour voir ce qui se passe n’est peut-être pas une mauvaise idée
• J’aime beaucoup le décalage évident entre « vibe » et « engineering », qui rend l’expression combinée ludiquement, et espérons-le mémorablement, contradictoire en elle-même

[m00nlygreat]

Je crois savoir qu’ils avaient déjà essayé il y a quelque temps de lui donner un nom du genre « quel codage ? », sans succès, donc l’expression la plus appropriée me semble être l’AI pair programming.

Trouver un nom pour pouvoir prétendre : c’est moi qui ai inventé ce nom.

[m00nlygreat]

Quelqu’un avait appelé ça le codage augmenté (Augmented Coding), puis le terme a rapidement disparu.

[GN⁺]

Commentaires Hacker News

• Ces derniers temps, lire ce genre de sujet me déprime un peu. Avant, j’avais des compétences en programmation rares, très demandées et bien rémunérées, et même si les langages ou les frameworks évoluaient vite, j’avais confiance dans ma capacité à suivre parce que je me sentais assez intelligent. Mais quand je vois des gens comme Simon Willison dire que ces nouvelles méthodes de code basées sur des agents et des flux de travail hautement parallélisés sont l’avenir, j’ai l’impression que ça va demander un effort énorme, et ça me pèse. J’ai essayé des agents de code, mais au final je passe plus de temps à attendre, et gérer plusieurs tâches en parallèle me fait perdre le fil et rend ça moins amusant. Du coup, je me surprends à penser que j’aimerais peut-être me reconvertir complètement dans autre chose, comme la vente.
  • Je compatis sincèrement, j’ai ressenti la même chose. En fait, l’un de mes objectifs était justement de réfuter l’idée que « les compétences en programmation ne servent plus à rien et que tout le monde peut coder avec un LLM ». Je crois au contraire qu’une personne avec une vraie expérience de développement devient beaucoup plus précieuse quand elle travaille avec des agents de code ou des LLM. On peut réutiliser tout ce qu’on a appris pour avoir un impact plus grand avec de nouveaux outils. Comme le billet le disait aussi, les outils d’IA servent surtout à amplifier les capacités des experts existants. Un débutant peut peut-être faire une belle UI avec ChatGPT, mais il ne saura pas gérer l’architecture, les tests automatisés, le CI/CD, un déploiement Kubernetes ou l’orchestration simultanée de plusieurs agents. Le rôle d’un ingénieur expérimenté devient donc encore plus important.
  • Moi aussi, « gérer plusieurs gros agents parallélisés » me paraît pesant. En surface, ça a l’air très puissant, donc beaucoup de développeurs doivent s’y intéresser, mais en pratique ça ressemble surtout à beaucoup de stress et de travail de gestion. Quand je suis tombé amoureux du développement, ce qui me plaisait c’était coder en soi ; je pouvais coder toute la journée et apprendre énormément. Maintenant, avec plus de dix ans de carrière, ma manière de penser est devenue plus business : « pourquoi coder ça, au juste ? ». En réunion, dès qu’un service demande « est-ce qu’on peut faire ça ? », la réponse est presque toujours « OUI ». Techniquement, presque tout est faisable. Mais les vraies questions sont plutôt « à quel point est-ce difficile ? » ou « pourquoi faudrait-il le faire ? ». Je pense toujours que l’essentiel n’est pas la capacité à itérer ou à sortir plein de choses, mais à voir le fond du problème.
  • Ça exprime exactement ce que je ressens. Moi non plus, je n’aime vraiment pas le fait de surveiller et gérer de l’IA. Et en plus, ça me fait peur de voir ce mode de développement piloté par l’IA normaliser une réalité où l’on dépend de comptes de grands groupes opaques et non vérifiés pour pouvoir travailler.
  • Pas d’inquiétude. Je suis en train d’accompagner un ingénieur junior dans mon équipe, et il a énormément de mal à améliorer son code, parce qu’une fois que ça marche, ça lui suffit. La structure n’est pas bonne, il y a des petits problèmes et des failles de sécurité cachés partout. Et tout ça avec à peine trois fichiers Python. On a dix développeurs dans l’équipe, et si tout le monde utilise des LLM, les écarts de qualité de code selon le niveau d’expérience deviennent encore plus visibles. D’après ce que j’ai observé pendant les six mois avant l’adoption officielle des LLM, l’écart entre juniors et seniors, ou plus largement entre personnes expérimentées et non expérimentées, tend en réalité à se creuser. Je pense comme Simon là-dessus.
  • Il faut simplement se rappeler que, fondamentalement, plus on a de connaissances, plus un outil nous rend puissant — jamais l’inverse.
• Au début de 2023, à peu près au moment de la sortie de GPT-4, il y a eu un changement similaire dans le secteur de la traduction. En traduction anglais-japonais, qui est mon domaine, la traduction automatique a pour la première fois commencé à approcher le niveau humain. À l’époque, j’ai eu beaucoup de discussions avec des traducteurs professionnels, et comme ici, beaucoup exprimaient leur découragement à l’idée que des compétences de traduction difficiles à acquérir puissent perdre leur valeur. Beaucoup disaient aussi que si les LLM devenaient des assistants, même le plaisir intellectuel du processus disparaîtrait. Les traducteurs que j’ai rencontrés travaillaient pour la plupart en freelance et avaient l’habitude de traduire soigneusement phrase par phrase. L’idée de devenir gestionnaire de gros projets de traduction les attirait peu, et même s’ils avaient les compétences culturelles et contextuelles pour ça, la motivation n’y était pas. Je fais moins de traduction aujourd’hui, mais je continue de suivre de près les progrès de l’IA, et il m’arrive de comparer des modèles sur des tâches de traduction. En ce moment, j’expérimente un système de traduction multi-LLM où plusieurs modèles travaillent en couches — relecture croisée et amélioration mutuelle de leurs traductions. Sur certains documents, on obtient des résultats vraiment proches d’une traduction humaine de très haut niveau. Les coûts d’API n’étaient pas donnés, mais pour des traductions importantes, l’investissement valait largement le coup. Et quand je conçois ce genre de système de « vibe translation », mon expérience de traducteur m’aide clairement. C’est très proche de ce que Simon appelle le vibe engineering. À mon âge, 68 ans, ça me va, mais si les LLM et tout le reste étaient apparus au début de ma carrière, vers mes 5 à 10 ans d’expérience, je pense que j’aurais peut-être abandonné le métier de traducteur.
  • L’exemple de la traduction est vraiment excellent pour discuter des LLM, merci pour ce retour. En même temps, la plupart des gens n’accordent pas une grande valeur au travail des traducteurs. Par exemple, presque personne ne se souvient de qui a traduit un livre. Et comme les gens lisent probablement moins de livres qu’avant, c’est peut-être encore plus vrai aujourd’hui. Pour cette raison aussi, la traduction a traditionnellement été contractualisée et rémunérée au mot ou à la ligne, un peu comme un contrôle final, à l’image de la sécurité logicielle. Les seuls domaines de la traduction qui me semblent vraiment avoir une forte résilience à l’avenir sont le juridique — parce qu’il y a derrière une responsabilité et un risque contentieux — et l’interprétation, simultanée ou sur site, parce qu’il y a une présence humaine réelle et une interaction en direct.
• En ce moment, je trouve un peu absurde à quel point les communautés tech poussent le discours du « coder plus vite et être plus productif ». On dirait qu’on valorise uniquement les résultats rapides, coûte que coûte. Dans mon expérience, les LLM produisent souvent un code verbeux et brouillon. Bien sûr, ils peuvent aller plus vite que moi, mais au final j’ai souvent l’impression que le code que j’écris plus lentement est bien meilleur. Cette ambiance du « il faut tout chatter vite, obtenir un résultat vite, et le pousser vite en production » est exactement ce qui causait autrefois la prolifération de produits web bricolés. Plutôt que de jouer avec des formules à la mode comme vibe coding ou vibe engineering, il faudrait discuter sérieusement de pourquoi on a besoin d’aller aussi vite, même au prix d’une faible qualité, et pourquoi on n’améliore pas davantage l’automatisation ou les processus eux-mêmes. Par exemple, on peut produire très vite des tests unitaires, mais il faut aussi se demander pourquoi on a besoin d’autant de tests unitaires au départ. Ils ont évidemment leur utilité, mais j’ai l’impression que les abstractions de haut niveau progressent, alors que les outils de bas niveau, eux, évoluent beaucoup plus lentement.
  • Le problème fondamental dans les débats sur le software engineering, c’est que même si les outils et les langages semblent les mêmes, les exigences réelles en matière de tolérance, de sécurité, de conformité et de maintenance varient énormément. Certains construisent juste un prototype rapidement, d’autres travaillent sur une feuille de route de dix ans ou manipulent des données sensibles. Comme ces deux points de vue se mélangent, on se retrouve à la fois avec l’idée que livrer vite est une compétence essentielle et avec la crainte que cela mène à des résultats catastrophiques. Aucun des deux camps n’a entièrement tort, mais on discute presque toujours en faisant abstraction du contexte réel de travail et du niveau de risque.
  • En pratique, c’est vrai que les LLM aident énormément à aller plus vite en développement. Je code depuis plus de vingt ans, depuis l’école primaire, et mon entourage reconnaissait déjà ma vitesse avant, mais depuis l’arrivée des LLM, mon échelle d’action a énormément grandi. Le paysage a déjà changé, et maintenant la question est simplement de savoir qui saura s’adapter et qui ne le pourra pas. J’ai moi aussi beaucoup d’amertume face aux incertitudes de l’avenir, mais en tant qu’ingénieur dans une situation similaire, je comprends complètement ce ressenti.
  • Je vais essayer d’exposer pourquoi la vitesse est si importante en développement logiciel. Je ne prétends pas forcément avoir raison, ni m’appuyer sur des données solides, et mes définitions sont peut-être discutables. Disons d’abord qu’un « logiciel trivial » est un logiciel dont tout le monde comprend clairement la valeur et la solution, qu’on peut valider automatiquement, ou pour lequel il n’existe qu’une seule manière de l’implémenter. Or, dans la réalité, la plupart des logiciels ne sont pas triviaux. On y trouve toujours des bugs, des besoins manquants, des abstractions qui fuient, des fonctionnalités inutiles, des problèmes d’intégration, des soucis de performance, des failles de sécurité, de la complexité et des problèmes de maintenance. Peu importe à quel point le développeur est bon ou le code bien écrit, ces problèmes sont inévitables. Et ils ne se révèlent et ne s’améliorent que par des boucles répétées de feedback, d’usage réel, de maintenance et d’expérimentations. En d’autres termes, on ne peut pas produire un logiciel parfait d’un coup ; sa qualité progresse à travers les itérations. La qualité globale d’un logiciel dépend donc de la quantité de « feedback loops » qu’on peut faire. Et le temps nécessaire pour boucler une seule itération limite mécaniquement le nombre total d’itérations possibles. Au final, plus la vitesse de production est élevée, plus on peut vivre de boucles de feedback, et plus on a de chances d’aboutir à un meilleur logiciel. Un code lent mais de haute qualité reste limité s’il ne bénéficie que d’une seule itération ; à l’inverse, même un code médiocre peut converger vers un meilleur résultat s’il passe par un très grand nombre d’itérations.
  • Dans cinq ans, on verra peut-être ça comme l’un des plus grands cas d’erreur des coûts irrécupérables au monde.
• Je pense qu’« agentic coding » ou « agentic software engineering » est un terme plus approprié que « vibe coding ». Mon flux de développement commence avec un plan de code généré par Claude, et la première étape est toujours de produire une spécification claire. J’utilise le TDD et je fais aussi respecter via des outils automatisés des règles de qualité de code que j’ai définies. Par exemple, un commit est bloqué si le code ne respecte pas le design system, et j’automatise aussi la vérification de la séparation des couches pour imposer que les handlers HTTP passent obligatoirement par la couche service. Je rappelle régulièrement au modèle de bien respecter le TDD, et Claude 4.5 s’en souvient bien mieux que 4.1. Grâce à cette base TDD, la revue de code des PR est devenue extrêmement facile. J’ai aussi créé un petit outil qui envoie la PR et la spec à Gemini pour qu’il signale automatiquement les incohérences, les oublis et les erreurs. C’est un très bon outil de secours. Mais au final, ce qui compte surtout, c’est la capacité à savoir quel résultat on veut et à détecter soi-même quand l’agent s’en écarte. En fin de compte, c’est toujours « garbage in, garbage out » : entrée de mauvaise qualité, sortie de mauvaise qualité ; entrée de bonne qualité, sortie de bonne qualité.
  • Tu dis que tu rappelles le TDD au modèle, mais dans la pratique, est-ce qu’en vibe coding l’agent suit réellement de façon répétée la boucle red-green-refactor du TDD ? Ou bien est-ce qu’il produit plutôt le résultat final d’un seul bloc ?
  • À la place de cette appellation basée sur le mot vibe, je trouve que « slop-coding » serait plus approprié.
• Je me demande si le terme « vibe engineering » est vraiment juste. En réalité, on impose toutes sortes de contraintes à l’agent : tests automatisés, planification en amont, documentation détaillée, formatage/lint du code, QA manuelle, etc. Moi aussi, après avoir lu le billet de Karpathy, j’ai essayé le vibe coding, et j’ai effectivement connu cette sensation de relancer encore et encore même quand le code se bloque, en faisant confiance au processus global. Mais avec l’expérience, j’ai fini par comprendre qu’il fallait en réalité contrôler le modèle. Faire tourner des agents ressemble un peu au karting : il faut des barrières tout autour de la piste, comme les pneus qui empêchent de sortir. Le cœur du sujet, c’est le Constraint Harness ; le code lui-même devient facile à générer et régénérer. À l’avenir, l’essentiel sera de bien construire des tests et des contraintes autour des productions de l’IA.
  • Le terme « vibe engineering » est trop léger et ne fait pas sérieux. Un terme plus neutre et descriptif comme « LLM-assisted programming » serait sans doute meilleur, même s’il est moins percutant.
• « Planification en amont » pourrait aussi se dire spec-driven development. D’une certaine manière, tout développement repose de toute façon sur des spécifications préalables. Mais le vrai cœur du sujet, c’est une « forme de management très étrange » : donner des consignes claires, un contexte suffisant et un feedback exploitable. Vu sous cet angle, ça ressemble presque plus au waterfall qu’à l’agile.
• J’ai l’impression que le terme vibe-coding a maintenant glissé pour désigner l’ensemble du codage assisté par IA. De fait, quand je travaille avec une IA, ça ressemble davantage à du pair programming, et j’ai vraiment l’impression d’être « en train de viber ». Cela dit, le vibe-coding originel, au sens de « Take the wheel, LLama of God », c’est-à-dire tout déléguer sans réfléchir, va probablement continuer d’exister fréquemment, donc je pense qu’il faudrait un mot distinct pour ça. J’aimerais proposer « Yolo-Coding », ça s’insère bien dans la lignée no-code, low-code, yolo-code.
  • À mon avis, il vaut mieux que vibe coder conserve une image négative, un peu comme no-code. Je n’aime pas beaucoup le terme vibe engineer, mais quoi qu’il en soit, le mot même d’ingénieur ou de développeur impliquera sans doute bientôt par défaut l’usage d’agents, et le développement « manuel » deviendra peut-être l’exception.
  • Chez $enterprise, en cherchant un terme qui distingue « responsible vibing » de « YOLO vibe coding », on a fini par arriver à « agent assisted coding ». Il nous fallait absolument un acronyme en trois lettres.
  • Le sens originel de « vibe coding », comme dans le post d’Ilya Sutskever sur Twitter, c’est simplement de saisir un prompt, puis de copier-coller et exécuter le résultat sans aucune revue. Sans analyse ni validation.
  • Personnellement, je vois l’AI-assisted coding plutôt comme de l’autocomplétion ou une aide pour lire une documentation peu claire, alors que le vibe coding, c’est :
  • le développeur ne comprend absolument pas le code écrit par le LLM
  • la dette technique apparaît immédiatement faute de revue de code
  • juridiquement, c’est extrêmement vulnérable dans l’UE et aux États-Unis à cause des questions de protection du copyright À mon sens, le plus gros point faible du vibe coding, c’est que le code produit par un LLM n’est fondamentalement ni protégeable ni enregistrable au titre du copyright. Il existe quelques exceptions, comme le Royaume-Uni, mais dans la plupart des pays, c’est sans issue.
  • Moi aussi, j’ai créé une commande slash du type /yolo dans Claude pour qu’il exécute des choses sans quasiment aucune consigne.
• Il existe une expérience où des pigeons interagissent avec un dispositif qui distribue de la nourriture de façon aléatoire, et comme ils croient être récompensés grâce à leur propre comportement, ils se mettent à répéter toutes sortes de danses et de gestes amusants.
  • Et si cette danse amusante, c’était justement quelque chose comme « écrire des tests » ou « faire des plans » ?
  • Quelqu’un aurait-il une référence, par exemple un article scientifique ? Si je cherche « pigeon mignon », je ne tombe que sur des vidéos des réseaux sociaux, donc c’est difficile à retrouver.
• « Augmented Engineering » (AE) est un meilleur nom. Puisqu’on peut étendre ses capacités grâce à la puissance de l’IA et obtenir les meilleurs résultats, c’est bien de l’« ingénierie augmentée ». AE peut aussi se comprendre comme « Advanced Engineering ». Comme l’IA donne immédiatement accès aux connaissances techniques les plus récentes, c’est forcément une ingénierie plus avancée. À l’inverse, vibe n’est pas terrible.
  • Il n’y a pas besoin de s’obséder sur la terminologie, et créer un nom à part pourrait même donner l’impression que le codage avec l’IA ne concerne qu’une partie des développeurs. À l’avenir, le codage traditionnel deviendra plutôt l’exception, et le mot vibe lui-même disparaîtra sans doute bientôt.
  • J’ai une objection à la dernière phrase : l’IA ne donne pas seulement un accès immédiat aux connaissances d’ingénierie les plus récentes, elle peut aussi absorber « instantanément » les erreurs, bugs, malentendus et défauts de conception accumulés ces 1 à 10 dernières années. En d’autres termes, il ne faut jamais faire une confiance aveugle aux informations fournies par l’IA ; il faut toujours vérifier les sources, et même vérifier que ces sources n’ont pas elles-mêmes été générées par une IA. Avec la contamination croissante des datasets, il faut être encore plus prudent.
  • J’aimerais demander si « Augmented Engineering » a vraiment besoin d’être un nom distinct. Au fond, c’est juste de l’« engineering ». Ce n’est pas parce qu’on s’aide d’un livre qu’on parle de « book-assisted engineering », donc pour vibe c’est pareil. On pourrait tout aussi bien dire « Yolo engineering », ou encore « Machine Outsourced Irresponsible LMAO Engineering », si on veut. Et le « Advanced Engineering » de la fin me paraît aussi relever de l’emphase.
• Simon met toujours très bien le doigt sur l’essentiel. Mais le vrai problème, ce n’est pas tant « coding » que le mot « vibe ». Même en disant vibe engineering, on garde cette nuance de « faire les choses à l’aveugle sans vraiment savoir ce qu’on fait ». Un terme comme « AI-assisted software engineering », qui distingue plus clairement les deux extrémités du spectre, me paraît quand même meilleur.

[kimjoin2]

Créer des appellations dénuées de sens ;