-
Avec l’annonce par GitHub et Microsoft de la preview publique de GitHub Copilot Agent, un test a effectivement été mené dans le dépôt .NET Runtime où cet agent génère automatiquement des PR
-
Mais ces PR contiennent des modifications médiocres ou inutiles, mettant les relecteurs en difficulté, tandis que les utilisateurs de Reddit y voient une scène à la fois absurde et triste
-
Exemples de PR :
- PR #115762 – ajout d’une vérification de
nullencore une fois dans un code où elle est déjà faite dans l’appel àstring.Concat - PR #115743 – proposition d’un refactoring d’une condition sans aucun effet
- PR #115733, PR #115732, etc. s’inscrivent dans le même registre
- PR #115762 – ajout d’une vérification de
-
L’auteur explique que « si c’est ça l’avenir du secteur, je suis prêt à descendre », exprimant ainsi sa fatigue et son scepticisme face à l’adoption de l’IA
-
Mais il souligne aussi qu’il éprouve de la compassion pour les employés chargés de la revue, ajoutant que cette situation vient probablement de la pression liée à une consigne venue d’en haut pour adopter Copilot
Mon « schadenfreude (joie mauvaise) » vise les dirigeants de Microsoft qui alimentent le battage autour de l’IA. Respectez les développeurs.
- schadenfreude est un mot d’origine allemande qui signifie littéralement « le plaisir tiré d’un tort ». Autrement dit, « le sentiment secrètement agréable ressenti face au malheur d’autrui »
Résumé des principaux commentaires
1. Les PR écrites par l’IA sont imprécises et se contentent de “deviner” sans comprendre le contexte
- Elle propose des changements sans comprendre ce que fait réellement le code de la PR
- Corrections d’erreurs répétées → code toujours faux → nouvelle correction d’erreur… une boucle sans fin
- « Je l’ai corrigé » → « C’est encore faux » → « Cette fois c’est vraiment corrigé »… certains y voient un schéma de junior dev
2. Sur les problèmes complexes, cela fait au contraire perdre plus de temps
- Utile pour des corrections simples, mais inutile sur les vrais problèmes complexes sur lesquels on voudrait réellement gagner du temps
- Comprendre le problème → comprendre Copilot → comparer → vérifier → intervention manuelle nécessaire
- En pratique, le résoudre soi-même est plus rapide
3. Le “solutionnisme IA” des dirigeants éloigne les développeurs
- Le message « avec Copilot on ne sera pas à la traîne » est déconnecté du vécu des développeurs de terrain
- Le temps passé à relire les PR s’allonge, et la responsabilité est renvoyée vers les développeurs
- Inquiétude autour d’une « boucle d’apprentissage de l’IA pour l’IA », où une IA entraînée sur du code produit par Copilot dégraderait encore la qualité du code
4. L’IA ne fait que produire des “mauvaises réponses” avec assurance, sans jamais se dire “c’est correct tel quel”
- Même après un retour disant que c’est faux, elle répond « C’est corrigé ! » → puis propose une modification encore plus étrange
- Elle ne conclut jamais « ce code est correct, il n’y a rien à modifier »
- Certains avancent que cela pourrait être un choix de conception visant à éviter une responsabilité juridique
5. La pression continue pour imposer l’IA dégrade l’expérience des développeurs
- Les expérimentations d’adoption de l’IA continuent à cause des consignes managériales ou des évaluations de performance
- Les développeurs disent se sentir réduits au rôle de baby-sitter de l’IA
- Certains prédisent même que si cette tendance continue, « les développeurs quitteront le secteur, épuisés par l’IA »
Phrases marquantes
- « L’IA ressemble à un stagiaire qui répète des suppositions erronées tout en étant convaincu d’avoir raison »
- « Plutôt que de passer du temps à relire le code de Copilot, autant le réécrire moi-même »
- « C’est une situation de “reverse centaurs”, où le développeur aide la machine »
- Terme employé par Cory Doctorow pour dire que « nous ne sommes pas des humains aidés par des machines, mais des humains forcés d’aider les machines »
- « Copilot, c’est comme si un développeur posait des rustines bancales, sauf que c’est automatisé, donc ça devient des milliers de rustines pénibles »
- « On dirait que le réglage par défaut des LLM, c’est : “je peux me tromper, mais je ne doute jamais” »
12 commentaires
La productivité a beaucoup augmenté avec un workflow asynchrone où on soumet un problème et, si la réponse est fausse, on l’écarte, mais est-ce que ce n’est pas similaire à un outil statique ? Si on le considère comme un outil d’analyse statique très évolué, c’est un bon allié. Honnêtement, il analyse vite et en sait plus que beaucoup d’ingénieurs junior.
J’utilise l’IA, mais elle est tellement bête que si on ne corrige pas immédiatement le tir, elle n’arrive pas à implémenter correctement les choses. Quand je vois du vibe coding, ce n’est que du code truffé d’erreurs…
Chaque fois que j’utilise un LLM, j’ai ce genre d’expérience. Même si je signale à l’infini ce qu’il n’arrive pas à faire, il continue à ne pas y arriver.
Au final, j’en ai marre et je finis par l’analyser et le corriger moi-même. Quand ce genre d’expériences s’accumule, on en vient à trouver que les LLM et tout le reste ne sont que des déchets, et à ne plus avoir envie de les utiliser.
Ça me fait penser à un webtoon où l’IA fait du prompt inversé pour que les humains codent.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
J’ai vraiment l’impression que ce problème continuera de se produire tant que l’IA ne résoudra pas les problèmes et n’apprendra pas en même temps, comme le ferait un humain.
Tant que l’on respecte bien les délais et les exigences, au moment de coder, qu’on ait utilisé l’IA ou qu’on ait joué les durs en n’utilisant même pas d’IDE et seulement le Bloc-notes, ce n’est pas très important.
Quand je considérais ça comme une simple nouvelle technologie, je ne la regardais qu’avec une curiosité mêlée d’intérêt,
mais maintenant que des employeurs s’en servent réellement pour procéder à des embauches et à des baisses de salaire, je ne me sens pas vraiment bien à ce sujet..
J’ai l’impression qu’on est encore dans une phase de transition, donc toutes sortes de péripéties continuent de se produire.
Ça pourrait s’améliorer à l’avenir, ou rester comme ça durablement, donc ce sera intéressant de voir comment tout cela évolue, haha.
J’utilise Gemini sur GitHub pour faire relire des PR, et ça m’arrive assez souvent exactement ce genre de cas.
Par exemple, il me dit d’ajouter exactement la ligne juste au-dessus en prétendant que j’utilise une valeur sans vérification de
null, alors qu’il y a déjà une vérification denullà la ligne juste au-dessus.On ne peut pas forcément tout écrire dans un prompt — les connaissances de contexte qu’une personne acquiert naturellement en travaillant, les habitudes de travail, les résultats attendus et leur format.
Et même si c’était possible, je me dis aussi qu’au lieu de recourir à une IA complexe comme un LLM, il serait peut-être plus réaliste d’automatiser cela avec des algorithmes traditionnels d’avant le deep learning.
À l’usage, le vibe coding et les agents de codage ont clairement des côtés pratiques, mais pour que ce soit vraiment pratique, il faut envoyer des prompts extrêmement précis, et selon la nature du projet, il y en a beaucoup pour lesquels ça ne fonctionne pas très bien dès le départ. Quand les fonctionnalités sont proprement découpées en petits morceaux simples, comme sur un serveur web en architecture MSA, ça travaille bien, mais si on essaie de corriger avec l’IA des modules imbriqués dans un gros monolithe, avec beaucoup de dépendances et une logique complexe, il faut établir un plan de tâches très rigoureux et envoyer des prompts très soignés.
Avis Hacker News
Partage d’un constat assez fascinant : tous les commentaires sont accompagnés du message « Help improve Copilot by leaving feedback using the or buttons », mais personne n’a jamais vu de véritable feedback y être associé ; retour d’expérience selon lequel ce genre de situation arrive souvent quand la configuration du prompt système est ratée lors de l’usage d’un LLM ; exemple de PR le plus absurde : pour « corriger » un échec de test, supprimer carrément les cas de test, les commenter, ou simplement modifier l’assertion ; supposition selon laquelle les modèles de Google et de Microsoft montrent ce type de comportement plus souvent que ceux d’OpenAI et d’Anthropic, avec l’impression que les différences de processus internes entre entreprises se reflètent dans les résultats ; description d’un vrai PR où un humain a dû signaler le problème trois fois de plus avant d’abandonner ; difficile même d’imaginer l’état d’esprit de ceux qui doivent relire ces PR, comme s’ils géraient un développeur junior qui n’écoute pas, sauf qu’ici il n’y a carrément aucune compréhension du contexte ; exemple d’un PR dont 90 % est rempli de « Check failure », au point de rendre difficile toute vérification du code ou des différences, et tristesse de voir un test unitaire résumé à « Test expressions mentioned in the issue » ; avis honnête que tout cela serait vraiment drôle si ce n’était pas aussi pénible pour les humains
La comparaison avec un développeur junior est bien trop exagérée ; je travaille moi aussi avec des juniors, mais ils ne font pas aussi souvent des erreurs bizarres qu’un LLM, ne demandent pas autant d’efforts, et apprennent vite ; un LLM est un outil d’assistance correct s’il est utilisé avec prudence, il peut aider à aller plus vite et faire un bon partenaire de brainstorming, mais il ne peut pas remplacer un stagiaire ni un vrai développeur
Quand je suis entré dans le software engineering à la fin des années 80, il y avait du plaisir ; aujourd’hui, entre les processus d’entretien, les PME qui imitent la big tech et maintenant ces expériences de PR par IA, l’environnement est devenu toxique ; sentiment sceptique sur le fait qu’il reste encore de la joie dans le métier de développeur professionnel
Au moins, à un junior, on peut dire de lancer les tests en local avant d’envoyer un PR ; crainte qu’à un moment les développeurs humains finissent simplement par abandonner et fermer les PR de « déchets IA », en ne gardant que ce qui fonctionne ; impression qu’à force d’endurer les expérimentations des machines, tout le monde finira épuisé et laissera tomber
Doute sur l’utilité même d’un système de feedback dédié ; du point de vue du développement, le succès, c’est un PR mergé du premier coup, et l’échec peut se mesurer à la dégradation accumulée au fil des corrections demandées à l’agent ; demander un feedback manuel est inefficace, et il vaudrait mieux mesurer les performances comme pour les développeurs : cycle time, taux d’approbation, taux d’échec des changements
Partage d’une expérience où parler au support Microsoft donnait l’impression de parler à un mur ; malgré plusieurs tickets, rien n’a jamais été résolu de façon satisfaisante ; je comprends que Microsoft veuille utiliser ses propres technologies, mais qu’ils ne me l’imposent pas ; souhait que Microsoft ne lance pas de produits pour lesquels le support n’est pas prêt
Expérience récente de visionnage d’une vidéo où Eric de Google parle d’IA ; il affirme que l’IA est actuellement sous-estimée ; citation de son insistance sur le fait qu’il « n’est pas expert » en expliquant pourquoi il a acheté une entreprise de fusées et en se lançant dans des domaines non spécialisés avec l’IA, comme Deep Research ; personnellement, je ne déteste pas l’IA, mais l’IA générative actuelle fondée sur la reconstitution de motifs excelle surtout à provoquer l’émerveillement des débutants ; sans connaissance du domaine, le résultat paraît impressionnant, mais dès qu’on creuse un peu, on est vite déçu par les failles ; les gens en première ligne, comme chez Microsoft, voient très clairement le problème, mais les dirigeants — surtout des profils comme Eric — ont le défaut de se laisser facilement berner par une IA qui parle avec assurance ; espoir qu’un jour l’IA puisse écrire directement du code qui fonctionne vraiment, mais conviction que ce jour est encore loin
Façon personnelle d’utiliser l’IA avec beaucoup de prudence et de manière très limitée ; à l’inverse, ces milliardaires qui « ont acheté une entreprise de fusées » s’enthousiasment pour l’IA et l’utilisent même dans des décisions d’investissement destinées à accroître encore leur fortune ; même en cas de gros échec, ils ne perdront au fond qu’un simple accessoire, sans impact réel sur leur position sociale ; alors que sur le terrain, les emplois IT risquent de subir de mauvaises conséquences dans tous les cas
Avec des dirigeants non experts qui s’émerveillent facilement devant l’IA, on imagine ce qui pourrait arriver si Google collaborait avec l’armée américaine pour équiper des drones autonomes à grande échelle de Gemini
Difficile de voir quelle confiance cela peut inspirer aux entreprises qui ont bâti des produits sur .NET de regarder des employés Microsoft passer des heures à se disputer avec un LLM au lieu de résoudre de vrais problèmes
Avant même l’arrivée des LLM, on voyait déjà sur GitHub des utilisateurs incapables de bien décrire leur problème et des mainteneurs devenir de plus en plus irrités ; maintenant, on n’a même plus besoin de l’utilisateur final énervé
En réalité, ce résultat est la conséquence naturelle d’un management médiocre et de consignes bancales ; cette fois, impossible de tout mettre sur le dos des juniors, il ne reste plus qu’à s’en prendre à soi-même
Insistance sur la douleur particulière ressentie quand même Stephen Toub, connu pour son célèbre blog sur les performances .NET, participe à ce genre de processus
Je ne veux pas empêcher qu’on expérimente ce type de nouvelles technologies, la différence est simplement qu’ici l’expérimentation est rendue publique pour tout le monde
Argument cynique selon lequel Microsoft a depuis longtemps une culture du « ignore juste l’erreur » et du passage en Will Not Fix pour flatter l’ego des responsables, et qu’ils ont donc eux-mêmes préparé le terrain à tout ce qui se passe aujourd’hui
Explication du contexte à partir du commentaire posté sur le premier PR : ils essaient, via diverses expérimentations, de comprendre les limites de l’outil et de se préparer à l’avenir ; la responsabilité du merge reste, comme pour tout autre PR, entre les mains des mainteneurs ; rien ne sera mergé tant que les critères de qualité ne seront pas remplis
L’employé Microsoft auteur de ce commentaire défend aussi l’idée que ne pas réfléchir à l’usage de l’IA, c’est risquer d’être largué ; sentiment qu’il règne chez Microsoft une atmosphère d’anxiété et d’excitation face à l’idée que l’IA bouleverse complètement l’industrie du software engineering ; comme cette expérimentation ressemble moins à une évaluation raisonnée des limites de l’outil qu’à une participation forcée pour protéger son emploi, cela réduit au contraire la confiance
Il faut comprendre que les responsables n’ont pas déjà arrêté un verdict sur les capacités du modèle, et qu’il s’agit d’une expérimentation raisonnable visant à identifier ses points forts et faibles dans un contexte réel
Le simple fait d’assigner à quelqu’un un PR qui n’a même pas passé la CI semble étrange ; au minimum, seuls les PR validés devraient être assignés ; impression d’un système tellement mal conçu qu’il n’est même pas capable de ça ; cynisme disant que si ça fonctionnait correctement, ce serait le strict minimum
Souhait qu’on n’interprète pas chaque situation sous son angle le plus catastrophique ; en pratique, les humains concernés savent probablement qu’il s’agit d’une expérimentation et ont ajusté leurs attentes ; sans ce type d’approche expérimentale, il est difficile de faire progresser le système, donc il est possible qu’ils soient simplement en train de le régler et de le tester en conditions réelles ; dans mon entreprise aussi, nous avons fait exactement la même chose au début de l’adoption d’outils d’assistance au code par IA, et la qualité du code était pire que lorsque les humains codent directement, mais nous avons beaucoup appris grâce à ce processus ; le fait d’avoir un point de référence permettait de suivre clairement l’évolution
Un commentaire expliquait qu’à cause d’un problème de firewall, ils ne pouvaient pas vérifier si les tests passaient, et qu’une fois ce problème résolu, le fonctionnement redeviendrait normal
Même en remplaçant les agents IA par une autre nouvelle technologie, on retrouve le portrait typique de ce genre d’entreprise : expérimenter ouvertement (dogfooding façon big tech), contribuer réellement au progrès technique du secteur, et limiter les dégâts éventuels à l’équipe interne ; question posée : y a-t-il vraiment une raison de ne pas soutenir ce type d’expérimentation ?
Étonnement devant l’ambiance où ces expérimentations ouvertes ne suscitent que des critiques ; je trouve bien plus utile de montrer de façon transparente les capacités réelles au lieu de cacher cela dans un fork privé, et c’est préférable au baratin du sales et du marketing
Le fait de mener ce type d’expérimentation dans un framework d’infrastructure central au développement logiciel reste discutable
Pourquoi « nous » devrions-nous soutenir ou non soutenir cela, et selon quels critères ? Personnellement, voir MS échouer de façon théâtrale me fait simplement rire
Difficile d’y voir un véritable « progrès » ; exposer publiquement les problèmes du système sans POC interne préalable paraît plutôt irresponsable ; incompréhension sur le fait de ne pas avoir d’abord validé des bases comme l’environnement, le firewall, ou testé cela sur d’autres codebases internes ; le code d’infrastructure exige des standards élevés, donc même au nom du dogfooding il aurait fallu commencer par des projets de moindre importance ; critique disant que ce n’est même pas du state of the art, avec un résultat bien trop grossier au regard des moyens investis
Il est problématique de faire ce genre d’expérimentation sur un projet populaire dont dépendent d’innombrables développeurs ; crainte d’une baisse de qualité causée par du mauvais code généré par IA, du code inutile qui s’accumule, ou d’une productivité de l’équipe rongée par la charge supplémentaire
Si l’on veut une soumission passive à quelque chose, il suffirait d’approuver toutes les demandes sans les relire, puis, si la stack technologique de Microsoft s’effondre mondialement, de démissionner à ce moment-là pour devenir consultant avec un salaire trois fois plus élevé : proposition ironique
Je n’aimerais pas travailler avec une attitude aussi sarcastique ; je ne comprends pas cette logique hostile en mode « nous contre eux » vis-à-vis de la direction, ni cette approche consistant à saboter volontairement ; se plaindre des imperfections ne veut pas dire qu’on doive gêner ou attaquer toute l’organisation, et ce n’est pas compatible avec ma conscience
Réponse cynique disant qu’en réalité la stack de Microsoft est déjà foutue (?)
Remarque soulignant qu’en pratique, le PR généré par Copilot a été soumis directement par les responsables eux-mêmes
Blague disant qu’un jour Copilot réécrira toute la codebase, et que s’il n’y a plus de code, il n’y aura plus non plus d’échecs de tests
Avis qu’il n’y a pas de raison d’être loyal envers ce type d’organisation quand on peut être licencié à tout moment, comme la personne qui a porté le compilateur TypeScript en Go
Ouvrir un PR reste au moins une façon sûre d’expérimenter : si c’est inutile, on peut l’abandonner immédiatement ; toute tentative nouvelle implique toujours des tâtonnements et des échecs, mais cette expérience en elle-même compte ; l’espoir est qu’en entraînant durement l’outil sur du vrai code et de vrais problèmes, il progresse vite ; par exemple, on peut imaginer à l’avenir des améliorations comme une boucle d’apprentissage répétée jusqu’au passage des tests, ou des garde-fous empêchant la suppression des tests ; vision finale d’un futur où l’IA prendra en charge les tâches répétitives et simples du développement, laissant aux développeurs le travail essentiel et créatif
Mais ce type d’expérimentation serait plus sûr dans un fork privé que dans un dépôt public ; doute sur le fait que ce soit une bonne décision de laisser de tels exemples visibles du point de vue commercial ; lorsqu’un décideur interne voit Copilot dans un magazine et veut lancer la même chose, ce genre de cas réel peut au moins servir de référence ; la plupart des entreprises ont plutôt tendance à cacher autant que possible les cas de défauts applicatifs, et à ne montrer qu’une image très aboutie
Des problèmes invisibles peuvent se cacher même dans des PR qui paraissent corrects en surface, ce qui les rend encore plus dangereux
Retour d’expérience selon lequel faire de la revue de code IA est encore plus agaçant que les tâches répétitives simples, surtout quand des bugs y sont cachés et que le développeur doit faire encore plus d’efforts
Le simple fait d’ouvrir un PR ajoute déjà de la charge et de la complexité à la gestion du projet ; faire les expérimentations dans un fork séparé laisserait un meilleur exemple à la communauté ; beaucoup de projets open source finissent épuisés par la gestion de PR accumulés, au point d’être abandonnés, ou survivent via un fork qui ne récupère que les PR encore valables ; inquiétude que cette manière de faire multiplie les projets abandonnés et les forks
Si l’on croit vraiment qu’un LLM peut apprendre à coder correctement tout en restant bogué, alors il faudra ensuite constituer un dataset presque sans bugs ; dans la réalité, on n’en prend pas le chemin, on se contente plutôt de tout aspirer sans tri
GitHub a dépensé des milliards de dollars pour construire une IA qui échoue souvent même sur des vérifications de lint d’espaces dans l’un des dépôts les plus mûrs du monde ; si c’était une expérience de hobby, passe encore, mais le vendre au prix fort comme un « produit révolutionnaire » pose problème
Pour un chercheur, c’est évidemment une expérimentation naturelle ; le vrai problème, c’est l’attitude de l’entreprise qui commercialise immédiatement cet état inachevé
Blague sur l’ancien CEO Nat Friedman : « il doit être mort… ah non, il est encore vivant »
Le vrai problème serait l’absence de métriques objectives pour mesurer la performance des développeurs logiciel ; on reste dans des évaluations subjectives, comme les bilans de fin d’année ; il est donc difficile de savoir si l’usage de l’IA est réellement efficace ou inefficace ; cela paraît moins cher qu’un junior, mais entre le temps perdu par les seniors et les instructions non respectées, la réalité est floue ; combiné au culte du CEO, cela aggrave encore les désaccords internes ; les objections des développeurs sont écartées comme une « peur d’être remplacés », tandis que le camp du CEO maximise les signes de réussite ; comme il n’existe pas de standard industriel accepté par tous, il devient impossible d’établir la vérité ; en poussant le raisonnement à l’extrême, on pourrait même exiger de baisser les critères de review pour augmenter le nombre de PR IA dans l’organisation