Le problème d'approvisionnement en tâches

Pendant longtemps, la question posée aux agents de codage était de savoir s'ils pouvaient réellement faire le travail. Cette question est en train de se refermer discrètement. Sur des tâches bien délimitées, avec le dépôt sous les yeux et la possibilité d'exécuter les tests, les bons agents livrent de vraies modifications qui passent la revue. Et dès l'instant où vous leur faites confiance, vous vous heurtez à un problème dont personne ne vous avait prévenu : vous n'arrivez pas à trouver du travail assez vite pour les occuper.

L'exécution a cessé d'être la contrainte

Il y a toujours un travail infini à accomplir sur un produit logiciel. Le backlog n'est jamais vide ; la liste des choses qui pourraient être améliorées n'a pas de fin. Il semble donc étrange de dire qu'une équipe pourrait manquer de travail à confier à un agent. Mais « il existe un travail infini » et « il existe du travail sous une forme qu'un agent peut prendre en charge et terminer » sont deux affirmations très différentes, et c'est dans l'écart entre les deux que les équipes se retrouvent bloquées.

Un agent peut exécuter une tâche claire en quelques minutes. Rédiger cette tâche claire — celle qui dispose d'un contexte suffisant, du bon périmètre et d'une définition de « terminé » — demande toujours à une personne les mêmes vingt minutes qu'auparavant. Quand l'exécution était la partie lente, cela ne posait pas de problème ; la spécification représentait cinq pour cent de l'effort et le travail constituait les quatre-vingt-quinze pour cent restants. Faites tendre le coût de l'exécution vers zéro, et le ratio s'inverse. La spécification devient désormais la moitié coûteuse, et une équipe qui parvenait à nourrir un agent découvre qu'elle ne peut pas en nourrir trois.

Le goulot d'étranglement a remonté la chaîne, jusqu'à vous

C'est là le problème d'approvisionnement en tâches : la contrainte du développement piloté par agents n'est plus la capacité de l'agent à accomplir des choses, mais la capacité de l'organisation à produire des choses bien formées à accomplir. Et cette contrainte retombe sur les personnes les plus rares dont vous disposez — celles qui ont assez de contexte pour dire ce qui doit se passer ensuite, et pourquoi.

Vous le ressentez comme une pression d'un genre étrange. L'agent est rapide et fiable, si bien que la file d'attente se vide plus vite que vous ne pouvez la remplir, et remplir cette file est justement la partie qui exige du jugement, du sens du produit et une connaissance de la direction que prend le système. Le goulot d'étranglement n'a pas disparu. Il s'est déplacé du clavier vers la tête de la personne qui sait ce que le clavier devrait faire.

L'agent doit aider à approvisionner le travail

La seule façon de surmonter un problème d'approvisionnement est d'augmenter l'offre, et la personne qui définit les tâches ne se démultiplie pas. L'agent qui exécute le travail doit donc commencer à aider à le générer — non pas en inventant des tâches sans intérêt, mais en transformant les signaux qui circulent déjà dans vos systèmes en tâches concrètes, prêtes à être exécutées.

TaskGoblin en propose déjà une version aujourd'hui, à deux endroits que vous n'aviez peut-être pas identifiés comme relevant de la « génération de tâches » :

• Les constats de revue deviennent du travail. Chaque merge request que l'agent examine produit des constats précis et localisés — cette fonction contient un bug de correction, ce chemin n'est pas couvert, ceci sent le problème de sécurité. Chacun d'eux constitue, de fait, une tâche pré-rédigée dotée d'une définition de « terminé ». Répondez @taskgoblin fix et le constat se transforme en modification. Personne n'a eu à s'asseoir pour rédiger ce ticket ; la revue l'a fourni.
• Les boucles permanentes deviennent du travail. Un loop est un générateur de tâches qui s'exécute selon une horloge : « chaque jour ouvré, trouvez le travail fusionné dont les issues sont encore ouvertes et fermez-les », « surveillez une CI restée rouge trop longtemps ». L'instruction est écrite une seule fois, et elle continue de produire du travail concret — ou, à juste titre, ne produit rien lorsqu'il n'y a rien à faire — sans que personne n'ait à réapprovisionner la file manuellement.

Dans les deux cas, l'agent n'attend pas qu'on lui dise quoi faire. Il lit l'état du système et propose la prochaine étape concrète et réalisable.

Pourquoi le contexte est tout l'enjeu

Si le travail proposé par un agent a généralement peu de valeur, ce n'est pas parce que le modèle n'est pas assez intelligent. C'est parce que l'agent ne sait pas ce qui compte pour vous. Aveugle à l'intention produit, un agent suggérera volontiers les vingt refactorisations qu'il peut voir, mais aucune de l'unique modification qui fait réellement avancer l'activité — parce que le code lui dit ce qui est possible, pas ce qui est important.

C'est pourquoi les interfaces utiles de génération de tâches sont celles qui sont ancrées dans une intention réelle. Un constat de revue compte parce qu'il porte sur une modification que quelqu'un a choisi de faire. Une boucle planifiée compte parce qu'un humain a décidé que maintenir issues et merges synchronisés valait la peine, chaque jour. Le contexte qui rend une tâche proposée digne d'être réalisée ne se trouve pas uniquement dans le code ; il se trouve dans les issues, les discussions et les décisions qui entourent le code — et un agent qui vit dans ces systèmes, comme le nôtre, peut lire cette intention au lieu de la deviner.

Où se trouve la valeur désormais

Il vaut la peine de préciser clairement où cela laisse l'avantage. À mesure que les modèles convergent vers la capacité d'exécuter presque n'importe quoi, la valeur disproportionnée cesse de s'accumuler chez celui qui possède l'agent le plus intelligent et commence à s'accumuler chez celui qui parvient à maintenir de bons agents approvisionnés en travail qui compte. Le coup gagnant n'est pas un modèle plus ingénieux. C'est fermer la boucle entre l'intention dispersée dans vos outils et l'agent capable d'agir en conséquence, de sorte que « que devons-nous faire ensuite » cesse d'être un goulot d'étranglement dont vous êtes personnellement responsable.

C'est le problème contre lequel nous construisons réellement. Rendre l'agent capable de coder était la première moitié. S'assurer qu'il sache toujours ce qui vaut la peine d'être fait — et qu'il puisse transformer votre contexte en la prochaine tâche concrète sans attendre après vous — c'est la moitié qui détermine la valeur de la première.