La Boucle Ralph Wiggum, Depuis Les Premiers Principes

Si tu as utilisé un agent de codage IA pendant plus de quelques heures, tu connais le « mur » : l’agent fait des progrès visibles, puis stagne — et tu finis par corriger et terminer le travail toi-même.

Comme les ingénieurs en IA ont souvent tendance à le faire, un modèle est apparu pour résoudre ce problème : il suffit de faire tourner l’agent contre des vérifications externes jusqu’à ce que le travail soit réellement accompli.

L’approche a pris assez fort qu’elle a été nommée — Ralph Wiggum.

Et le mème a persisté parce que le modèle fonctionne. D’ici fin 2025, Anthropic l’avait formalisé en un plugin officiel de Claude Code.

Ralph représente un changement dans la manière dont les développeurs utilisent les outils existants. Au lieu de traiter les systèmes IA comme des assistants interactifs, ils sont exécutés comme des processus de longue durée, guidés par des tests, des linters et des conditions d’arrêt explicites.

Donc, ce guide succinct est la version pratique. Nous verrons ce que Ralph est réellement, pourquoi cela fonctionne, comment cela s’est répandu, et ce qui a changé lorsqu’il a été commercialisé.

Qu’est-ce Que « Ralph » Vraiment ?

Au fond, voici ce qu’est Ralph : exécuter un agent en boucle, vérifier la sortie par rapport à quelque chose qui ne peut pas mentir comme un test, un linter, un vérificateur de type ; et continuer à boucler jusqu’à ce que cela passe.

C’est tout.

L’exemple original que Geoffrey Huntley a partagé en juillet 2025 était volontairement direct :

while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

Claude Les variantes de code suivent la même forme, juste avec plus de garde-fous. Mais le principe ne change pas : nourris une invite épinglée à l’agent de manière répétée jusqu’à ce que la réalité externe indique que tu as terminé.

La boucle elle-même est presque sans importance, et ce qui compte, c’est le contrat :

• L’état vit dans le dépôt : Fichiers, différences, logs, historique git ; tout ce qui est durable se trouve ici.
• La complétion vit à l’extérieur du modèle : Tests, linters, vérificateurs de type ; l’agent ne décide pas quand il a terminé ; c’est le harnais qui le fait.
• L’agent est remplaçable : C’est un travailleur invoqué à répétition jusqu’à ce que la porte passe ; s’il est lent ou stupide aujourd’hui, remplacez-le par quelque chose de plus rapide demain.

Vu de cette manière, Ralph devient un principe de conception : arrête de demander au modèle de savoir quand il a terminé. Arrête de t’attendre à ce qu’il se souvienne des contraintes à travers les réinitialisations de contexte.

Plutôt, construis le système de manière à ce que le modèle ne puisse pas échouer de ces manières.

Pourquoi La Boucle Persiste-T-Elle ?

Quelques raisons :

1. Les Fenêtres Contextuelles Se Comportent Comme Des Tampons

Huntley présente souvent des fenêtres de contexte en termes de bas niveau :

« Pense comme un ingénieur en C ou C++. Les fenêtres contextuelles sont des tableaux. »

Ils ont une taille fixe ; ils glissent ; ils écrasent ; ils oublient.

Les sessions de longue durée supposent une continuité qui n’existe pas, donc traiter le tampon comme une mémoire durable conduit à un décalage, à des contraintes manquées et à un comportement incohérent.

Ralph se penche sur la réalité du système. Plutôt que de prétendre que la fenêtre de contexte est stable, il la considère comme jetable.

L’espace de travail temporaire de l’agent est réinitialisé entre les itérations, tandis que l’état durable persiste sur le disque. Le dépôt accumule la vérité au fil des exécutions. Cela rend le redémarrage de l’agent routinier plutôt que superflu ; chaque boucle commence à zéro mais se construit sur ce qui a réellement persisté.

2. Les Vérifications Externes Surpassent Le Raisonnement Interne

De nombreux cadres d’agents répondent à l’échec en ajoutant de la structure à l’intérieur du modèle : planificateurs, résumés, état interne et boucles de réflexion.

Ralph conserve l’intelligence à l’extérieur de l’agent. Il repose sur :

• Une spécification fixée qui ne dérive pas
• Des preuves concrètes de la dernière exécution
• Une porte déterministe qui évalue le succès

L’agent ne décide pas quand le travail est terminé – c’est le harnais qui le fait.

C’est pourquoi Ralph excelle dans le travail mécanique : refactorisations, migrations, nettoyages, tâches de conformité… Partout où le succès peut être mesuré par un script plutôt que par un jugement, l’itération devient fiable.

Le modèle ne peut pas se soustraire aux exigences car les exigences existent en dehors de son raisonnement.

3. La Compaction Érode les Contraintes

Une critique récurrente de la part de Huntley cible la synthèse et la compaction.

Lorsqu’un système demande au modèle de décider ce qui est assez important pour être conservé, des informations sont perdues — les contraintes s’assouplissent, les cas limites disparaissent et les broches tombent.

Ralph contourne cela en gardant les entrées littérales :

• Les caractéristiques techniques restent verbatim au lieu d’être résumées, 
• Les résultats d’échec restent bruts et non filtrés; et 
• La gestion de la mémoire ne passe jamais dans le modèle.

Le harnais préserve la fidélité ; l’agent opère à l’intérieur, contraint par ce qui est réellement présent plutôt que par ce que le modèle pense qu’il devrait y avoir.

Alors, Comment L’idée S’est-elle Répandue ?

Le calendrier est assez compressé.

• 19 Juin 2025 : Lors d’une rencontre à San Francisco avec environ 15 ingénieurs discutant du codage agentic, Huntley présente Ralph, Cursed (le langage de programmation développé par Ralph) et diffuse en direct le codage autonome pendant la nuit tout en dormant en Australie. La salle engage une conversation troublante sur la facilité de copier 80%-90% d’un SaaS et sur le nombre de types de travaux qui sont sur le point de disparaître totalement.
• Juillet 2025 : Huntley publie le billet de blog original avec la structure de boucle bash de base. L’article comprend une invite légère et une demande : “tu pourrais probablement trouver le dépôt lang cursed sur github si tu le cherchais, mais s’il te plaît, ne le partage pas encore.”
• Août 2025 : Le hackathon des agents YC a lieu — les équipes exécutent Claude Code en boucles continues. Le résultat est 6 dépôts livrés pendant la nuit. Dexter Horthy exécute une boucle expérimentale de Ralph sur une refactorisation de codebase React. En 6 heures, il développe un plan complet de refactorisation et l’exécute ici.
• Septembre 2025 : Huntley lance officiellement Cursed Lang, le langage de programmation que Ralph a construit. Il existe en trois implémentations (C, Rust, Zig), possède une bibliothèque standard et un compilateur de stade-2 écrit en Cursed lui-même.
• Octobre 2025 : Dexter présente Ralph à Claude Code Anonymous à San Francisco. La question de l’audience : “Alors, tu recommandes ça ?” Sa réponse : “Les choses stupides peuvent fonctionner étonnamment bien. Que pourrions-nous attendre d’une version intelligente ?”
• Décembre 2025 : Anthropic lance un plugin officiel Ralph Wiggum. Le plugin prend la boucle bash de Huntley et la formalise avec des Stop Hooks et des données structurées d’échec.
• Janvier 2026 : Huntley et Horthy font une analyse approfondie lors d’une discussion sur YouTube comparant l’implémentation originale de la boucle bash de Ralph avec l’implémentation des stop-hooks par Anthropic.

Bash-loop Ralph contre Plugin Ralph

L’original Ralph est une boucle bash de 5 lignes. Tu cat un fichier d’invite, le pipes à Claude, vérifies si la sortie passe ton test, et boucles jusqu’à ce que ce soit le cas. Tout vit sur le disque, tout est visible. Si quelque chose se casse, tu peux voir exactement pourquoi.

Le plugin Anthropic inverse ce modèle, donc au lieu d’exécuter la boucle de l’extérieur, il installe un crochet d’arrêt dans ta session Claude. Lorsque Claude essaie de sortir, le crochet l’intercepte, vérifie tes conditions de complétion et renvoie la même invite si du travail reste à faire. Les fichiers que Claude a modifiés sont toujours là.

L’historique git est toujours là, mais les mécanismes du harnais sont désormais opaques — cachés dans un fichier d’état markdown, sensibles aux permissions, faciles à casser si tu ne sais pas ce que tu fais.

Ceci est le compromis d’abstraction classique.

Le plugin réduit le coût d’adoption. Tu n’as pas besoin d’écrire en bash et tu n’as pas besoin de penser aux boucles. Mais à mesure que le mécanisme se cache, l’aperçu original devient plus facile à manquer.

La version bash-loop t’oblige à concevoir le harnais. La version plugin te permet de sauter cette étape, ce qui est acceptable jusqu’à ce que tu rencontres un cas limite et que tu ne puisses pas voir ce qui se passe réellement.

Dexter Horthy l’a testé et a découvert qu’il se bloque de manière cryptique à moins que tu n’utilises “–dangerously-skip-permissions.” Le plugin installe des crochets dans des endroits étranges, utilise des fichiers d’état opaques, et si tu supprimes le fichier markdown avant de l’arrêter, tu casses Claude dans ce dépôt jusqu’à ce que tu désactives entièrement le plugin.

Alors, quelle est la leçon ? Les deux fonctionnent, mais pour des raisons différentes. La boucle bash fonctionne parce qu’elle est simple et transparente. Le plugin fonctionne lorsque l’abstraction ne cache rien de critique.

Qu’Apprends-Tu En Le Gérant ?

Ralph suppose une distance entre l’humain et l’agent. Tu ne t’assois pas dans la session pour le guider. Au lieu de cela, tu le mets en marche, tu t’éloignes, tu inspectes les artefacts lorsqu’il a fini, et tu ajustes les contraintes pour la prochaine itération.

L’interaction se produit au niveau du harnais — la sollicitation, les tests, les conditions d’arrêt — et non à l’intérieur de la conversation.

Au fil du temps, un modèle se dégage : la plupart des échecs ne sont pas des échecs de modèle ; ce sont des échecs de harnais.

Le cahier des charges était vague, le test était trop général, ou la condition de fin ne décrivait pas réellement ce que signifie “terminé”.

Une fois que tu as vu cela quelques fois, ton instinct change. Tu arrêtes de demander “comment rendre Claude plus intelligent ?” et tu commences à demander “comment rendre les contraintes plus strictes ?”

C’est là que les spécifications deviennent cruciales.

Spécifications Comme Surfaces De Contrôle

Huntley redéfinit les spécifications non pas comme une documentation, mais comme des entrées de contrôle fixes. Tu les produis à travers des conversations avec Claude, les modifies délibérément jusqu’à ce qu’elles soient précises, puis tu les fixes. Une fois fixées, elles ne changent pas pendant toute la boucle.

Cela importe parce que les spécifications accomplissent trois choses à la fois :

1. Ils définissent ce que l’agent peut inventer : Sans un cahier des charges précis, Claude ajoutera des couches de protection, des abstractions ou des fonctionnalités que tu n’as jamais demandées, élargissant le périmètre à chaque itération. 
2. Ils ancrent la recherche et la récupération : Ainsi l’agent n’hallucine pas de nouvelles exigences.
3. Ils stabilisent le comportement à travers les exécutions : Chaque itération résout le même problème, pas une interprétation légèrement différente de celui-ci.

Si tes spécifications sont vagues concernant ce que signifie “terminé”, l’agent l’interprétera différemment à chaque boucle. Tu finis par avoir un décalage, une extension du périmètre et des itérations qui se contredisent.

Comment Exécutes-Tu La Boucle De Manière Responsable ?

Une configuration minimale de Ralph ressemble souvent à :

MAX_ITERS=30
for i in $(seq 1 $MAX_ITERS); do
  cat PROMPT.md | claude
  if ./ci.sh; then exit 0; fi
done
exit 1

Les mécanismes de la boucle importent bien moins que les règles qui l’entourent :

• Garde la spécification immuable ; ne l’ajuste pas en cours de boucle en fonction de ce que fait Claude. 
• Encode le suivi comme vérifications exécutables.
• Applique des limites d’itération et des limites de temps pour que la boucle ne puisse pas tourner indéfiniment et épuiser ton budget de jetons. 
• Conserve les logs et les différences pour que tu puisses inspecter ce qui a mal tourné si cela arrive. 

De plus, la pratique opérationnelle a révélé quelques heuristiques importantes :

• Préfère de petites modifications régulières plutôt que de grands remaniements, car les grands changements accumulent les erreurs et sont plus difficiles à déboguer. 
• Relance sur la branche principale actuelle plutôt que de rebaser, car les conflits de fusion gaspillent des itérations.
• Et évite d’utiliser Ralph pour un travail exploratoire, car si tu n’as pas de tests d’acceptation clairs, tu obtiendras juste une boucle chaotique qui invente des choses que tu n’as pas demandées.

La contrainte est la fonctionnalité.

La Boucle Est la Leçon

Alors que Ralph gagnait en popularité, des variations sont apparues. Certaines équipes ont construit des boucles externes structurées autour des agents appelant des outils. D’autres ont ajouté des composants vérificateurs séparés : un modèle différent qui examine la production du travailleur avant que la boucle décide de se terminer. Ces extensions fonctionnent, oui, mais seulement si elles respectent l’aperçu original.

La règle est simple : la vérification doit rester déterministe et les résumés ne doivent jamais remplacer les entrées principales.

• Si tu ajoutes un vérificateur, il devrait contrôler des choses concrètes : les tests réussissent, le linter se termine proprement, le git diff correspond aux attentes. 
• Si tu ajoutes des boucles externes structurées, elles devraient toujours voir la sortie brute et les logs bruts, pas un résumé épuré de ce qui a mal tourné. 

L’argument principal de Huntley est que le développement logiciel en tant que profession est effectivement mort, mais le génie logiciel — la pratique de construire des systèmes de manière efficace — est plus vivant que jamais.