Piloter une refactorisation à grande échelle

Migrer soixante appels d'une ancienne API interne vers la nouvelle est exactement le genre de tâche pour laquelle un agent est imbattable : mécanique, répétitive, sans décision à prendre. C'est aussi le genre de tâche qui produit le pire résultat possible quand elle est lancée d'un bloc. Vous récupérez un diff de 1 400 lignes touchant soixante-deux fichiers, la suite de tests affiche onze échecs, et vous n'avez aucun moyen de savoir si ces onze échecs viennent d'une erreur systématique répétée soixante fois ou de trois cas particuliers légitimes. Le diff est trop gros pour être relu, trop entrelacé pour être annulé partiellement, et trop long à régénérer pour être jeté sans douleur.

Le problème n'est pas la capacité de l'agent, c'est la granularité de la vérification. Sur une refactorisation, la question à laquelle vous devez pouvoir répondre à chaque instant est : « est-ce que le dépôt est encore cohérent ? ». Un diff monolithique ne permet de répondre qu'une seule fois, à la fin, quand toutes les erreurs sont mélangées. La méthode consiste donc à imposer une séquence d'étapes dont chacune est committable seule, vérifiable seule et annulable seule — et à faire de cette séquence une contrainte du prompt, pas un espoir.