Coder avec l'IA = perdre du temps. Enfin la vérité éclate !

C'est une étude scientifique tellement importante que, dans la seule journée d'hier, j'en ai entendu parler partout : sur Bluesky, sur LinkedIn et même dans quelques Slacks. Cette étude, c'est Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Elle confirme ce que l'on savait déjà tous : pour écrire du code, l'IA, c'est sympa mais ça ne fait pas gagner de temps. Bien au contraire, ça en fait même perdre.

Les vendeurs d'assistant de code nous promettent de coder beaucoup plus vite. Des visionnaires nous annoncent même le remplacement de milliers de développeurs par des IAs. Ce résultat à contre courant a donc de quoi surprendre.

En utilisant un assistant de code, il y a toujours des moments où celui-ci part dans un délire et il n'y a plus aucun moyen de le faire revenir sur l'objectif que l'on avait en tête. Il y a des situations où l'IA fait perdre du temps. Ceux qui diront le contraire mentent. C'est aussi simple que ça.
Mais l'étude qui nous intéresse aujourd'hui va bien plus loin dans ses affirmations.

We provide evidence that recent AI systems slow down experienced open-source developers with moderate AI experience completing real issues on large, popular repositories they are highly familiar with. This observed slowdown serves as some evidence that AI capabilities in the wild may be lower than results on commonly used benchmarks may suggest.
Furthermore, we show that both experts and developers drastically overestimate the usefulness of AI on developer productivity, even after they have spent many hours using the tools.

Ces affirmations me dérangent car, en tant qu'utilisateur d'assistant de code, je n'ai pas l'impression que, en moyenne, l'IA me fasse perdre du temps. Je suis donc allé voir comment on pouvait arriver à cette conclusion.

Dans les grandes lignes, le fonctionnement de cette étude, c'est :

• On a 16 développeurs expérimentés et maintenaurs actifs sur des gros projets open source (14 projets dont la moitié ont plus de 400 kloc et ça monte jusqu'à 8 Mloc)
• Ces développeurs proposent des taches de dev (bug fix, nouvelle feature...) pour lesquelles le temps de réalisation devrait, a priori, ne pas dépasser 2 heures. On retient ainsi 246 taches.
• Pour chacune d'entre elles, un tirage au sort est effectué pour savoir si l'IA sera autorisée (mais pas imposée) ou pas.
• Le temps effectif pris par ces taches est mesuré.
• Le constat : les taches où l'IA était autorisée ont pris en moyenne 19% de temps en plus.

Rien à redire sur la méthode. Le contexte étroit est, en revanche, beaucoup plus questionnable.

On est sur de toutes petites taches. Si j'ai une tache que je maitrise suffisamment bien pour pouvoir dire "Je vais la terminer en 2 heures max", je ne suis pas sûr de vouloir faire appel à l'IA, ou alors pour un truc très spécifique comme reformater un jeu de données.

On est sur des bases de codes immenses. On sait que le contexte sur lequel opèrent ces IA est forcément limité. On est donc dans les pires conditions.
Une anecdote intéressante : un développeur explique que l'IA a fait des changements bizarres dans des parties de code qui n'auraient pas dû être touchées. Pour moi, ça en dit plus sur la mauvaise organisation de ces projets que sur les limitations des IAs. Un contexte de travail où on peut naviguer dans des centaines de milliers de ligne de code, c'est juste un non sens.

On a des développeurs peu familiers avec l'assistant de code utilisé. Toutes les tâches IA ont été réalisées avec Cursor pour les taches où l'IA était autorisée mais moins de la moitié des développeurs avaient utilisé cet outil auparavant.

Ce dernier point me rappelle des études d'il y a 15 ou 20 ans quand les gens voulaient évaluer la pertinence du TDD. Par exemple, dans Evaluating Test-Driven Development in an Industry-sponsored Capstone Project

In contrast to several previous studies, our data analysis indicates that the Test-First methodology did not outperform Test-Last in many of the measures. In fact, the Test-Last group appeared to be more productive than their Test-First counterpart in terms of hours per implemented feature and total features completed.
All three teams wrote about the same amount of lines of production code but the group utilizing Test-Last outperformed the groups utilizing Test-First with more than seven times the amount of test code.

Le problème ? Les équipes en question étaient des étudiants qui venaient tout juste de découvrir le TDD.

Voilà ce qui me gêne avec ces études sur les méthodes de développement. On est toujours sur des contextes trop spécifiques qui sont trop souvent éloignés de la diversité du développement logiciel.

Alors, on ne va pas jeter cette info sur l'utilisation de l'IA mais on va se souvenir qu'elle se base sur un contexte très précis et on ne l'utilisera pas pour lui faire dire plus que ce qu'elle ne dit. Les nombreuses anecdotes en annexe sont d'ailleurs beaucoup plus intéressantes que les résultats chiffrés.