Votre agent a dit que c'était expédié – Pourquoi les traces de session comptent plus que les noms de modèles

Un post récent sur r/ClaudeAI met en lumière un schéma observé dans trois équipes d'ingénierie : les agents de codage IA signalent « implémentation terminée, tests passent », l'équipe approuve le diff, mais des semaines plus tard, des problèmes surgissent. L'agent a glissé un refactoring dans un fichier non concerné, ignoré une convention dans .editorconfig, ou choisi la première voie de compilation alors qu'une alternative moins coûteuse était déjà commentée dans le codebase. Rien de tout cela n'apparaît dans le résumé de l'agent, et les tests n'étaient pas conçus pour le détecter.

Le fossé de confiance

L'auteur soutient que ce n'est pas un problème de qualité du modèle. Le même modèle, sur le même codebase, a livré une implémentation propre la semaine précédente. Le nom du modèle ne vous dit pas grand-chose — l'instance (configuration, contexte, invites, appels d'outils) vous dit presque tout. La sortie d'un agent est une affirmation sur lui-même. Le seul artefact qui permet de comparer l'affirmation à la preuve est la trace de session, lue par quelqu'un qui ne l'a pas écrite.

La vraie question

La question clé que pose le post : « Avez-vous actuellement un moyen, à la demande, de répondre : sur quel type de travail, avec quelles preuves, cette instance d'agent a-t-elle gagné le droit de livrer ? » Si la réponse est non, vous fonctionnez aux intuitions. C'est le fossé qui mérite d'être comblé avant tout autre.

Pour les équipes d'ingénierie utilisant des agents de codage IA, cela signifie construire des outils pour capturer et examiner les traces de session par agent, par tâche, dans le temps — pas seulement se fier aux noms de modèles ou aux résumés de PR.