Le problème du travail de nuit : comment les agents travaillent tout en oubliant tout

Donne à Claude une tâche suffisamment vaste et il abandonnera à mi-chemin, convaincu d'avoir fini. Le travail n'est pas terminé. Il ne se souvient tout simplement pas d'avoir commencé.

Un agent ne travaille pas sur une tâche longue comme on pourrait le croire. Il travaille par équipes.

Imaginez un projet logiciel géré par des ingénieurs qui travaillent en quarts, où chaque nouveau arrivant débarque sans aucun souvenir de ce qui s'est passé pendant le quart précédent. Ce n'est pas une métaphore pour décrire ce que ressentent les agents. C'est mécaniquement ce qu'ils sont. La fenêtre de contexte est finie, la plupart des travaux réels n'y tiennent pas, donc l'agent travaille en sessions distinctes – et chaque nouvelle session commence sans aucun souvenir de la précédente.

Anthropic a mené exactement cette expérience et a publié ce qui a cassé. C'est cette partie qui vaut la peine d'être lue, car ce n'est pas un blogueur disant que l'outil est faible. C'est l'équipe qui construit Claude qui documente là où Claude s'effondre.

Pourquoi une seule fenêtre ne peut pas terminer le travail

Donnez à un modèle de codage de pointe une instruction de haut niveau – « construis un clone de claude.ai » – mettez-le dans une boucle à travers plusieurs fenêtres de contexte, et il échoue à produire une application fonctionnelle. Pas parfois, de manière fiable. Et c'est Opus fonctionnant sur le propre framework d'agents d'Anthropic, avec la compaction de contexte activée, toute la configuration conçue pour le maintenir en marche.

Il échoue de deux manières spécifiques, et les deux sont des problèmes de transfert entre équipes.

La première : l'agent essaie de tout faire à la fois. Il tente de réaliser l'application entière en une seule fenêtre, manque de contexte à mi-chemin d'une fonctionnalité, et la session se termine avec quelque chose de moitié construit et non documenté. L'équipe suivante arrive, voit un désordre qu'elle n'a pas créé, et doit deviner ce qui se passait. Elle passe donc toute sa session à simplement faire fonctionner à nouveau l'application de base, au lieu d'avancer.

La seconde apparaît plus tard, une fois que certaines fonctionnalités existent. Un agent frais regarde autour, voit que des progrès réels ont été réalisés, et décide que tout est terminé. Mais ce n'est pas le cas – la moitié des fonctionnalités n'ont jamais été construites, et personne n'a noté lesquelles. L'équipe a déclaré le travail fini sans vérifier la liste.

Les deux échecs ont la même cause. L'équipe qui part n'a rien laissé derrière elle, donc l'équipe qui arrive travaille à l'aveugle. La solution n'est pas un modèle plus intelligent. C'est ce que l'équipe note avant de partir.

Ce que l'équipe qui part doit écrire

La réponse sur laquelle Anthropic a atterri comporte deux parties : un agent qui met en place le site avant que le travail ne commence, puis les travailleurs en quarts qui se succèdent session après session pour faire avancer les choses.

L'agent de configuration s'exécute une fois, au tout début. Son seul travail est de laisser l'environnement dans un état où chaque future équipe sait à quoi ressemble « fini ». La pièce clé qu'il écrit est une liste de fonctionnalités – un fichier structuré énumérant chaque chose que l'application finie doit faire.

Pour le clone de claude.ai, cela signifiait plus de 200 fonctionnalités. Des choses comme « un utilisateur peut ouvrir une nouvelle discussion, taper une requête, appuyer sur Entrée et voir une réponse. » Chacune marquée comme échouant au début. Chaque entrée ressemblait à peu près à ceci :

1{
2  "description": "Le bouton Nouvelle discussion crée une conversation vierge",
3  "steps": ["cliquer sur Nouvelle discussion", "vérifier la conversation vierge", "vérifier l'état d'accueil"],
4  "passes": false
5}

Ce « passes » : false sur chaque entrée est tout l'intérêt. C'est une case non cochée, et il y en a 200.

Cette liste d'échecs est ce qui empêche un agent de déclarer victoire trop tôt. Une équipe ne peut pas regarder autour et décider que le travail est fini, car il y a un fichier juste là avec 200 cases non cochées. Le travail est défini avant que la première ligne ne soit écrite.

Un petit détail qui montre à quel point cela a dû être minutieux : ils ont utilisé du JSON pour ce fichier, pas du Markdown. La raison est que le modèle est moins susceptible de réécrire ou supprimer discrètement un fichier JSON qu'un fichier Markdown. Et les instructions autour sont volontairement brutales – il est inacceptable de supprimer ou modifier des tests, car supprimer un test, c'est ainsi qu'une fonctionnalité disparaît en silence. L'équipe a le droit de cocher une case. Elle n'a pas le droit d'en effacer une.

La note sur le bureau

Mettre en place le travail, c'est la moitié de l'affaire. L'autre moitié consiste à s'assurer que chaque équipe laisse l'endroit assez propre pour que la suivante puisse entrer.

Deux choses le permettent. L'agent commit son travail dans git avec un vrai message décrivant ce qui a changé, et il écrit un simple fichier de progression – un journal courant de ce qui a été fait. Ce journal, associé à l'historique git, permet à un agent frais, démarrant à froid, de comprendre l'état des choses en quelques minutes au lieu de passer une heure à faire de la rétro-ingénierie.

Git fait aussi autre chose ici. Quand une équipe fait une mauvaise modification, la suivante peut revenir à la dernière version fonctionnelle au lieu d'essayer de démêler les dégâts. Le fichier de progression dit où nous en sommes. L'historique des commits est le bouton d'annulation.

Et « propre » a un sens spécifique. Cela signifie le genre de code que vous seriez prêt à fusionner dans une branche principale – pas de bugs majeurs, ordonné, documenté. Pas « techniquement, j'ai fait des progrès ». La norme est : la personne suivante pourrait commencer une nouvelle fonctionnalité sans d'abord nettoyer votre désordre.

Comment l'équipe suivante arrive

Mettez ces deux choses en place et chaque équipe commence de la même manière. Avant de toucher quoi que ce soit de nouveau, l'agent exécute une routine d'ouverture fixe pour se repérer – la même chose qu'un bon ingénieur fait en arrivant sur un projet qu'il n'a pas vu depuis un moment.

1exécutez pwd pour voir dans quel répertoire vous êtes – c'est le seul endroit où vous pouvez éditer
2lisez le fichier de progression et le journal git pour voir ce qui s'est passé récemment
3lisez la liste des fonctionnalités et choisissez la chose la plus prioritaire qui n'est pas encore faite
4démarrez l'application et exécutez une vérification de base pour confirmer que les fonctionnalités principales fonctionnent toujours
5ce n'est qu'ensuite, commencez à construire

Cette quatrième étape compte plus qu'il n'y paraît. Avant d'écrire une seule nouvelle fonctionnalité, l'agent démarre l'application et confirme que les bases fonctionnent toujours – ouvre une discussion, envoie un message, reçoit une réponse. Si l'équipe précédente a laissé quelque chose de cassé, cela le détecte immédiatement, avant que la nouvelle équipe n'empile du travail frais sur une fondation brisée et n'aggrave les choses.

C'est toute l'astuce, et c'est presque ennuyeux tellement c'est simple. L'équipe qui part note ce qu'elle a fait et ce qui reste. L'équipe qui arrive lit cela avant de faire quoi que ce soit. Le transfert est tout le jeu.

Vos longues tâches ont aussi des équipes

Tout cela ne concerne pas vraiment la construction d'applications web. Anthropic l'a testé sur du code parce que le code est facile à vérifier, mais la forme en dessous est la forme de toute longue tâche que vous confiez à un agent.

Tout ce qui ne tient pas dans une seule fenêtre a des équipes. Écrire un long rapport chapitre par chapitre. Mener un projet de recherche à travers une douzaine de discussions. Travailler sur une grande analyse pendant des jours. Chaque fois que vous commencez une nouvelle session sur la même tâche, un nouveau travailleur arrive sans mémoire de la précédente – et si vous n'avez pas laissé de note de transfert, il commence par deviner.

Alors laissez-en une. Avant qu'une longue session ne se termine, faites écrire au modèle ce qui a été fait, ce qui reste ouvert, et ce que la prochaine session devrait prendre en premier. Gardez cette note quelque part où il pourra la lire en arrivant. C'est la différence entre un projet qui avance à chaque session et un qui reconstruit sans cesse la même chose.

Même modèle ce soir et demain. La seule chose qui change est de savoir si la session de demain arrive à l'aveugle, ou si elle arrive en lisant la note de la nuit dernière.

Il n'a jamais été question de l'intelligence de l'équipe. Il s'agit de ce qu'elle laisse pour celle qui vient après.

Plus d'analyses comme celle-ci – https://t.me/+xYv1MgmIuds5YTli