Le flux de travail « sans prompt » : la théorie de Boris sur les boucles pour la productivité des développeurs

« Je ne saisis plus de prompts dans Claude. C'est la boucle qui tourne, et c'est elle qui décide quoi faire ensuite en lançant des instructions à Claude. Mon travail consiste désormais à écrire ces boucles. »

Ces mots ont été prononcés publiquement par Boris Cherny, responsable de Claude Code (présenté dans The New Stack et des articles d'Addy Osmani).

Alors que beaucoup d'entre nous affinent encore leurs prompts pour améliorer la précision, celui qui construit l'outil s'est déjà éloigné du rôle de « prompteur ».

Quand on y pense, tant que le « tour humain » — être assis devant un écran, attendre une réponse de l'IA, la vérifier, puis donner de nouvelles instructions — reste impliqué, la limite de vitesse est dictée par la rapidité de vos propres mains.

Le Loop Engineering est l'idée de supprimer ce tour humain de la structure. Boris y est totalement engagé : il dit avoir supprimé son IDE en novembre 2024 et ne pas l'avoir rouvert depuis. Il affirme que presque toutes ses contributions à Claude Code du dernier mois ont été écrites par Claude Code lui-même (plus de 200 PR, paraît-il).

Le créateur de l'outil n'écrit plus de code lui-même, mais s'est déplacé du côté de « surveiller si la boucle tourne correctement ». Aujourd'hui, je vais détailler cela au niveau des spécifications techniques, pas seulement comme une ambiance. Je suis également en train de basculer vers le côté boucle, et je sens que mes mains deviennent plus libres à mesure que je progresse.

Article connexe : Introduction au Vibe Coding : 6 étapes pour que les non-codeurs créent des apps avec Claude. L'ère de la production maison le week-end est arrivée

https://note.com/nobel/n/n8192ec07d689

Le Loop Engineering signifie un changement de rôles

En d'autres termes, votre position change. Auparavant, l'humain était au centre d'un échange où il donnait des instructions, l'IA répondait, et l'humain vérifiait et corrigeait. Dans la conception de boucles, l'humain est responsable de la conception du mécanisme de circulation (la boucle), tandis que les essais-erreurs et la vérification des résultats sont transférés du côté de l'IA. Vous attendez simplement une notification quand c'est terminé.

Addy Osmani, de Google, a écrit la même chose dans un article intitulé Loop Engineering, le décrivant comme « remplacer la personne qui tape des prompts par un mécanisme qui tape des prompts à sa place ». Le levier s'est déplacé de la capacité à écrire de bons prompts vers la façon de concevoir un système qui permet à l'IA d'écrire des prompts pour vous. C'est le cœur du sujet.

Cependant, Addy lui-même prévient : « C'est encore aux premiers stades, et je suis plutôt sceptique. Il faut vraiment être prudent avec les coûts de tokens. » Nous reviendrons sur ce piège dans la seconde moitié.

Les spécifications techniques de /loop

Claude Code dispose d'une compétence intégrée appelée /loop (à partir de la v2.1.72). C'est le point d'entrée le plus simple dans le loop engineering. Comme les explications en ligne contiennent souvent des erreurs, je vais me concentrer sur les points clés basés sur la documentation officielle des tâches planifiées.

Le comportement change selon ce que vous lui passez :

• Intervalle et prompt : /loop 5m check if the deployment is finished and let me know s'exécutera à intervalles fixes.
• Prompt seul : /loop check if the CI passed and respond to review comments. Claude décidera lui-même de l'intervalle entre 1 minute et 1 heure (auto-rythmé).
• Rien passé /loop : Le prompt de maintenance intégré (continuer le travail inachevé, s'occuper des PR, nettoyage léger) ou un fichier loop.md que vous avez placé s'exécutera.

L'intervalle peut être placé au début comme 30m ou à la fin comme every 2 hours. Les unités sont s / m / h / d. Vous pouvez également passer d'autres commandes, comme /loop 20m /review-pr 1234, pour exécuter des compétences sauvegardées à chaque fois. Pour arrêter, appuyez sur Esc pendant l'attente (les tâches créées via des demandes en langage naturel ne s'arrêtent pas avec Esc ; vous devez demander leur suppression). En mode auto-rythmé, si Claude détermine que la tâche est vraiment terminée, il se termine sans planifier la prochaine exécution.

Le mode auto-rythmé a un avantage subtil : il s'ajuste automatiquement, attendant peu de temps si une build est presque terminée et plus longtemps si rien ne se passe. Parfois, un mécanisme appelé « Monitor » est utilisé pour diffuser la sortie en arrière-plan plutôt que de poller, ce qui est souvent moins coûteux que de lancer un prompt à intervalles fixes.

Permettez-moi de corriger une idée fausse courante trouvée dans les articles sources. Il est parfois écrit que les tâches sont « automatiquement supprimées 3 jours après leur création », mais en réalité, les tâches récurrentes expirent 7 jours après leur création (elles s'exécutent une dernière fois puis disparaissent). De plus, /loop est limité à la session et disparaît lorsque vous démarrez une nouvelle conversation. Si vous le fermez, vous pouvez revenir avec --resume s'il n'a pas expiré.

Il existe trois méthodes de planification, choisies selon le cas d'usage :

• Cloud (Routines) : S'exécute côté Anthropic. Fonctionne même si votre machine est fermée. Intervalle minimum de 1 heure.
• Desktop Scheduled Tasks : S'exécute sur votre machine et peut toucher aux fichiers locaux.
• /loop : Uniquement tant que la session est ouverte. Minimum 1 minute, pratique pour le polling pendant une session.

La répartition est : utilisez Routines ou GitHub Actions pour une résidence permanente sans intervention humaine, et /loop pour la surveillance pendant une session.

Tâches standard où les boucles sont efficaces

Les tâches de votre routine où vous répétez « vérifier et corriger un peu » sont généralement adaptées aux boucles. Il existe trois schémas courants :

• Bug Patrol : Détecter les problèmes ou les échecs de test, lire la cause, corriger, exécuter les tests, et créer un PR à intervalles réguliers.
• Continuous Review : Surveiller les modifications de code et signaler les points préoccupants. L'humain décide seulement d'accepter ou non les suggestions.
• Document Sync : Détecter les changements de source et maintenir le README ou les spécifications à jour.

Le point commun entre ces trois est que l'objectif peut être clairement jugé, comme « les tests passent » ou « le PR est créé ». À l'inverse, les tâches aux critères ambigus ne conviennent pas aux boucles. Si le point d'arrêt n'est pas clair, cela continuera à tourner et à consommer des tokens. Pour votre première tâche, il est plus sûr d'en choisir une où le succès ou l'échec est évident au premier coup d'œil.

Prévenir les emballements et les oublis avec des « fichiers d'état »

Il y a deux craintes avec les boucles : répéter la même erreur et consommer des tokens sans fin.

C'est là que concevoir avec un seul fichier d'état dans le projet est efficace. Que ce soit STATE.md ou todo.md, l'IA lit et écrit l'objectif actuel / les éléments terminés / les prochaines étapes / les points bloqués à chaque boucle. Même si la session est interrompue, l'IA ne perd pas le fil de « où elle en est et ce qu'elle vise ».

Ce n'est pas une simple pratique aléatoire ; Anthropic elle-même est arrivée à une conclusion presque identique dans Effective harnesses for long-running agents (novembre 2024). Leur configuration utilise deux rôles : un agent initialisateur pour configurer l'environnement et un agent de codage pour faire progresser une fonctionnalité par session. La progression est transférée entre les sessions via des commits git et un fichier claude-progress.txt. Pour les longs travaux, la compression via résumé est insuffisante. La politique est d'écrire dans un fichier structuré une fois et de reconstruire le contexte.

Dans mes propres opérations, j'utilise tasks/state.md comme hub pour l'état partagé, que le côté brainstorming et le côté implémentation lisent avant d'agir. C'est la même chose que l'article : « Ne faites pas confiance au contexte, faites confiance au fichier. » C'est simple, mais sans cela, la boucle se perd au deuxième tour.

La méthode Ralph et la séparation du créateur et du vérificateur

Il existe une version extrême de la boucle appelée méthode « Ralph ». Popularisée par Geoffrey Huntley, la source originale n'est qu'une simple boucle bash :

En alimentant sans cesse le même prompt et en utilisant un fichier Markdown contenant le plan comme état partagé sur le disque, l'IA le lit à chaque fois et décide elle-même « quoi faire ensuite ». Cela semble téméraire, mais comme il y a un fichier d'état, cela avance à chaque tour. Claude Code dispose également d'un plugin officiel ralph-loop qui continue de soumettre le même prompt jusqu'à ce qu'une condition de complétion (promesse de complétion) soit remplie. Il y a une contrainte : la déclaration de complétion ne doit être émise que lorsqu'elle est vraiment atteinte.

Cependant, si vous laissez tout à une seule IA, elle dira « OK » au code qu'elle a elle-même écrit. C'est là que séparer l'IA qui crée (Maker) et l'IA qui inspecte (Checker) est efficace. Dans mes propres opérations, je sépare l'implémentation et la vérification dans différents agents, et je ne donne pas l'intention d'implémentation au côté vérification – je ne montre que les exigences et le laisse évaluer indépendamment. J'ai appris à mes dépens que les auto-revues dans la même session sont inévitablement indulgentes.

Incorporer un « agent de revue uniquement, avec une perspective différente » dans la boucle – concevoir cette vérification multicouche est l'une des tâches que les humains devraient garder.

Concevoir l'autonomie en trois étapes

Tout confier d'un coup mène à des accidents. Il est plus sûr de séparer le niveau d'implication en couches :

• L1 (Manuel) : Les humains tapent des prompts et vérifient chacun. La méthode traditionnelle.
• L2 (Boucle semi-autonome) : Suivre un fichier d'état et surveiller un ensemble spécifique de tâches jusqu'à leur achèvement avec /loop.
• L3 (Résident) : Fonctionner en continu via Routines ou GitHub Actions sans intervention humaine.

Il est réaliste de commencer avec L2. Exécutez une tâche jusqu'à son terme avec /loop et observez le comportement. Passez à L3 une fois que vous voyez la plage de fiabilité. Pour mes premières fois, j'ai surveillé les logs sur un écran latéral pour voir « où il a fait un mauvais jugement ».

Pièges (à connaître d'abord)

Comme je n'ai écrit que sur les bons côtés, voici trois points où vous pourriez bloquer :

1. Coûts des tokens : Les boucles consomment plus à mesure qu'elles tournent. C'est ce qu'Addy a souligné ; si vous définissez l'intervalle trop court, cela peut coûter pas mal du jour au lendemain. L'auto-rythme est meilleur que les intervalles fixes car il attend quand il le faut, réduisant le gaspillage.
2. Opérations irréversibles : Le prompt de maintenance intégré ne prend des actions irréversibles (push, suppression) que dans la « plage déjà autorisée dans la conversation ». Lorsque vous écrivez vos propres prompts, il est plus sûr de définir vous-même les limites pour les opérations destructrices.
3. Disparaît en 7 jours : Les tâches récurrentes /loop expirent 7 jours après leur création. Si vous voulez les exécuter plus longtemps, passez aux Routines ou aux tâches Desktop.

Notes pour les utilisateurs intermédiaires

• /loop et /goal sont différents. /loop s'exécute par intervalle. Si vous voulez continuer à chaque tour jusqu'à ce qu'une condition soit remplie, utilisez /goal. Si vous voulez qu'il réagisse au moment où un événement se produit, utilisez le push via Channels.
• Placer un fichier loop.md (.claude/loop.md ou ~/.claude/loop.md) vous permet de remplacer le prompt par défaut d'un /loop nu par le vôtre. Utile pour écrire des tâches de routine comme « corriger si le CI de la branche release est rouge ».
• Jusqu'à 50 tâches planifiées par session. Vous pouvez voir la liste avec CronList et supprimer par ID avec CronDelete.

Résumé

Auparavant, le temps passé devant l'écran était la limite supérieure du progrès. Maintenant, une boucle qui lit un fichier d'état pendant que je dors fait progresser une fonctionnalité à la fois, et ma matinée commence par vérifier cette progression.

Avant d'améliorer le contenu (la précision des prompts), concevez la manière dont il s'exécute (séparation des boucles, gestion de l'état, et vérification). Le levier s'est déplacé là – c'est le point commun dans les histoires de Boris, Addy et du harnais d'Anthropic. Je crois que ce n'est pas une théorie difficile, mais une accumulation régulière de conceptions simples, comme décider quand s'arrêter avant de lancer la boucle.

Des informations utiles qui ne peuvent pas être partagées sur X sont partagées dans le LINE OpenChat. Si vous êtes intéressé par l'utilisation de Claude Code/Codex ou l'utilisation de l'IA pour les opérations X, rejoignez-nous.

https://t.co/9LOoUYvCbO