Note de la rédaction : À mesure que les agents IA deviennent de plus en plus abordables et faciles à appeler, le développement logiciel entre dans une nouvelle phase : la question n’est plus de savoir si l’on peut lancer davantage d’agents, mais si les humains ont encore suffisamment d’attention pour gérer, évaluer et fusionner leurs résultats.

Cet article présente un concept très inspirant : le « coût d'orchestration ». Le démarrage d'un Agent coûte peu cher, nécessitant seulement une seule instruction Prompt ou un seul clic ; mais les étapes suivantes sont véritablement coûteuses : vérifier la validité des résultats, comprendre leur impact sur l'architecture du système, résoudre les conflits entre différents Agents, et enfin décider quels codes peuvent être intégrés à la branche principale. Ces tâches ne peuvent pas être facilement parallélisées et doivent toujours passer par une ressource séquentielle : le jugement humain.

L'auteur compare les développeurs au « GIL » dans les systèmes d'agents IA, ce verrou monofilament qui limite le débit final d'un système parallèle. Bien que plusieurs agents puissent s'exécuter simultanément, dès qu'ils atteignent les phases d'évaluation d'architecture, de revue de code et de fusion de conflits, ils doivent tous repasser par le cerveau du développeur. Ainsi, plus il y a d'agents, cela ne signifie pas nécessairement une production plus élevée ; cela peut simplement allonger la file d'attente des tâches en attente de revue et plonger le développeur dans des changements de contexte plus fréquents et une fatigue cognitive accrue.

C’est aussi un point souvent négligé dans la vague actuelle d’outils de programmation IA : le sentiment d’efficacité ne correspond pas toujours à une productivité réelle. Un tableau de bord rempli d’agents en cours d’exécution crée une illusion de productivité élevée ; mais si les développeurs ne comprennent pas, n’examinent pas et n’intègrent pas véritablement ces modifications, le système finit par accumuler non pas de la productivité, mais de la dette technique et de la dette cognitive.

Ainsi, ce qui est véritablement discuté dans cet article n'est pas « comment utiliser davantage d'agents », mais « comment redessiner les flux de travail autour de l'attention humaine ». À l'ère des agents, les compétences clés ne se limitent pas à savoir poser des questions ou déléguer des tâches ; elles consistent à savoir quelles tâches peuvent être confiées à la machine pour traitement parallèle, et lesquelles doivent rester sous la responsabilité du jugement humain ; quand il faut effectuer des revues par lots, et quand il faut arrêter l'orchestration pour se recentrer sur une question centrale.

L'IA élargit la capacité concurrente de la production logicielle, mais l'attention humaine reste la ressource la plus rare et la plus irréplicable du système. Un flux de travail Agent véritablement mature ne consiste pas à déléguer toutes les tâches à la machine, mais à concevoir soigneusement son architecture d'attention, comme on conçoit un système de production.

Voici le texte original :

Il est désormais plus facile de lancer plusieurs agents IA. Mais avoir plus d’agents en cours d’exécution ne signifie pas que « vous » vous multipliez. Votre bande passante cognitive ne peut pas être parallélisée. Tout jugement véritablement nécessaire pour les guider, évaluer les résultats et fusionner ou modifier leurs sorties doit passer par le même processeur sériel : vous-même.

Ce qu'on appelle « taxe de planification » est essentiellement le prix que vous payez lorsque vous oubliez ce point. La seule vraie solution consiste à concevoir votre propre attention comme on conçoit tout système concurrent.

J'ai participé précédemment à une table ronde lors de Google I/O, où j'ai discuté avec Richard Seroter, Aja Hammerly et Ciera Jaspan de l'état actuel du génie logiciel et de sa possible évolution future. À la fin de la discussion, Richard nous a demandé : quel est le point le plus important que les développeurs devraient retenir et modifier après avoir écouté ?

J'ai exprimé ce que je réfléchissais depuis plusieurs mois : se sentir occupé ne signifie pas nécessairement produire réellement. Vous pouvez faire fonctionner simultanément 20 agents et vous sentir débordé. Mais cela ne signifie pas que vous avez livré le volume de travail correspondant à 20 agents.

Plus tôt dans la conversation, Richard a donné un nom à cette question. Il a dit : « Ce que vous venez de décrire, c’est en fait de la planification fiscale. Vous ne pouvez pas gérer avec succès 20 agents dans votre tête. »

Il a tout à fait raison. Je souhaite décomposer ce concept plus en détail, car il ne s'agit pas d'un problème de discipline, mais d'un problème d'architecture.

Lors de cette table ronde, il y avait une phrase que j'ai presque dite à la légère, et qui n'a cessé de me hante depuis : exécuter plusieurs agents ne signifie pas qu'il y a un autre vous dans le monde.

L'asymétrie non prise en compte par les gens

Il existe une asymétrie cachée dans les flux de travail des agents.

Lancer un agent est très peu coûteux. Il vous suffit de taper une touche du clavier ou d'écrire une seule invite. Mais boucler l'agent n'est pas du tout peu coûteux. Quelqu'un doit toujours vérifier si les résultats qu'il renvoie sont corrects et les réconcilier avec les modifications apportées par d'autres agents.

Cette personne, c'est toi. Et tu n'es qu'un seul.

Le mois dernier, j’ai abordé une partie de cette question dans « Votre limite d’agents parallèles », en me concentrant principalement sur cette forme d’anxiété environnementale : vous ne savez pas quelle ligne parallèle échoue en silence. Cet article vise à explorer la structure sous-jacente à ce coût.

Lorsque vous commencez à considérer le développement d'agents comme un système concurrent, vous réalisez que les êtres humains ne sont qu'un composant de ce système : un composant séquentiel très lent.

Tu es cette ressource mono-threadée

Si vous avez déjà écrit du code concurrent, vous possédez déjà l'intuition nécessaire pour comprendre ce problème. Vous avez simplement utilisé cette intuition au mauvais endroit par le passé.

Python possède un verrou d'interpréteur global, également appelé GIL. Vous pouvez créer autant de threads que vous le souhaitez, mais un seul thread peut exécuter du bytecode Python à la fois, car tous doivent d'abord acquérir ce verrou.

Vous êtes le GIL de votre agent IA.

Ils peuvent tous fonctionner en même temps. Mais dès qu'ils doivent comprendre l'architecture du système ou résoudre des conflits de fusion, ils doivent d'abord obtenir cette clé. Et il n'y a qu'une seule clé, que vous détenez.

La loi d'Amdahl exprime cela avec une grande précision : la limite supérieure de l'accélération apportée par la parallélisation dépend de la partie du travail qui doit encore être effectuée de manière séquentielle. Si une grande partie de votre processus ne peut pas être parallélisée, alors, quel que soit le nombre de cœurs que vous investissez, vous finirez toujours par rencontrer une limite absolue.

Dans le développement d'agents, cette partie séquentielle est le jugement.

Lancer 8 agents n'accélérera pas votre temps de prise de décision. Il ne fera que allonger la file d'attente en attente de votre traitement.

C'est un fait bien établi en ingénierie des performances, mais beaucoup sont encore surpris par cela : optimiser des parties non critiques n'améliore pas le débit global. Vous n'faites que accumuler plus de travail en attente avant le goulot d'étranglement.

L'optimisation de l'agent porte sur une partie qui n'était pas un goulot d'étranglement. Le véritable goulot d'étranglement est l'étape de révision, et le débit total du système correspond exactement au débit de cette étape.

La fiscalité de la compilation est un écart structurel entre la capacité de production de l'agent et le contenu que vous pouvez réellement fusionner. Elle se produit lorsque vous faites gérer un système concurrent par une ressource mono-thread.

Résister ne résout pas les limites structurelles

Lors de ce panel, j'ai dit une chose : je n'ai jamais senti mes outils aussi efficaces qu'aujourd'hui, mais je n'ai jamais été aussi fatigué qu'aujourd'hui.

Ces deux sentiments sont entièrement réels et proviennent de la même cause.

Cette fatigue a une source très spécifique : c'est le sentiment d'avoir constamment poussé un processeur séquentiel à 100 % sans lui laisser la moindre marge.

Chaque fois que vous revenez vers un Agent qui a quitté votre champ d'attention, vous payez un coût de basculement de contexte. Vous devez vider votre esprit, puis recharger entièrement un autre contexte depuis le début.

Le CPU peut accomplir cela en microsecondes, et pourtant, les architectes évitent toujours de basculer fréquemment. Vous, vous mettez plusieurs minutes à le faire, et vous ne pourrez jamais reconstituer parfaitement le contexte.

Cinq agents ne représentent pas une charge de travail unique répétée cinq fois. Ce sont cinq rechargements de contexte en mode « cold start », accompagnés d’un processus cérébral en arrière-plan qui ne cesse de s’inquiéter de quel agent vous devriez vérifier en ce moment.

Vous ne pouvez pas résoudre une limitation structurelle en « travaillant plus ». Cette taxe doit toujours être payée.

Si vous tentez de résister, cela finira par réapparaître sous une autre forme : soit les revues de code deviennent de plus en plus superficielles, soit vous entrez dans un état de « reddition cognitive » — car former votre propre jugement consomme trop d’attention, vous acceptez simplement le code écrit par l’Agent.

Soit vous payez activement cet impôt, soit vous laissez celui-ci détruire lentement, dans l'ombre, votre compréhension de votre système.

Concevez votre attention comme un système de conception

Vous devez donc traiter votre attention comme une ressource sérieuse et rare.

Vous ne concevez pas un système distribué en ignorant complètement les goulots d'étranglement. Accordez donc à votre cerveau le même respect.

Voici quelques méthodes qui ont vraiment fonctionné pour moi :

Un bon système concurrent utilise un mécanisme de rétroaction pour éviter que les files d'attente ne croissent indéfiniment. Le producteur doit ralentir pour s'adapter à la capacité de traitement du consommateur.

Le nombre de vos agents correspond aux producteurs, et votre capacité à effectuer des revues correspond aux consommateurs. Le nombre optimal d'agents parallèles est le nombre que vous pouvez examiner attentivement. Pour la plupart des personnes, cela correspond généralement à un très faible nombre unitaire.

Les outils d'IA seront bien sûr ravis de vous permettre de lancer 20 agents, mais il s'agit simplement d'une fonctionnalité d'interface utilisateur et ne signifie pas que vous avez réellement la capacité de les gérer.

Lorsque Richard m'a demandé comment gérer cette situation, j'ai mentionné cette méthode. Je vais diviser la tâche en deux groupes.

Le premier ensemble de tâches est relativement indépendant ; je suis prêt à le confier à un Agent s'exécutant en arrière-plan dans le cloud. Ces tâches peuvent être exécutées de manière asynchrone et ne nécessitent généralement qu'une seule validation de ma part à la dernière étape.

Le deuxième type est les tâches complexes, où le travail consiste véritablement à juger. Par exemple, un bug très étrange ou une conception d'architecture.

La plus grande erreur consiste à essayer de paralléliser également les tâches de deuxième catégorie. Traiter plusieurs tâches complexes en parallèle n'augmente pas votre productivité, mais fait seulement en sorte que ce verrou soit constamment disputé, ce qui finit par dégrader tous les résultats.

Chaque changement de contexte vous coûte très cher. S'asseoir une fois pour examiner les résultats de 4 agents est bien moins coûteux que d'en regarder un, faire autre chose, puis redémarrer pour examiner un autre.

Donnez à l'agent une laisse plus longue. Laissez le travail s'accumuler légèrement, puis traitez-le en lot.

Ne gaspillez pas votre cerveau à des choses que la machine peut vérifier elle-même. Laissez l'Agent écrire des tests qui passent ou générer des captures d'écran.

Laissez-les prouver eux-mêmes les 80 % ennuyeux mais vérifiables. Ainsi, votre attention limitée ne sera consacrée qu’aux 20 % nécessitant un jugement humain.

The bottleneck requires your best time, not the fragmented time left between a few Agent checks.

Parfois, le mouvement de levier maximal consiste simplement à arrêter complètement la chorégraphie : éteignez cet ordinateur surchargé d’agents, concentrez-vous uniquement sur une seule question, et tenez fermement cette clé tout au long du processus.

La planification n'est pas un vrai travail. Ce n'est que le surcoût généré par le travail.

Aja souligne que l'architecture est devenue la compétence la plus urgente : vous devez savoir quelles tâches conviennent à un Agent et lesquelles sont trop complexes pour lui.

Je voudrais également ajouter ceci : vous êtes également un composant de ce système. Votre attention possède un débit série connu, très faible. Le système soit respecte ce chiffre, soit le contourne en abaissant discrètement vos normes.

Être occupé ne signifie pas être productif

This is very important because this failure mode is nearly invisible to you personally.

Vingt agents en cours d'exécution vous donnent une sensation de « productivité à plein régime ». Le tableau de bord est rempli, tout bouge. Mais ce sentiment est désormais déconnecté de la véritable intégration de code de haute qualité dans la branche principale.

Tu peux être débordé jusqu’au bout, tout en produisant presque rien. Sur le plan de l’expérience interne, les deux sont presque identiques.

Ciera a mentionné les recherches de Margaret-Anne Storey sur la dette. Nous avons discuté de la dette technique ainsi que de la dette cognitive.

Aucune taxe de règlement ne vous permettra d'accumuler simultanément ces deux dettes.

Tu as fusionné des choses que tu n’as pas lues attentivement. Ton modèle mental du codebase est complètement obsolète. Ces problèmes n’apparaîtront pas aujourd’hui sur le tableau de bord. Ils se manifesteront lorsqu’une défaillance surviendra en production — à ce moment-là, tu regarderas le système et réaliseras soudainement que tu ne sais plus comment il fonctionne vraiment.

Donc, la vraie conclusion est : lancer un Agent n'est pas une compétence. N'importe qui peut en exécuter 20.

La véritable capacité consiste à concevoir un système autour d'une ressource sérielle qui ne peut pas être clonée ni parallélisée.

Cette ressource, c'est votre attention.

Concevez-le comme vous le feriez pour tout composant critique dépendant dans un environnement de production.