CodeTaste: Can LLMs Generate Human-Level Code Refactorings?

Le papier présente CodeTaste, une nouvelle norme d'évaluation révélant que, bien que les agents LLM puissent exécuter des refactorisations lorsqu'elles sont spécifiées en détail, ils peinent à identifier spontanément les choix humains, une lacune que l'approche « proposer puis implémenter » permet de combler.

L'essentiel

🍽️ Le Grand Défi de la Cuisine : CODETASTE

Imaginez que vous avez un chef robotique ultra-puissant (c'est l'IA ou "LLM"). Ce robot est incroyable pour cuisiner de nouveaux plats : il peut suivre une recette à la lettre et créer un gâteau parfait en quelques secondes.

Mais il y a un problème : quand on lui demande de rénover une vieille cuisine (ce qu'on appelle le "remaniement" ou refactoring en informatique), il a tendance à faire des bêtises.

• Il ajoute des placards inutiles.
• Il laisse des traces de farine partout.
• Il duplique les mêmes ustensiles dix fois.
• Il rend la cuisine si complexe qu'aucun humain ne pourrait plus la nettoyer ou l'agrandir plus tard.

Les humains, eux, savent faire le ménage : ils réorganisent les placards, jettent le superflu et rendent la cuisine plus logique, sans changer le goût des plats (le code doit continuer à fonctionner).

L'article CODETASTE pose une question simple : Nos chefs robots sont-ils capables de faire ce travail de rénovation aussi bien que des humains ?

🕵️‍♂️ Comment ils ont testé les robots ? (La Méthode)

Pour répondre à cette question, les chercheurs ont créé un grand concours de cuisine appelé CODETASTE. Voici comment ça marche :

1. La Chasse aux Trésors : Ils ont fouillé dans des milliers de cuisines (des projets informatiques réels sur Internet) pour trouver 100 exemples de rénovations réussies faites par de vrais humains.
2. Le Laboratoire de Test : Pour chaque exemple, ils ont recréé une cuisine exacte dans un laboratoire virtuel. Ils ont aussi créé une "règle de sécurité" magique (un détecteur de code) qui vérifie deux choses :
   • Est-ce que les plats sortent toujours bons ? (Les tests passent-ils ?)
   • Est-ce que la cuisine est vraiment plus rangée ? (Les mauvaises habitudes ont-elles disparu ?)
3. Les Deux Épreuves : Ils ont fait passer les robots à deux types d'exercices :
   • L'Épreuve "Recette Détaillée" (Instructed) : On donne au robot une liste précise : "Déplace ce placard ici, jette ce vieux four, et peins le mur en bleu."
   • L'Épreuve "Idée Floue" (Open) : On donne juste une idée vague : "Cette cuisine est un peu en désordre, améliore-la." Le robot doit deviner quoi faire et comment le faire.

📊 Les Résultats : Ce que les robots ont fait

Les résultats sont très clairs et un peu décevants :

1. Quand on leur donne une recette précise 📝

Les robots sont très bons. S'ils savent exactement quoi faire, ils réussissent à ranger la cuisine correctement dans environ 70 % des cas (pour le meilleur robot, GPT-5).

• Analogie : C'est comme si on leur disait "Coupe les carottes en rondelles". Ils le font parfaitement.

2. Quand on leur demande juste d'"améliorer" 🤷‍♂️

C'est là que ça coince. Quand on ne leur donne qu'une idée vague, ils réussissent à peine moins de 10 % du temps.

• Ce qu'ils font : Au lieu de réorganiser toute la cuisine, ils se concentrent sur des détails insignifiants (comme changer le nom d'un tiroir) ou ils font des solutions "bricolées" (comme mettre un bout de scotch pour cacher un problème) plutôt que de vraiment réparer la structure.
• Analogie : On leur dit "Rends cette pièce plus agréable", et ils décident de repeindre juste une seule vis en or, en oubliant que le sol est cassé.

💡 La Solution Magique : "Penser avant d'agir" 🧠

Les chercheurs ont découvert un petit truc pour aider les robots. Au lieu de leur demander de modifier la cuisine tout de suite, ils leur ont demandé de faire un plan d'abord.

• Sans plan : Le robot saute sur le marteau et casse des choses.
• Avec un plan : Le robot prend du temps pour dessiner un croquis de la nouvelle cuisine, puis il agit.
• Résultat : Cela double presque leurs performances ! C'est comme si on disait au robot : "D'abord, explique-moi comment tu vas ranger, et ensuite, fais-le."

🏁 La Conclusion en une phrase

Les robots sont d'excellents exécutants (ils font très bien ce qu'on leur dit), mais ils sont encore de très mauvais architectes (ils ne savent pas encore décider seuls de ce qui doit être amélioré dans un code complexe).

CODETASTE est donc une nouvelle "piste d'entraînement" pour aider les développeurs à entraîner ces robots à devenir de vrais chefs d'orchestre capables de garder nos logiciels propres, simples et durables, comme le font les meilleurs humains.

Résumé technique

Voici un résumé technique détaillé de l'article de recherche "CODETASTE: Can LLMs Generate Human-Level Code Refactorings?" en français.

1. Problématique

Les agents de codage basés sur les grands modèles de langage (LLM) excellent dans la génération de code fonctionnel pour résoudre des problèmes spécifiques. Cependant, ils ont tendance à accumuler de la complexité, de la duplication et de la dette technique au fil des itérations. Contrairement aux développeurs humains qui utilisent le restructuration (refactoring) pour améliorer la structure et la maintenabilité tout en préservant le comportement, les agents actuels peinent à identifier et à exécuter ces transformations de manière autonome.

Les benchmarks existants (comme RefactorBench ou SWE-Refactor) souffrent de limitations majeures :

• Ils se concentrent sur des refactorisations à petite échelle (fichiers uniques ou méthodes isolées).
• Ils ne testent pas la capacité du modèle à découvrir quelles refactorisations sont nécessaires sans instructions explicites.
• Ils deviennent rapidement obsolètes car les modèles atteignent rapidement des scores élevés sur ces tâches simples.

L'article pose la question centrale : Les agents LLM peuvent-ils exécuter des refactorisations de manière fiable et identifier les choix de refactorisation que les développeurs humains auraient faits dans de vrais codebases multi-fichiers ?

2. Méthodologie : Le Benchmark CODETASTE

Les auteurs introduisent CODETASTE, un benchmark conçu pour combler ce fossé. La méthodologie repose sur un pipeline automatisé et rigoureux :

A. Collecte et Curation des Données

• Source : Extraction de 100 instances de refactorisations complexes (multi-fichiers) à partir de dépôts GitHub open-source populaires.
• Filtrage : Un pipeline en trois étapes (filtrage par mots-clés, pré-filtrage pour éliminer les changements de documentation, et notation par un LLM) sélectionne des commits impliquant de grands changements structurels (en moyenne 91,5 fichiers et 2 605 lignes modifiées).
• Diversité : Le benchmark couvre 6 langages de programmation (Go, JavaScript/TypeScript, Java, Python, Rust, C/C++) et 87 dépôts.

B. Environnement d'Exécution

Pour chaque tâche, un environnement conteneurisé reproductible est généré. Cela inclut :

• L'installation des dépendances système et des outils de build.
• L'exécution de la suite de tests du dépôt pour valider la correction fonctionnelle.
• Une isolation stricte pour empêcher l'agent d'accéder à la solution "or" (golden patch).

C. Génération de Règles Statiques (OpenGrep)

Au lieu de se fier uniquement aux tests, le système génère des règles d'analyse statique (via OpenGrep) pour capturer l'intention sémantique de la refactorisation :

• Règles additives ($\Gamma^+$) : Patterns qui doivent apparaître après la refactorisation.
• Règles réductives ($\Gamma^-$) : Patterns indésirables qui doivent disparaître.
• Ces règles utilisent un raisonnement sur le flux de données (dataflow) pour être plus flexibles que la simple correspondance syntaxique.

D. Deux Pistes d'Évaluation

1. Piste "Instructed" (Instructe) : L'agent reçoit une description détaillée de la refactorisation à effectuer (similaire à un ticket GitHub complet). Cela teste la capacité d'exécution sur des tâches à long contexte.
2. Piste "Open" (Ouverte) : L'agent reçoit uniquement une zone de focalisation vague (ex: "Améliorer l'organisation interne"). Il doit découvrir et proposer la refactorisation appropriée, simulant un scénario réel de dette technique.

E. Métriques d'Évaluation

Le score final (Alignment Score) combine :

• Correction Fonctionnelle (PASS) : Les tests du dépôt passent-ils ?
• Taux de Respect des Instructions (IFR) : Les règles statiques sont-elles respectées (patterns ajoutés supprimés) ?
• Précision : L'agent évite-t-il les modifications non pertinentes ?

3. Résultats Expérimentaux

L'étude a évalué plusieurs agents de pointe (GPT-5.2, GPT-5.1 CODEX Mini, Claude 4.5 Sonnet, Qwen3 Coder).

A. Piste "Instructed" (Instructions Détaillées)

• Performance : Les modèles de pointe obtiennent de bons résultats lorsqu'ils sont guidés. GPT-5.2 atteint un score d'alignement de 69,6 %, suivi par Claude 4.5 (32,4 %) et GPT-5.1 Mini (34,6 %).
• Observation : Bien que les agents suivent les instructions, il existe un écart significatif dans le maintien de la correction fonctionnelle (PASS). GPT-5.2 réussit mieux car il applique des correctifs ciblés, tandis que d'autres modèles utilisent des commandes de remplacement global moins sûres.
• Coût : Les refactorisations complètes sont coûteuses en tokens et en temps (GPT-5.2 atteint souvent la limite de budget de 11 $ par tâche).

B. Piste "Open" (Découverte Autonome)

• Échec Majoritaire : Les performances s'effondrent lorsque l'agent doit identifier la refactorisation lui-même. Le score d'alignement maximal est de 7,7 % (GPT-5.2 en mode direct).
• Stratégies d'Amélioration :
  • Planification (Plan Mode) : Demander à l'agent de proposer un plan avant de coder améliore le score (passant de 7,7 % à 14,1 % pour GPT-5.2).
  • Sélection Oracle (Multiplan) : Générer plusieurs plans et sélectionner le meilleur via un juge LLM améliore encore le score à 19,4 %.
• Limites : Même avec ces stratégies, les agents peinent à reproduire les choix humains. Ils tendent vers des solutions superficielles (correction de fautes de frappe, renommages mineurs) ou des "workarounds" paresseux (shims de compatibilité) plutôt que des refontes architecturales profondes.

C. Analyse des Échecs

Les études de cas révèlent que les agents :

• Se focalisent sur des sujets évidents mais triviaux (ex: une faute de frappe) en ignorant le problème structurel global.
• Utilisent des commandes de remplacement de chaînes destructrices qui brisent l'état du dépôt.
• Ne parviennent pas à généraliser les transformations à l'ensemble du dépôt.

4. Contributions Clés

1. CODETASTE : Le premier benchmark de refactorisation à grande échelle, multi-fichiers et multi-langages, basé sur des changements réels de l'industrie.
2. Pipeline de Validation Hybride : Une combinaison de suites de tests exécutables et de règles d'analyse statique sémantique (dataflow) pour vérifier la transformation du code au-delà de la simple syntaxe.
3. Analyse de l'Alignement Humain : La démonstration qu'il existe un fossé majeur entre la capacité des LLM à suivre des instructions de refactorisation et leur capacité à découvrir et choisir les bonnes refactorisations autonomement.
4. Validation des Stratégies de Planification : La preuve que la décomposition "Proposer puis Implémenter" (Propose-then-implement) est essentielle pour améliorer l'alignement avec les décisions humaines dans des scénarios ouverts.

5. Signification et Perspectives

Ce travail met en lumière une limitation critique des agents de codage actuels : ils sont excellents pour appliquer des correctifs fonctionnels mais manquent de jugement architectural pour maintenir la qualité du code à long terme.

• Pour la recherche : CODETASTE offre une cible d'évaluation rigoureuse pour entraîner des agents à préserver la qualité du code sur le long terme.
• Pour l'industrie : Il suggère que l'intégration de mécanismes de planification explicite et de sélection de plans est nécessaire avant de déployer des agents autonomes pour la maintenance de codebases complexes.
• Futur : Les auteurs envisagent d'étendre le dataset, d'affiner la couverture des règles statiques et d'explorer des mécanismes d'apprentissage pour améliorer la génération de propositions de refactorisation.

En résumé, bien que les LLMs puissent exécuter des refactorisations complexes lorsqu'ils sont guidés, ils ne sont pas encore capables de remplacer le jugement humain pour identifier quand et comment refactoriser un codebase existant.