Une fois que l’Agent prend en charge la tâche, la première chose à resserrer est l’unité de travail.

J’ai lu beaucoup de discussions sur Agent récemment, et au final je reviens toujours à la même question : à qui doit donner une œuvre, comment doit-elle être emballée avant de la remettre, et comment sera-t-elle acceptée après son retour. Une fois que ce problème survient dans un projet, la première chose qui augmente n’est souvent pas le coût du modèle, mais la complexité de l’unité de travail. Si la tâche est trop importante, le modèle apparaîtra « comme si cela pouvait être fait » ; les vrais problèmes résident généralement dans le démantèlement, la reproduction et l’acceptation.

L’unité de travail doit au préalable pouvoir être acceptée

Au cours des derniers jours, après avoir enchaîné les notes fragmentées de Martin Fowler et plusieurs discussions lors de la retraite Thoughtworks sur l’avenir du développement logiciel, le sentiment le plus évident est que la conversation lors de la réunion était superficiellement dispersée, mais qu’en dessous elle tournait en fait autour d’une seule chose : confier une grande partie du travail à l’agent.

La finition de Kief Morris est la plus simple. Différentes sessions ont discuté de la révision du code, des accidents de production, de la division du travail en équipe et du routage des modèles. Ils semblaient parler de choses différentes, mais la conclusion s’est avérée la même : les gens ont ajusté la taille du « travail unitaire ». Plus l’unité est grande, plus il sera facile de la céder ; plus l’unité est grande, plus il sera difficile de l’accepter après son retour. Ce n’est pas que le modèle ne peut pas le faire, c’est que le lien de confirmation ultérieur ne peut pas tenir le coup en premier.

C’est pourquoi le harnais est mentionné encore et encore. Gestion du contexte, capteurs informatiques, tests basés sur les propriétés, méthodes formelles, tout cela ressemble à des outils supplémentaires, mais ils collectent en réalité des unités de travail. Certaines personnes contrôlent agents.md à moins de 200 lignes, non pas pour rechercher une forme soignée, mais pour forcer le système à ne recevoir que la partie des informations qui est vraiment utile et peut réellement être vérifiée. Le contexte est trop lâche, bien sûr l’agent peut s’exécuter ; mais après l’exécution, personne ne sait quelle couche de contraintes il a avalé.

L’auto-hébergement fait apparaître la surface de contrôle

Les discussions sur les modèles auto-hébergés indiquent également la même chose. Une fois que les jetons sont devenus plus chers, que les exigences de conformité sont devenues plus strictes et que les données ne peuvent plus être divulguées, les modèles open source et les modèles locaux deviendront naturellement plus attrayants. Mais une fois que vous transportez le modèle vous-même, vous rencontrez également des problèmes : GPU, salle d’inférence, routage, restauration, réglage fin et sélection du modèle. Ce ne sont pas les capacités du modèle elles-mêmes, mais elles détermineront si le système est finalement stable.

Ces coûts sont souvent sous-estimés. De nombreuses équipes se sont d’abord concentrées sur « si le modèle est plus solide », mais ont découvert plus tard que ce qui prend réellement du temps, c’est le transfert stable d’unités de travail entre plusieurs modèles. Quand utiliser un grand modèle, quand utiliser un modèle léger et quand simplement utiliser un modèle local, cela ne dépend pas de la préférence verbale, mais d’une couche de surface de contrôle qui peut être utilisée pour le détournement et la dissimulation. Sans cette couche de choses, l’auto-hébergement passera de « prendre l’initiative » à « prendre en charge vous-même la complexité de l’exploitation et de la maintenance ».

Simon Willison a mentionné qu’il fallait laisser les modèles les plus forts choisir des modèles plus petits pour faire le travail. Cette idée est également très similaire à ce que fait le plan de contrôle. Le modèle lui-même ne connaît pas nécessairement les limites de coûts de l’équipe, mais le système les connaît. Traiter le modèle comme un intermédiaire et l’utiliser pour répartir les tâches est plus proche d’une prestation réelle que de poursuivre aveuglément un modèle unique pour une prestation globale.

L’acceptation et les objectifs ne peuvent pas être externalisés

« Bring me a Rock » de Sam Ruby a mis en lumière un autre problème. Donner le travail au modèle équivaut à ajouter un exécuteur testamentaire ; la responsabilité ne disparaît pas. Les gestionnaires peuvent utiliser LLM pour l’exploration, et ils peuvent d’abord le laisser cracher un tas de solutions candidates, mais les critères d’acceptation finaux doivent encore tomber entre des mains humaines. Les objectifs cachés sont les plus gênants. Les autorisations, la confidentialité, les actions destructrices et les fuites de contexte ne sont souvent pas incluses dans les exigences initiales.

Les tests de conformité sont donc souvent plus utiles que les spécifications. Les spécifications sont efficaces pour décrire « ce qui est requis » et les tests sont meilleurs pour exposer « ce qui ne peut pas arriver ». Cela est particulièrement vrai dans les systèmes Agent. Le modèle peut très bien compenser les objectifs explicites, mais les limites implicites doivent être vérifiées par une vérification plus rigoureuse. Tant que les conditions d’acceptation restent dans des descriptions vagues, plus l’agent en fera, plus le système aura l’air de parier sur les probabilités.

Par conséquent, la révision du code, la gestion des incidents et l’attribution des tâches, qui étaient autrefois des tâches très humaines, commencent désormais à prendre d’autres formes. Les managers utilisent directement le modèle. En apparence, cela semble améliorer l’efficacité, mais au fond, ils changent en fait une méthode de gestion : des méthodes de gestion à la gestion des objectifs. Si l’objectif est clairement écrit, le modèle aura une chance de fonctionner ; si l’objectif n’est pas clair, le modèle ne fera qu’amplifier l’ambiguïté pour les autres.

L’expérience et les compétences en lecture continuent de s’améliorer

L’expertise interactionnelle et l’expertise contributive évoquées par Dan Davies sont également très pertinentes dans ce changement. Le modèle peut lire beaucoup de documents et porter un jugement décent, mais pour que le système soit stable, il faut toujours quelqu’un qui puisse lire les spécifications, voir les résultats et savoir ce qui ne va pas. La clé ici n’est pas que les gens doivent rivaliser avec le modèle pour voir qui est le plus intelligent, mais qu’ils doivent continuer à occuper une position qui définit les limites.

Cette question est plus simple lorsqu’il s’agit de livraison de logiciels. Une fois que l’agent aura pris le relais, le travail humain reposera moins sur l’exécution manuelle et davantage sur la segmentation des tâches, la définition des limites, la conception de l’acceptation et la gestion des exceptions. La possibilité de confier les tâches détermine clairement si la gestion du contexte, le routage des modèles et l’orchestration des outils en valent la peine. Si l’unité n’est pas claire, quel que soit le nombre de couches, cela ne fera que repousser le problème.

Après avoir lu ces fragments ces derniers jours, ce qui me reste à l’esprit n’est pas un certain nom de modèle, ni un nouveau cadre, mais un jugement plus simple : la première chose que le système Agent doit renforcer n’est pas la capacité du modèle, mais l’unité de travail. Si l’unité est plus petite, l’acceptation plus stricte et les autorisations plus strictes, le système aura la possibilité de maintenir la complexité dans une plage contrôlable.