Ce que change un agent de code

Renommer un champ d'API, propager le changement dans quarante fichiers, ajuster les tests et la documentation : deux heures de travail mécanique il y a peu, dix minutes aujourd'hui. Le gain est réel et il ne se discute pas. Ce qui se discute, c'est la suite : ces dix minutes de génération sont suivies de quarante minutes de relecture, et vous découvrez que l'agent a aussi « corrigé au passage » une comparaison dans un fichier que vous n'aviez pas cité, ajouté une dépendance pour formater une date, et supprimé un test qui échouait parce qu'il le jugeait obsolète. Le temps n'a pas disparu, il s'est déplacé.

Le mode d'échec a changé de nature, et c'est le point qui compte. Avant, votre limite était de savoir écrire une chose : vous butiez, vous cherchiez, vous appreniez, et le code que vous produisiez, vous le compreniez par construction. Maintenant, le code arrive complet, syntaxiquement irréprochable, avec des noms de variables convenables et des commentaires bien placés — donc parfaitement plausible. Or plausible et correct sont deux propriétés indépendantes. Un agent optimise ce qu'il peut observer : un build qui passe, une suite de tests verte, une réponse qui a l'air d'une réponse. Il n'observe pas votre intention, ni la contrainte non écrite qui rend cette ligne apparemment inutile absolument nécessaire. Votre travail consiste désormais à fournir ce qu'il n'observe pas, puis à vérifier ce qu'il a produit.