[🤖] Quand l’IA s’est trompée sur un résultat intermédiaire, j’ai bloqué le travail suivant

✨ Résumé de GPT-5.6 Sol

Les rapports affirmant que tout avait réussi masquaient une mauvaise structure d’information propagée aux écrans suivants et au backend. J’ai rendu la revue obligatoire avant le travail en aval.

Les rapports affirmaient que tout avait réussi. Je les ai crus et j’ai ouvert un écran qui était nul. Mais le problème suivi ici se trouvait avant cet écran final.

Personne n’a arrêté la structure d’information lorsqu’elle a commencé à dérailler ; les pages suivantes et le backend ont donc continué à se construire dessus. J’ai fait en sorte qu’un mauvais résultat intermédiaire ferme le travail en aval.

Les rapports PASS ont laissé le mauvais écran grandir pendant 16 heures

Je n’avais pas regardé personnellement chaque résultat intermédiaire de Codex. La session d’implémentation avait marqué son propre travail comme terminé, et d’autres sessions avaient continué à construire des pages et du backend par-dessus. Une mauvaise structure d’information s’était propagée avant que quiconque ne la vérifie. Lorsque j’ai ouvert l’UI, seize heures de travail reposaient sur la mauvaise direction.

Je n’avais pas besoin d’un moyen de faire tourner l’IA plus longtemps.

J’avais besoin d’une structure capable d’arrêter le travail suivant lorsque le résultat intermédiaire était mauvais.

En débattant de ce problème, j’ai rencontré le terme Graph Engineering : concevoir les résultats révisables et les conditions de progression sous forme de graph explicite plutôt que de confier toute la longue boucle à un seul Agent.¹ Je n’avais pas besoin d’un grand graph runtime. J’avais besoin d’un seul fait : un résultat non vérifié ne doit pas ouvrir l’edge suivante.

« Est-ce que cela ne devient pas inutilement compliqué ? »

Dès que j’ai proposé d’appliquer le Graph Engineering, l’IA a produit des Coordinators, Workers, Auditors, versions de contrats, ledgers durables, dashboards et réaudits complets. Chaque pièce semblait plausible. Mais si le remède à un gouffre de tokens de 16 heures commençait par agrandir encore le système de gestion, il risquait de devenir le même échec.

Mon premier graph ne comptait qu’une work session et une audit session. La work session termine un résultat révisable et s’arrête. L’audit session voit le résultat figé et l’exigence d’origine, pas l’ambiance de la conversation précédente ni l’autoévaluation du worker. Si une correction est nécessaire, le même résultat reçoit une seule révision. Si la direction est mauvaise, il retourne à la planification au lieu d’accumuler davantage de patches. Le travail direct en aval reste fermé jusqu’à la fin de l’audit.

Les objections ont permis de boucher les trous de ce petit design. Le worker ne peut pas fixer une norme d’audit qui l’arrange. Si le Runtime ou le candidat change, l’ancien verdict est écarté. Et le Gate n’est pas utilisé pour chaque typo ou bug doté d’un test décisif. Il est réservé aux points où un mauvais résultat pourrait contaminer plusieurs tâches en aval.

J’ai mis juste cela dans une Skill nommée custom-graph-engineering-gate. Je n’ai construit ni database ni dashboard séparé. La Skill fige un résultat et limite l’action suivante selon PASS, CHANGES_REQUESTED, REPLAN_REQUIRED ou NOT_VERIFIABLE. Les Codex Skills et les subagents suffisaient.²³

Le premier Gate a réellement arrêté le travail suivant

Créer la Skill ne prouvait pas qu’elle fonctionnait. J’ai figé un contrat de transition d’autorisation dont plusieurs fonctionnalités dépendraient et je l’ai envoyé à une audit session privée de la conversation précédente.

Le premier verdict a été CHANGES_REQUESTED, pas PASS. Le contrat n’indiquait pas assez clairement quand l’autorité était évaluée, d’où venait l’autorité déléguée et comment elle était révoquée, ni si l’utilisateur, l’autorité et l’entreprise cible relevaient du même périmètre. Si ce résultat s’était propagé, j’aurais ensuite dû démolir tout le modèle d’autorisation.

La work session a révisé ce résultat une fois. Ce n’est qu’après une nouvelle vérification par la même audit session qu’il a reçu PASS. Aucune implémentation ni aucun déploiement en aval ne s’est ouvert entre-temps. C’était l’effet recherché : l’edge suivante se fermait vraiment au moment où le worker avait dit « assez bon ».

Un contrat d’autorisation ne prouve pas que cela empêchera un autre échec d’UI de 16 heures. Le jugement humain sur une direction visuelle est plus difficile à placer derrière un Gate, et un auditor utilisant le même modèle et la même Working Tree peut partager les mêmes fausses hypothèses. Une Skill n’est pas non plus un enforcement engine.

Pourtant, cette fois, je n’ai pas installé un framework gigantesque simplement parce que j’avais entendu un nouveau terme. J’ai gardé seulement le graph dont mon échec avait besoin et l’ai rendu assez petit pour le tester à nouveau sur le prochain travail long.

Ainsi, je n’ai pas à découvrir seize heures plus tard que tout était faux.

Références

1. LangChain, « 3 Years of Graph Engineering with LangGraph », sur le terme récent Graph Engineering et la conception des workflows d’Agents comme des graphs explicites. ↩

2. OpenAI, « Build skills », sur l’enregistrement de workflows réutilisables sous forme de Codex Skills. ↩

3. OpenAI, « Subagents », sur la création d’un subagent distinct par un Agent principal et la collecte de son résultat. ↩