J'ai fait tourner 1 000 agents IA en 6 étapes, 5 prompts et 1 fichier (Guide du développeur)

Le prompting est mort en 2024. La nouvelle compétence, c'est l'orchestration

J'ai fait tourner 1 000 agents IA pendant 30 jours, et voici ce que j'ai découvert

La compétence qui a remplacé le prompting, et les systèmes que vous pouvez déployer dès aujourd'hui.

Arrêtez d'optimiser votre prompt. Ce n'est plus le goulot d'étranglement.

Avec un agent dans une seule fenêtre de chat, le prompt représente l'essentiel du jeu.

Avec dix agents qui tournent pendant des heures, le prompt n'est plus qu'une variable d'ajustement.

Ce qui détermine la qualité du travail, c'est le système qui entoure les agents :

• le mode dans lequel chaque tâche s'exécute
• le modèle qui prend en charge chaque étape
• la façon dont les agents restent coordonnés
• la manière dont le « terminé » est vérifié pendant que vous dormez

Un prompt vous donne un résultat. Une boucle vous donne une opération qui se cumule.

Le changement est simple. Vous cessez d'être la personne qui lit chaque résultat et tape l'instruction suivante. Vous devenez celle qui conçoit le système une fois et le laisse fonctionner.

Cette couche de conception est désormais le cœur du métier. Voici comment la construire.

Vous construisez l'orchestrateur, pas le code

Vous ne gérez pas trente agents en parlant à trente agents. Vous parlez à un seul. C'est l'orchestrateur, et il gère les autres.

Un bon orchestrateur fait exactement trois choses :

1. Décomposer un objectif en sous-tâches délimitées et vérifiables indépendamment.
2. Déléguer chaque sous-tâche à un exécutant, avec un brief précis et une propriété claire des fichiers.
3. Assembler les résultats et décider de la suite.

Une règle prime sur toutes les autres : l'orchestrateur n'effectue jamais le travail lui-même.

Dès que votre agent principal commence à écrire du code d'implémentation, son contexte se remplit de détails et il perd le fil de l'ensemble du projet.

Gardez son contexte propre. Il réfléchit, décompose, attribue et vérifie. Rien d'autre.

Ensuite, allez en profondeur, pas en largeur :

• Ne faites pas spawner huit exécutants directement par l'orchestrateur. Cela brise son contexte.
• Faites-lui plutôt spawner deux ou trois responsables.
• Laissez chaque responsable spawner ses propres deux ou trois spécialistes.

Le gain est une profondeur de décomposition trois fois supérieure pour le même coût de contexte. C'est ainsi qu'une véritable organisation passe à l'échelle : par couches, et non en ayant une seule personne qui assigne chaque tâche.

Vérifiable ou non : la division qui décide de tout

Avant de construire quoi que ce soit, posez une question sur la tâche. Une machine peut-elle vérifier si elle est terminée ?

Cette réponse détermine toute votre approche.

Si la tâche est vérifiable, vous pouvez la boucler :

• Les tests passent ou ne passent pas.
• Le vérificateur de type est au vert ou non.
• Le benchmark franchit le seuil ou pas.

Ordonnez un agent sur une tâche vérifiable et il va l'escalader pendant la nuit. Vous vous réveillez avec un problème résolu.

Si la tâche n'est pas vérifiable, une boucle seule ne vous sauvera pas. Exemples :

• Concevoir une bonne évaluation.
• Décider si une API semble appropriée.
• Juger si une direction de recherche mérite d'être poursuivie.

Pour celles-ci, vous injectez du goût. Vous ne pouvez pas confier l'objectif et partir, car il n'y a pas de porte pour s'arrêter.

La solution est donc de rendre autant de travail que possible vérifiable :

• Transformez « rends-le bon » en « passe ces vérifications spécifiques ».
• Remplacez les objectifs vagues par des objectifs concrets et mesurables.
• Là où vous ne pouvez pas, gardez un humain dans la boucle pour piloter.

L'essentiel de l'ingénierie d'orchestration consiste à convertir des objectifs flous en objectifs vérifiables, afin que la boucle puisse prendre le relais.

Commencez par le plus petit système réel : une boucle d'objectif

Une boucle d'objectif, c'est un objectif persistant plus une vérification déterministe. L'agent travaille étape par étape vers une cible au lieu de s'arrêter après un tour.

Le système entier est une boucle autour de votre agent et d'un validateur :

1i=0
2until npm test -s; do
3  agent -p "Objectif : rendre la suite de tests verte.
4            LIS le code et construis une image complète AVANT de changer quoi que ce soit.
5            'npm test' échoue. Fais le plus petit changement possible pour réussir."
6  (( ++i > 20 )) && { echo "stop : 20 itérations"; exit 1; }
7done

Le validateur est n'importe quelle commande dont le code de sortie est la porte. Tests, vérification de type, lint, ou script personnalisé.

Deux choses sont non-négociables :

1. Une limite. Une boucle sans condition d'arrêt, c'est vous réveiller avec une facture de jetons à cinq chiffres.
2. Une instruction « lire d'abord ». Le mode d'échec par défaut de tout agent est de tirer au hasard sur le premier correctif plausible au lieu de lire le code.

Forcez la lecture. C'est plus lent par étape et bien plus rapide globalement.

Rendez le « terminé » non-négociable : le juge

Les agents s'arrêtent tôt. Ils sont entraînés à s'arrêter dès qu'ils peuvent le justifier.

« J'ai fait de mon mieux, je m'arrête là » n'est pas la même chose que « terminé ».

Si un agent note son propre travail, il triche. Pas méchamment. Il se persuade simplement d'être fini.

La solution est un juge séparé :

• Un second agent dont le seul travail est d'évaluer le travail par rapport à une grille d'évaluation concrète.
• Il répond à une question : terminé, ou pas terminé, et ce qui manque.
• Il n'a aucun intérêt à s'arrêter, donc il ne flanche pas.

Faites tourner le constructeur et le juge sur des familles de modèles différentes. Différentes familles font des erreurs non corrélées, donc le juge voit ce que le constructeur ne voit pas.

1while :; do
2  agent --model "$BUILD" -p "Tâche : $TASK. Lis d'abord, implémente, exécute les tests."
3  verdict=$(agent --model "$JUDGE" -p "Relecteur strict. Évalue par rapport à chaque élément de rubric.md.
4            Réponds exactement 'PASS' ou 'FAIL : <ce qui manque>'.")
5  [[ $verdict == PASS* ]] && break
6done

Rendez la grille d'évaluation concrète et binaire :

• Bonne grille : « tous les tests verts, migration incluse, pas de logs de débogage. »
• Mauvaise grille : « rends-le bon. »

Un vérificateur désintéressé avec un droit de veto est la seule chose qui permette à une exécution de continuer pendant des heures au lieu de s'effondrer dès que l'exécutant se fatigue.

Déclenchez-le à chaque achèvement de tâche. Ainsi, vous ne voyez que du travail validé comme vert.

Plus de boucles que vous utiliserez réellement

La boucle d'objectif est le motif de base. Quelques variantes couvrent la plupart de ce que vous ferez tourner.

1. La boucle de validation.

Agir, exécuter le validateur, renvoyer l'échec, répéter jusqu'à ce que la porte soit verte.

Utilisez-la pour les explorations de régression, les vérifications de type, et tout succès ou échec déterministe.

2. La boucle de file d'attente et de réinitialisation.

Divisez le travail en une liste de petites tâches atomiques. Traitez-en une à la fois.

Après chaque tâche, réinitialisez l'agent dans un contexte propre et passez à la suivante.

Un contexte qui tourne pendant des heures se remplit de confusion. La réinitialisation garde chaque tâche propre.

La mémoire vit en dehors de l'agent, dans le fichier de tâches et l'historique des commits.

1while read -r task; do
2  agent -p "Tâche : $task. Lis d'abord. Implémente, puis exécute les tests."
3  npm test -s && git commit -aqm "auto : $task"   # commit uniquement sur vert
4done < tasks.txt

3. La boucle de surveillance.

Ordonnez un agent sur un flux de signaux et laissez-le remonter ce qui compte. Tickets ouverts, builds qui échouent, logs d'erreur, nouveaux retours.

Il n'attend pas que vous demandiez. Il lit, trie et remonte, ou ouvre un correctif préliminaire.

1while sleep 300; do
2  agent -p "Lis les 5 dernières minutes de logs d'erreur. Si un NOUVEAU motif apparaît,
3            ouvre un ticket avec une reproduction minimale. Sinon, dis 'rien de nouveau'."
4done

4. La boucle « planifier, puis construire ».

Exécutez la boucle en deux phases. D'abord un passage de planification qui produit un plan écrit et s'arrête.

Vous révisez le plan. Ensuite, un passage d'exécution suit le plan approuvé.

Le plan est peu coûteux à corriger. Le code est coûteux à corriger. Attrapez la mauvaise direction dans le plan.

Les prompts qui font le travail

Un prompt n'est pas un vœu. Pour un agent, c'est un cahier des charges.

L'écart entre un résultat médiocre et un résultat excellent est presque entièrement dû à la qualité de ceux-ci.

Gardez un petit ensemble de prompts réutilisables. Cinq d'entre eux supportent l'essentiel du poids.

1. Le prompt de décomposition, pour l'orchestrateur :

1Tu es l'orchestrateur. N'écris PAS de code.
2Décompose cet objectif en 3 à 6 sous-tâches délimitées.
3Pour chacune : un brief d'une ligne, les fichiers exacts qu'elle possède, et sa vérification d'achèvement.
4Signale toute tâche qui dépend d'une autre. Produis la liste, puis arrête-toi.
5Objectif : <objectif>

2. Le brief de l'exécutant, pour un spécialiste :

1Tu ne possèdes QUE ces fichiers : <fichiers>.
2Tâche : <une ligne>. Terminé quand : <vérification vérifiable>.
3Lis ces fichiers ET leurs appelants AVANT de modifier quoi que ce soit. Ne change rien en dehors de tes fichiers.
4Quand tu as terminé, écris un rapport de 5 lignes dans <nom>.md, puis exécute les tests.

3. Le prompt du juge, pour une famille de modèles différente :

1Tu es un relecteur strict et sans indulgence. Tu n'as pas écrit ce code.
2Évalue le dépôt par rapport à CHAQUE élément ci-dessous. Un manquement est un ÉCHEC.
3<grille>
4Réponds avec exactement une ligne : 'PASS' ou 'FAIL : <ce qui manque>'.

4. Le prompt « plan d'abord », pour le mode planification :

1Produis un plan écrit pour <objectif>. Couvre : l'approche, les fichiers à toucher,
2les cas limites, la stratégie de test, et ce que tu NE feras PAS.
3N'écris pas encore de code. Arrête-toi après le plan pour que je puisse le réviser.

5. Le prompt « réfléchir ou tuer », quand un agent est bloqué :

1Tu as échoué à la même vérification 3 fois. Arrête de répéter l'approche.
2Réponds en 3 lignes : ce qui a exactement échoué, quelle hypothèse était fausse,
3et la plus petite chose différente à essayer. Ensuite, essaie UNIQUEMENT cela.

Un motif traverse les cinq. Énoncez le rôle, les limites, la vérification d'achèvement, et ce qu'il NE faut PAS faire.

Routage des modèles : la question que tout le monde pose

La question est généralement formulée comme un choix. Dois-je mettre le modèle coûteux sur la planification, ou sur l'implémentation ?

C'est le mauvais cadre. Routez plutôt par rayon d'impact. Demandez-vous où une erreur vous coûte le plus.

La logique est simple :

• Une mauvaise décision en planification se propage à toute votre flotte.
• Une mauvaise ligne dans une fonction délimitée et testée est repérée en quelques minutes.
• Donc, dépensez là où les erreurs sont coûteuses et irréversibles, et économisez là où elles sont bon marché et contenues.

Voici le routage, niveau par niveau :

1. Planification, architecture et décomposition : toujours le meilleur niveau. Le plus grand effet de levier, un volume de jetons minuscule. Être bon marché ici est l'erreur la plus coûteuse que vous puissiez faire.
2. Implémentation avec un cahier des charges précis : niveau intermédiaire, exécution en parallèle. Le cahier des charges a fait la réflexion. Vérifiez avec des tests.
3. Implémentation avec un cahier des charges imprécis : meilleur niveau. Combler les lacunes, c'est du raisonnement, et un modèle bon marché se trompe dans une douzaine de directions.
4. Révision et jugement : une famille différente, et pas une famille bon marché. C'est là que vous attrapez les erreurs coûteuses.
5. Navigation, recherche, résumé et classification : le modèle le moins cher et le plus rapide. Zéro raisonnement, volume élevé. Ne payez jamais de tarifs premium pour du « grep ».

Donc, la vraie réponse à « planification bon marché ou implémentation bon marché » n'est ni l'un ni l'autre aveuglément.

Meilleur modèle sur la planification et la révision, toujours. L'implémentation est la variable.

Différentes familles de modèles ont aussi des personnalités différentes, et cela compte pour le routage :

• Une famille comble les lacunes. Quand le cahier des charges est imprécis, elle fait des hypothèses raisonnables et continue d'avancer. Cela aide quand les hypothèses sont bonnes, et nuit quand elles ne le sont pas.
• Une autre famille est littérale. Elle fait exactement ce que vous avez dit et pas grand-chose de plus, comme un couteau utilitaire de précision.

Utilisez le combleur de lacunes là où le travail est ouvert et le cahier des charges imprécis. Utilisez le littéral pour la révision et pour des changements exacts et bien spécifiés.

Le levier qui contrôle l'implémentation est votre cahier des charges

• Un cahier des charges précis vous donne le droit d'utiliser des exécutants parallèles bon marché.
• Un cahier des charges imprécis vous force à revenir à un modèle coûteux pour combler les lacunes.

Investissez dans le plan précisément pour pouvoir rendre la construction moins chère.

Un piège mérite d'être mentionné. Le routage bon marché optimise le prix de chaque appel, mais il peut détruire silencieusement la part des jetons qui produisent un résultat livrable et fusionnable.

Un modèle bon marché qui réessaie cinq fois et produit du code que vous ne pouvez pas fusionner est plus coûteux qu'un passage propre d'un modèle premium.

Mesurez le coût du résultat utile, pas le coût par appel.

Pour l'échelle, deux chiffres aident :

• Votre meilleur niveau coûte environ cinq fois le prix de sortie par jeton d'un niveau bon marché.
• Le routage par niveaux réduit généralement les dépenses de 40 % à 60 % par rapport à l'exécution de votre meilleur modèle partout.

Compétences : empaquetez un workflow une fois, réutilisez-le pour toujours

Quand vous continuez à coller le même prompt ou à exécuter le même workflow, transformez-le en compétence.

Une compétence est un petit fichier d'instructions que l'agent charge uniquement quand elle est pertinente.

Vous écrivez le workflow une fois, et chaque agent peut y recourir.

Un fichier de compétence a deux parties :

• Un en-tête YAML avec un nom et une description.
• Un corps en markdown avec les instructions réelles.

La description est la ligne la plus importante. Elle dit à l'agent ce que fait la compétence et exactement quand l'utiliser, afin que l'agent la sélectionne tout seul sans que vous la nommiez.

Un fichier de compétence minimal :

1---
2name : révision-thermonucléaire
3description : Révision de code profonde et contradictoire. À utiliser après tout changement non trivial,
4  ou lorsqu'on demande de réviser, auditer ou durcir une diff avant fusion.
5---
6
7# Révision thermonucléaire
8
9Lis la diff complète et les fichiers qu'elle touche. Ne parcours pas.
10
11Révisé en trois passages :
121. Exactitude : erreurs de logique, cas limites, courses critiques, décalages d'un.
132. Sécurité : injection, auth, secrets, entrée non sécurisée, opérations destructrices.
143. Adéquation : correspond-elle à l'architecture existante, ou ajoute-t-elle un nouveau motif ?
15
16Pour chaque constatation : fichier, ligne, gravité, et le correctif en une ligne.
17Termine par un verdict : LIVRER ou BLOQUER, plus les 3 principales choses à corriger en premier.

Règles pour les bonnes compétences :

1. Gardez le fichier court. Moins de quelques centaines de lignes. Déplacez le matériel de référence long vers des fichiers séparés auxquels la compétence renvoie.
2. Faites correspondre le nom à son dossier, sinon il ne se chargera pas.
3. Écrivez la description pour le déclenchement. Énoncez les cas « utiliser quand ».
4. Ne laissez jamais un agent réécrire une compétence. Un humain conserve chaque ligne.

Les compétences sont la façon dont un workflow se cumule. La première fois que vous résolvez bien quelque chose, vous le sauvegardez et le rendez découvrable. Chaque session suivante, c'est gratuit.

En faire tourner plusieurs : la flotte

Une fois qu'une boucle fonctionne, vous passez à l'échelle.

Donnez à chaque exécutant deux choses :

• Son propre répertoire de travail git, pour que jamais deux agents ne touchent aux mêmes fichiers.
• Sa propre fenêtre de terminal, pour pouvoir le surveiller et lui envoyer des messages.

1tmux new-session -d -s fleet
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• Nommez vos agents. En faire tourner quinze, « agent_7 » est inutile.
• Les noms vous permettent d'avoir toute la flotte en tête. Celui-ci possède la couche de données, celui-là écrit les évaluations, cet autre révise.
• La lisibilité est le but. Une flotte que vous ne pouvez pas suivre est une flotte que vous ne pouvez pas diriger.
• Ensuite, faites-les coopérer. Par défaut, les agents s'ignorent et traitent tout ce qui vient d'un frère comme un bruit de fond.

L'astuce est de délivrer les messages entre agents comme des tours d'utilisateur. Les modèles sont entraînés à répondre à l'utilisateur et à ignorer en grande partie les signaux ambiants.

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= renvoie [{id,title,url}]. Câble l'interface utilisateur dessus."

Ce seul mouvement transforme un tas de processus isolés en une équipe qui se transmet des contrats et se débloque mutuellement.

Vous restez au sommet. Vous envoyez un message au responsable, et le responsable relaie vers les exécutants.

Workflows dynamiques : compilez la coordination en code

Une boucle garde la coordination à l'intérieur du modèle. Le modèle décide chaque étape, ce qui brûle des jetons et remplit son contexte.

Un workflow dynamique inverse cela. L'orchestrateur écrit un script qui coordonne les exécutants, et un runtime séparé exécute le script en arrière-plan.

L'idée clé est l'endroit où vit l'état. La boucle, le branchement et les résultats intermédiaires résident dans les variables du script, pas dans la mémoire du modèle.

Ce que cela vous apporte :

• La coordination coûte zéro jeton de modèle, car du code simple le fait.
• Votre contexte principal reste propre. Seul le résultat final revient.
• Il se déploie en largeur. Des dizaines d'exécutants à la fois, jusqu'à un millier sur une exécution.

Quand l'utiliser :

• Le motif est connu et la vérification est objective.
• Le travail est vaste et répétitif. Beaucoup de fichiers, beaucoup de cas, beaucoup de points d'entrée.
• Il peut fonctionner sans surveillance.

Quand ne pas l'utiliser :

• Vous êtes encore en train de déterminer quoi faire. C'est une boucle d'objectif, pas un workflow.
• La tâche nécessite une chaîne de raisonnement cohérente unique. Cela nécessite un seul agent fort, pas un millier.

Une forme concrète. Disons que vous devez migrer 200 fichiers vers une nouvelle API :

1// l'orchestrateur écrit ceci une fois ; un runtime l'exécute, pas le modèle
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`Migre ${file} vers la nouvelle API. Exécute ses tests.`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `migré ${results.length - failed.length} sur ${results.length}. ` +
11       `recommencer : ${failed.map(f => f.file).join(", ")}`;

Lisez ce que cela fait :

1. Il liste les 200 fichiers dans le code, pas dans la tête du modèle.
2. Il exécute 16 sous-agents à la fois, chacun migrant un fichier et exécutant ses tests.
3. Il enregistre succès ou échec par fichier dans un simple tableau.
4. Il renvoie un court résumé. Les 200 transcriptions intermédiaires ne touchent jamais votre contexte.

C'est tout l'intérêt. Le modèle a fait la réflexion une fois, pour écrire le script. Le script a fait la coordination, gratuitement.

Garde-fous : ce qui empêche une flotte de se dévorer elle-même

Le goulot d'étranglement humain faisait autrefois le vrai travail. À la vitesse humaine, les erreurs font mal tôt et vous les corrigez en cours de route.

Supprimez-vous complètement et les petites erreurs s'accumulent plus vite que vous ne pouvez les ressentir. Une duplication ici, une abstraction inutile là.

Un jour, l'architecture ne pliera plus, et vos tests ne sont plus fiables parce que les agents les ont aussi écrits.

Chaque garde-fou ci-dessous remplace la correction que le goulot d'étranglement fournissait auparavant :

1. Lire avant de deviner. Faites-en une règle permanente dans chaque prompt de construction, pas une supplique par tâche.
2. Limiter et tuer. Chaque boucle a une limite d'itérations. Chaque agent a un budget de jetons qui se met en pause automatiquement près de 85 %. Après trois itérations bloquées sur la même erreur, tuez l'agent et confiez la tâche à un nouveau.
3. Un fichier, un propriétaire. Isolez avec des répertoires de travail. Ne laissez jamais deux agents modifier le même fichier.
4. Réinjectez la mission. Sur les longues exécutions, postez la liste de contrôle comme un message utilisateur toutes les quelques minutes pour que l'agent ne dérive pas à mesure que son contexte se remplit.

1while sleep 900; do
2  send gauss "RAPPEL : toujours sur la tâche ? Lis d'abord. Exécute les tests après chaque changement. Reste dans tes fichiers."
3done &

Le point le plus profond se situe en dessous de tout cela :

• La vérification est désormais le goulot d'étranglement, pas la génération.
• Les agents produisent des résultats plausibles plus vite que vous ne pouvez les vérifier.
• Plausible n'est pas correct.

Jusqu'à ce que votre vérification soit aussi rapide que votre génération, la révision humaine n'est pas une surcharge. C'est le système de sécurité.

Mémoire : vous êtes le stockage à long terme

Un modèle a une mémoire à court terme, la fenêtre de contexte, et rien d'autre. Tout ce qui dépasse cette fenêtre est perdu, sauf si vous le portez.

Considérez donc vous-même, et les fichiers que vous conservez, comme la mémoire à long terme pour les agents qui n'ont qu'une mémoire à court terme.

Deux habitudes comptent.

Premièrement, transmettez l'état par référence, pas par résumé :

• Quand un contexte se remplit, la solution paresseuse est de le résumer. Les résumés sont avec perte et suppriment les détails dont vous aurez besoin plus tard.
• Au lieu de cela, orientez les agents vers des fichiers, des enregistrements de tâches et des sorties antérieures qu'ils peuvent relire. Rien d'important n'est silencieusement jeté.

Deuxièmement, conservez la mémoire durable en dehors de l'agent :

• Un fichier de tâches avec des statuts.
• Un journal de progression en cours.
• L'historique des commits.
• Un fichier de notes à long terme qui collecte les motifs et les pièges.

Concevez comme si vos agents allaient tourner pendant des jours, car avec une bonne compaction, ils le feront.

Les modèles ne le savent pas encore eux-mêmes. Ils portent un biais vers la résolution de tout en un seul budget court, comme si dépenser des jetons était fatal. Votre échafaudage est ce qui leur permet de tourner longtemps sans perdre le fil.

Topologie : combien d'agents, et sous quelle forme

Plus d'agents n'est pas plus de résultats. Au-delà d'un certain point, c'est moins, car la coordination n'est pas gratuite et elle se cumule avec chaque agent que vous ajoutez.

La règle qui compte est d'adapter la forme au travail :

• Le raisonnement séquentiel et dépendant nécessite moins d'agents, parfois un seul. Diviser une chaîne de pensée unique fragmente le raisonnement et dégrade le résultat.
• Le travail indépendant et parallèle nécessite un déploiement en largeur. Topologie plate, propriété claire des fichiers. C'est là que le parallélisme paie.
• Une équipe coordonnée nécessite trois à cinq exécutants. Le coût en jetons augmente à peu près linéairement avec la taille. Le coût de coordination augmente plus vite. Trois exécutants concentrés battent cinq exécutants dispersés.

Alors, comment quelqu'un peut-il en faire tourner des centaines ? Pas comme une seule conversation géante qui se dispute avec elle-même.

Ils les font tourner en profondeur et en indépendance :

• Quelques agents avec lesquels vous parlez réellement, chacun déléguant vers le bas à des sous-tâches délimitées qui n'ont pas besoin de se coordonner.
• Des essaims de boucles indépendantes faisant leur propre chose et remontant.

Le passage à l'échelle vient de la profondeur de délégation et de l'indépendance. Jamais de l'élargissement d'un seul fil.

Le fichier de contrôle : orchestration.md

Vous conservez probablement un fichier qui dit aux agents comment écrire du code dans votre dépôt. Style, pièges, architecture. Gardez-le.

Il répond cependant à la mauvaise question pour l'orchestration.

Le fichier orchestration.md répond à une question différente. Comment le travail doit-il être exécuté ici ?

C'est un contrat rédigé par un humain qui couvre :

• quel mode utiliser pour quelle tâche
• quel niveau de modèle va où
• quels sont les garde-fous
• quand escalader vers un humain

Chaque agent le lit au début de chaque session et l'utilise pour auto-sélectionner son approche.

C'est le fichier au plus grand effet de levier dans le dépôt. Il déplace la décision de sélection de mode hors de votre tête, où vous la reprenez de manière incohérente à chaque session, et dans un cahier des charges que la flotte suit.

Une version courte ressemble à ceci :

1# orchestration.md. Comment le travail est EXÉCUTÉ ici. Conservé par un humain. Les agents ne doivent pas modifier.
2
3Choisis le mode :
4- Boucle d'objectif (supervisée) : travail flou ou de conception. Définis la vérification d'achèvement.
5- Boucle de validation : porte déterministe. Limite toujours les itérations et le coût.
6- Construction plus juge : l'exécutant construit, un juge d'une famille différente approuve.
7- Flotte (trois à cinq) : sous-tâches interdépendantes, répertoires de travail isolés, messagerie entre pairs.
8- File d'attente et réinitialisation : nombreuses petites tâches atomiques, contexte frais à chaque fois.
9- Workflow dynamique : motif connu, porte objective, vaste et répétitif. Coordination dans le code, sans surveillance.
10
11Route les modèles par rayon d'impact :
12- Planification et architecture : meilleur niveau, toujours.
13- Construction, cahier des charges précis : niveau intermédiaire, parallèle, vérifie avec des tests.
14- Construction, cahier des charges imprécis : meilleur niveau, car combler les lacunes est du raisonnement.
15- Révision et juge : une famille différente. Jamais le modèle de l'implémenteur.
16- Navigation, recherche, résumé : le moins cher. Optimise le résultat fusionnable, pas le prix de l'appel.
17
18Garde-fous :
19- Budget de jetons par agent. Pause automatique près de 85 %. Tue et réaffecte après 3 tentatives bloquées.
20- Toute exécution de plus d'une heure nécessite un juge séparé. Les exécutants ne signalent jamais qu'ils ont terminé eux-mêmes.
21- Lis le code avant d'émettre des hypothèses. Planifie par écrit avant la première modification.

Deux règles régissent le fichier :

1. Gardez-le court.
2. Ne laissez jamais un agent le réécrire.

La valeur est qu'un humain a conservé chaque ligne.

Ce qui reste vôtre

L'orchestration rend les agents fiables dans l'exécution. Elle ne choisit pas le problème, et elle ne sait pas ce qui est bon.

Trois choses restent de votre côté de la ligne, en permanence.

Premièrement, déléguez les tâches, pas le jugement :

• Confiez aux agents un travail cadré avec des critères clairs de réussite ou d'échec. Modèles, migrations, échafaudages de tests, et approches que vous n'auriez jamais le temps d'essayer à la main.
• Gardez l'architecture, la décision sur ce qu'il ne faut pas construire, et la révision en contexte complet pour vous-même.
• Les agents ont absorbé un océan d'architecture médiocre, et ils reproduiront volontiers des motifs lourds dans un projet qui ne devrait pas les avoir. Dire non est une fonctionnalité qu'ils n'ont pas.

Deuxièmement, votre cahier des charges est l'effet de levier :

Un cahier des charges qui attrape la mauvaise direction avant que la première ligne de code ne soit écrite est la chose la plus productive que vous ferez.

Lorsque vous vous déployez sur une flotte, une pensée vague ne vous ralentit pas seulement. Elle se multiplie.

Une exigence ambiguë se propage à travers des dizaines d'exécutions parallèles, chacune déviant dans sa propre direction.

Un cahier des charges précis se multiplie en implémentations précises partout.

C'est pourquoi un bon ingénieur tire davantage de ces outils, pas moins. La frappe a été automatisée. La compréhension a été amplifiée.

Passez la majeure partie de votre temps en mode planification, sur un plan écrit sur lequel tout le monde s'aligne, avant la première modification.

Troisièmement, sous-financez délibérément :

• Faites travailler deux agents sur un travail qui en nécessite quatre. La contrainte impose le comportement souhaité.
• Vous créez des boucles au lieu de faire les choses à la main, et la prochaine fois, ce travail est déjà automatisé.
• Déplacez votre budget de l'effort manuel vers les tokens. Investissement élevé au départ, coût marginal quasi nul par la suite.

Les équipes qui font cela cumulent les bénéfices. Celles qui ne le font pas paient le prix fort à chaque fois.

Vous n'écrivez plus le logiciel. Vous construisez l'usine qui l'écrit.

Une usine a besoin d'intrants précis, d'un contrôle qualité à chaque poste, et d'un propriétaire qui sait ce que le produit est censé être.

Commencez ici

N'essayez pas de lancer cent agents lundi. Gravissez l'échelle :

1. Exécutez une boucle d'objectif sur une tâche avec une ligne d'arrivée vérifiable. Apprenez à quoi ressemble un bon contrôle d'achèvement.
2. Ajoutez un juge d'une famille de modèles différente pour toute tâche de plus d'une heure. Interdisez l'auto-déclaration d'achèvement.
3. Écrivez votre orchestration.md. Dites à vos agents de le lire en premier. Regardez-les commencer à choisir des modes pour vous.
4. Déployez-vous prudemment. Une tâche parallélisable, trois à cinq travailleurs, des arbres de travail isolés, des budgets de tokens.
5. Acheminez vos modèles. Le haut de gamme pour la planification et la relecture, le moins cher pour les tâches de construction et de routine. Mesurez le résultat fusionnable.
6. Laissez-le tourner sans surveillance une fois qu'un modèle est validé et vérifiable objectivement. Épuisez le backlog pendant la nuit.

Le système n'a besoin d'être qu'approximativement correct, pas parfait :

• Le fichier de contrôle donne à la flotte suffisamment de structure pour s'auto-diriger.
• Le juge attrape les cas limites.
• La boucle de rappel gère la mémoire.
• Votre goût gère les décisions qui ne se délèguent pas.

Le prompt était la compétence de l'année dernière. C'est la compétence maintenant.

Les versions exécutables de chaque système ici – la boucle d'objectif, la boucle de juge, le lanceur de flotte, le bus de messages, le chien de garde de rappel et le routeur de modèles – se trouvent dans le kit compagnon. Définissez une variable sur votre CLI d'agent et lancez-vous.

Avertissement

Cet article a été rédigé en utilisant des sessions Claude Code et des sessions codex de l'auteur.

Édité par l'auteur et le modèle Kimi K2.6 pour des problèmes de grammaire et de formatage.