Les outils permettant de travailler avec des agents de programmation sont devenus véritablement bons, et rapidement. D'abord est venue l'autocomplétion. Puis des agents capables de recevoir un prompt et de produire un diff. Aujourd'hui, l'état de l'art est le centre de commande personnel : une application de bureau ou de terminal où un développeur orchestre plusieurs agents à la fois — des worktrees en parallèle, des compétences packagées, des automatisations planifiées, une file d'exécutions à relire. C'est un véritable progrès, et si vous gagnez votre vie en écrivant du code, cela vaut la peine de l'avoir.
Mais regardez où tout cela vit : sur l'ordinateur portable d'une seule personne, à l'intérieur de la session d'une seule personne, visible pour exactement une seule paire d'yeux. Quel que soit le nombre d'agents qu'il gère, un centre de commande est monojoueur par défaut. Or le logiciel n'est pas un jeu monojoueur.
De l'autocomplétion aux centres de commande
Chaque génération d'outils d'agents a corrigé le goulot d'étranglement de la précédente. L'autocomplétion a corrigé la frappe. Les agents prompt-vers-diff ont corrigé la page blanche. Les centres de commande ont corrigé la boucle « un prompt, un diff, une attente » en permettant à un seul développeur d'exécuter de nombreux agents en parallèle.
Ce qu'aucun d'entre eux n'a corrigé, c'est que l'unité de propriété est restée la même : mon éditeur, ma session, mon agent. L'interface est devenue plus puissante, mais elle n'a jamais quitté l'ordinateur portable.
Le plafond du monojoueur
Un agent personnel présente un problème structurel qu'aucun perfectionnement ne peut corriger : tout ce qu'il apprend reste piégé dans une session privée.
Lorsque vous et votre agent comprenez pourquoi le service de facturation est structuré ainsi, cette compréhension vit dans votre historique de discussion. Lorsque l'agent de votre coéquipier se heurte à la même question demain, il repart de zéro — tout comme votre coéquipier, si vous êtes en vacances. Multipliez cela sur toute une équipe, et vous obtenez une étrange forme d'amnésie organisationnelle : l'entreprise fait tourner des dizaines de sessions intelligentes par jour et n'en retient presque rien.
Il existe un second problème : la délégation. Si l'agent vit dans vos outils, vous seul pouvez lui confier du travail, et vous seul pouvez voir ce qu'il a fait. « Votre agent peut-il regarder ceci ? » devient une demande qui vous est adressée, filtrée par votre attention, exécutée sur votre machine. L'agent a un responsable, pas une équipe.
Ce qui change lorsque l'agent est partagé
Nous avons construit TaskGoblin sur l'autre modèle : l'agent n'est pas une application que vous ouvrez, c'est un coéquipier avec lequel vos outils savent déjà communiquer.
Il possède sa propre identité partout où votre équipe travaille — @taskgoblin sur GitLab et Slack, taskgoblin[bot] sur GitHub. N'importe qui dans l'équipe peut le mettre au travail comme il le ferait avec un collègue : lui assigner un ticket Linear, le mentionner dans un commentaire de merge request, étiqueter un ticket sur GitHub, lui demander quelque chose dans un fil Slack. Il prend en charge le travail, l'exécute dans un bac à sable dans le cloud — toujours actif, sur l'ordinateur portable de personne — et livre le résultat là où le travail vit déjà : une branche, une merge request, un commentaire de relecture, une réponse dans le fil.
Cela change qui peut voir et orienter le travail. La production de l'agent n'est pas une transcription privée ; c'est une merge request que toute votre équipe peut relire, un fil de commentaires que n'importe qui peut lire, un ticket qui a traversé le tableau au grand jour. La supervision cesse d'être une activité solitaire pour devenir ce qu'elle est déjà pour le travail humain : quelque chose que l'équipe fait dans des espaces partagés, avec les outils qu'elle possède déjà.
La trace de contexte vit avec le travail
Voici la partie qui s'accumule. Parce que l'agent travaille au sein des systèmes de votre équipe, son contexte est ancré au travail, et non à la session d'une personne.
Chaque ticket sur lequel TaskGoblin travaille possède un fil : la conversation, les décisions, la branche qu'il a poussée, et une mémoire de transmission qui porte ce qu'il a appris jusqu'à l'exécution suivante. Revenez trois jours plus tard avec un commentaire de suivi, et il reprend avec l'historique en main — non pas parce que quelqu'un a recollé le contexte, mais parce que le contexte n'est jamais parti. La trace se trouve sur le ticket et la merge request, là où le prochain humain — ou la prochaine exécution — regardera réellement.
Le point sous-estimé est que le principal bénéficiaire de cette trace n'est pas l'humain. C'est l'agent. Un agent capable de voir comment la dernière modification de ce fichier a été relue, ce que l'équipe a décidé dans le ticket à deux liens de distance, et pourquoi l'approche précédente a été annulée, est tout simplement un meilleur ingénieur que celui qui se réveille chaque matin dans une pièce vide.
L'équipe apprend une seule fois
Le contexte partagé transforme le travail de l'agent en volant d'inertie. Chaque merge request relue, chaque correction qu'un coéquipier laisse en commentaire, chaque décision consignée sur un ticket rend l'exécution suivante mieux informée — pour tout le monde, pas seulement pour la personne qui se trouvait par hasard dans la session. L'équipe enseigne à l'agent une seule fois, en public, au lieu que chaque personne enseigne en privé à sa propre copie.
Les centres de commande personnels ne peuvent pas faire tourner ce volant d'inertie, aussi performants soient-ils, car l'apprentissage se produit dans un endroit qu'une seule personne peut voir.
Un test simple
Si vous voulez savoir de quel côté de la ligne se situe un outil, posez deux questions. N'importe qui dans l'équipe peut-il mentionner l'agent avec @ là où il travaille déjà ? Et lorsque c'est le cas, l'agent arrive-t-il en connaissant l'historique — le ticket, le fil, les exécutions précédentes — sans que personne n'ait à le lui réexpliquer ?
Si la réponse est non, c'est un outil personnel. Peut-être très bon — mais la question pour les équipes n'est plus « un agent peut-il écrire du code ? », mais « comment déléguer, superviser et apprendre aux côtés des agents, ensemble ? ». Cette question ne trouve de réponse que dans des espaces partagés. C'est pourquoi TaskGoblin n'est pas livré comme une fenêtre sur votre ordinateur portable, mais comme un coéquipier dans les outils que votre équipe ouvre déjà chaque matin.
