Des agents pendant que vous dormez : le runtime est trivial, le pipeline est dur

Chaque développeur qui construit avec des agents IA a eu le même fantasme à 3 heures du matin. Vous allez dormir. Une flotte d’agents passe en revue votre backlog, corrige des bugs, construit des fonctionnalités, et le matin vous revoyez une pile de petits changements testés et bien expliqués. Les mauvais matins, vous revoyez une catastrophe et vous êtes content de l’avoir attrapée.

J’ai essayé de rendre ça réel, et j’ai appris la dure façon une chose qui sonne évidente : garder le processus agent en vie est trivial. Le pipeline de travail est le vrai problème.

Le runtime est un projet de week-end

Il y a quatre façons de garder un agent qui tourne 24h/24, et aucune n’est dure :

tmux — un agent interactif survit aux déconnexions et à la déconnexion SSH
cron + mode print — pi -p "check the failing tests" sur un timer, des runs one-shot qui sortent proprement
mode RPC — un processus long-lived auquel un autre programme parle
un daemon SDK — embarquez l’agent dans votre propre processus Node et bouclez sur une queue

N’importe laquelle de celles-ci tourne soixante-douze heures d’affilée sans se plaindre. Et aucune ne produira un seul commit utile. Parce que la question n’a jamais été « comment je garde le processus en vie ? » C’est :

sur quoi l’agent travaille ?
que signifie done ?
comment le travail atterrit ?
comment plusieurs agents évitent de s’écraser les uns les autres ?

Appelez ces quatre choses la source de tâches, la définition de done, la porte d’atterrissage, et l’allocateur.

Ce que ~300 runs m’ont appris sur la partie écrasement

Je construis gitaccord, des git hooks qui laissent plusieurs agents IA travailler sur un même repo en parallèle. Il existe à cause d’un échec que j’ai vu à plusieurs reprises dans les expériences : donnez à plusieurs agents capables le même dépôt et laissez-les choisir des fonctionnalités et atterrir leur propre travail avec du git plain — pas d’autorité de merge humaine centrale. Les agents résolvent les conflits de merge correctement. Ce n’est pas le danger.

Le danger, c’est l’agent qui atterrit en dernier et réécrit tranquillement la fonctionnalité d’un autre agent pour coller à la sienne, ajuste les tests, et rapporte le succès. Dans notre spike, sur environ 300 runs avec Claude Code (Sonnet) et pi (GLM), ça s’est produit dans 24–28 % des runs sur du git plain. Aucune malice nulle part. Chaque agent a fait exactement ce qu’un agent solo bien élevé devrait faire. L’échec était structurel : les agents ne pouvaient pas voir les plans et le raisonnement des autres, donc « merge » est silencieusement devenu « overwrite ».

gitaccord corrige ça de façon volontairement ennuyeuse. Une branche par agent. Un fichier de plan par tâche que chaque agent lit. Une ligne Why: sur chaque commit expliquant le raisonnement. Une porte pre-push qui refuse d’atterrir tout changement qui casse la fonctionnalité d’un autre agent sauf s’il est déclaré comme un Override: pour revue humaine. Dans les mêmes ~300 runs : les overrides silencieux sont passés à 0 %, main n’a jamais été laissé cassé, et chaque décision sans issue a été signalée pour un humain au lieu d’être résolue silencieusement.

Donc des quatre pièces, je dirais que la porte d’atterrissage et l’allocateur sont solubles — surtout avec des conventions et des hooks, pas de nouvelles plateformes.

Quels jobs marchent réellement la nuit

La contrainte n’est pas la capacité de l’agent. C’est si done est vérifiable par machine. Un humain qui dort ne peut pas se faire demander « est-ce la fonctionnalité que tu voulais ? » à 3 heures du matin.

Ce qui marche :

Corrections de bugs avec une repro qui échoue. Le test rouge devient vert, la suite complète passe, le diff est petit.
Expansion de couverture de tests sur du code existant — couverture en hausse, comportement prouvé inchangé.
Petites fonctionnalités entièrement spécifiées découpées d’un plan écrit par un humain.
Mises à niveau de dépendances, où la suite décide.
Triage — reproduire un rapport de bug, écrire le test qui échoue, draft la fix sur une branche. Il n’a même pas besoin d’atterrir.

Ce qui ne marche pas la nuit — et c’est là que beaucoup de rêves d’agents 24/7 meurent tranquillement :

« Figure out what to build next. » La direction ouverte n’a pas de done vérifiable par machine. Il y a une bonne forme pour ça cependant : un agent écrit une proposition + spike + test d’acceptation qui échoue sur sa branche et ne l’atterrit pas. Vous approuvez la direction le matin. L’autonomie d’atterrissage était toujours le problème plus facile ; l’autonomie de direction est celle que vous devriez garder.

La boucle de nuit

À quoi ressemble le tout quand ça marche :

soir                nuit                               matin
─────────          ──────────────────────────────      ──────────────
humain écrit/      l’agent prend la tâche N            l’humain lit un digest :
élague le backlog ──▶ écrit son plan                    ▸ ce qui a atterri
                   implémente, teste, commit            ▸ overrides signalés &
                   merge main, passe la porte              décisions sans issue
                   répète pour la tâche N+1 …           ▸ propositions en attente de direction

Les règles qui le gardent en vie jusqu’au matin :

Petites tâches. Les longs runs autonomes pourrissent par dérive de contexte. Un bug par tâche, une tranche par fonctionnalité.
Autonomie bornée. Un plafond par nuit, un budget par run, des branches par agent. Une tâche échouée est enregistrée et la boucle continue au lieu de thrash.
Un seul output que vous devez lire : la file de flags. Le job du système est de rendre cette file courte et à fort signal — les Override: et décisions sans issue — pour que votre revue du matin prenne des minutes, pas des heures.

Remarquez où vit le vrai engineering, cependant. Une boucle daemon fait cent lignes. Le format de backlog, l’allocateur, le générateur de digest — cette colle entre la direction humaine et l’exécution agent est le vrai build. Presque personne ne l’a productisé, parce que tout le monde (moi y compris) reste coincé à polir le runtime agent au lieu.

Où j’en suis, honnêtement

Je n’ai pas encore la boucle de nuit qui tourne. J’ai la partie dure du milieu en cours : les hooks et conventions qui empêchent les agents de détruire le travail des autres quand il n’y a pas de porte humaine. Les options de runtime sont là, prêtes. La pièce manquante est le pipeline ennuyeux — et mon plan est de le faire tourner d’abord sur gitaccord lui-même : le backlog de porter chaque hook du spike à l’implémentation réelle s’écrit tout seul, et si des agents de nuit cassent quelque chose, ma propre porte d’atterrissage est l’endroit le moins cher possible pour l’apprendre.

Ce que j’aimerais de vous

Si vous avez essayé de faire tourner des agents sans surveillance — ou décidé de ne pas le faire — je veux entendre où ça a cassé :

Quelle est votre source de jobs ? Fichiers de backlog, issues GitHub, autre chose ?
À quoi ressemblait votre définition de done, et les agents ont-ils trouvé des loopholes dedans ?
Avez-vous laissé le travail atterrir sur une branche main, ou l’avez-vous mis en queue pour revue le matin ?
Quelqu’un a-t-il shippé un bon outil d’allocation de tâches / digest, ou est-ce que tout le monde le fait à la main ?

Les guerres de runtime sont terminées. Le pipeline est là où ça se gagne ou se perd.