Presque tout le monde tombe dans un piège avec les agents de codage, et il sape discrètement tout l'intérêt d'en utiliser un. L'agent produit une modification, et vous posez la question évidente : « Est-ce que ça fonctionne ? » L'agent répond oui. Vous le croyez, parce que cela sonne avec assurance et que, la plupart du temps, c'est vrai. Et de temps en temps, il se trompe avec une assurance totale — et vous ne le découvrez qu'en production.
Le problème n'est pas que l'agent mente. Le problème, c'est la question.
Pourquoi « est-ce que ça fonctionne ? » est la mauvaise question
Quand vous demandez à un agent si sa propre modification fonctionne, vous lui demandez d'évaluer sa production avec exactement le même raisonnement qui l'a produite. Il corrige sa propre copie avec le même stylo. S'il a manqué un cas limite en écrivant le code, il manquera le même cas limite en le jugeant, car rien de nouveau n'est entré en jeu — même modèle, même contexte, mêmes angles morts.
Pire encore, les modèles de langage ont tendance à acquiescer. Formulez la question ainsi : « ça gère bien les e-mails nuls, n'est-ce pas ? », et vous n'avez pas demandé une évaluation : vous avez proposé une conclusion et invité l'agent à la confirmer. Il le fera généralement. Ce que vous obtenez n'est pas une vérification. C'est un écho très éloquent de votre propre espoir.
Exigez des preuves à la place
La correction est minime mais change tout : cessez de demander à l'agent d'affirmer que la modification fonctionne, et demandez-lui de vous le montrer. Une preuve est un artefact que vous pouvez vérifier vous-même, produit par le système et non par l'opinion que l'agent a du système. Toutes les preuves ne se valent pas — il existe une hiérarchie approximative :
- La preuve par exécution est la plus solide : l'agent a réellement exécuté le code et vous montre la sortie réelle — le test qui est passé, la commande qui a renvoyé ce qu'elle devait renvoyer.
- La preuve avant/après est presque aussi bonne : un changement concret dans un état observable. Le nombre de requêtes est passé de 47 à 2 ; la requête qui échouait renvoie désormais 200.
- Un test écrit par l'agent est plus faible, car l'angle mort qui a raté le bug peut aussi le rater dans le test — mais un test que vous pouvez lire et exécuter reste bien meilleur qu'une simple affirmation.
- Une explication verbale est la plus faible. Parfois c'est tout ce que vous pouvez obtenir, mais « voici mon raisonnement » n'est pas une preuve ; c'est précisément ce que la preuve est censée vérifier.
La démarche est la même dans tous les cas : transformer la question fermée en une demande de quelque chose d'observable.
À quoi cela ressemble concrètement
Au lieu de « cette migration va-t-elle gérer les e-mails nuls ? », demandez à l'agent d'insérer une ligne avec un e-mail nul, d'exécuter la migration et de vous montrer la sortie. Au lieu de « est-ce que ça a corrigé la requête N+1 ? », demandez-lui d'ajouter la journalisation des requêtes, d'appeler le point de terminaison et de vous montrer le nombre de requêtes avant et après. Au lieu de « est-ce que le limiteur de débit se réinitialise ? », demandez-lui d'atteindre la limite, d'attendre, de réessayer, et de vous montrer la requête aboutir. Dans chaque cas, vous avez remplacé une affirmation qu'il fallait croire par un résultat que vous pouvez lire.
C'est pourquoi notre agent vit dans un bac à sable
Les preuves ne fonctionnent que si l'agent peut réellement exécuter des choses, et c'est une décision de conception, pas une réflexion après coup. Chaque exécution de TaskGoblin se déroule dans un bac à sable où le dépôt est cloné et la chaîne d'outils disponible, de sorte que l'agent ne se contente pas de raisonner sur ce que le code ferait — il peut exécuter les tests, lancer les commandes et observer le résultat réel. Lorsqu'il examine une merge request, ses constats pointent vers un comportement concret, et lorsque vous répondez @taskgoblin fix, la modification en est une qu'il peut vérifier plutôt que simplement défendre.
C'est aussi pourquoi un bon environnement de développement rapporte plus que jamais. Un agent capable de démarrer vos services, de charger des données de test et d'exécuter votre suite de tests peut produire de véritables preuves ; un agent qui ne peut que lire le code ne peut vous donner qu'une opinion. Plus votre projet est exécutable, plus vous pouvez vérifier la production de l'agent au lieu de simplement lui faire confiance.
La version en une phrase
Ne demandez pas à un agent si son travail est correct. Demandez-lui de vous le montrer — et privilégiez les formes de démonstration que vous pouvez vérifier vous-même. L'agent qui exécute le code et vous en remet la sortie fait la seule chose que l'agent qui se porte garant du code ne pourra jamais faire : vous donner autre chose à croire que sa propre assurance.
