Traduction en français (Français) :
En décembre dernier, Boris Cherny a soumis 259 pull requests en un seul mois. Toutes rédigées par Claude. Il déclare ne pas avoir ouvert d'éditeur de la période.
Son travail n'était pas d'écrire du code. C'était d'écrire ce qui écrit le code. Peter Steinberger l'a résumé en deux lignes qui ont été vues plus de 8 millions de fois : « Il ne faut plus demander aux agents de codage. Il faut concevoir des boucles qui demandent à tes agents. »
C'est ça, l'ingénierie de boucle. Tu construis un petit système qui trouve le travail, le confie à un agent, vérifie le résultat, décide de la prochaine action, puis tu le laisses tourner pendant que tu dors.
L'inconvénient est arrivé le même mois. La boucle de quelqu'un d'autre a tourné onze jours sans surveillance et a brûlé 47 000 $ avant que quiconque ne s'en aperçoive. Il s'agit donc vraiment de deux compétences, et presque tout le monde n'enseigne que la première : construire une boucle qui livre du travail, et construire les freins qui l'empêchent de te précipiter dans le vide.
Une seule question détermine quelle boucle tu as construite : converge-t-elle vers quelque chose de vrai, ou n'est-ce qu'une coûteuse marche aléatoire ?
1. Une boucle, c'est six pièces et une question
Sous le bruit, une boucle qui fonctionne comporte six parties. La liste semble trop simple la première fois qu'on la voit. Le détail à l'intérieur de chaque partie est ce qui fait qu'une boucle tient bon ou fuit de l'argent pendant la nuit.
Tu ne construis plus rien de tout cela à la main. Il y a un an, une boucle signifiait un tas de scripts shell que tu possédais et dont tu t'occupais éternellement. Maintenant, les pièces sont intégrées dans les produits, et les six mêmes s'appliquent à la fois à l'application OpenAI Codex et à Claude Code. Une fois que tu as compris ça, l'outil cesse d'être le sujet de débat et la boucle devient la conception.
1PIÈCE RÔLE DANS LA BOUCLE CODEX CLAUDE CODE2------------- ------------------------ ------------------------- --------------------------3État se souvenir d'une exécution à l'autre markdown / Linear (MCP) markdown / Routines + MCP4Automatisations s'exécuter selon un planning onglet Automations + Triage /loop (skill), Routines, /goal5Worktrees isoler les agents parallèles Worktree par fil --worktree, isolation: worktree6Compétences codifier ton intention ~/.agents/skills/SKILL.md ~/.claude/skills/SKILL.md7Connecteurs toucher tes outils réels serveurs MCP (config.toml) serveurs MCP (.mcp.json)8Sous-agents séparer le créateur du vérifieur TOML dans .codex/agents/ .claude/agents/ + équipes d'agents
2. L'état est la seule chose que la prochaine exécution hérite
Commence par le bas, car tout le reste s'appuie dessus.
Un modèle oublie quand une exécution se termine. La conversation meurt, le contexte s'efface, la prochaine exécution se réveille sans rien savoir. La mémoire dans le chat meurt avec l'exécution. Elle doit vivre sur le disque.
En pratique, c'est un seul fichier. Un STATUS.md dans le dépôt, ou un tableau Linear atteint via un connecteur, contenant ce qui est fait, ce qui est en cours, ce qui est à faire, et la poignée de choses que la boucle ne doit jamais toucher.
1# STATUS.md (la boucle lit ceci en premier, l'écrit en dernier)2## Fait3- [x] auth : migration vers tokens v2, tests verts4## En cours5- [ ] facturation : refonte du webhook (PR #214, CI rouge)6## Suivant7- [ ] tableau de bord : test instable dans test/charts8## Jamais9- ne pas modifier infra/ sans un humain
Considère la boucle comme un quart de nuit que tu ne surveilles jamais. On ne te juge pas sur ce qu'elle a fait à 3 heures du matin. On te juge sur la note qui t'attend sur ton bureau à neuf heures. Conçois cette note d'abord, et la majeure partie de la boucle se conçoit d'elle-même.
3. Les automatisations sont la différence entre une boucle et quelque chose que tu as exécuté une fois
Une boucle ne mérite son nom que lorsqu'elle se déclenche toute seule.
Dans l'application Codex, tu en construis une dans l'onglet Automatisations : le dépôt, l'invite, la cadence. Les exécutions qui trouvent quelque chose atterrissent dans une boîte de réception Triage ; les exécutions qui ne trouvent rien s'archivent elles-mêmes. OpenAI utilise cela pour l'épine dorsale sans glamour d'une base de code : tri quotidien des problèmes, résumés des échecs CI, détection du bug que quelqu'un a glissé la semaine dernière.
Claude Code y parvient via quelques primitives, et les articles populaires se trompent souvent sur les détails, donc il vaut la peine d'être précis. /loop est une compétence, pas une commande intégrée, et elle réexécute une invite selon une cadence tant que ta session est ouverte. Les tâches récurrentes dans le cloud sont des Routines, définies avec /schedule, avec un minimum d'une heure, et elles continuent de s'exécuter même lorsque ton ordinateur portable est fermé. Il n'y a pas de crontab local.
Celle qui vaut la peine d'être apprise est /goal. Elle s'exécute jusqu'à ce qu'une condition que tu as écrite soit vraie, et après chaque tour, un modèle séparé plus petit vérifie si tu as réellement terminé. L'agent qui a écrit le code n'a pas le droit de le noter.
1# Claude Code : exécuter jusqu'à ce que ce soit vraiment fini, pas jusqu'à ce que ça semble fini2/goal all tests in test/auth pass and the lint step is clean34# Claude Code : une tâche récurrente dans le cloud (minimum 1 heure)5/schedule daily PR triage at 9am67# Codex : une invite d'automatisation (définir la cadence dans le formulaire)8"Weekdays 9am: scan open PRs, flag failing CI or no reviewer, post to Triage."
Rédige la condition d'arrêt comme un contrat. « Tous les tests dans test/auth passent » est un contrat. « Améliore-le » est une façon de faire tourner une boucle jusqu'au jour de paie.
4. Les worktrees empêchent les agents parallèles de se gêner mutuellement
Dès que tu exécutes plus d'un agent, le mode de défaillance change. Ce n'est plus le modèle. Ce sont deux agents qui écrivent le même fichier, le même désordre que deux ingénieurs qui valident les mêmes lignes sans se parler.
Un git worktree est le mur entre eux : un répertoire de travail séparé sur sa propre branche, partageant l'historique du dépôt, de sorte que les modifications d'un agent ne puissent pas atteindre le checkout d'un autre.
1# Claude Code : un checkout isolé par agent2claude --worktree feature-auth34# ou sur un sous-agent, dans le frontmatter .claude/agents/<nom>.md :5# isolation: worktree67# Codex : choisir "Worktree" lorsque tu ouvres un fil (un HEAD détaché chacun)
Un avertissement que l'outil ne mentionnera pas. Les worktrees suppriment la collision, pas le goulot d'étranglement. Tu es toujours le plafond. Quel que soit le nombre d'agents que tu lances, ta propre bande passante de révision détermine combien tu peux approuver.
5. Les compétences sont ton intention, écrite une fois, à l'extérieur
Un agent commence chaque exécution à froid et comble toute lacune dans ton intention par une estimation confiante. Une compétence est cette intention écrite là où le modèle la lit à chaque fois, afin qu'il cesse de deviner.
Le format est le même pour les deux outils : un dossier avec un SKILL.md contenant des instructions et une description, plus tous les scripts nécessaires. Elle se déclenche lorsque tu l'appelles par son nom ou lorsque ta tâche correspond à sa description, ce qui est exactement la raison pour laquelle une description plate et littérale est préférable à une description astucieuse.
1# .claude/skills/triage/SKILL.md (Codex : ~/.agents/skills/triage/SKILL.md)2---3name: triage4description: Read yesterday's CI failures, open issues, and recent5 commits; write each finding to STATUS.md as a task.6---71. Pull failing CI and cluster by root cause.82. Match each to the open issue or commit that caused it.93. Write one STATUS.md task per real finding. Skip the noise.
Sans compétences, chaque cycle réapprend ton projet à partir de zéro. Avec elles, la boucle devient un peu plus nette chaque matin.
6. Les connecteurs permettent à la boucle d'agir, pas seulement de parler
Une boucle qui ne peut voir que le système de fichiers est un jouet. Les connecteurs, basés sur la norme partagée MCP, permettent à l'agent de lire ton gestionnaire de tickets, d'interroger une API de staging, d'interroger une base de données, de poster sur un canal.
1# Claude Code2claude mcp add --transport http linear https://mcp.linear.app/mcp34# Codex5codex mcp add linear --url https://mcp.linear.app/mcp
C'est la frontière entre un agent qui dit « voici la correction » et une boucle qui ouvre la pull request, lie le ticket, et signale que tout est vert par elle-même. Comme les deux outils parlent MCP, un connecteur que tu branches pour l'un s'installe généralement dans l'autre.
7. Les sous-agents éloignent le créateur du vérificateur
La manœuvre à plus haute valeur ajoutée dans toute boucle est de séparer l'agent qui écrit de l'agent qui vérifie.
Un modèle qui révise son propre travail se valide à chaque fois. Un second agent, avec des instructions différentes et idéalement un modèle différent, détecte ce que le premier s'est persuadé d'accepter.
1# Codex : .codex/agents/reviewer.toml2name = "reviewer"3description = "Adversarial PR reviewer: correctness, security, missing tests."4developer_instructions = "Review like an owner. Assume the author is wrong5 until the diff proves otherwise."6model_reasoning_effort = "high"78# Claude Code : frontmatter .claude/agents/reviewer.md9# name: reviewer10# description: Adversarial reviewer. Use after any code change.11# model: opus
L'un explore, l'un implémente, l'un vérifie par rapport au cahier des charges. C'est ce que /goal fait déjà en arrière-plan : un modèle frais décide si le travail est terminé. Les seconds avis coûtent des tokens, car chaque agent exécute son propre modèle et ses propres outils, alors dépense-les là où se tromper coûte cher.
8. À quoi ressemble une boucle
Mets les six ensemble et un seul fil devient une petite machine.
Une automatisation planifiée s'exécute chaque matin sur le dépôt. Elle appelle ta compétence de tri, qui lit les échecs CI de la nuit, les problèmes ouverts, et les commits récents, et écrit chaque véritable résultat dans STATUS.md. Pour chaque résultat qui vaut la peine d'être traité, la boucle ouvre un worktree isolé, envoie un sous-agent pour rédiger la correction et un second pour la vérifier par rapport à tes compétences et à tes tests. Les connecteurs ouvrent la PR et mettent à jour le ticket. Tout ce qu'elle ne peut pas gérer attend dans ta boîte de réception de tri. STATUS.md se souvient de ce qui a réussi et de ce qui est encore ouvert, de sorte que demain commence là où aujourd'hui s'est arrêté.
Ce à quoi tu te réveilles réellement, c'est à un court compte rendu, pas à un mur de journaux :
1# 9h00 — le compte rendu nocturne de la boucle (ta boîte de réception Triage)2PRÊTS À FUSIONNER3 PR #218 correction du test instable dans test/charts CI vert4 PR #219 nouvelle tentative du webhook sur 429, ajout du test backoff CI vert5ONT BESOIN DE TOI6 auth/session.ts deux façons sûres de corriger ça ; je n'ai choisi aucune, à toi de voir7SILENCIEUX8 7 exécutions planifiées n'ont rien trouvé et se sont archivées
Tu l'as conçue une fois. Tu n'en as sollicité aucune.
9. Construis les freins avant de t'éloigner
C'est la moitié que personne n'enseigne, et elle détermine si ta boucle est un atout ou un passif.
Cette facture de 47 000 $ n'était pas un modèle intelligent devenu fou. C'était deux agents, un analyseur et un vérificateur, se demandant poliment l'un à l'autre plus de travail, sans limite d'étapes, sans plafond budgétaire, et sans condition d'arrêt. Elle a tourné onze jours. Un seul plafond l'aurait tuée dès le premier jour.
Installe les freins avant la puissance. N'expédie pas le moteur avant d'avoir expédié la pédale de frein.
1# Vissez CEUX-CI AVANT de vous éloigner :2- limite d'étapes : --max-turns 50 (arrêt brutal, sans exception)3- plafond budgétaire : claude -p --max-budget-usd 10 (mode print ; par phase)4- rayon d'explosion : un worktree, une branche, lecture seule hors de src/5- disjoncteur : même outil + mêmes arguments 3 fois de suite = arrêt6- vérification de sécurité : écrire un heartbeat dans STATUS.md à chaque exécution ; le silence t'appelle
Définis le périmètre d'une boucle par ce qu'elle peut détruire, pas par ce que tu veux qu'elle fasse : quels dépôts, quelles branches, combien de dollars, combien d'étapes avant qu'elle ne force l'arrêt. Choisis d'abord le rayon d'explosion, la tâche ensuite.
Et évalue-la honnêtement. La flotte de cent agents de Steinberger est réelle, et elle coûte environ 1,3 million de dollars par mois. Elle fonctionne parce qu'OpenAI l'emploie désormais et paie la facture. Le cas extrême est sponsorisé. Le tien ne l'est pas. Avec un forfait de 20 à 200 dollars, la boucle qui rapporte est petite, plafonnée, et pointée vers une seule tâche ingrate, pas vers une nuée.
1LA RÉPARTITION DES COÛTS (tous réels, tous des six derniers mois)2-----------------------------------------------------------------3259 PR en 30 jours un ingénieur, 100 % écrites par Claude447 000 $ en 11 jours une boucle incontrôlée sans plafond, sans surveillance5~1,3 M$ par mois une flotte de 100 agents (la facture est sponsorisée)6-----------------------------------------------------------------7Même technologie. La différence, ce sont les freins.
10. Comment les boucles meurent
Chaque boucle qui échoue meurt d'une de quatre morts. Apprends les noms maintenant pour les repérer à 3 heures du matin.
Récursion incontrôlée. Deux agents s'alimentent mutuellement indéfiniment. Le remède est le plafond d'étapes et le plafond budgétaire ci-dessus, rien de plus intelligent.
Mort silencieuse. L'exécution nocturne d'un développeur a atteint une fenêtre de contexte pleine, s'est arrêtée, puis a continué d'essayer de reprendre contre le même mur tout en ayant l'air vivante. Ta boucle peut être morte pendant des heures et encore signaler une progression. Le remède est un heartbeat et un contexte frais par phase, pas une exécution sans fin.
La marche aléatoire. Sans condition d'arrêt vérifiable, la boucle s'éloigne de l'objectif au lieu de s'en rapprocher. Une suite de tests qui réussit est un point fixe qu'elle peut atteindre. « A l'air terminé » n'en est pas un.
La dette de compréhension. Plus vite une boucle livre du code que tu n'as pas écrit, plus l'écart se creuse entre ce que fait ton dépôt et ce que tu comprends. Laisse-la tourner assez longtemps sans la lire et tu cesses d'être l'ingénieur pour devenir un tampon en caoutchouc. Le remède est une passerelle de lecture humaine que la boucle n'est jamais autorisée à sauter.
11. Construis la boucle. Reste l'ingénieur.
Deux personnes peuvent construire la boucle identique et obtenir des résultats opposés. L'une l'utilise pour aller plus vite sur un travail qu'elle comprend jusqu'à l'os. L'autre l'utilise pour cesser de comprendre le travail du tout. La boucle ne peut pas les distinguer. Toi, tu le peux.
Le propos de Cherny n'a jamais été que le travail est devenu plus facile. C'est que le levier s'est déplacé : de l'invite à la boucle, et de la frappe au jugement. C'est un travail plus difficile que de lancer des invites, pas plus facile.
Alors voici la manœuvre, et elle est intentionnellement petite, parce que c'est tôt et que les coûts varient énormément. Demain matin, prends le travail le plus ennuyeux que tu fais encore à la main — trier la CI, clôturer les problèmes obsolètes, traquer un test instable — et enveloppe-le dans une boucle plafonnée. Les freins d'abord. Assez petite pour que tu lises encore chaque diff qu'elle livre.
Personne qui livre 200 pull requests par mois n'a commencé avec cent agents. Ils ont commencé avec une boucle en laquelle ils avaient confiance, et ils sont restés ingénieurs tout du long. Construis celle-là.
