Study maps developer frustration over "AI slop" as a "tragedy of the commons" in software development

Une étude révèle la frustration des développeurs face à la "brouillon AI" comme une "tragédie des biens communs" dans le développement logiciel

Une étude qualitative examine comment les développeurs perçoivent et réagissent face au contenu AI de faible qualité, ou "brouillon", dans le développement logiciel. Les critiques décrivent une "tragédie des biens communs" où les gains de productivité individuels se font au détriment des réviseurs et de la communauté open-source.

Des chercheurs de l'Université de Heidelberg, de l'Université de Melbourne et de l'Université de gestion de Singapour ont analysé 1 154 publications provenant de 15 fils de discussion sur Reddit et Hacker News.

Les chercheurs ont spécifiquement recherché des fils contenant le terme "AI slop". Cela signifie que l'ensemble de données est fortement biaisé vers les développeurs qui perçoivent déjà ce phénomène de manière négative. Les expériences positives ou neutres avec la génération de code assistée par AI sont largement absentes par conception. Ainsi, l'étude ne représente pas l'opinion de la communauté des développeurs dans son ensemble, mais cartographie les arguments d'un sous-groupe critique.

À partir de ces données, les chercheurs ont développé un codebook avec 15 catégories réparties en trois clusters thématiques : Friction de révision, Dégradation de la qualité, et Forces et conséquences.

Gains de productivité individuels, coûts collectifs

La découverte centrale de l'étude présente un tableau différent : les développeurs critiques décrivent le "brouillon AI" comme une tragédie des biens communs. Les développeurs et les entreprises individuelles tirent profit de la production générée par l'AI, mais les réviseurs, les mainteneurs et la communauté au sens large finissent par en payer le prix.

Les bases de code accumulent de la dette technique, les ressources de connaissance se polluent, les réviseurs s'épuisent, et la confiance qui unit le développement collaboratif s'effondre.

Le problème est particulièrement aigu dans le monde open-source, où les ressources partagées sont maintenues par des bénévoles. Des cas concrets illustrent déjà cela : le projet curl a fermé son programme de récompense pour les bogues après que les rapports de vulnérabilité générés par l'AI aient consommé le temps des mainteneurs sans produire de résultats valides. Des problèmes similaires ont été signalés avec Apache Log4j 2 et le moteur de jeu Godot.

Les développeurs ont également rapporté avoir des flux de travail AI imposés par la direction. Dans un cas, des cadres supérieurs ont copié directement les résultats de l'AI en réponse à chaque problème technique rencontré par l'équipe.

Les réviseurs transformés en ingénieurs de prompt non rémunérés

Un thème dominant parmi les voix critiques était le fardeau imposé aux personnes qui doivent réviser le code généré par l'AI. "Le temps de développement a été réduit, mais l'équipe doit maintenant passer plus de temps à réviser. Cela ne semble pas être un avantage", a déclaré un développeur. Une équipe a rapporté 30 demandes de tirage par jour avec seulement six réviseurs.

Les réviseurs ont décrit le sentiment d'être "le premier être humain à poser les yeux sur ce code" et se sont plaints d'être transformés en ingénieurs de prompt non rémunérés : "Ils vous utilisent littéralement pour faire leur travail (c'est-à-dire évaluer de manière critique et comprendre leur brouillon AI et donner le prochain prompt)."

Les réviseurs ont également développé leurs propres heuristiques pour repérer le code généré par l'AI. Les emojis dans les commentaires de code sont considérés comme un indice quasi certain. D'autres marqueurs incluent des motifs de commentaires étape par étape, un style gonflé, et des artefacts Unicode. La confiance dans les processus collaboratifs en prend également un coup. Un développeur a décrit une demande de tirage d'un agent AI : "Je ne sais pas comment vous pourriez faire confiance à quoi que ce soit à un moment donné. Pas de réelle compréhension de ce qu'il fait, il ne fait que deviner."

Contre-mesures allant des limites de PR aux normes de responsabilité

L'étude documente des contre-stratégies spécifiques que les développeurs proposent ou mettent déjà en pratique :

• Limites de taille pour les demandes de tirage avec du code généré par l'AI ("moins de 500 LOC par PR ou ils ne le réviseront pas")
• Auto-révisions obligatoires avant la révision par les pairs
• Walkthroughs de code synchrones
• Double révisions de code avec des équipes externes
• Lien de la responsabilité aux évaluations de performance

Les chercheurs tirent des recommandations pour trois groupes à partir de leurs conclusions. Les développeurs d'outils devraient déplacer leur attention de la génération de code à la vérification et à la révision, par exemple, à travers des indicateurs d'incertitude et des informations sur la provenance. Les outils devraient également encourager des changements plus petits et incrémentaux et structurer leur sortie pour qu'elle soit plus facile à inspecter.

Les leaders d'équipe devraient repenser les critères d'évaluation qui récompensent le volume de production et tenir compte des coûts en aval comme l'effort de révision et les taux d'erreur. En même temps, l'étude souligne que les développeurs devraient garder le contrôle sur le moment et la manière dont ils utilisent les outils AI. Les équipes devraient également exiger que les contributeurs comprennent et expliquent leurs changements, soutenus par des pratiques telles que des limites de taille de PR et des walkthroughs de code.

Pour les institutions éducatives, les chercheurs recommandent des formats d'examen comme des examens oraux ou du codage en direct, ainsi que de limiter l'utilisation des outils AI dans les premiers cours afin que les étudiants développent d'abord des compétences fondamentales. La production de résultats seule n'est pas une preuve de compétence, affirment-ils.