Steve Yegge n’est pas du genre timide et réservé, alors quand il veut des recommandations sur la façon dont d’autres gèrent 10 à 20 (ou plus) agents de codage, il pose la question sur X. Plus précisément, il recherche un IDE parce que « j’utilise Emacs, et je ne vous le souhaiterais pas ».
Les réponses (600 et plus) offrent de nombreuses alternatives : Herdr, cmux, Conductor, les applications de bureau Claude et Codex, et un assortiment impressionnant de logiciels maison. Pour tous ceux qui espéraient que l’industrie ait trouvé une manière sensée de travailler avec les agents, ce n’est clairement pas le cas. D’où la question de Yegge.
Cependant, les données les plus intéressantes cachées dans les réponses ne concernent pas l’IDE ou les développeurs suppléants de l’IDE. Il s’agit plutôt de ce que les développeurs ont ajouté à ces outils pour combler les lacunes de la technologie. Ceux-ci incluent des raccourcis pour trouver l’agent qui a besoin d’une décision, des moyens de récupérer une conversation antérieure et des regroupements qui expliquent comment une tâche s’intègre dans un projet. En d’autres termes, malgré l’incroyable intelligence dont nous disposons désormais pour nous aider à écrire du code, les développeurs ont toujours du mal à accomplir la simple tâche d’automatiser la mémorisation de ce qu’ils ont demandé à l’IA de faire.
Il semble que nous ayons facilité la génération du travail sans faciliter l’absorption et la finition du travail.
Tout le monde construit un sélecteur d’espace de travail
Mark Jaquith utilise Herdr avec une interface personnalisée pour accéder directement à un agent ayant besoin de son attention. Kai Backman a travaillé sur un raccourci clavier pour l’amener au « prochain endroit le plus pertinent pour agir ». Jacob Voytko a construit un sélecteur d’espace de travail qui regroupe les tâches en jalons et lui permet d’accéder aux tickets et aux demandes d’extraction correspondants. Il souhaitait avoir une idée visuelle de la situation de l’œuvre, plutôt qu’une liste non structurée. Un autre répondant, Basil, a construit un gestionnaire qui l’aide à « trouver la session où nous avons fait x ».
Bien entendu, les développeurs ont toujours personnalisé leurs outils. Les utilisateurs d’Emacs pourraient à eux seuls fournir des tonnes de preuves. Mais, encore une fois, il ne s’agit pas vraiment du fait que les développeurs peaufinent leurs outils, mais pourquoi. Une grande partie des ajustements visent à aider à cohérence les intentions du développeur avec le travail qui se déroule à plusieurs endroits à la fois. Ils ne demandent pas une meilleure IA : ils demandent que l’IA les aide à exprimer leur humanité, pour ainsi dire.
Le travail revient
Prenons l’exemple d’un développeur qui demande à un agent de corriger un bug, à un autre d’enquêter sur un problème de performances et à un troisième de mettre à jour une dépendance. Pendant que les agents travaillent, elle peut faire autre chose, ce qui rend le développement axé sur le LLM si attrayant, du moins jusqu’au retour des agents.
Aucun de ces agents ne fonctionne de manière totalement isolée du reste du système. Pensez-y : la correction du bug modifie le comportement dont quelqu’un peut dépendre. OK… nous pouvons résoudre ce problème ! Mais attendez, nous avons maintenant l’enquête sur les performances qui propose trois options, chacune avec des coûts différents. Hmm. Attendez une minute pendant que j’aborde cela… sauf que la mise à jour des dépendances n’attend pas. Il réussit ses tests, mais l’agent a également réécrit un fichier de configuration. Mieux vaut vérifier ça !
Comme le montre cet exemple simple, avant que le développeur puisse prendre une décision, il doit d’abord récupérer ce qu’il a demandé, ce que l’agent a découvert et ce qui reste incertain. Et non, l’ajout d’agents supplémentaires ne résout pas le problème. Cela pourrait au contraire aggraver le problème.
Les agents ont peut-être gagné des heures. Hourra! Mais une liste des sessions terminées n’indique pas au développeur par où commencer. Un résultat de test vert ne répond pas non plus à la question de savoir si le changement appartient à l’application.
C’est pourquoi le nombre d’agents en activité nous dit si peu, même s’il nous rassure. Je veux dire, que font ces agents, de toute façon ? Les commentateurs de Yegge fournissent quelques indices. Par exemple, Anton décrit l’utilisation de 30 onglets de terminal avec un agent actif par projet, afin d’éviter que leurs travaux ne se chevauchent. Jerry Combs dit qu’il ne maintient généralement pas plus de trois conversations, les agents gérant leurs propres sous-agents selon les besoins. Même ces trois conversations sont déjà assez difficiles à suivre.
Les deux approches peuvent avoir du sens. Les exigences dépendent de l’indépendance avec laquelle le travail peut se dérouler et du jugement humain qu’il requiert tout au long du processus. Un développeur disposant de 20 agents peut avoir moins de décisions à prendre qu’un développeur qui en compte trois.
Gergely Orosz a récemment énuméré plusieurs observations à considérer ensemble : les développeurs passent moins de temps dans les IDE, les révisions de code deviennent un théâtre et les gens travaillent davantage malgré les promesses de productivité de l’IA. Ses observations n’établissent pas que les outils des agents provoquent un surmenage ou une révision superficielle. Cela vaut la peine de se demander si nous déplaçons nos efforts vers des domaines négligés par nos histoires de productivité. Regarder un agent produire un changement est satisfaisant, mais passer l’après-midi à reconstituer pourquoi six changements ont été effectués l’est moins.
Mais ce travail, aussi insatisfaisant soit-il, est nécessaire si l’on veut comprendre et maintenir ces changements.
Apprenez aux outils à attendre
Une partie de la plomberie existe déjà pour atténuer ces problèmes. Par exemple, Herdr suit les agents comme étant en activité, bloqués ou inactifs et transfère ces états dans ses onglets et espaces de travail ; cmux propose des notifications et un raccourci vers l’espace de travail avec la notification non lue la plus récente. Ce sont là des débuts utiles, mais ils mettent en évidence tout ce qui reste à faire. Après tout, la notification la plus récente peut concerner la tâche la moins importante, et un agent posant une question peut être parfaitement capable d’attendre que le développeur termine autre chose.
La prochaine amélioration devrait aider les développeurs à faire ces distinctions. Une tâche doit conserver son objectif initial, les décisions pertinentes et les preuves étayant son résultat. Lorsqu’il a besoin d’une personne, il doit expliquer la décision requise et ce qui se passe si cette décision attend. Un résumé peut aider, mais il doit renvoyer aux changements réels et aux résultats des tests. Sinon, nous avons facilité l’approbation d’un travail sans le comprendre.
Encore une fois, les meilleurs outils pour l’IA agentique seront ceux qui ramèneront l’humain dans la boucle et fourniront les informations nécessaires à la prise de décisions.
J’aimerais un outil qui puisse me dire qu’une tâche est prête à être révisée parce que le comportement demandé a été démontré, tout en gardant une question distincte et moins urgente à l’écart. J’aimerais également qu’il se souvienne que j’ai rejeté une approche hier, afin de ne pas avoir à la découvrir à nouveau dans le correctif proposé aujourd’hui. Que cet outil s’appelle lui-même un IDE semble secondaire. Google a présenté Antigravity 2.0 en tant qu’application d’agent autonome sans IDE, tout en recommandant aux développeurs de l’utiliser avec l’IDE de leur choix. En d’autres termes, le rédacteur a toujours un travail, même si ce n’est plus le point de départ de chaque tâche.
En 2022, j’ai écrit sur la commodité du cloud et la tendance à mal comprendre ce que les développeurs attendent de leurs outils. Ils ont du travail à accomplir et veulent moins d’obstacles pour y parvenir. Nous devrions appliquer cette même norme au développement agent dans l’ensemble de la tâche, y compris l’effort d’y revenir.
Non pas que nous puissions mettre toute la responsabilité sur l’IA et ses outils. Les équipes ont un rôle à jouer ici. Si chaque tâche est urgente, l’outil n’a rien d’utile à prioriser. Si personne ne définit ce qui est considéré comme terminé, l’outil peut uniquement signaler qu’un agent s’est arrêté. Se mettre d’accord sur ces choses et limiter le travail qui nécessite des décisions humaines simultanées fera plus que l’ajout d’un autre badge de statut.
Les lecteurs de Yegge construisent déjà des éléments de cet avenir, un raccourci et un espace de travail maison à la fois. L’opportunité du fournisseur est de rendre cette commodité disponible sans obliger tout le monde à maintenir un projet parallèle. Donnez aux développeurs plus de travail qu’ils peuvent accomplir en toute confiance et moins de conversations qu’ils doivent maintenir en vie dans leur tête.
