L’outillage pour agents, surtout autour de la génération de code, est un sujet passionnant. Ok, on tente ça : imaginez que vous écriviez un éditeur de plages. Un éditeur de plages est un outil qui permet aux agents de modifier un fichier texte par petits morceaux, via des plages de lignes. Cascade est un bon exemple d’éditeur de plages utilisé concrètement.
Le truc, c’est que les modèles d’IA ont un problème persistant qui n’apparaît qu’en tests approfondis. Et c’est celui-ci... ils détournent leurs outils d’édition pour halluciner des modifs sur des fichiers qu’ils n’ont même pas lus.
La semaine dernière, Claude Code a poussé une mise à jour pour empêcher Claude de modifier des fichiers non lus. Claude fait ça occasionnellement. Et hier soir, j’ai appris que les modèles Llama4 font la même chose, mais beaucoup plus souvent. Et le nouveau DeepSeek R1 ? Jusqu’à 50 % du temps. C’est hallucinant.
Ce bug est subtil, mais dévastateur.
Alors, on répare ça comment ?
Eh bien, Claude Code limite l’édition de plages. La fonctionnalité est très basique et n’autorise Claude à modifier que s’il a lu tout le fichier. C’est sensé. On évite le problème en renvoyant une erreur. Mais... qu’est-ce qui se passe quand on ne modifie pas tout le fichier, quand tout repose sur la sélection de lignes ?
Piégeux, non ? C’est beaucoup plus complexe.
Ma solution a été de suivre quelles lignes de quels fichiers ont été constatées par l’IA dans une fenêtre de contexte donnée. On laisse l’édition se faire si le fichier a été lu par l’IA. Mais... s’il tente de modifier une section qu’il n’a pas encore lue, ou si sa dernière lecture du fichier est obsolète, on affiche le diff, on demande « vous êtes sûr ? » et on propose trois options : 1. Relire le fichier avant de modifier 2. Annuler 3. Enregistrer quand même.
Ça ajoute une étape au processus.
Ça reste à tester, mais je pense que c’est comme ça que ça se fait.
Vous vous y prendriez comment ?