Résumé technique : L'influence des grands modèles de langage sur le code

Problématique

L'intégration rapide des grands modèles de langage (LLM) et des outils basés sur les LLM (par exemple, Copilot, Cursor) dans le développement logiciel a soulevé des questions concernant leur impact tangible sur les pratiques de programmation réelles. Alors que les recherches précédentes se sont concentrées sur la distinction entre le code généré par LLM et le code écrit par l'humain ou sur l'évaluation de la justesse fonctionnelle, il existe un manque de preuves empiriques quant à savoir si les LLM ont fondamentalement transformé le style de code dans le monde réel. Cet article examine la question centrale : Les LLM ont-ils transformé le style de code, et comment une telle transformation peut-elle être caractérisée ? Plus précisément, les auteurs examinent si les préférences stylistiques des LLM (par exemple, les conventions de nommage, les mesures de complexité) imprègnent les bases de code écrites par des humains au fil du temps.

Méthodologie

L'étude emploie une approche à deux volets combinant une analyse empirique à grande échelle de dépôts réels avec des simulations contrôlées.

1. Collecte de données

• Dépôts GitHub : Les auteurs ont collecté 22 074 dépôts et plus d'un million de fichiers de code source liés à des articles arXiv publiés entre le premier trimestre 2020 et le troisième trimestre 2025. Les dépôts ont été catégorisés par langage de programmation (Python, C/C++) et par domaine scientifique (Informatique vs Non-informatique).
• Base de référence humaine : Pour établir une base de référence pré-LLM, les auteurs ont utilisé Code4Bench, un ensemble de données de soumissions d'utilisateurs acceptées sur Codeforces avant 2020.
• Sous-ensemble de problèmes : Un sous-ensemble de 200 problèmes algorithmiques a été sélectionné à partir de Code4Bench, stratifié par difficulté (classement 800–2000+) et par type d'algorithme (ex: DP, Greedy, Math).

2. Simulation et génération

Les auteurs ont simulé la programmation assistée par LLM en utilisant 12 LLM diversifiés (incluant les séries Qwen3, DeepSeek-R1, GPT-4.1, Llama-4 et Gemini-2.0). Deux stratégies de génération ont été testées :

• Génération directe (ANS) : Les modèles résolvent les problèmes à partir de zéro en se basant uniquement sur les descriptions de problèmes.
• Génération guidée par référence (REF) : Les modèles reçoivent une solution humaine correcte (code AC) et reçoivent l'instruction de la réviser ou de la réécrire.

3. Métriques d'évaluation

L'étude a analysé le code selon quatre dimensions :

• Modèles de nommage : Catégorisés par formats (snake_case, camelCase, PascalCase, etc.) et mesurés par la longueur des noms.
• Complexité et maintenabilité : Mesurées via la complexité cyclomatique, les métriques de Halstead (Volume, Difficulté, Effort, Bugs) et l'indice de maintenabilité (standard et personnalisé).
• Similitude de code : Quantifiée par la similitude cosinus et la similitude de Jaccard entre le code humain, la génération directe et la génération guidée par référence.
• Alignement du raisonnement : Analyse de la correspondance entre les étiquettes algorithmiques dans la chaîne de raisonnement du modèle et les étiquettes réelles du problème.

Principales contributions et résultats

1. Preuve de la transformation du style (Modèles de nommage)

L'étude fournit la première preuve empirique à grande échelle que les LLM influencent les styles de codage humains.

• Adoption des préférences des LLM : En Python, la proportion de noms de fonctions en snake_case dans les dépôts GitHub est passée de 40,7 % au T1 2023 à 49,8 % au T3 2025. Cette tendance s'aligne sur la préférence observée dans le code généré par les LLM.
• Nommage des variables : Les LLM préfèrent systématiquement des noms de variables plus longs et plus descriptifs (ex: max_length au lieu de ml) et évitent les noms à lettre unique ou avec suffixe numérique. Les dépôts GitHub montrent une baisse parallèle des noms courts/à suffixe numérique et une augmentation de la longueur moyenne des noms, particulièrement dans les domaines de l'informatique.
• Différences de langage : Bien que le Python montre des tendances temporelles claires dans le nommage, les tendances en C/C++ sont moins prononcées, bien que l'usage du snake_case pour les variables et fonctions en C/C++ montre tout de même une trajectoire ascendante.

2. Complexité et maintenabilité

• LLM vs Humain : En Python, le code généré par les LLM présentait une complexité cyclomatique plus élevée que le code écrit par l'humain. Inversement, en C/C++, les LLM ont produit du code avec une complexité cyclomatique plus faible.
• Maintenabilité : Le code généré par les LLM présentait généralement des indices de maintenabilité plus élevés et un nombre estimé de bugs plus faible par rapport aux solutions humaines lors de la simulation.
• Référence-guidée vs Direct : En Python, la génération guidée par référence (réécriture de code existant) a produit un code plus concis (volume/effort de Halstead plus faible) que la génération directe. En C/C++, l'observation inverse a été faite.

3. Similitude de code

• Capacité d'imitation : Lorsqu'ils sont fournis avec un code de référence, les LLM produisent des solutions présentant une similitude nettement plus élevée (Cosinus et Jaccard) avec le code humain original par rapport à la génération directe.
• Divergence : Sans guidage par référence, le code généré par les LLM dans les tâches d'algorithmes d'E/S (I/O) divergeaient considérablement en style du code écrit par l'humain, suggérant que les LLM possèdent des styles "natifs" distincts qui diffèrent des normes humaines, à moins d'être explicitement conditionnés.

4. Raisonnement et compréhension algorithmique

• Correspondance d'étiquettes : L'analyse des chaînes de raisonnement a révélé que les LLM échouent souvent à mentionner explicitement les étiquettes algorithmiques correctes (ex: "DP", "Greedy") associées au problème.
• Taux d'erreur : Le taux d'erreur (identification d'algorithmes incorrects) a généralement dépassé le taux de correspondance (identification d'algorithmes corrects).
• Biais de langage : Les modèles ont tendance à s'appuyer davantage sur le raisonnement algorithmique pour les tâches en C/C++ par rapport au Python, où ils se concentrent davantage sur les détails d'implémentation pratique.
• Corrélation avec la difficulté : Les taux de correspondance et d'erreur augmentent tous deux avec la difficulté des problèmes, suggérant que les problèmes plus difficiles activent mieux les capacités de raisonnement algorithmique des modèles, bien qu'avec plus de bruit.

Signification et affirmations

L'article affirme fournir la première preuve empirique à grande échelle que les LLM ne sont pas seulement des outils de génération de code, mais qu'ils remodèlent activement le paysage stylistique de la programmation réelle.

• Changement de normes : Les auteurs soutiennent que les styles de codage humains évoluent vers les conventions préférées des LLM (ex: snake_case, noms plus longs), créant une boucle de rétroaction où les développeurs humains s'alignent subtilement sur les normes générées par la machine.
• Au-delà de la détection : Contra�à les travaux précédents axés sur la détection de code généré par IA, cette étude se concentre sur l'influence des LLM sur l'évolution du style de code, soulignant que l'impact des LLM s'étend au-delà de la justesse fonctionnelle pour toucher les normes esthétiques et structurelles.
• Implications : Les conclusions suggèrent qu'avec l'adoption croissante des LLM, la distinction entre le style "humain" et "machine" pourrait s'estomper, nécessitant une réévaluation de la manière dont la qualité et le style du code seront évalués à l'avenir.

Les auteurs restent modestes quant à leurs affirmations, reconnaissant des limites telles que l'incapacité de quantifier le pourcentage exact de code généré par les LLM dans le monde réel et le caractère potentiellement incomplet de la base de référence pré-LLM (Code4Bench) pour représenter tout le spectre des styles de codage humains. Ils soulignent que leur travail identifie des traces d'influence plutôt qu'une causalité définitive pour tous les changements observés.