Claude a-t-il augmenté le nombre de bugs de rsync ?

• Les versions avec assistance de Claude ne sont qu’au nombre de deux, rsync v3.4.2 et v3.4.3, et rien n’indique qu’elles comportent anormalement plus de bugs que les versions passées selon le critère des bugs pondérés par gravité pour 10 commits
• sev/10c est l’indicateur central : il normalise le score de gravité des bugs sur une échelle de 0 à 1, additionne ces valeurs par version, puis divise par le nombre de commits avant de ramener le résultat à 10 commits
• v3.4.2 compte 50 commits, 9 commits Claude, 0 bug et 0.00 sev/10c ; v3.4.3 compte 34 commits, 28 commits Claude, 17 bugs et 3.29 sev/10c, les deux encadrant l’IQR sans qu’aucune ne soit une valeur aberrante
• La p-valeur du test exact par permutation est de 46 %, celle du test exact de Fisher de 74 %, avec un odds ratio de 1.06 : il y a donc très peu d’indices que les versions Claude soient pires que deux versions aléatoires ou aient davantage de chances de dépasser la médiane
• v3.4.1 est une version antérieure à l’introduction de Claude, mais c’était déjà la pire de tout l’ensemble de données avec 59 bugs, 9 commits et 39.39 sev/10c ; le cœur de la controverse autour de rsync vient du fait qu’une régression isolée a été liée à Claude sans tenir compte de la distribution historique

---

Contexte et question

• Fin mai 2026, la controverse autour de rsync a commencé avec un post Mastodon reliant la régression de v3.4.3 et les commits Claude de cette version ; elle s’est ensuite propagée à Hacker News et à l’issue GitHub "Please Do Not Vibe Fuck Up This Software", qui a accumulé plus de 300 commentaires
• La thèse centrale répétée était que le développement assisté par Claude avait introduit des bugs dans un outil jusque-là stable ; la question de données est donc de savoir si les versions assistées par Claude ont anormalement plus de bugs que les versions historiques
• Sur Lobsters, certains ont demandé un graphique temporel du nombre de régressions par version, et l’analyse se concentre sur une seule question : « Les versions assistées par Claude ont-elles inhabituellement beaucoup de bugs ? »

Périmètre des données et reproductibilité

• Les données couvrent 36 versions de RsyncProject/rsync, de v2.4.6 à v3.4.3, pour lesquelles des données de bugs existent ; seules deux versions contiennent des commits Claude : v3.4.2 et v3.4.3
• Le choix des métriques, de la méthodologie et des sources de données a été fait manuellement, avec l’appui des conseils d’une conjointe titulaire d’un master en statistiques
• La collecte des données, le chargement dans DuckDB, la création de vues et les scripts d’analyse statistique ont été produits par GLM 5.1, mais tous les chiffres, statistiques, tableaux et graphiques ont été insérés automatiquement par le script Python qui exécute l’analyse statistique
• Le dépôt de reproduction alexispurslane/rsync-analysis permet d’exécuter toute la chaîne de traitement de bout en bout

Métrique et attribution des bugs

• La métrique clé est le nombre de bugs pondérés par gravité pour 10 commits, sev/10c, calculé ainsi : sev/10c = (Σ severity/100 ÷ total_commits) × 10
• Les commits sont triés selon la date de commit sur la branche principale, et chaque intervalle de version va du tag précédent jusqu’au tag courant ; les tags pre et rc sont exclus des bornes et absorbés dans la version finale
• Les bugs proviennent de trois sources : les issues GitHub, le Bugzilla de rsync et la mailing list rsync ; les bugs issus des issues GitHub et de la mailing list sont attribués à la dernière version publiée juste avant leur signalement
• Pour Bugzilla, le champ « Version » indique explicitement la version dans laquelle le bug a été signalé, et le bug lui est donc attribué
• L’analyse au niveau des versions a été retenue parce que la critique elle-même prend la forme « les versions contenant des commits Claude sont globalement devenues plus boguées », et parce que la plupart des bugs ne précisent pas de quel commit exact ils proviennent

Méthode d’évaluation de la gravité

• Tous les rapports de bugs ont été notés sur une échelle de gravité de 0 à 100 par Qwen 3 35B, avec un prompt lui assignant le rôle d’un ingénieur senior en fiabilité évaluant l’impact réel sur les utilisateurs
• Les scores de 90 à 100 correspondent à une corruption silencieuse de données, une perte de données, une exécution de code à distance ou des vulnérabilités de sécurité donnant un accès non autorisé ; les scores de 70 à 89 à des crashs, des blocages, des échecs de sauvegarde ou de build ; les scores de 50 à 69 à des régressions fonctionnelles contournables
• Pour Bugzilla et la mailing list, seul le titre était disponible sans corps de message ; le modèle a donc évalué à partir du seul titre, avec instruction de se rabattre vers la zone médiane 40–60 en cas d’informations insuffisantes
• La sortie utilisait une structured output avec schéma JSON n’autorisant qu’une gravité entière, et la température était fixée à 0 afin qu’une même entrée produise toujours le même score
• Les issues notées 0, comme les demandes de fonctionnalité, le spam, les protestations non techniques liées à l’IA ou les soumissions vides, sont exclues du décompte de base des bugs

Résultats statistiques pour les versions Claude

• v3.4.2 comporte 9 commits Claude sur 50 commits, 0 bug réel, 0.00 sev/10c et se situe au 0e percentile
• v3.4.3 comporte 28 commits Claude sur 34 commits, 17 bugs, 3.29 sev/10c et se situe au 77e percentile
• L’IQR historique va de 0.29 à 2.59 sev/10c ; v3.4.2 est juste en dessous et v3.4.3 juste au-dessus, si bien que les deux versions encadrent la distribution centrale chacune d’un côté
• Le test exact par permutation montre que, parmi les 595 combinaisons possibles de 2 versions, 272 ont une moyenne au moins égale à celle du groupe Claude, soit 1.65 sev/10c, ce qui donne une p-valeur de 46 %
• Le test exact de Fisher vérifie si les versions Claude se retrouvent plus souvent au-dessus de la médiane de 0.74 sev/10c ; il donne une p-valeur de 74 % et un odds ratio de 1.06

Nombre de commits et ampleur des changements

• Les versions Claude comptaient en moyenne 42 commits, contre 185 pour les versions sans Claude ; la probabilité que deux versions prises au hasard aient autant ou plus de commits était de 88 %
• D’après l’API GitHub compare, les versions Claude ont modifié en moyenne 3 756 lignes, contre 696 lignes pour les versions sans Claude ; la probabilité que deux versions aléatoires aient autant ou plus de lignes modifiées était de 5 %
• Le nombre de bugs pondérés par gravité était en moyenne de 5,6 pour les versions Claude, contre 14,9 pour les versions sans Claude ; la probabilité que deux versions aléatoires aient autant ou plus de bugs pondérés par gravité était de 77 %
• En conclusion, les versions Claude ont bien eu beaucoup plus de lignes modifiées, mais pas davantage de commits ni davantage de bugs pondérés par gravité

Système de versions et valeurs aberrantes antérieures

• La moyenne des versions v2.x est de 1.11 sev/10c, contre 4.23 sev/10c pour les versions v3.x, ce qui indique un taux de bugs plus élevé du côté de v3.x
• Même en ne comparant que les v3.x, les versions Claude se situent dans le milieu de classement ou mieux ; pour faire apparaître Claude comme une valeur aberrante, il faut comparer à une époque plus calme et attribuer à Claude un changement qui avait déjà eu lieu avant son introduction
• Le test des suites de Wald–Wolfowitz donne, sur 35 versions sans Claude, 13 suites observées contre 18,5 attendues aléatoirement, avec z=-1.88 et p=0.060 ; ce n’est pas suffisamment fort pour rejeter l’hypothèse d’aléa au seuil de 0.05
• v3.4.1, pourtant antérieure à l’introduction de Claude, enregistre le taux de bugs le plus élevé de tout l’ensemble de données, avec 59 bugs, 9 commits et 39.39 sev/10c
• v3.4.1 était une version hotfix sortie le lendemain de v3.4.0, et affichait le taux de bugs le plus élevé de toutes les versions, avec une avance de plus d’un chiffre sur toutes les autres, à une époque où il n’y avait pas d’IA à blâmer

Interprétation et limites

• L’interprétation compatible avec les données est la suivante : « les deux versions Claude actuelles ne sont pas statistiquement distinguables des versions historiques »
• v3.4.3, avec 3.29 sev/10c et un 77e percentile, est élevée mais pas extrême ; 8 versions historiques obtiennent un score supérieur
• L’affirmation selon laquelle « Claude a clairement empiré les choses » n’est étayée ni par la distribution des versions, ni par le test par permutation, ni par le test de Fisher
• À l’inverse, on ne peut pas non plus conclure à partir de ces données que « les commits Claude ne rendront généralement pas les choses pires à l’avenir » ; on peut seulement dire que, pour l’instant, ces deux versions restent dans une plage ordinaire
• Cette métrique a pour limite d’être un outil grossier, incapable de contrôler la complexité des commits ou l’intensité du travail lié à la sécurité

Facteurs de confusion discutés

• Un utilisateur de Hacker News estime que les correctifs de sécurité liés aux CVE ont vraisemblablement révélé des erreurs de code présentes depuis 2007
• Un utilisateur de Lobsters propose la chaîne causale suivante : « LLM → augmentation des problèmes de sécurité connus → besoin de plus de changements que d’habitude → plus de régressions que d’habitude »
• Andrew Tridgell explique qu’un déluge de signalements de CVE générés par IA a imposé des changements rapides et étendus dans la surface d’attaque de rsync
• Si l’on tient compte de ces facteurs de confusion, le problème semble moins venir de Claude lui-même que d’une charge de travail sécurité plus importante et, en conséquence, d’un volume de modifications accru

[GN⁺]

Commentaires Hacker News

• En parcourant les commits, j’ai trouvé le commit d’origine et le commit de revert : https://github.com/RsyncProject/rsync/commit/d046525de39315d...
  Même les chemins qui auraient dû utiliser malloc ont été changés en calloc, comme si toutes les allocations devaient être forcées au motif que calloc serait un sur-ensemble strictement compatible. Sur de grosses allocations ou des allocations récursives, le coût devient assez important. Ça ressemble à un bon exemple du genre de chose qui peut échapper à la vigilance dans du code écrit avec Claude. Le revert est ici : https://github.com/RsyncProject/rsync/commit/7db73ad9a1b8721..., et même en ne lisant qu’à moitié l’explication du revert, on sent la patte d’un LLM. Je comprends bien l’état d’esprit de la personne qui a posté le message d’origine

  • Le nombre de commits lui-même paraît suspect. Sur les deux derniers mois, le nombre de commits intégrés à rsync est comparable à celui des 2 années précédentes, et la plupart sont des commits faits avec Claude. Vu que ce type de changement est entré aussi, ça ressemble au cas typique où l’enthousiasme pour l’IA mène peu à peu à plus de négligence
  • Dire que c’est « écrit avec Claude » n’est pas exact. Le commit de revert renvoie à https://github.com/RsyncProject/rsync/issues/959, et dans cette issue l’auteur explique lui-même que « le changement consistant à mettre la mémoire à 0 était mon idée et ma modification »
    Le rapport de sécurité signalait l’utilisation d’éléments au-delà de la fin d’un tableau, et il estimait qu’initialiser les allocations à 0 augmenterait les chances que des bugs similaires se terminent plus tard par un déréférencement de pointeur null plutôt qu’avec un pointeur valide. Claude n’a servi qu’à organiser un lot de commits, et comme le moindre ajustement ajoute un tag co-authored, cela ne veut pas dire que Claude a écrit la modification. Il précise que le code a bien été écrit par lui
  • Je n’affirmerais pas que c’est Claude qui a pris cette décision. Ce n’est pas un changement annexe glissé discrètement au milieu d’un gros commit ; dès le message de commit, ça commence par « initialiser à 0 toute la mémoire nouvellement allouée », et c’est effectivement ce qui est fait. Je ne vois même pas quel prompt il faudrait imaginer au départ
    Il est tout à fait possible qu’un humain ait d’abord cru à une amélioration, puis ait changé d’avis après avoir constaté une régression RSS. Et il n’existe pas non plus de loi naturelle imposant que ce changement augmente forcément la RSS. calloc peut aussi bénéficier d’un traitement spécial en sachant qu’un nouveau mapping mémoire tout juste fourni par l’OS est déjà initialisé à 0. Si on veut blâmer l’IA ici, ce serait plutôt au sens où l’IA a provoqué une explosion des rapports de vulnérabilité, laquelle a entraîné une explosion des correctifs urgents, et où les correctifs urgents créent parfois d’autres problèmes
  • Une époque formidable : l’IA combinée au overcommit Linux. Personnellement, 10.8GB ce n’est même plus grand-chose aujourd’hui, et le buffer de sprintf est peut-être encore plus gros. Sinon, il devrait l’être ; et si ce n’est pas le cas, il faudrait commencer à utiliser snprintf

• Je recommande de lire le billet mis en lien par l’auteur de rsync avant de commenter : https://medium.com/@tridge60/rsync-and-outrage-d9849599e5a0
  Pour être transparent, je n’ai plus de contact avec Tridge depuis quelques années, mais il a longtemps été un collègue et un mentor. Ça vaut la peine de prendre en compte son point de vue avant de rejoindre la croisade

  • Ça devrait être le commentaire tout en haut. C’est assez triste qu’il ait dû aller jusqu’à écrire un tel billet. Des gens qui ne paient même pas sa facture se permettent énormément de juger
  • Je ne comprends pas complètement la partie disant : « j’ai pensé qu’il valait mieux construire d’abord en public sur master la structure de base de la nouvelle suite de tests ». Si seuls les tests avaient été mis à jour, ou si ça n’avait été poussé que sur master, les gens n’auraient probablement pas été furieux
    Mais il a aussi poussé un changement cassant sur la branche de release. Casser un workflow qui fonctionnait depuis des années est le moyen le plus sûr de mettre les gens en colère, et voir en plus “Claude” dans le commit revient à jeter de l’huile sur le feu
  • Sa réponse me semble être une réaction vraiment très bien rédigée

• Je ne suis pas directement investi dans ce débat, mais certains points paraissent suspects. La release à laquelle on attribue le plus de bugs est celle de janvier, juste avant la première release contenant un commit coécrit par Claude, et je me demande s’il n’est pas possible que des commits écrits par un LLM sans attribution explicite y aient été inclus
  La méthodologie d’attribution aux releases n’est pas très bonne non plus. Les bugs introduits dans une mise à jour de version mineure ont tendance à être attribués à la release patch de cette version mineure qui a vécu le plus longtemps. Il est difficile de croire que 3.4.1 a réellement introduit autant de bugs ; comme elle est sortie le lendemain de 3.4.0, il est très probable que des bugs apparus avec cette release aient été comptabilisés dans 3.4.1. De plus, les releases récentes ont eu moins de temps pour que des bugs soient signalés, ce qui peut aussi introduire un biais faisant paraître les releases récentes moins boguées

  • D’accord. La formule de l’article, « la pire release de l’histoire de rsync date d’avant l’introduction de Claude et personne ne l’avait remarqué », donne moins l’impression que l’auteur est sans intérêt dans ce débat que celle de recouvrir une opinion d’un vernis de jargon statistique
    « Éblouissant de clarté » ? Il suffit de tracer un graphique. Et v3.4.1 date du 2025-01-16, donc elle se situe techniquement déjà dans l’ère du codage assisté par l’IA, avant que l’attribution ne devienne une pratique standard
  • Vu que les releases sont assez peu fréquentes, j’ai commencé à regarder cette partie aussi. Pour éviter le problème des commits LLM non attribués, je pense que l’analyse devrait inclure une comparaison de la gravité des bugs avant et après v3.3.0. La date est le 6 avril 2024
  • On peut utiliser les LLM de plusieurs façons. Cela va d’un humain très impliqué qui ne leur fait faire que des modifications locales à une délégation quasi complète
    J’ai vu beaucoup de code généré par un LLM sans coauteur dans le message de commit. En général, ces tags semblent n’apparaître que lorsque l’interface avec la base de code passe entièrement par des outils comme Claude/Codex, et ces commits sont souvent les plus verbeux tout en disant très peu sur la raison du changement, se contentant surtout de résumer la modification du code. À l’inverse, j’ai aussi vu des développeurs utiliser Claude comme un outil : ils font des allers-retours entre VSCode et le terminal Claude, vérifient eux-mêmes le bon code et ne confient à Claude que le travail de plomberie. L’auteur a peut-être commencé modestement puis augmenté l’usage avec le temps
  • Le premier et le deuxième point semblent se contredire. Si tous les bugs de 3.4.1 devaient être attribués à 3.4.0, alors le moment où des commits LLM non attribués auraient dû entrer dans le projet reculerait encore davantage, ce qui rendrait l’hypothèse encore plus invraisemblable
    Le problème plus important, c’est qu’il n’y a absolument aucune preuve à l’appui de l’hypothèse selon laquelle des commits LLM se seraient glissés discrètement dans des releases antérieures, expliquant ainsi le taux de bugs élevé. À moins de supposer qu’un nombre élevé de bugs signifie automatiquement une intervention de l’IA, il n’y a aucun fondement, et ce serait un raisonnement circulaire. Le troisième point est valable. J’ai analysé en général combien de temps il faut pour trouver les bugs et où chaque version se situe dans le cycle de release ; je peux le publier si ça intéresse
  • Pour commencer par l’erreur la plus grossièrement stupéfiante, les statistiques sur Claude reposent sur deux points de données au total

• Il y a ici une ironie importante au niveau méta. L’article original défend l’usage de l’IA, mais il semble aussi avoir manifestement utilisé l’IA pour analyser les données et présenter les résultats
  Dans ce processus, l’auteur a utilisé des statistiques d’une manière qu’il ne comprend visiblement pas bien, et il en a tiré plusieurs conclusions erronées. On peut voir la discussion associée sur https://news.ycombinator.com/item?id=48417626. En résumé, cette étude manque de puissance statistique et avance une affirmation de « pas de différence » qui n’est pas justifiée. En fin de compte, en utilisant un LLM pour interpréter les données, il a commis le même type d’erreur que celle que l’étude prétendait examiner : affirmer avec assurance quelque chose de faux

  • L’IA ressemble trop à une religion. Quoi qu’on dise à ceux qui y croient, on ne peut pas les amener à remettre leur foi en question. Plus généralement, on ne peut pas convaincre quelqu’un par la raison d’abandonner ce qu’il veut croire

• À mon avis, si des gens en colère à propos de cette affaire font pression sur le mainteneur de rsync, le seul résultat sera d’inciter d’autres personnes à ne plus divulguer de manière responsable leur usage de l’IA. Cela les poussera à désactiver l’attribution à Claude dans les commits pour éviter la controverse

  • Je ne me soucie pas vraiment de la divulgation de l’usage de l’IA. Si je ne connais pas personnellement la personne, je ne pars pas du principe que du code écrit par un humain est forcément meilleur que du code généré par l’IA
    Quoi qu’il en soit, la responsabilité du code qu’on commit et qu’on pousse incombe à l’humain. Cela n’a jamais changé. Qu’il ait été écrit à la main, produit parce qu’un chat a marché sur le clavier, ou généré par l’IA, cela m’est égal. La qualité du code d’un projet peut se dégrader pour toutes sortes de raisons, et se focaliser uniquement sur le fait qu’il ait été généré par l’IA n’est pas productif. Si certains veulent y voir un prétexte pour critiquer l’IA et d’autres veulent la défendre, libre à eux, mais ce n’est pas une bonne manière d’évaluer la qualité du code d’un projet
  • Indépendamment de la controverse, il vaut mieux désactiver ce genre de marquage. Il n’y a aucune raison de faire de la publicité gratuite à des entreprises valant des centaines de milliards. Des trailers comme Generated-by ne sont pertinents que lorsqu’on contribue à des projets tiers, et dans ce cas il est poli de le divulguer
  • Ça sonne comme : « Ne vous fâchez pas contre quelqu’un qui a fait quelque chose de contraire à l’éthique ou d’immoral, sinon il fera quelque chose d’encore plus contraire à l’éthique ou d’immoral ! »
    Désactiver l’attribution de code généré par un LLM, c’est de la fraude. Cela revient à dire qu’on a soi-même écrit le code. Évidemment, c’est assez cohérent avec le fait même de générer du code avec un LLM. En pratique, cela revient à régurgiter des entrées après avoir retiré les licences et mentions de copyright
  • Je ne suis pas sûr que ce soit une mauvaise chose. Du point de vue du service marketing d’Anthropic, peut-être, mais si un agent n’est qu’un outil de plus dans la boîte à outils du développeur, cette attribution paraît un peu étrange. Au final, la responsabilité du commit revient au développeur
  • Cet argument revient à chaque fois, mais je ne le trouve pas convaincant. Il est vrai que signaler publiquement un problème crée une incitation à le cacher, mais je ne vois pas ce que cela est censé impliquer
    En laissant de côté un instant le débat sur le fait que l’IA soit mauvaise ou non, pour prendre une analogie : la fraude fiscale est mauvaise, contraire à l’éthique, et si on la voit, il faut la dénoncer. Le fait que cela crée une incitation à la dissimuler ne mène pas à la conclusion qu’il faudrait se taire et ne rien dire

• Je suis reconnaissant envers Andrew pour avoir créé et maintenu rsync, mais comme je dépends fortement de rsync pour les sauvegardes de fichiers entre machines sur mon réseau domestique, j’ai pris le temps de comprendre comment épingler la version de rsync de Homebrew sur 3.4.1
  Les bugs des deux versions suivantes sont vraiment inquiétants, tout comme le rapport initial qui a déclenché toute cette affaire. J’ai documenté ici la procédure, bien plus compliquée que je ne l’imaginais : https://gist.github.com/e40/caa67c1b8d439a528695f996d0519d8e

• Ce texte soulève plus de questions qu’il n’apporte de réponses, ce qui rend difficile de se faire un avis. Je ne comprends pas pourquoi la v3.4.1, juste avant le commit de Claude, était celle qui avait le plus de bugs, ni pourquoi « personne ne l’a remarqué ». C’est bien trop étrange pour être balayé comme une simple erreur humaine
  Je me demande aussi pourquoi la v3.4.2 a 0 bug, ou un score de bug de 0. Il est également étrange que ce type de valeur aberrante, qui ne semble pas exister dans les autres commits, ait été mélangé aux statistiques agrégées au point de faire baisser le score « Claude crée des bugs ? ». Franchement, je ne comprends pas que cela n’ait pas été perçu comme un signal d’alerte dans l’analyse de l’auteur. On a l’impression qu’une analyse incomplète a été présentée comme un produit fini très sophistiqué sous prétexte qu’elle utilise des statistiques avancées

  • Je ne vois pas sur quoi repose l’idée que la v3.4.1 ne puisse pas être une erreur humaine, en dehors de l’hypothèse de départ selon laquelle ce serait impossible
    Quant à la v3.4.2, dans les métriques d’origine, elle avait 4 bugs avant qu’on ne filtre les demandes de fonctionnalités et les questions, et avant cela elle était encore plus haute, mais cela ne changeait pas grand-chose à l’analyse globale. Elle restait bien dans l’intervalle interquartile, plutôt dans la partie basse. Et avec seulement deux releases Claude, retirer une valeur aberrante simplement parce qu’elle paraît amusante me semble pire et plus arbitraire

• Si l’idée est : « on ne contrôle ni la complexité des commits, ni leur dimension sécurité, ni la gravité des bugs. C’est un instrument grossier qui ne distingue pas une correction de faute de frappe d’un patch CVE. Mais comme les critiques qui disent que Claude aggrave la situation utilisent eux aussi un instrument grossier, alors l’instrument grossier est la réponse la plus équitable », j’ai du mal à être d’accord
  Du point de vue de l’utilisateur, il faut comprendre si la nature des bugs est devenue plus grave. Même si le ratio reste identique, si la qualité logicielle perçue baisse, surtout pour le mainteneur du projet, alors on peut considérer que la situation s’est dégradée. Je ne dis pas qu’il faut ignorer complètement cette analyse, mais ce genre de question me semble difficile à trancher uniquement avec une analyse quantitative

  • Je trouve quand même cela équitable. Jusqu’ici, je n’ai vu personne analyser le code et dire combien de régressions de telle ou telle gravité il y avait eu. Les gens se contentent de dire : « les LLM ont augmenté le nombre de bugs »
    Cette analyse est vérifiable directement si on le souhaite, et elle dit que « même avec un LLM, le nombre de bugs reste assez moyen ». En ce sens, elle répond bien à l’affirmation initiale. Si quelqu’un veut une analyse plus nuancée, libre à lui de la faire et de partager le résultat
  • Une affirmation avancée sans preuve peut être rejetée sans preuve. Cette analyse apporte plus d’éléments et une rigueur supérieure à ce qui soutenait l’affirmation de départ. Pour moi, cela suffit. Si quelqu’un finit par étayer l’affirmation initiale avec de meilleures preuves, tant mieux, j’aimerais le voir. En attendant, je ne vais pas m’inquiéter de cette question
  • La charge de la preuve n’incombe-t-elle pas à celui qui affirme ?

• Je code depuis plus de 20 ans, j’ai toujours aimé ça et il y a de fortes chances que ce soit encore le cas à l’avenir. Il y a encore quelques mois, j’étais sceptique vis-à-vis de l’IA, mais Claude et Codex ont transformé ma manière de développer et ma vitesse d’une façon que je n’aurais jamais imaginée
  Résultat : je produis plus de code et je trouve aussi plus de bugs. C’est pourquoi je suis assez surpris de voir sur HN une haine aussi extrême envers tout ce qui est produit avec l’IA. Ce n’est pas parce qu’un projet a été aidé par l’IA, ou entièrement généré, qu’il devient soudainement du vibe coding, ni que ce terme devrait être une insulte adressée aux utilisateurs de LLM. Cela me rappelle beaucoup les expressions méprisantes visant les « développeurs indiens » à partir du milieu des années 90, avec la montée de l’externalisation offshore. Et maintenant, au milieu des années 2020, on entend des propos similaires à propos de l’IA. Je ne comprends pas. Une chose est sûre : quoi qu’en pensent les opposants, une part croissante du code sera générée par l’IA

  • J’étais moi aussi sceptique à peu près de la même manière il y a 3 ans. À l’époque où GPT-4 représentait l’état de l’art, je pensais qu’on allait vite plafonner à cause des limites de taille de contexte. Je me souviens de l’époque où il fallait payer des sommes absurdes pour utiliser un contexte de 32K
    L’an dernier, j’ai vu pour la première fois un agent IA déboguer et corriger de façon satisfaisante un bug non trivial. Même à ce moment-là, il était clair qu’en l’utilisant sur de gros travaux, on n’était pas encore au point de pouvoir lui confier tout un issue tracker. Aujourd’hui, cela fait quelques mois que je travaille sur un projet non trivial avec Codex. J’ai fait un prototype en C++ pour des raisons de bibliothèques, écrit une première version en Haskell, puis l’ai récemment porté en Rust pour limiter l’usage mémoire sur mobile. Ce n’est pas un outil sans défauts, mais le rythme des progrès sur la seule dernière année est impressionnant. Le scepticisme est sain, mais un scepticisme sain doit reculer face à des preuves concrètes
  • Sur tous les sujets liés aux outils, il y a des gens qui aiment l’outil lui-même, et d’autres qui aiment s’en servir pour faire autre chose. En programmation, j’ai toujours été dans le second camp. La programmation est l’outil qui me permet de faire ce que j’aime vraiment : résoudre des problèmes, penser à l’échelle système, et fournir des solutions élégantes via le logiciel
    Donc oui, j’adore que l’IA m’aide sur les parties ennuyeuses, et c’est aussi très amusant de voir des collègues non programmeurs s’enthousiasmer en voyant leurs idées vibe coded devenir réalité. Je suis sincèrement curieux du point de vue anti-IA chez les gens qui travaillent dans l’industrie logicielle. Est-ce lié à la fin imminente de leur métier, ou à une transition technologique ?
  • Si des expressions méprisantes visant les « développeurs indiens » sont apparues avec la montée de l’externalisation offshore dans les années 90, qu’est-ce qui les a déclenchées ?
  • Je gère en permanence du code externalisé, et sans exception c’est un incendie de pneus. Je viens justement de passer une semaine à nettoyer une base de code où un développeur, incapable de configurer correctement son environnement local, avait commité avec l’option de contournement des vérifications d’authentification activée par défaut
    On signale le même problème de « raccourcis » dans l’AI vibe coding, et même en utilisant des modèles de pointe au niveau de raisonnement 11, j’ai dû réécrire presque tout le code généré par l’IA. Cela dit, l’IA est extrêmement utile pour d’autres activités : revue de PR, analyse de vulnérabilités de sécurité, repérage de fautes de frappe, rétro-ingénierie. Je devrai probablement passer à l’abonnement supérieur, tout en considérant en même temps que le code généré par l’IA reste inutilisable. Si une seule personne peut penser à la fois « c’est tellement utile que je dois payer plus » et « la qualité du code produit est inutilisable », il est normal que l’ensemble des utilisateurs ait des avis très variés
  • Les LLM sont bons pour la recherche dans le contexte et la production de modèles. Mais ce qu’ils garantissent, c’est au mieux la réponse saillante du plus petit dénominateur commun, une production non protégeable par le droit d’auteur, avec en plus un risque juridique potentiel de fuite de copyright
    Nous sommes actuellement dans l’âge d’or Napster du plagiat homomorphe

• Je me demande sérieusement ce que c’est que ça. Ce qui compte réellement, c’est simplement de savoir si, une fois que du code écrit par l’IA a été autorisé dans la base de code, le nombre de bugs a augmenté. Tout le monde connaît déjà la réponse. Cela dit, il est toujours intéressant de voir ce qu’on peut faire passer pour une conclusion qui « nécessite » des données

[GN⁺]

Avis sur Lobste.rs

• Je pense que chacun peut décider pour soi s’il veut continuer à utiliser des projets FOSS qui seront désormais développés en vibe coding. En revanche, la colère de la communauté après le passage du mainteneur à des outils de vibe coding a été assez surprenante, et les données empiriques présentées dans l’article permettent au moins de mieux contextualiser l’impact de ce changement de pratique
  Il faudra du temps pour voir si l’adoption de cette façon de coder par le mainteneur permettra de préserver la confiance ou si elle l’érodera davantage

  • Je me demande combien de ceux qui se sont énervés contre cette transition ont réellement contribué de façon significative à rsync ou ont versé de l’argent

• Cette analyse était exactement ce que j’espérais, et même plus. J’ai particulièrement apprécié le passage disant : « J’ai moi-même choisi tous les indicateurs, la méthodologie et les sources de données après en avoir discuté avec ma femme, titulaire d’un master de statistique de Penn State University », et le fait d’avoir impliqué une véritable spécialiste des statistiques ainsi que d’en avoir fait un texte facile à lire est excellent
  Puisqu’un seul indicateur a été utilisé, « le nombre de bugs pour 10 commits », c’est dommage d’avoir raté l’occasion d’utiliser un préfixe SI et d’appeler ça des décibugs par commit

  • D’accord. Ce n’est pas mon article, mais j’ai apprécié que quelqu’un dépasse les réactions excessives pour ou contre et montre avec des données l’impact sur la qualité du code

• Le succès d’un projet open source dépend tellement de la perception que certains vont jusqu’à acheter des étoiles GitHub. Malheureusement, ce problème d’image est désormais hors de contrôle et s’est transformé en argument récurrent, et il sera difficile pour n’importe quelle donnée de changer cela
  À l’avenir, « le mainteneur de rsync a utilisé un LLM et a tout cassé » sera brandi par les sceptiques de l’IA aux côtés d’arguments comme « les datacenters gaspillent 50000 gallons d’eau potable par jour » ou « une étude du METR a dit que les LLM faisaient baisser la productivité »
  Je ne suis pas en train de dire si je suis moi-même sceptique vis-à-vis de l’IA ou non ; je veux simplement dire que les débats sur ce sujet prennent généralement cette tournure

  • Pourquoi serait-ce un « argument », ce n’est pas simplement un fait ?
  • Je ne sais pas si l’auteur cherche à convaincre qui que ce soit avec des données. Je vois plutôt cet article comme une tentative d’apporter un contexte chiffré à la polémique virulente autour de l’adoption de ces outils par rsync
    Cela dit, il est vrai que l’article laisse complètement de côté d’autres éléments non quantitatifs, et c’est sans doute volontaire étant donné qu’il y a déjà assez de bruit des deux côtés, évangélistes comme sceptiques

• Le fait que la pire version de toute l’histoire de rsync soit sortie avant l’arrivée de Claude, avec 39,39 bugs pour 10 commits, est une conclusion très importante et prévisible
  Si les processus entre utilisateurs et développeurs, comme les tests et l’assurance qualité, ne garantissent pas l’exactitude du logiciel, alors on finira par livrer des bugs avec ou sans LLM. Les LLM peuvent nuire à ce processus comme ils peuvent l’aider

  • D’accord. Le billet récent sur cURL semble montrer l’exemple inverse
    Grâce à des pratiques de génie logiciel solides et en place depuis des années, la valeur de ce type d’outils d’IA pour trouver des bugs a globalement diminué
  • J’ai quelques inquiétudes quant à l’avenir de rsync. Le principal problème, c’est que rsync était en pratique un projet terminé depuis des années, mais qu’avec l’usage de l’IA, le code de test existant a été arraché et remplacé par une suite de tests Python, sans faire tourner les anciens tests en parallèle pendant une période significative pour valider la justesse
    À mes yeux, c’est irresponsable. D’autant plus que la fonction première de rsync est de déplacer des données précieuses, et que l’intégrité de ces données est absolument essentielle

• J’aimerais qu’on évite des formules comme « comme c’est typique chez les utilisateurs anti-IA, cela a fini par escalader en fantasmes de violence ». Non seulement l’auteur généralise à partir de certaines personnes avec qui il n’est pas d’accord, mais il risque aussi de braquer les lecteurs qui ne partagent pas son avis, si bien que ceux qui devraient le plus lire l’article ne le liront pas
  Par ailleurs, qu’il y ait plus ou moins de bugs que dans les versions précédentes m’importe assez peu. Ce qui compte pour moi, c’est que le logiciel soit développé d’une manière qui ne correspond pas à ma conception du développement logiciel. Si l’on ne comprend pas d’emblée qu’il y a des problèmes au-delà de la seule efficacité, je n’ai guère d’espoir de convaincre qui que ce soit que cette position est raisonnable
  Heureusement, si je n’en veux pas, je ne suis pas obligé d’utiliser cette version de rsync, et je choisirai une alternative issue d’un fork antérieur à l’usage des LLM

  • Cet article était tellement chargé de colère que je n’ai pas réussi à le lire longtemps et j’ai abandonné. Il aurait mieux valu qu’il cherche à être équitable, ou au moins à en donner l’impression
    Le fait de répéter un mème déjà réfuté depuis longtemps, à savoir que le premier bug report était un ticket sur lequel les gens s’étaient rués, n’a pas aidé non plus. Le véritable premier bug report était un autre ticket

• Franchement, je trouve le texte actuel meilleur. Mais le passage « cet indicateur ne contrôle ni la complexité des commits, ni la sensibilité en matière de sécurité, ni la gravité des bugs. C’est un outil grossier qui ne sait pas distinguer une correction de coquille d’une ligne d’un patch de CVE » passe, de mon point de vue plutôt LLM = mauvais, à côté de la critique essentielle.
  La critique que moi et d’autres formulons, c’est que l’IA pousse à déverser des commits plus gros, plus difficiles à comprendre et qui augmentent la complexité. Les partisans des LLM disent souvent quelque chose de similaire, puis déplacent les poteaux depuis la pratique éprouvée depuis des décennies de « lire la PR » vers « le LLM doit pouvoir tout tester ». Mais le problème de la complexité du code comme dette technique ne disparaît pas pour autant.
  Dans ce cas précis, la gravité du bug est très élevée, parce que le workflow de sauvegarde a réellement été cassé. rsync est largement utilisé pour les sauvegardes, et c’est un outil auquel on faisait confiance comme à quelque chose de « battle-tested », au point que les gens n’imaginaient même pas qu’une mise à jour de patch puisse casser leurs scripts de sauvegarde.
  On peut dire que le fait que le LLM ait produit un logiciel bogué était un accident, ou que le mainteneur doit changer son workflow avec LLM et augmenter la couverture de tests. C’est d’ailleurs ce qu’il a dit lui-même. Mais au cœur de la colère, il y a le fait que cet outil a brisé cette confiance.
  Il existe vraiment en ce moment une nouvelle catégorie de programmeurs au LLM qui disent « je ne lis plus le code du tout ». Ils disent que ça prend trop de temps à lire et que c’est plus complexe à appréhender que du code écrit par des programmeurs ordinaires. Lire du code, c’est apprendre le modèle mental de quelqu’un d’autre, et les outils LLM ne fournissent pas un modèle mental cohérent unique.
  À part ça, il faudrait aussi vérifier l’accessibilité du site. J’ai une très bonne vue et je suis encore dans la vingtaine, mais du texte gris clair sur fond crème/jaune clair est vraiment pénible à lire.

  • Le passage cité me perturbe. L’indicateur utilisé dans l’article semble bien appliquer une pondération par gravité au nombre de bugs pour 10 commits ; l’auteur se contredit lui-même ou c’est moi qui ai mal lu ?
  • Pour les gens dont le workflow a été cassé, j’y vois une bonne occasion d’apprendre ce qu’est le logiciel open source et ce que garantit une licence GPL.
    Je ne pense pas que ces gens auraient découvert ce bug eux-mêmes. J’imagine que plus de 90 % des utilisateurs de rsync utilisent une version antérieure qui n’a pas ce bug. J’en fais partie.

    $ uname -a  
    Darwin riemann.local 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:53:31 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T8103 arm64
    
    $ port info rsync  
    rsync @3.4.1 (net)  
    [...]  
    

    Si ça a attiré l’attention, c’est probablement parce qu’on n’a pas besoin d’être Steven Pinker pour voir qu’une bonne partie de la communauté est en pleine confusion en ce moment. Le fait que les LLM programment mieux que les humains n’est pas quelque chose de facile à accepter.
    Les personnes qui fondaient leur identité et leur estime d’elles-mêmes sur leurs compétences de programmation ou leur métier font face à une double crise : l’incertitude sur leurs moyens de subsistance futurs / leur valeur sur le marché, et une crise d’identité.
    La peur, l’incertitude et le doute sont difficiles à gérer, et les entreprises du LLM font de leur mieux pour amplifier cet effet afin de faire monter leur cours de bourse. Si le marché corrige brutalement après octobre, il est possible que ce mécanisme d’amplification s’affaiblisse aussi.
    Une toute petite proportion des programmeurs dans le monde, à savoir ceux qui voient le code comme une forme d’art, utiliseront probablement les LLM pour s’entraîner et progresser.

• Cet article cite beaucoup de commentaires qui parlent de régressions, mais l’analyse elle-même ne mesure pas des régressions, seulement des rapports de bugs. Elle rattache les bugs à la version où ils ont été signalés, pas à la version où ils ont été introduits, et elle mesure la gravité des versions par le nombre de commits tout en excluant des facteurs évidents comme la durée d’une version ou l’adoption par les distributions.
  Je ne vois pas en quoi cela a du sens.

• Personnellement, j’évite les projets qui utilisent des LLM. Pas tellement pour une raison concrète, plutôt parce que ça me met profondément mal à l’aise ; un peu comme quand quelqu’un dit « kek » ou « fren » et que je le prends comme un signal que je n’ai plus envie d’interagir, même sans raison précise.
  Les explications avancées aujourd’hui pour justifier le rejet des LLM me donnent l’impression d’être des rationalisations plaquées après coup. Les inquiétudes actuelles sur l’éthique, la qualité, etc. sont valides, mais même si ces problèmes étaient résolus, je ne pense pas que des gens comme moi, de tendance plutôt anti-IA, changeraient soudain d’avis.
  C’est pour ça que j’évite, sans raison précise, les projets avec des AGENTS.md, des commits coécrits par Claude, etc. Ça me déplaît, ce n’est pas mon goût, et peu importe qu’il y ait des bugs ou non. J’imagine que d’autres ressentent la même chose.

• À l’auteur : premièrement, un fantasme reste du langage. En pratique, cela revient à affirmer que ça s’est arrêté aux mots, ou du moins à ne pas prétendre qu’il y a eu une escalade non verbale.
  Deuxièmement, si on veut défendre ce genre d’affirmation, il faudrait demander à un statisticien proche comment l’étayer. Le fait que quelques personnes aient posté ce type de messages ne permet pas, à lui seul, d’étayer de manière significative l’idée que ce serait « typique ».
  Mon observation anecdotique non étayée statistiquement, c’est que les utilisateurs « anti-IA » sont généralement plus tristes que violemment agressifs face au fait que des LLM s’imposent là où ils ne sont d’aucune aide.

  • Je vois parfois des textes très longs et très détaillés qui cherchent à réfuter une partie des opposants aux LLM, en général ceux qui y réagissent sur un plan émotionnel et social. J’ai du mal à expliquer pourquoi, mais ces textes me paraissent très peu sincères, avec une impression de s’en prendre aux plus faibles.
    C’est tellement détaillé qu’il devient difficile d’y répondre sur le plan émotionnel, et au final ça semble toujours conclure que « le problème, ce n’est pas le LLM ; bien utilisé, c’est un amplificateur. Les anti-IA ne comprennent simplement pas et ont seulement peur d’être laissés derrière ».
    Je n’ai pas non plus envie de réduire le travail des mainteneurs de rsync à une simple controverse, donc je ne sais pas comment formuler une contre-réponse convaincante.
    Les statistiques présentées ici peuvent être intéressantes du point de vue de la maintenance open source, mais les conclusions me semblent bizarrement orientées d’un seul côté, et ça me laisse l’impression que l’open source façon GitHub n’est pas la forme à laquelle j’ai envie de contribuer.
    Cela dit, je trouve tout à fait malsain que des gens soient allés se jeter en meute sur le dépôt rsync pour s’en prendre au mainteneur.
  • Il est juste de dire que les fantasmes publics de violence ne sont pas acceptables. Ce n’est pas le genre de chose auquel une civilisation devrait aspirer. En revanche, le fait que l’auteur qualifie cela de « typique » me gêne, parce que c’est une généralisation.
    Pour ce qui est des observations anecdotiques, cette BD dit des choses justes. J’aime voir des affirmations concrètes et mesurables, en partie parce que j’aime les chiffres, et aussi parce que cela aide les discussions en ligne à se rapprocher un peu plus du monde idéal de la dernière case.

• Merci pour l’analyse, mais je ne suis pas convaincu par la méthodologie. J’aimerais voir des métriques comme le nombre de bugs par unité de diff, obtenu en multipliant pour chaque commit le nombre de lignes modifiées dans le code principal — donc hors tests et documentation —, ainsi qu’une analyse du temps nécessaire après une release pour atteindre un certain nombre de bugs.
  Cela dit, comme cette release a probablement attiré bien plus d’attention que les autres, il est très possible que davantage de bugs aient été signalés, ce qui semble rendre difficile l’élaboration d’un indicateur vraiment convaincant. Une question comme « est-ce typique au bout de quelques semaines après la release ? » pourrait aussi ne pas être très utile.