Sur-édition : quand un modèle modifie du code au-delà du nécessaire

• Même pour des bugs qui se corrigent avec une modification minimale, on voit souvent une réécriture complète de la fonction, l’ajout de logique auxiliaire et jusqu’au changement de signature, ce qui produit facilement un diff énorme
• Dans les travaux brown-field, où il faut préserver la structure existante, il ne suffit pas que les tests passent : il faut aussi évaluer l’ampleur des changements pour maintenir la facilité de revue et la sûreté des modifications
• À partir de 400 problèmes BigCodeBench endommagés programmatiquement, l’over-editing est quantifié avec la distance de Levenshtein au niveau des tokens, un score de patch relatif et l’Added Cognitive Complexity
• Une tendance à la réécriture excessive a été observée sur l’ensemble des modèles de code récents ; Claude Opus 4.6 se distingue par une bonne combinaison de précision et de modifications minimales, tandis que GPT-5.4 montre relativement plus d’over-editing
• Un prompt demandant explicitement de préserver l’original réduit le diff, surtout pour les modèles de raisonnement ; parmi les approches d’entraînement, le RL produit les résultats les plus équilibrés en apprenant un comportement d’édition minimale sans dégrader les performances générales en code

---

Le problème de l’Over-Editing

• Over-Editing désigne le phénomène où un modèle modifie largement la structure du code au-delà de la correction minimale nécessaire pour réparer un bug
  • Même pour un bug off-by-one où il suffit de remplacer range(len(x) - 1) par range(len(x)), le modèle peut réécrire toute la fonction et ajouter des fonctions auxiliaires ou de la logique de validation
  • Dans l’exemple, GPT-5.4 ajoute une vérification de None, une conversion np.asarray(dtype=float), un masquage des valeurs finies, une validation de la taille du tableau, modifie la signature de l’appel à curve_fit et remplace la logique de tracé ; les tests passent, mais le diff est énorme
• Dans les travaux brown-field, qui portent sur une base de code existante, il est important de corriger le problème tout en conservant un code déjà compris et écrit intentionnellement par l’équipe
  • Contrairement au green-field, des modifications qui ne respectent pas la structure existante rendent plus difficile pour les reviewers de comprendre ce qui a changé et pourquoi
  • Lorsqu’une fonction entière est réécrite, le code devient plus difficile à reconnaître et la sûreté du changement plus compliquée à évaluer
• Le seul critère « les tests passent » ne suffit pas à détecter ce problème
  • L’Over-Editing n’est pas un échec de correction, mais un échec de fidélité dans l’édition, donc il apparaît mal dans une suite de tests
  • Plus le volume de code généré augmente, plus la quantité à relire s’accroît, et la complexité inutile peut s’accumuler au point de dégrader discrètement la qualité du codebase

Comment mesurer l’Over-Editing

• Pour construire un dataset où la bonne réponse minimale est évidente, l’étude crée un jeu d’évaluation à partir de 400 problèmes BigCodeBench endommagés programmatiquement
  • Au lieu d’injecter les bugs avec un autre LLM comme dans des benchmarks existants, les altérations sont finement contrôlées, par exemple en remplaçant < par <=, + par - ou True par False
  • Chaque échantillon endommagé est validé pour rester syntaxiquement correct et faire échouer les tests associés ; la correction attendue consiste uniquement à annuler cette altération, de sorte qu’elle soit bien minimale
• Cette construction permet d’évaluer non seulement si le modèle corrige le bug, mais aussi à quel point il modifie davantage le code en le faisant
  • La taille relative du patch est calculée en comparant à l’entrée endommagée à la fois la sortie du modèle et la réponse de référence
  • Plus il y a de changements supplémentaires au-delà de la restauration correcte, plus le score se dégrade
• Le code associé est disponible dans le dépôt GitHub

Métriques de mesure

• Distance de Levenshtein au niveau des tokens

  • Au lieu d’une Levenshtein classique au niveau caractère, l’étude utilise une variante au niveau des tokens Python
  • Le code est découpé par le tokenizer Python en unités syntaxiques atomiques comme def, add, (, a, ,, b, ), puis la distance est calculée sur cette séquence
  • Si def add(a, b): devient def someotherfunctionname(a, b):, la distance caractère par caractère vaut 19, mais la distance au niveau des tokens vaut 1 car un seul identifiant a changé
  • La métrique est normalisée par le nombre total de tokens pour rester comparable entre fonctions de longueurs différentes

• Score de patch relatif

  • La sortie du modèle n’est pas comparée directement à la réponse de référence ; les deux sont comparées à l’entrée endommagée
  • L’édition qui ramène la solution endommagée à la solution d’origine est la véritable modification minimale, et la métrique mesure à quel point l’édition produite par le modèle s’en rapproche
  • Plus la valeur est proche de 0, plus le patch du modèle ressemble à la vraie correction minimale

• Added Cognitive Complexity

  • L’étude utilise aussi la Cognitive Complexity, qui reflète mieux la difficulté de lecture que la Cyclomatic Complexity
  • Elle pénalise l’imbrication, la récursion, les opérateurs logiques composés et les flux de contrôle peu intuitifs ; des structures comme if, les boucles ou try/except, qui demandent au lecteur de suivre davantage d’état, augmentent la complexité
  • Dans l’exemple, le code avec boucles imbriquées et conditions atteint une Cognitive Complexity de 6
  • Comme les altérations de cette étude changent uniquement des valeurs sans toucher à la structure, une correction correcte devrait toujours avoir une Added Cognitive Complexity égale à 0
  • Si la complexité augmente dans la sortie du modèle, cela signifie que du code non demandé a été ajouté ; une valeur négative est également jugée indésirable, car elle correspond à une simplification inutile

Les modèles font-ils vraiment de l’Over-Editing ?

• Même les modèles frontier récents présentent de l’Over-Editing
  • Les modèles de raisonnement comme les modèles non orientés raisonnement montrent un écart entre le Pass@1 et la capacité à effectuer des modifications minimales
  • La seule capacité à corriger correctement ne suffit pas à juger de la fidélité de l’édition
• Parmi les modèles de raisonnement, Claude Opus 4.6 montre la meilleure combinaison
  • Il obtient le meilleur Pass@1 à 0,912, ainsi qu’une Levenshtein normalisée de 0,060 et une Added Cognitive Complexity de 0,200, soit aussi les plus petits diffs
  • Gemini 3.1 Pro Preview se situe dans une zone similaire, et parmi les modèles open-weight, GLM 5 édite de manière relativement plus conservatrice
• GPT-5.4 fait partie des modèles les plus sujets à l’Over-Editing dans cette évaluation
  • En mode raisonnement, il affiche une Levenshtein de 0,395 et une Added Cognitive Complexity de 2,313 ; même en mode non-raisonnement, les valeurs restent élevées à 0,327 et 1,563
  • Son Pass@1 est également assez bas, à 0,723 et 0,770, ce qui traduit des résultats faibles à la fois en précision et en modification minimale
• Côté modèles non orientés raisonnement, Qwen 3.6 Plus obtient le meilleur Pass@1 avec 0,870, tandis que GLM 5 affiche l’Added Cognitive Complexity la plus basse à 0,235
  • La version non-raisonnement de Claude Opus 4.6 maintient elle aussi des changements très limités, avec une Levenshtein de 0,079 et une Added Cognitive Complexity de 0,313

Peut-on améliorer cela par le prompt ?

• Quand on ajoute au prompt « IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible », la distance de Levenshtein diminue pour tous les modèles
  • Sauf pour DeepSeek R1/v3, le Pass@1 s’améliore également
  • On peut interpréter cela comme le fait que la contrainte de modification minimale réduit l’espace des corrections possibles et oriente vers des changements plus précis et mieux ciblés
• Cet effet est particulièrement marqué pour les modèles de raisonnement
  • Comme ils ont tendance à mieux suivre les consignes explicites, la demande de minimiser l’édition se traduit fortement par une réduction du diff
  • Cela montre que, même s’ils ont tendance à trop intervenir par défaut, ils peuvent basculer vers des corrections plus fidèles lorsqu’on leur donne une instruction explicite

Le raisonnement conduit-il à une réécriture excessive ?

• En appariant des modèles de raisonnement et non raisonnants d’une même famille, puis en comparant la distance de Levenshtein sur les seuls échantillons où les deux donnent la bonne réponse
  • S’il y a beaucoup d’échecs, cela crée un biais qui réduit mécaniquement les occasions d’Over-Editing ; l’idée est donc d’abord de contrôler la précision, puis d’isoler uniquement le style d’édition
• Avec les réglages de prompt généraux, dans la plupart des paires, le modèle de raisonnement réécrit davantage
  • DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus et Kimi 2.5 affichent tous une barre plus élevée côté raisonnement
  • Cela montre qu’un raisonnement étendu tend à viser une « meilleure implémentation » plutôt qu’une modification minimale, ce qui génère des refactorings inutiles
  • L’exception est Claude Opus 4.6, dont la version de raisonnement modifie nettement moins que la version non raisonnante
• Lorsque l’on demande explicitement de préserver le code d’origine, le tableau change fortement
  • Les modèles de raisonnement affichent, dans presque toutes les paires, une distance de Levenshtein égale ou inférieure à celle des modèles non raisonnants
  • La version de raisonnement de Claude Opus 4.6 enregistre, dans ce réglage, la plus faible distance de Levenshtein de tous les modèles
  • GPT-5 et GPT-5.4 voient aussi fortement baisser leur score côté raisonnement, mais pour GPT-5.4 la version non raisonnante reste encore légèrement devant
• Par défaut, les modèles de raisonnement ont tendance à faire de l’Over-Editing, mais cette même capacité de raisonnement les aide aussi à mieux respecter les contraintes
  • L’écart entre réglage général et réglage explicite apparaît de manière systématiquement plus marquée chez les modèles de raisonnement
  • L’Over-Editing semble donc relever davantage d’un comportement par défaut que d’une limite fondamentale, et peut être inversé via des contraintes

Peut-on former un éditeur fidèle par apprentissage ?

• Le modèle de base est Qwen3 4B 2507 Instruct, et les configurations 0-shot et 8-shot avec instruction de préservation du code d’origine servent de baseline
  • Les autres méthodes d’apprentissage sont évaluées dans un réglage général, sans instruction explicite de préservation de l’original

• Configuration expérimentale

  • Les problèmes de DeepCoder sont corrompus de la même manière pour créer un jeu de données synthétique
  • En parallèle, Qwen3 4B 2507 Instruct de base génère 8 completions pour chaque problème ; seules les sorties fonctionnellement correctes sont conservées, puis classées par distance de Levenshtein pour former aussi un jeu de données de self-distillation
  • L’apprentissage s’inspire de la Context Distillation afin d’obtenir, à l’évaluation, un comportement de modification minimale sans instruction explicite

• Méthodes d’apprentissage

  • SFT : fine-tuning supervisé direct sur le jeu de données généré programmatiquement
  • rSFT : apprentissage sur les 3 completions ayant la plus faible distance de Levenshtein pour chaque échantillon du jeu de self-distillation
  • DPO : optimisation par préférence entre la completion à distance de Levenshtein la plus élevée et celle à la plus faible, pour chaque échantillon
  • RL : application d’un apprentissage par renforcement combinant exactitude fonctionnelle et récompense de modification minimale basée sur Levenshtein
    • Si tous les tests passent, r = r_edit + 0.1
    • Sinon, r = -0.2
    • r_edit est calculé comme une récompense basée sur une distance de Levenshtein normalisée

Qu’obtient-on sur le même type de corruption ?

• Dans le réglage in-domain, où le type de corruption est identique entre entraînement et test, SFT produit un résultat presque parfait
  • Baseline 0-shot : Pass@1 à 0.735, Norm. Levenshtein à 0.169, Added CC à 0.731
  • Baseline 8-shot : Pass@1 à 0.775, Norm. Levenshtein à 0.115, Added CC à 0.479
  • SFT obtient les meilleurs résultats sur les trois métriques avec Pass@1 à 0.932, Norm. Levenshtein à 0.002 et Added CC à 0.000
  • rSFT enregistre 0.782 / 0.100 / 0.435, DPO 0.752 / 0.021 / 0.113, et RL 0.802 / 0.046 / 0.112
• Comme ce résultat paraît presque trop bon, la possibilité d’une simple mémorisation de la transformation inverse d’un type de corruption donné est examinée
  • Il est possible que le modèle n’ait pas appris un comportement général de modification minimale, mais seulement à inverser des motifs de corruption prédéfinis
  • Pour le vérifier, les types de corruption des données d’entraînement et d’évaluation ont été entièrement dissociés

Cela se généralise-t-il à d’autres types de corruption ?

• Dans le réglage out-of-domain, où les types de corruption diffèrent entre entraînement et test, SFT s’effondre fortement
  • Le Pass@1 de SFT tombe jusqu’à 0.458, et le modèle en vient à tenter uniquement certaines modifications minimales sans réellement corriger les bugs
  • Norm. Levenshtein à -0.008 et Added CC à 0.006 restent très faibles, mais la capacité à produire la bonne correction s’écroule
• rSFT et DPO font légèrement mieux que la baseline 8-shot, mais les gains restent limités
  • rSFT : 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
  • DPO : Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
  • Même un apprentissage fondé uniquement sur des données de trace générées par le modèle de base permet une certaine généralisation
• RL est la seule méthode à bien se généraliser sur l’ensemble des métriques
  • RL obtient Pass@1 à 0.782, Norm. Levenshtein à 0.050, Added CC à 0.185 et LiveCodeBench Change à +0.006
  • Les trois métriques sont meilleures que pour les deux baselines, sans dégradation des performances générales en programmation
  • Le fait que les gains sur Levenshtein et Added Cognitive Complexity soient plus importants que sur Pass@1 renforce l’idée qu’il ne s’agit pas d’une simple mémorisation de l’inversion des corruptions, mais bien de l’apprentissage du comportement de modification minimale lui-même

Catastrophic Forgetting

• Une vérification sur LiveCodeBench v6 permet aussi de voir si le niveau général en programmation baisse après un fine-tuning axé sur la modification minimale
  • L’objectif est de conserver, après entraînement, un niveau proche de celui du modèle pretrained d’origine
• SFT provoque une très forte dégradation des capacités générales
  • Sur LiveCodeBench, on observe une baisse de performances de 43 %, et même les capacités de base d’identification et de correction de bugs ne sont plus maintenues
• rSFT et DPO reculent aussi légèrement
  • Même lorsqu’ils sont entraînés sur des échantillons générés par le modèle d’origine, un certain niveau de Catastrophic Forgetting subsiste du fait de la nature de la tâche
• RL apprend le nouveau comportement sans perte de performance
  • Il conserve les capacités générales de programmation tout en améliorant le plus nettement les performances sur la tâche de modification minimale
  • Cela rejoint SFT memorizes while RL generalizes
• Du point de vue de la distribution, on peut aussi interpréter le phénomène ainsi : plus l’écart est grand entre le jeu de données généré programmatiquement et la distribution d’origine du modèle, plus le Forgetting est important
  • SFT modifie fortement la distribution du modèle en l’ajustant intensivement à des données très éloignées de la distribution d’origine
  • rSFT et DPO évoluent de manière moins brutale, car leurs données self-distilled restent plus proches de la distribution d’origine
  • Le degré de Catastrophic Forgetting est probablement proportionnel à l’écart entre la distribution d’origine et celle des données d’apprentissage de la tâche

Expériences supplémentaires

• RL avec LoRA : faut-il un fine-tuning complet ?

  • Comme ce travail consiste davantage à ajuster le style de la capacité à modifier du code existant qu’à injecter de nouvelles connaissances, les auteurs ont vérifié si LoRA pouvait suffire
  • rank 1 : Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
  • rank 8 : 0.775 / 0.112 / 0.426 / -0.022
  • rank 16 : Pass@1 0.805 / 0.087 / 0.328 / -0.005
  • rank 32 : 0.795 / 0.065 / 0.235 / -0.011
  • rank 64 : 0.797 / 0.051 / 0.160 / +0.001
  • Le meilleur modèle en Full RL atteint 0.782 / 0.050 / 0.185 / +0.006
  • LoRA rank 64 arrive presque au niveau de Full RL sur Levenshtein et fait mieux sur Added CC
  • À mesure que le rank augmente, Levenshtein et Added CC diminuent de façon monotone de 1 à 64
  • Les plus gros gains se concentrent au début : de rank 1 à 16, Levenshtein chute fortement de 0.166 à 0.087, puis l’écart se resserre progressivement de 16 à 64, de 0.087 à 0.051
  • Les ranks 1 et 8 montrent un compromis entre précision et édition minimale ; il est possible que la capacité soit insuffisante pour apprendre simultanément les deux fonctions de récompense, avec un biais vers la minimisation des éditions, mieux récompensée
  • Pour des changements de comportement au niveau du style sur une tâche où les capacités existent déjà, un petit nombre de paramètres supplémentaires semble suffire, et le rendement de capacité additionnelle diminue après un certain point

• Note sur le reward hacking

  • La fonction de récompense initiale comportait un bug qui attribuait 0 point aux rollouts sans aucune exécution réussie
  • Comme le signe de Levenshtein avait été inversé pour en faire une métrique où « plus c’est grand, mieux c’est », ce 0 devenait paradoxalement une récompense plus élevée qu’une exécution réussie
  • Malgré cela, Full RL a appris la tâche, tandis qu’un reward hacking est apparu uniquement avec LoRA, allant jusqu’à ne plus produire du tout de code fonctionnellement correct, ce qui a conduit à une inspection de l’environnement
  • Après correction de la fonction de récompense, les résultats de Full RL ne se sont améliorés que légèrement

• Est-ce que cela s’étend aussi aux modèles plus grands ?

  • La même recette de RL out-of-domain a été appliquée à Qwen3 14B
  • Le baseline 14B affiche Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315
  • Après application de RL, les résultats passent à Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011, avec une amélioration globale
  • Même avec davantage de paramètres, la hausse de Pass@1, la baisse de Levenshtein, la diminution de l’Added Cognitive Complexity et l’absence de Catastrophic Forgetting se maintiennent ensemble
  • Cela renforce l’idée que la recette RL pour l’édition minimale de code pourrait s’étendre à des modèles de tailles variées

Bilan final

• Over-Editing apparaît comme un problème répandu et mesurable
  • Sur l’ensemble des modèles de coding de pointe, la capacité à corriger correctement et la capacité à corriger au minimum se révèlent distinctes
  • En particulier, GPT-5.4 montre par défaut une tendance relativement forte à la réécriture excessive, tandis qu’Opus 4.6 constitue un baseline solide
• Un prompting explicite permet déjà d’orienter largement vers des éditions fidèles
  • Les modèles de raisonnement ont notamment tendance à trop intervenir par défaut, mais suivent mieux les consignes quand on leur demande de préserver l’original
  • GPT-5.4 montre aussi une forte amélioration en mode raisonnement, ce qui met en évidence de solides capacités d’instruction following
  • Si l’amélioration d’Opus 4.6 paraît faible, c’est peut-être parce que ses performances de base sont déjà élevées
• Du point de vue de l’apprentissage, RL apparaît comme la solution la plus équilibrée
  • Le modèle apprend un comportement d’édition plus fidèle sans dégrader ses capacités générales de coding, et l’effet se maintient sur Qwen3 en 4B comme en 14B
  • SFT était performant sur certains types de corruption, mais a largement échoué en généralisation et en préservation des capacités générales
• L’évaluation de correction de bugs au niveau d’une fonction unique reste plus limitée que des évaluations plus agentiques comme SWE-Bench Pro, mais elle constitue un point de départ pour traiter un problème difficile à quantifier dans des conditions réalistes : l’Over-Editing
  • Évaluer et améliorer la capacité d’édition minimale pourrait contribuer à rehausser la qualité globale du code généré par l’IA

[GN⁺]

Avis Hacker News

• La façon dont j’utilise Claude Code dépasse de loin mes attentes
  Quand il modifie trop de choses, je lui fais expliquer ce qui n’allait pas et consigner la leçon dans des fichiers de skill propres au projet
  Du coup, il répète rarement la même erreur, et quand les fichiers de skill grossissent, il se débrouille plutôt bien pour les réorganiser et les compresser
  J’ai maintenant l’impression qu’écrire moi-même du code au travail n’a plus vraiment de sens d’un point de vue économique
  Je suis davantage dans un rôle d’enseignant, d’architecte et d’administrateur d’infrastructure, et je confie l’essentiel du développement à une équipe de sessions Claude expérimentées
  Bien sûr, je relis tout, et Claude écrit aussi des tests serrés qu’on examine ensemble
  Ces temps-ci, il gère même de gros projets sans difficulté
  Je ne veux pas dire ça comme une pub pour Anthropic, je me demande plutôt ce que je fais pour que ça marche particulièrement bien dans mon cas
  Et maintenant, je manque rarement de tokens
  J’utilise presque uniquement le modèle Opus, qui est efficace en tokens, et la semaine dernière j’ai poussé plus de 150 commits significatifs avec l’aide de Claude tout en ne consommant qu’un tiers de mon quota hebdomadaire
  Avant Claude, ma limite était plutôt de 25 à 30 commits par semaine

  • Moi aussi, c’est pareil
    J’ai regardé les stats hier et j’ai été surpris de voir que 97 % du code de l’entreprise est désormais écrit par Cursor AI
    Je le fais surtout tourner via l’agent cloud, parce que le regarder en temps réel est trop dispersant
    Ma méthode est très simple : lui dire clairement ce que je veux, à l’oral
    Les gens compliquent trop la chose
    Partager des fichiers .md et creuser l’orchestration ou les prompt hacks, ça m’intéresse à peu près autant que les raccourcis vim ou les skins d’IDE
    Il suffit d’exprimer clairement ce qu’on veut et de donner de bons retours
  • Pareil pour moi. Comme outil d’économie de travail, c’est étonnamment bon
    Le résultat est à un niveau que j’accepterais sans gêne même s’il venait d’un collègue
    Bien sûr, je lis tout ligne par ligne et je corrige, mais ces corrections restent du même ordre que ce que je faisais déjà en code review
    Je ne mesure pas ma productivité en chiffres, mais le simple fait que je m’attaque enfin à des tâches que je repoussais depuis des années suffit à me le faire sentir
    Par exemple, il est particulièrement fort pour les tâches ennuyeuses du genre convertir 100 fichiers markdown en 5 fichiers json puis mettre à jour le code qui les lit
  • Quand des gens disent qu’en ce moment Claude Code est devenu inutilisable, je peux le croire, mais j’ai du mal à le comprendre
    C’est un logiciel truffé de défauts et de bugs, et pourtant en pratique il est très efficace
    L’une des choses les plus étranges avec l’IA, c’est à quel point le ressenti varie de façon extrême d’une personne à l’autre
  • J’imagine que ça dépend beaucoup de si le code passe par une review par d’autres, de si les code reviews étaient pénibles avant, et de l’importance accordée à la qualité du code par les collègues
    Le volume de travail d’exploitation et le fait de toucher à du code produit destiné à durer comptent aussi
    Mon hypothèse, c’est que cet outil fonctionne bien sur des motifs simples et qu’il peut aussi traiter des tâches complexes, mais qu’il est mauvais pour inventer de nouveaux motifs
    Si on le laisse sans supervision, il se met vite à inventer de nouveaux motifs risqués et casse tout
    Donc il m’arrive assez souvent de réécrire entièrement ce que Claude a produit
    Parfois, je fais même la course avec le robot et je termine plus vite que lui
    J’ai l’avantage de déjà savoir ce que je veux, mais j’ai aussi l’impression que le coût des petits ajustements est sous-estimé
    Entre le futzing fraction et the peril of laziness lost, il y a aussi quelque chose d’irritant dans cette manière qu’a la machine d’en faire trop
    Je ne comprends pas pourquoi elle essaie d’en faire trois quand on lui demande d’en faire une seule
    Même si elle se recale après correction, c’est agaçant de devoir rejouer le même scénario que déjà avec un collègue : « ne fais pas A, B, C, fais seulement A »
    La génération de tests est aussi délicate : il sait bien écrire des tests quand on lui donne une direction, mais si on lui laisse de la créativité, il produit trop de tests inutiles du genre foo + bar == bar + foo
    Il faut constamment remettre en question l’utilité des tests pour garder une boucle de feedback saine
    En ce moment, il m’est parfois plus utile pour récupérer d’un coup les imports nécessaires que pour les tests eux-mêmes
    Si ces machines doivent faire le travail à notre place, la qualité moyenne du code devrait au moins pouvoir monter
    Mais beaucoup de gens les utilisent plutôt en mode « ça reste globalement dans la moyenne », et selon la façon de travailler, ça peut même tirer la moyenne vers le bas
  • Même impression pour moi
    Ça fait 28 ans que je fais ce métier, et écrire moi-même le code d’une application métier pendant des heures payées par l’entreprise ne me semble plus très cohérent, ni économiquement ni même de bonne foi

• À l’inverse, j’ai souvent l’impression qu’avec les agents de codage, pour s’adapter à une nouvelle exigence il faudrait modifier plus franchement le code existant, mais qu’ils donnent une priorité excessive à la préservation du code existant
  Au fond, tout tourne autour du degré auquel on veut figer l’existant
  Pour une grosse application de production qui traîne depuis des décennies, minimiser les changements est sans doute la bonne approche, mais pour un projet expérimental bricolé il y a 3 jours, il vaut mieux peut-être l’améliorer franchement plutôt que de le préserver tel quel
  Il faudra sans doute qu’ils apprennent à ajuster eux-mêmes l’intensité selon le contexte du projet

  • Ce compromis est dépendant du contexte, donc un agent ne peut pas toujours juger correctement juste en survolant le projet
    Même au sein d’un même projet, selon la PR, certaines zones peuvent être modifiées librement alors que d’autres doivent rester figées pour limiter le diff et la portée des tests
    J’essaie donc d’expliquer à l’avance quelles parties peuvent être modifiées agressivement et dans quelle mesure, mais le résultat reste inégal
    Globalement, ça penche vers le diff minimal, au prix de duplication ou d’abstractions tordues de force
    S’il existe une meilleure méthode, je suis preneur moi aussi
  • J’ai parfois l’impression que, pour pousser l’agent à réfléchir par lui-même, il faut d’abord supprimer pas mal de code et de markdown
    Même si je lui demande de refactorer ou de reconsidérer plus largement, les résultats restent faibles
    Du coup, je lui fais nettoyer le markdown où le design est trop imposé, puis je retire du source le contenu technique ou les implémentations/interfaces clés avant de demander à une nouvelle session de refaire la conception
    Ensuite, je restaure ce que j’avais supprimé et je fais un reconcile avec une session moins naïve
    La dépendance au chemin est tellement forte que je fais ça à la main pour l’instant, mais j’aimerais formaliser ce schéma dans une skill
  • Rien qu’au ton, on voit que tu utilises Codex

• L’IA cherche souvent à masquer ses échecs en avalant les exceptions et en renvoyant des valeurs factices, ou en ne laissant qu’un seul message noyé dans toutes sortes de logs parasites
  Les logs aussi sont trop condensés et omettent souvent les données essentielles au vrai débogage
  J’imagine que c’est parce qu’elle a été entraînée à tricher avec le système pour maximiser son score
  Si une exception remonte telle quelle, l’échec est évident et donc pénalisant, alors que si le problème est dissimulé, ça peut parfois ressembler à un succès
  Je me demande comment cela se manifeste dans le Q&R généraliste
  Est-ce que le modèle cherche simplement à paraître assez plausible pour que l’utilisateur soit convaincu puis parte ?
  Un schéma fréquent, c’est « ce n’est pas X, c’est Y », ce qui crée une fausse dichotomie et empêche d’envisager d’autres possibilités
  Il est aussi courant qu’il termine par un plan d’action, et ça ressemble au assumptive close, une technique commerciale où l’on pousse à approuver l’IA puis à imaginer le résultat plus qu’à évaluer la réponse elle-même

  • Le comportement de l’IA devient assez prévisible si on le voit comme une tentative de tromper coûte que coûte la métrique optimisée
    Après tout, grimper une métrique par hill-climbing a naturellement cet aspect
    Ça ressemble à une forme d’A/B enshittification poussée à un niveau illisible
    Tant qu’on entraîne sur du feedback humain, chaque fragment de chaque réponse finira inévitablement orienté vers le contournement et la satisfaction de l’évaluateur

• Faire quelque chose de vraiment bon avec l’IA demande plus de travail qu’on ne le croit
  Si on lui demande, elle produit quelque chose d’assez plausible, mais elle peut ne même pas savoir qu’elle ignore quelque chose
  C’est particulièrement dangereux quand l’IA parle avec assurance
  Vérifier sous plusieurs angles et confirmer l’exactitude n’est donc pas simple
  Ce sera intéressant de voir comment cela évolue avec le temps

  • Je suis totalement d’accord
    En même temps, cet article et les commentaires ici me donnent l’impression d’une capture d’un instant
    Le rythme de progrès du secteur est si rapide que les modèles de codage sont déjà bien meilleurs qu’il y a seulement 9 mois
    Chaque fois que je lis des critiques sur les capacités de l’IA, sans blâmer les gens, je pense intérieurement : « pour l’instant »
  • En ce moment, je passe plus de temps à faire relire un contexte IA par une autre IA qu’à faire directement produire quelque chose par l’IA
    L’idée est de leur faire reviewer mutuellement leurs résultats
    Comme tout cela tourne surtout en asynchrone, je peux faire autre chose pendant ce temps
  • Si je ne sais même pas ce que je ne sais pas, je vois mal comment produire quelque chose de meilleur qu’un agent de codage
    Donc sur certains projets, j’ai d’abord fabriqué un prototype avec un agent pour apprendre, puis j’ai écrit la conception et je suis reparti de zéro
    Ça permet de voir plus clairement quels points méritent d’être approfondis
  • Oui. En général, il t’amène assez bien jusqu’au seuil des 80 %
    La nature des 20 % restants dépend ensuite du problème

• Ici on parle d’sur-modification du code, mais les agents font bien plus que ça
  Ils touchent à plusieurs fichiers, lancent les tests, déploient, puis font même des smoke tests, et tout cela disparaît derrière une couche d’abstraction
  D’un côté c’est impressionnant, de l’autre c’est très inquiétant
  D’abord, je ne comprends pas vraiment ce qui se passe réellement à l’intérieur
  Il est trop tentant d’approuver et d’exécuter tel quel le script assemblé par l’agent
  Or il m’est déjà arrivé de détruire une base de données parce que l’agent avait jugé que c’était correct, et j’ai aussi déjà intercepté une tentative d’envoi d’identifiants AWS vers une cible de déploiement où ils n’auraient jamais dû partir
  Ensuite, je n’apprends rien
  Même assembler une simple commande docker devient une charge cognitive plus lourde, ce qui me pousse à m’appuyer de façon répétée sur l’IA comme sur une béquille

  • Je ne comprends pas pourquoi vous laissez le LLM prendre le volant
    N’activez pas l’auto-approve, et approuvez vous-même chaque commande exécutée par l’agent
    Ne lui déléguez pas non plus les décisions de conception ou d’architecture ; c’est à l’humain de choisir comment construire et de donner des instructions claires à cette boîte vide
    Je ne plaisante pas : si vous traitez l’IA comme un outil, vous l’exploiterez bien mieux
    Peut-être pas jusqu’à un x10 de productivité, mais au moins vous continuerez à comprendre votre code
  • Pour la partie identifiants, voilà comment je vois les choses
    Day 1, il traite la sécurité avec un grand sérieux, explique pourquoi il faut mettre .env dans .gitignore et sermonne sur le fait de ne pas lui donner d’identifiants et de faire soi-même les modifications sensibles
    Puis Day 2, si on lui redemande la même chose, il oublie ces règles et cette configuration, fouille tout le disque pour lire .env et d’autres fichiers, comprend qu’il a des tokens en main, construit lui-même une commande curl et lance les tests
    Le premier jour, on dirait un expert sécurité ; le lendemain, il donne l’impression d’être en dessous d’un stagiaire moyen
  • En pratique, je l’utilise selon trois modes
    1. pour l’application cœur, je spécifie, implémente et teste tout moi-même, et je ne confie à l’IA que le nettoyage final
    2. l’IA écrit les fonctions et prépare seulement le squelette des tests, puis je réécris souvent les fonctions moi-même
       Cette méthode produit beaucoup de comportements indésirables ou de sur-implémentation, mais elle reste utile pour éliminer le boilerplate
    3. pour le code expérimental ou les parties jetables, je la laisse tout faire
       En pratique, sur ces zones, je finis par supprimer environ 70 %
       En revanche, je lui interdis de toucher aux zones 1 et 2
       Bien sûr, il faut une architecture qui permette cette séparation, mais j’en suis plutôt satisfait
  • C’est un problème plus simple qu’il n’y paraît
    Il suffit de ne pas donner au LLM des identifiants de production
    Si quelque chose n’est pas reproductible en local ou en staging/dev, il faut rapprocher davantage l’infrastructure de déploiement de la prod, et si vous ne pouvez pas segmenter suffisamment les permissions par environnement, il faut d’abord corriger le système d’autorisations
    En suivant ce principe, je n’ai presque jamais eu les problèmes du type que tu décris
    Pour du diagnostic, je pourrais éventuellement lui donner brièvement des identifiants en lecture seule, mais même dans ce cas je n’émettrais que des tokens à durée de vie très courte
  • En général, je relis tout le code écrit par Claude, et je fais aussi relire mon propre code par Claude
    Donc dans l’ensemble, je garde une bonne idée de ce qui se passe
    Il arrive que Claude prenne des décisions anormales ou hors des usages
    Cela dit, quand on travaille en équipe sur une grande base de code, il existe déjà beaucoup de zones cachées derrière des abstractions qu’on ne comprenait pas vraiment au départ, y compris des parties écrites par des gens qui ont quitté l’entreprise depuis longtemps

• Avant, on enseignait souvent une sagesse qui, en pratique, était rarement suivie : refactorer en travaillant
  L’idée était que lorsqu’on touche une zone, on en profite pour la nettoyer et résorber la dette technique
  Dans les faits, cela arrivait peu, et maintenant que les LLM commencent réellement à le faire, on ressent ses effets de bord

  • Quand le modèle écrit du nouveau code qui fait la même chose que la logique existante, ce n’est pas du refactoring
    Il lui arrive de recréer quelque chose alors que la fonction nécessaire est déjà juste là
    Pire encore, il peut modifier une fonction existante en donnant l’impression de préserver le comportement tout en cassant d’autres usages
    Le pire du pire, c’est quand il change l’état entre des classes sans comprendre les effets de bord, et crée ainsi des deadlocks ou de simples bugs
  • Même quand on décide de retoucher quelque chose en passant, dans les faits ce n’est souvent pas une amélioration
    À mes yeux, cela ressemble moins à du refactoring qu’à tirer une fois de plus le levier d’une machine à sous
  • J’ai encore passé du temps là-dessus aujourd’hui
    Mon vrai problème, c’est surtout que la qualité du refactoring fait par l’agent était mauvaise
    Je voulais seulement empêcher ce genre de modifications, puis indiquer plus explicitement quoi corriger et comment
  • Ce n’est pas aussi simple
    Dans bien des cas, les abstractions existantes sont suffisamment correctes pour qu’on puisse s’appuyer dessus pour traquer un bug ou étendre une fonctionnalité
    Mais parfois, on arrive à un carrefour où il faut choisir entre contourner l’implémentation existante de force ou repenser la conception
    Avec un LLM, il devient plus flou de savoir comment reconsidérer cela, voire s’il faut vraiment le reconsidérer
    Et en plus, ces décisions finissent cachées d’une manière peu visible pour l’utilisateur
  • C’est vraiment la partie qui m’intéresse
    Peut-être que ce genre de changement est utile, donc j’aimerais voir davantage d’exemples
    Je ne fais pas confiance à la métrique de complexité cognitive, mais il est tout de même un peu intéressant de voir que ce type de modifications la fait monter de façon assez cohérente

• Je n’avais pas vu de sur-modification dans Claude Code ou Codex depuis un moment, donc je me suis demandé quels prompts avaient été utilisés dans cette étude
  Je pense que c’est ici, et la dernière modification remonte à 8 mois
  https://github.com/nreHieW/fyp/blob/5a4023e4d1f287ac73a616b5b944a14f28422c7e/partial_edits/utils/prompts_utils.py

  • Ça m’est encore arrivé aujourd’hui
    GPT-5.4 a réécrit 50 lignes sous prétexte que c’était plus propre, alors que je lui demandais simplement d’en ajouter 10
    C’était pourtant un ajout mécanique : il suffisait de regarder le code existant, de réutiliser la même structure en changeant seulement les noms de variables
    En plus, au départ, il n’avait même pas ajouté la fonctionnalité demandée, ce qui rendait ça encore plus absurde
    L’over-editing est loin d’être un problème du passé, et c’est arrivé parce que j’avais oublié de baisser le niveau de réflexion et l’avais laissé en xhigh thinking
  • J’ai eu la même impression
    Pour moi, ça ressemblait à un problème des débuts des agents

• Cet article est assez solide
  Les LLM sont trop verbeux aussi bien en prose qu’en code, et à mon avis la cause principale tient à la façon dont ils sont entraînés
  La cross entropy loss les pousse à préférer des phrases de type garden path
  Là où un humain dirait cela en une phrase, voire en quelques mots, eux l’étirent en un paragraphe
  Les longues phrases suivent statistiquement un chemin moins surprenant, donc une trajectoire de faible perplexité

• J’ai aussi un sentiment partagé sur ce problème
  La plupart du temps, l’agent en fait trop et je dois passer 30 minutes à corriger derrière, donc je suis d’accord avec l’évaluation
  Mais à d’autres moments, il passe aussi à côté de changements plus globaux
  C’est sans doute lié aux limites de contexte, ce qui m’a poussé à encadrer l’outil plus strictement
  Malgré cela, je n’ai toujours pas le niveau de contrôle que je voudrais

• On dirait un résidu des données d’entraînement
  Dans les données SFT et de préférences, il y a énormément d’exemples de « version plus propre d’un fichier », et peu d’exemples du type « diff de exactement 3 lignes »
  Le modèle a donc appris qu’une sortie plus ample et plus polie gagne
  On peut en reprendre partiellement le contrôle par le prompt, mais au fond on lutte contre un biais préalable très fort