METR a publié le 10 juillet 2025 une étude expérimentale (randomized controlled trial) sur l’impact d’outils d’IA « frontier » (période février–juin 2025) sur la productivité de développeurs open-source expérimentés, travaillant sur leurs propres dépôts.
Méthode : 16 devs recrutés sur de gros projets OSS (≈ 22k+ stars, ≈ 1M+ LOC, contributions depuis plusieurs années) ont proposé une liste d’issues réelles à traiter (bugfix/features/refactors, 246 issues au total). Chaque issue a été assignée aléatoirement à une condition « IA autorisée » ou « IA interdite ». Les tâches (≈ 2h en moyenne) ont été réalisées en enregistrant l’écran, puis les devs ont auto-reporté le temps total d’implémentation. Rémunération : 150$/h. Quand l’IA était autorisée, les outils utilisés étaient librement choisis, majoritairement Cursor Pro avec Claude 3.5/3.7 Sonnet.
Source : https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Signal à retenir : dans une RCT menée par METR sur 16 devs OSS expérimentés (246 issues), autoriser des outils d’IA (principalement Cursor Pro + Claude 3.5/3.7 Sonnet) a conduit à un ralentissement moyen de 19% sur des tâches réalistes (≈20 min à 4 h).
Point clé : les participants étaient convaincus du contraire : ils prévoyaient +24% de vitesse, et même après coup pensaient encore être +20% plus rapides.
Limites explicitement rappelées par METR : ce résultat ne prouve pas que l’IA n’accélère « personne » ou « la majorité » des devs ; l’étude ne couvre pas d’autres domaines ; elle ne prédit pas l’effet des modèles futurs ; et il peut exister de meilleures façons d’utiliser ces outils (prompting, scaffolding, fine-tuning). METR mentionne aussi un possible effet d’apprentissage (gains qui n’apparaîtraient qu’après des centaines d’heures) et l’hypothèse que l’IA performe moins quand les exigences de qualité et les contraintes implicites sont élevées.
Résultat central (contre-intuitif) : quand l’IA est autorisée, les devs mettent 19% de temps en plus à terminer les issues. Et le plus perturbant n’est pas seulement le signe du résultat, c’est l’écart perception ↔ réalité :
- Avant : les devs s’attendaient à être 24% plus rapides avec l’IA.
- Après l’expérience : ils croyaient encore avoir été 20% plus productifs avec l’IA.
Metr dit avoir testé/révélé plusieurs points importants :
- Ils affirment avoir écarté pas mal d’artefacts : usage de modèles « frontier », respect des consignes (IA autorisée/interdite), pas de drop sélectif qui biaiserait la difficulté, et qualité des PRs similaire entre conditions.
- Le slowdown persiste selon différentes mesures, estimateurs et sous-analyses.
- Ils explorent des facteurs explicatifs et identifient plusieurs contributeurs probables (sans conclure à une cause unique).
Ce que ça change côté « lecture produit » : ce papier met un coup de projecteur sur un point souvent ignoré dans les discussions sur les agents et les benchmarks. Un LLM peut « scorer » sur SWE-bench/RE-bench, et pourtant ne pas accélérer (voire ralentir) des tâches réalistes avec contexte, standards de qualité, contraintes implicites (tests, doc, style, review).
Conséquence pratique : si tu relies ta stratégie (ou ton pipeline) à “l’IA = gain de vitesse”, ce papier est une alerte. Il suggère qu’en conditions réelles, une partie du coût est dans la vérification, la mise en conformité et l’itération plutôt que dans la génération brute.
Add new comment