Observation, review et synthèse

Observation dans un environnement d’exécution du système

Au-delà des tests, vérifier le comportement en conditions les proches possibles du réel.

Déploiement

Environnements éphémères / preview, déploiement sandboxé, feature flags et canary. L’agent confirme que le système démarre correctement, répond et se comporte correctement.

Logs & traces

Le log fournit la trace de l’exécution du code généré. Il permet d’obtenir les causes d’échec d’un test ou d’une invocation de code. Sans accès aux logs, l’agent corrige sur hypothèse, avec accès aux logs, il ancre son diagnostic sur des observations (sous réserve bien sûr que les logs soient pertinent). Les logs sont une source précieuse pour les cas d’usage de troubleshooting et de diagnostic.

La qualité de la boucle de feedback avec les logs dépend de la qualité de leurs contenus.

Plus spécifiquement :

• Logs structurés (JSON, clé-valeur) : l’agent parse un champ au lieu d’extraire par regex. Niveau, timestamp et contexte sont plus facilement requêtable.
• Trace IDs / corrélation : pour suivre une requête à travers les composants. En système distribué ou asynchrone (event sourcing, files de messages), le span tree d’un tracing OpenTelemetry permet de reconstruire la causalité.
• Niveaux signifiants : l’agent filtre ERROR/WARN, puis descend dans le contexte de l’incident.
• Contexte au point d’échec : entrées, état pertinent, cause — plutôt qu’un message générique. Idéalement, un log “Will do this” (avec les paramètres d’entrée) et “done that” (avec les résultats suite aux changements d’états).
• Idéalement le mécanisme de log level per request pour activer des logs de debugs détaillées pour les requêtes de l’agent (c.f. cet article et https://www.tegud.net/dynamic-logging-log-level-per-request/)

Deux principes nous semblent importants à garder en tête :

• Lecture des logs à la demande. Ajouter des milliers de lignes de logs dans le contexte de l’agent va forcément saturer sa context window. Adopter la même approche que Playwright CLI : récupérer les logs dans un fichier, puis filtrer par un grep avant envoi à l’agent (niveau, fenêtre temporelle, trace ID, signature). L’agent récupère les logs pertinents, pas le journal entier.
• Les logs sont un signal de diagnostic, pas un oracle fort. Le log indique pourquoi et comment, non si le comportement est correct. L’absence d’ERROR ne prouve pas que le comportement est correct, c’est une preuve faible à ne pas confondre avec une validation. Le log se marie bien avec les oracles durs comme les tests, notamment en cas d’échec.

Métriques

Faire suivre à l’agent les Four Golden Signals : latence, trafic, erreurs, saturation, comparés avant/après un changement. Une métrique qui change est un oracle de régression majeur.

Benchmark

Mesures reproductibles contre une baseline : l’agent doit pouvoir quantifier l’impact d’un changement.

Review par d’autres agent (LLM-as-a-Judge evaluation)

Un agent génère et un second agent évalue et juge les résultats du premier (analyse statique inférentielle) : idéalement un modèle, un vendeur différent (ex. OpenAI Codex juge et Claude Code génère) ou contexte différent. Ce dispositif atténue le biais d’auto-évaluation, mais reste un signal probabiliste avec un mécanisme inférentiel, pas un oracle dur : il se subordonne aux vérifications déterministes (types, exécution, propriétés).

Sur les composants et code à fort enjeu, l’humain demeure l’arbitre final, mais la review faite par l’agent peut servir de travail préparatoire.

Synthèse

Ordre de confiance des boucles de feedback:

1. Computationelles & très peu coûteuses : types, compilation, analyse statique.
2. Computationelles & exécuté : tests example-based et property-based en sandbox.
3. Computationelles & En environnement réel : intégration, déploiement, logs, métriques, benchmark.
4. Inférentielles : review par un autre agent.
5. Humain : arbitre les composants critiques et à fort enjeu.