Reprise du message précédent :
Ça parle de plus en plus de loop engineering sur le net, vous vous y êtes mis ? J'ai compris en gros qu'il s'agit d'une partie dev puis une partie vérification faite par un agent indépendant (ou autre modèle) qui revient avec ses findings et les retourne à l'agent principal qui corrige. J'ai l'impression qu'avec un cli les solutions sont d'utiliser une commande comme /goal (jamais testé), utiliser des hooks, ou coder ça en python pour la ci qui dépile les tickets. Sinon faire ça manuellement. J'arrive pas à savoir si c'est facilement accessible ou un truc de niche.

 
Je fais des boucles directement dans mon prompt. Dans le prompt de l’implémentation d’une feature, je dis après implémentations qu’il fasse un « clawpatch » review, qu’il corrige les findings de clawpatch, relance clawpatch, corrige les findings jusqu’à ce qu’il y en a plus.

Je fais ça tout le temps avec des boucle dans mon prompt/skill.
 

Ça se fait avec le même contexte ou un autre contexte ? Parce qu'apparemment pour que le principe de boucle fonctionne il faut un contexte propre sans connaissance des choix architecturaux. Et l'intérêt des loop ça semble être de l'intégrer au harness, et non pas au prompt, pour que ce soit systématique, et éventuellement plus complexe que des chaînes de prompts. Bon dans tous les cas je pense que ça va arriver dans les cli de manière plus standard.

Je fais ça depuis la possibilité d'invoquer des agents. Sur Claude, tu peux le faire via /review, pas besoin de /loop ou /goal. Tu peux aussi lui donner en consigne dans le .md de faire une review avec des agents à différentes personnalités. Perso, mon agent fait même appel à Codex pour la review. Opus en max à tendance à déclencher de lui même les reviews (4 agents), et Fable le fait de façon très aggressive (jusqu'à 70 agents - token$$$)
Mais globalement, je fais ça depuis jour 1, avant mêmes les CLI et agents : une solution renvoyé par une IA est confronté à une autre IA et à moi-même. Principe de base du développement, cumulé à un développement en guidé par les tests (TDD) tu évites le gros des problèmes (valide que se soit des IA ou des humains)

dans ton /loop tu dis d'invoquer un sub-agent neuf à chaque fois

Ca me semble bizarre comme affirmation.

Non c'est logique, si il hérite du contexte précédent il va se faire influencer par les tokens qui ont abouti à la décision initiale, c'est de la merde.

Je fais ça de temps en temps quand le sujet est touchy et que j'ai l'impression que le modèle n'est pas rentré assez dans les détails. Je sauvegarde toujours le plan dans un .md, je relance un autre agent (genre gml 5.2 sur un plan d'opus) et je lui dis de vérifier la logique du plan et les assomptions sur le code existant et je lui pointe les parties critiques de la fonctionnalité en lui précisant bien de chercher les edges cases, races... Sinon ces branleurs de modèle te répondent un truc du genre "franchement c'est bien écrit ça a l'air sérieux moi ça me va  ). Je lui fais sauvegarder ça dans review.md que je recharge dans l'agent d'origine et je lui dis d'inspecter les remarques et de double check si c'est juste et pertinent + mes remarques perso car souvent le reviewer reporte des choses qui avait été convenu avec le concepteur d'origine, mais comme il a pas le contexte...
La plupart du temps je fais ça dans le contexte du concepteur d'origine si il est pas trop pourri, parfois je reprends ça plusieurs jours après avec un agent vierge, parce que je travaille souvent sur des trucs complexes donc j'ai des plans qui traînent sur plusieurs semaines, par exemple parfois en élaborant un plan je me rends compte que ça va rentrer en conflit avec un refactoring prévu plus tard ou qu'on pourrait faire quelque chose de mieux en commençant par une évolution du backend donc ça finit en fichier markdown à reprendre plus tard

Voilà c'est exactement ça. Et pour l'invocation en slash commande ou dans des prompts / fichiers, la limite c'est que c'est soit manuel, soit pas déterministe, soit trop complexe si les conditions de d'embranchements sont trop compliqués. L'idée c'est vraiment de faire des loops un peu complexes pour vraiment chaîner des prompts, et arrêter de prompter. Paraît que anthropic a sorti une longue vidéo mais j'ai pas eu le temps de la trouver.

Matez cette vidéo ou envoyez la à Gemini pour discuter
Https://youtu.be/5WB5bcGNib8

Related : Loop engineering: Getting started with loops | Claude by Anthropic https://share.google/EkNnzyxJ63c8eygL3

Mais ton exemple n'a rien avoir avec une boucle.
Une boucle c'est une série d'actions...en boucle    
Et si une boucle est réalisée par un sous-agent, il n'a pas le contexte du projet en mémoire.

Je pense que l'idée c'est vraiment de chaîner des étapes du développement logiciel comme si on passait ça d'équipe en équipe. J'imagine que l'objectif à terme c'est seulement d'écrire des tickets de feature, de bug ou autre en masse, et la boucle s'occupe de dispatcher ça de manière autonome. Les tickets vont être triés, transformés en tâches, envoyés en dev, review puis statut ok ou ko, renvoyés au dev, intégrés, etc.
Aujourd'hui si on bosse avec superpowers par exemple faut passer par brainstorm, writing plan, exécute plan, review, etc, faut maintenir un suivi, ça peut devenir le boxon si on gère trop de features en même temps. L'idée là c'est de se concentrer sur la spec, et le reste est automatique. Enfin c'est ce que je comprends. Dans tous les cas je pense que tout ça arrivera dans des outils user friendly.

https://x.com/ClaudeDevs/status/2077840063342506351

Non bein ça a l'air pas mal implémenté dans l'app codex les loops (à 4min)
https://youtu.be/eiQgljOrkWU

Quand est-ce qu'on a un reset de codex ?
J'ai déjà cramé celui du jour Reset le 23  

Va falloir que je prenne du Ollama Cloud à ce rythme.