Douze façons de se tromper sur le codage assisté par IA

 (third-bit.com)
9 points par GN⁺ 2 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La valeur du codage assisté par IA se réduit difficilement à des chiffres simples comme le nombre de lignes de code, de tickets ou le niveau de satisfaction, et la manière de l’évaluer peut facilement fausser les conclusions
  • Le nombre de lignes de code ainsi que le nombre de commits, de Pull Requests et de tickets ne mesurent que le volume d’activité ; dès qu’ils deviennent un objectif, ils se manipulent facilement et ne distinguent pas la qualité
  • Le taux d’acceptation et le taux d’adoption ne sont que des signaux indiquant que les suggestions semblaient plausibles ou que l’outil a été déployé ; ils ne garantissent ni l’exactitude, ni la sécurité, ni la maintenabilité
  • Les tâches-jouets, les comparaisons avant/après sans groupe témoin, la comparaison entre utilisateurs volontaires et non-utilisateurs, ainsi que des références trop faibles rendent difficile de séparer l’effet des LLM du biais de sélection
  • Pour juger de la productivité, il faut des indicateurs au niveau du système incluant la revue, le débogage, la sécurité, la dette technique, les goulets d’étranglement de l’équipe et les évolutions de long terme

Objet de l’évaluation et hypothèses

  • Lorsqu’on cherche à démontrer la valeur d’outils de codage assisté par IA par rapport à leur coût d’abonnement, le volume de code généré, le nombre de tickets terminés et les enquêtes de satisfaction des développeurs peuvent chacun conduire à des conclusions erronées de manière différente
  • L’enjeu central n’est pas la valeur du codage assisté par LLM en soi, mais la facilité avec laquelle son évaluation peut passer à côté de la réalité
  • La même critique peut s’appliquer, avec peu d’ajustements, aux affirmations sur le développement agile, le développement piloté par les tests et d’autres pratiques de développement logiciel
  • Cela conduit à conclure que si l’ingénierie logicielle avait mieux intégré les méthodes de recherche des sciences humaines, elle serait bien plus avancée dans l’étude de ce type de phénomènes

Mauvais indicateurs de productivité

  • Compter les lignes de code générées

    • Le nombre de lignes de code est utilisé depuis longtemps comme indicateur indirect d’une productivité difficile à mesurer directement
    • Les LLM peuvent produire davantage de code, sans pour autant garantir un meilleur résultat
    • Une équipe dont le nombre de lignes de code par développeur augmente de 40 % après l’adoption d’un LLM a peut-être mesuré non pas la productivité, mais la verbosité
    • Remplacer 2 000 lignes de logique enchevêtrée par 200 lignes propres apparaît comme une perte dans un indicateur fondé sur les lignes de code
    • Plus de code signifie aussi plus de lecture, de maintenance et de débogage, et la charge future laissée par l’IA n’apparaît pas dans ce décompte

  • Compter les commits, Pull Requests et tickets

    • En 2023, McKinsey a proposé de mesurer la productivité individuelle des développeurs à partir du nombre d’activités comme les commits, les Pull Requests ou les revues de code
    • Comme avec la loi de Goodhart, dès qu’une mesure devient un objectif, elle cesse d’être une bonne mesure
    • Si le nombre de commits est suivi, les développeurs feront des commits plus petits et plus nombreux ; si le nombre de tickets est suivi, les tickets seront découpés
    • Les chiffres peuvent s’améliorer sans que le travail sous-jacent ne progresse réellement
    • L’activité n’est pas un résultat, et un résultat n’est pas automatiquement de la valeur

  • Prendre le taux d’acceptation des suggestions comme signal de qualité

    • Le taux élevé d’acceptation des suggestions des assistants de codage LLM est souvent présenté comme une preuve de l’utilité de l’outil
    • Le taux d’acceptation mesure seulement si le code généré semblait assez plausible pour que le développeur appuie sur Tab, pas son exactitude, sa sécurité ou sa maintenabilité
    • Sous pression temporelle, les développeurs acceptent davantage de suggestions, y compris des suggestions dangereuses
    • Une étude d’entreprise menée auprès de 400 développeurs a constaté un taux moyen d’acceptation de 33 % et une forte satisfaction des développeurs, sans suivre l’exactitude ni la sécurité du code accepté
    • Un indicateur qui récompense ce qui paraît plausible n’est pas un indicateur qui récompense ce qui est réellement bon

  • Prendre le taux d’adoption comme indicateur de succès

    • Dire qu’« un taux d’adoption de 90 % des outils IA a été atteint dans l’ensemble de l’organisation d’ingénierie » relève d’un succès d’achat et de déploiement, pas d’un succès de productivité
    • Le taux d’adoption mesure seulement si l’outil a été installé et ouvert ; il ne dit rien sur l’utilité des suggestions, sur l’acceptation non critique par les développeurs, ni sur la justesse des suggestions acceptées
    • Une forte adoption combinée à une faible qualité des suggestions peut conduire les développeurs à passer leur temps à gérer l’outil plutôt qu’à en tirer un bénéfice
    • Une étude d’IBM sur un assistant de codage IA pour l’entreprise a montré que l’outil produisait souvent un gain net de productivité, mais que ce bénéfice n’était pas uniforme selon les utilisateurs
    • Le taux d’adoption est plus facile à mesurer que le bénéfice, et c’est précisément pour cela qu’il est plus souvent rapporté

Erreurs de conception expérimentale

  • Chronométrer des tâches artificielles

    • Une étude très citée sur GitHub Copilot a montré que les utilisateurs terminaient une tâche 55 % plus vite que les non-utilisateurs
    • La tâche consistait à implémenter de zéro un serveur HTTP en JavaScript, avec une limite de 90 minutes et sans autre obligation pour les développeurs ce jour-là
    • Le développement logiciel réel implique l’exploration de grandes bases de code que l’on n’a pas écrites soi-même, la compréhension de tickets aux exigences ambiguës, la coordination avec des collègues et des réunions
    • La vitesse sur des tâches-jouets greenfield ne prédit pas la vitesse sur ce travail réel
    • Dans un essai contrôlé randomisé auprès de développeurs open source expérimentés, contrairement aux attentes des participants, donner accès à un outil IA a augmenté de 19 % le temps nécessaire pour terminer la tâche

  • Comparaisons avant/après sans groupe témoin

    • Si une équipe commence à utiliser un LLM en janvier et que les Pull Requests sont déployées plus vite en juin, on peut avoir l’impression que l’outil a produit un effet
    • Mais si, dans le même temps, l’entreprise a recruté 12 ingénieurs, refactoré le pipeline CI et changé de fournisseur cloud, il devient impossible d’isoler la cause
    • Sans groupe n’ayant pas adopté l’outil, il est difficile de distinguer l’effet du LLM de celui des autres changements survenus en parallèle
    • La validité interne exige un contrefactuel crédible permettant de savoir ce qui se serait passé sans l’outil

  • Comparer volontaires et non-volontaires

    • Comparer les développeurs qui choisissent d’utiliser un LLM à ceux qui choisissent de ne pas l’utiliser revient à comparer non pas deux conditions, mais deux groupes différents
    • Les premiers adoptants sont souvent plus enclins à expérimenter, plus à l’aise avec les nouveaux outils et potentiellement déjà plus performants que les adoptants tardifs ou les non-adoptants
    • À cause du biais de sélection, les différences observées peuvent tenir aux caractéristiques des personnes plutôt qu’à celles de l’outil
    • Cette approche a le coût de mise en œuvre le plus faible, ce qui en fait un défaut de conception fréquent dans les rapports industriels sur la productivité liée à l’IA
    • Une étude longitudinale menée pendant deux ans dans une grande organisation IT, suivant l’usage de Copilot, a montré que les utilisateurs étaient déjà durablement plus actifs que les non-utilisateurs avant même l’adoption de l’outil

  • Comparer l’IA à « rien du tout »

    • Comparer un développeur assisté par IA à un groupe témoin n’utilisant aucun outil revient à choisir une référence qui n’existe pas dans le travail réel
    • Même sans assistant LLM, les développeurs utilisent de la documentation, des collègues et du temps de réflexion personnelle pour résoudre leurs problèmes
    • La vraie question est de savoir si l’outil LLM est meilleur que les alternatives dont les développeurs disposent déjà, et ce type de comparaison est rare
    • Choisir une référence trop faible fait paraître n’importe quel outil performant, sans que cela signifie une utilité réelle

Ce que la mesure oublie

  • Ne mesurer que la moitié facile

    • Les LLM accélèrent la génération de code, et cette partie est facile à mesurer
    • L’autre moitié, plus difficile, comprend le temps passé à relire le code généré par LLM, le temps perdu en débogage à cause de suggestions fausses mais assurées d’elles-mêmes, les vulnérabilités de sécurité créées par un code plausible mais non sûr, et la dette technique produite par des solutions improvisées ignorant la conception globale
    • Une étude sur le code généré par GitHub Copilot a montré qu’une part importante comportait des vulnérabilités de sécurité, et que les développeurs sous pression temporelle acceptaient plus souvent des suggestions dangereuses
    • Une évaluation de 2025 portant sur cinq grands LLM a montré qu’aucun modèle ne produisait de code d’application web conforme aux standards industriels de sécurité
    • Une analyse à grande échelle de plus de 300 000 commits écrits par IA a montré que plus de 15 % introduisaient au moins un problème de qualité, dont près d’un quart restaient durablement dans la base de code
    • Mesurer seulement l’augmentation de la production en ignorant l’augmentation parallèle des coûts, ce n’est pas de la mesure mais du marketing

  • Mesurer le système, pas seulement l’individu

    • La vitesse de codage individuelle est ce qu’il y a de plus facile à mesurer, donc c’est souvent ce qu’on mesure
    • Même si un outil IA permet à un développeur d’écrire du code 30 % plus vite, si le délai entre ticket et mise en production ne change pas pour l’équipe, alors le goulet d’étranglement n’était pas l’écriture du code
    • Plus de code généré signifie aussi plus de code à relire ; si l’IA augmente seulement le volume de code sans augmenter la capacité de revue, le cycle time peut se dégrader
    • Une étude empirique sur des développeurs professionnels a montré que les outils IA augmentaient la production des contributeurs moins expérimentés, mais que la productivité des développeurs seniors chutait de 19 % en raison d’une hausse de 6,5 % de la charge de revue causée par le code généré par IA
    • Optimiser une seule étape du pipeline tout en ignorant le reste revient moins à une étude de productivité qu’à un échec de pensée systémique

Distorsions dans le temps

  • Demander aux développeurs si leur productivité a augmenté

    • Les résultats d’enquête du type « 87 % des développeurs estiment être plus productifs grâce aux outils IA » sont souvent cités comme preuve que l’outil fonctionne
    • Les déclarations auto-rapportées peuvent produire des malentendus systématiques pour trois raisons
    • À cause de l’effet Hawthorne, les personnes travaillent différemment lorsqu’elles savent qu’elles sont observées ou évaluées
    • Un nouvel outil produit un effet de nouveauté : parce qu’il est nouveau, il donne l’impression d’aller plus vite, et cette sensation disparaît généralement en quelques semaines
    • À cause du biais de désirabilité sociale, les répondants ont tendance à donner la réponse qu’ils pensent souhaitée par l’enquête, en particulier lorsque la direction a choisi l’outil

  • Ne mesurer que pendant la période d’effet de nouveauté

    • Si une étude de quatre semaines trouve un gain de productivité, elle n’a trouvé qu’un gain de productivité sur quatre semaines
    • Les développeurs s’investissent davantage dans un nouvel outil pendant la période initiale, ce qui peut gonfler les performances observées par rapport à la référence de long terme
    • Les effets réellement importants apparaissent sur des mois plutôt que sur quelques semaines
    • La dégradation des compétences sur les tâches déléguées à l’IA, la dette technique accumulée à partir de suggestions erronées et l’évolution des modes de collaboration dans l’équipe exigent une observation de long terme
    • Une étude conçue pour détecter des gains de court terme ne dit rien de ce qui se passe après la fin de l’étude
    • Une analyse de 807 dépôts open source ayant adopté Cursor a montré une nette mais temporaire hausse de la vitesse de développement après l’adoption, tandis que la complexité du code et les alertes d’analyse statique augmentaient de manière importante et durable

Conclusion pour une meilleure interprétation

  • La mesure de la productivité se laisse difficilement réduire à un chiffre unique ou à un indicateur indirect facile
  • Pour juger des effets du codage assisté par LLM, il faut regarder non seulement la vitesse d’écriture du code, mais aussi la revue, le débogage, la sécurité, la maintenance, la dette technique, les goulets d’étranglement de l’équipe et les évolutions de long terme
  • Sans groupe témoin, sans référence réaliste, sans contrôle du biais de sélection, sans observation de long terme et sans indicateurs au niveau du système, il est difficile de distinguer l’effet des outils IA de celui des autres changements
  • Les valeurs faciles à mesurer sont faciles à rapporter, mais elles ne remplacent pas pour autant les valeurs importantes
  • Pour évaluer les pratiques de développement logiciel, il faut prendre beaucoup plus au sérieux les méthodes de recherche des sciences humaines

Principales sources citées

À lire aussi

1 commentaires

 
GN⁺ 2 시간 전
Avis sur Lobste.rs

  • L’auteur est l’un des fondateurs de Software Carpentry, donc quelqu’un qui réfléchit à de meilleures façons de mesurer la productivité logicielle depuis bien avant l’arrivée des LLM
    L’étude METR citée est plus intéressante que la raison qu’on voit habituellement mise en avant. Pour beaucoup de gens, le titre à retenir était « l’IA a rendu les gens plus lents », ce à quoi on peut rétorquer que les LLM version 2025 continuent simplement de s’améliorer
    Mais le résultat plus intéressant, c’est qu’a posteriori, leurs propres estimations n’allaient même pas dans la bonne direction par rapport à la réalité. Il semble y avoir là un facteur que la plupart des entreprises ignorent, et qui crée une difficulté fondamentale pour toute mesure
    Même la vague impression qu’un outil rend les gens plus productifs n’est pas fiable. Les gens ne le savent pas eux-mêmes
    L’étude de suivi qui a suivi a pratiquement échoué à cause d’un biais de sélection

    The primary reason is that we have observed a significant increase in developers choosing not to participate in the study because they do not wish to work without AI
    Le fait que des développeurs refusent de travailler sans IA peut vouloir dire que l’outil fonctionne bien, ou au contraire qu’à force d’en dépendre, leur capacité à effectuer des tâches plus difficiles s’est complètement atrophiée

    • Mon hypothèse est que les gens ont tendance à davantage s’appuyer sur les LLM pour les parties qu’ils n’ont pas envie de faire, et quand on fait quelque chose qu’on n’a pas envie de faire, le temps paraît toujours passer beaucoup plus lentement

  • L’idée que « les nouveaux outils semblent plus rapides parce qu’ils sont nouveaux, et que cette impression disparaît en général en quelques semaines » me paraît inversée
    Les nouveaux outils me ralentissent toujours parce que je ne les maîtrise pas encore. Bien sûr, j’en vois le potentiel pour aller plus vite, mais je ne sais pas encore les utiliser efficacement

    • Il y a aussi un autre effet lié à cela. En particulier, les personnes qui essaient volontairement de nouveaux outils sont motivées, et travaillent davantage en dehors des heures normales pour compenser leurs lacunes
      Pendant un temps, cela peut paraître impressionnant, mais ça finit naturellement par disparaître quand elles reviennent à leur manière habituelle de travailler

  • Mesurer est difficile. D’une certaine manière, vouloir mesurer le coding assisté par IA est peut-être déjà une erreur
    Il est évident que certaines tâches deviennent plus rapides, et il existe presque certainement des façons de s’en servir pour réellement accélérer les choses
    La question plus importante est de savoir lesquelles, et ce qu’on perd dans le processus

    • La productivité et l’accélération de l’exécution d’une tâche ne sont pas la même chose. Même si une tâche devient plus rapide, cela peut n’avoir aucun effet positif sur la productivité si cette tâche n’était pas le goulot d’étranglement, ou si ce gain de vitesse a un coût
      L’article original en parle comme du fait de « ne mesurer que la moitié facile »

  • À la question « si votre manager vous demandait la semaine prochaine de montrer que l’outil de coding IA souscrit par l’entreprise vaut son prix d’abonnement, mesureriez-vous le nombre de lignes de code générées, ou le nombre de tickets fermés ? », Claude mesure déjà, via les relevés de facturation, le nombre de lignes de code, le taux d’acceptation et l’usage des tokens
    Le nombre de tickets fermés relèverait de la vélocité de l’équipe, dont la sortie de l’IA n’est qu’un facteur parmi d’autres, et Jira mesure déjà la vélocité des sprints
    Quoi qu’il en soit, cette question se manipule facilement selon ce que l’on pense être le livrable que le manager veut voir, et il y a de fortes chances que ce soit déjà le cas

  • J’ai l’impression que l’auteur a laissé de côté une question extrêmement importante : « Quels dommages l’usage de l’IA provoque-t-il ? »
    À mes yeux, cette question est plus fondamentale que toutes les autres. Parce que les dommages, eux, sont bien plus faciles à mesurer. Il suffit de faire tourner une Git forge et de regarder les crawlers se jeter dessus comme des requins attirés par l’odeur du sang
    Le fait que des scrapers DDoS l’ensemble d’Internet est un problème mesurable, et une réalité concrète pour tous ceux qui s’auto-hébergent
    Les soi-disant bénéfices de l’IA, que nous avons tant de mal à mesurer correctement, valent-ils vraiment les dommages très réels causés par les crawlers ?
    Et si l’on ajoute l’énergie nécessaire pour faire tourner ces crawlers et traiter leurs requêtes, le coût de l’entraînement, le coût de l’inférence, et le besoin de data centers toujours plus grands ?
    Il me semble bien plus important de se demander si ces soi-disant bénéfices de l’IA valent tous ces sacrifices

    • Ce qui me frustre toujours dans ce genre de débat du type « il faut parler de X », c’est que j’ai vu l’argument exactement inverse dans des textes sur les dégâts écologiques
      Du style : « même si ces outils ne consommaient pas d’énergie, ils produiraient quand même du mauvais code, donc c’est bien plus important d’en parler », ou encore « pourquoi parler de coding, le vrai dommage c’est leur usage pour la surveillance », et ainsi de suite