« Il n'y a pas de questions bêtes » est l'une de ces phrases bienveillantes que nous nous adressons les uns aux autres, et pour des humains, c'est vrai. Un nouveau coéquipier qui demande où se trouve le code de facturation est en train d'apprendre la structure du système ; la question construit un contexte partagé et la réponse prend une minute. Mais un agent autonome n'est pas un nouveau coéquipier qui prend ses marques. Il peut lire tout le dépôt dans le temps qu'il vous faut pour lire cette phrase. Pour un agent, certaines questions sont réellement bêtes — et les plus bêtes sont celles auxquelles il aurait pu répondre simplement en regardant.
Ce qu'est une question bête pour un agent
Une question bête est une question dont la réponse se trouve déjà dans le code. « Où se trouve le code qui gère cela ? » « Quelle est la commande de build ? » « Avons-nous déjà un modèle pour ce genre de chose ? » Un humain pourrait raisonnablement poser n'importe laquelle de ces questions le premier jour. Un agent qui les pose annonce qu'il préfère qu'on lui mâche le contexte plutôt que d'aller le chercher — alors même que le chercher est précisément la chose où il vous surpasse sans conteste.
Le signe distinctif, c'est que la réponse est trouvable. Si l'agent pouvait y accéder en lisant un fichier, en faisant un grep dans l'arborescence, en consultant la configuration CI, ou en lisant les derniers commits qui ont touché cette zone, alors vous le demander n'est pas de la prudence. C'est vous renvoyer un travail qu'il aurait dû faire lui-même.
Un agent asynchrone paie ses questions en journées entières
Pour un assistant de discussion assis à côté de vous, une question ne coûte rien : vous êtes là, vous répondez, il continue. TaskGoblin n'est pas assis à côté de vous. Il est déclenché par l'assignation d'un ticket, une mention, ou une nouvelle merge request, et il effectue son travail dans un bac à sable pendant que vous êtes en réunion, en train de dormir, ou dans un autre fuseau horaire. Dans ce monde-là, une question n'est pas une pause — c'est un arrêt complet.
Un agent qui demande « Dois-je mettre ceci dans services/ ou dans lib/ ? » puis attend a transformé une exécution qui aurait pu se terminer en quelques minutes en une exécution qui ne se termine que lorsque vous jetez par hasard un œil au fil de discussion. Une seule question fermée, posée au mauvais moment, peut coûter une journée entière en temps réel pour trente secondes de réflexion effective. Le modèle asynchrone, sans humain dans la boucle, qui rend l'agent précieux, est exactement celui qui rend une question évitable si coûteuse.
Sur-spécifier, c'est la même erreur commise plus tôt
La parade naturelle face à un agent trop enclin à poser des questions consiste à tout expliquer à l'avance : coller la structure des répertoires dans le prompt, lister les commandes, détailler les conventions de nommage, inclure un extrait du modèle à suivre. Cela paraît responsable. C'est la même erreur déguisée.
Le contexte rédigé à la main devient obsolète dès que le code évolue. Lorsque vous préchargez le prompt avec « nos repositories se trouvent dans app/Repositories », vous pariez que c'est toujours vrai, que vous avez pensé à chaque détail pertinent, et que rien de tout cela ne biaise l'agent vers l'approche d'hier. En général, au moins l'un de ces paris est perdu, et l'agent construit désormais avec assurance sur un fait que vous lui avez fourni plutôt que sur la vérité qu'il aurait pu lire lui-même. Vous avez remplacé le vrai travail — comprendre l'état actuel du système — par un travail sur ce travail, et vous avez, ce faisant, dégradé le résultat.
Un bon agent répond lui-même à ses propres questions
La solution n'est pas un meilleur prompt. C'est un agent qui traite votre instruction comme un objectif et qui va lui-même établir les faits.
C'est pourquoi une exécution de TaskGoblin commence par cloner l'intégralité du dépôt dans son bac à sable — pas seulement le diff en cours de revue, mais toute l'arborescence de travail — afin que les éléments de vérité soient là, prêts à être lus. Il lit les fichiers, l'historique de la zone qu'il modifie, le ticket qui l'a déclenché ainsi que la discussion associée, et la mémoire de transmission laissée par les exécutions précédentes sur le même fil. Il peut exécuter les propres commandes du projet dans le bac à sable pour voir ce qui compile et passe réellement, plutôt que de faire confiance à une commande de build que quelqu'un a tapée dans un prompt six semaines plus tôt. Lorsqu'il a besoin de l'état actuel de vos outils, il le lit directement via ses intégrations plutôt que de vous demander de le lui transmettre.
Le résultat, c'est que l'agent parvient à la même compréhension qu'un bon ingénieur après une heure de lecture — sauf qu'il le fait en quelques secondes, et qu'il le fait à partir du code tel qu'il est aujourd'hui, et non tel que quelqu'un s'en souvenait.
Quand il doit tout de même poser une question
Rien de tout cela ne signifie qu'un agent ne devrait jamais rien demander. Les questions qui méritent d'être posées sont celles auxquelles le code ne peut réellement pas répondre : lequel de deux comportements acceptables vous souhaitez réellement, si une migration risquée entre dans le périmètre, une décision produit qui n'existe que dans votre tête. Ce ne sont pas des questions bêtes — ce sont les décisions qui relèvent de votre jugement, et un bon agent les met en évidence clairement et tôt plutôt que de deviner.
Toute la distinction est là. Un agent qui vous demande où se trouve le code gaspille ce en quoi il excelle. Un agent qui vous demande lequel de deux produits vous cherchez à construire utilise votre temps pour la seule chose où vous excellez. Nous avons conçu TaskGoblin pour qu'il réponde lui-même au premier type de questions, afin que les seules questions qui vous parviennent soient celles qui méritent réellement votre attention.
