Pipeline en 7 étapes pour vérifier le code écrit par des agents IA

C’est le sujet le plus brûlant du moment. Les agents enchaînent des centaines de commits par jour, et personne ne peut tous les relire.

Peter, développeur chez OpenClaw, pousse parfois plus de 3 000 commits en une seule journée. C’est bien au-delà de ce qu’un humain peut traiter. C’est devenu une tâche que les humains ne peuvent tout simplement plus gérer seuls.

Au départ, je pensais qu’il n’y avait pas de solution. Puis j’ai lu “Code Factory” de Ryan Carson, et tout s’est mis en place. Plutôt que d’essayer de tout lire, on construit une structure où des machines vérifient le code.

Définir les règles de fusion dans un seul fichier JSON

Consignez dans un seul fichier quels chemins sont à risque élevé et quelles vérifications doivent passer. L’idée clé : cela empêche la documentation et les scripts de diverger.

• Les chemins à risque élevé exigent un Review Agent ainsi que des preuves issues du navigateur
• Les chemins à faible risque peuvent être fusionnés après avoir passé un policy gate et la CI seule

Exécuter les vérifications de qualification avant la CI

Lancer des builds sur des PR qui n’ont même pas passé la revue, c’est brûler de l’argent. Placez un risk-policy-gate en amont de la CI. Cela seul réduit considérablement les coûts de CI inutiles.

• Ordre fixe : policy gate → confirmation du Review Agent → CI
• Les PR non qualifiées n’entrent jamais dans la phase de test ou de build

Ne jamais faire confiance à un « pass » d’un commit obsolète

C’est ce que Carson a le plus insisté. Si un « pass » d’un ancien commit persiste, le dernier code est fusionné sans vérification. Relancez les revues à chaque push, et bloquez le gate s’ils ne correspondent pas.

• Un Review Check Run n’est valide que s’il correspond au headSha
• Forcer une re-exécution à chaque événement synchronize

Émettre les demandes de re-exécution depuis une seule source

Quand plusieurs workflows demandent des re-exécutions, on obtient des commentaires en double et des conditions de concurrence. Cela semble anodin, mais si vous ne corrigez pas ce point, tout le pipeline vacille.

• Éviter les doublons avec un pattern Marker + sha:headSha
• Ignorer la demande si le SHA a déjà été soumis

Laisser les agents gérer les corrections aussi

Quand le Review Agent détecte un problème, le Coding Agent le corrige et pousse sur la même branche. L’observation la plus aiguisée du post de Carson : épinglez la version du modèle. Sinon, vous obtenez des résultats différents à chaque fois, et la reproductibilité disparaît.

• Codex Action corrige → push → déclenchement de la re-exécution
• Les versions de modèle épinglées garantissent la reproductibilité

Ne fermer automatiquement que les conversations bot à bot

Ne touchez jamais aux fils où un humain est intervenu. Sans cette distinction, les commentaires des reviewers se retrouvent ensevelis.

• Résolution automatique uniquement après une re-exécution propre sur le head actuel
• Les fils avec des commentaires humains restent toujours ouverts

Laisser des preuves visibles et vérifiables

Si l’interface a changé, ne vous contentez pas d’une capture d’écran. Exigez des preuves vérifiables par la CI. Transformez les incidents de production en cas de test pour que la même défaillance ne se reproduise jamais.

• Régression → problème de couverture du harness → ajout d’un cas de test → suivi du SLA

Les choix d’outils de Carson

Pour référence, voici ce que Carson a sélectionné : Greptile comme agent de revue de code, Codex Action pour la remédiation, et trois fichiers de workflow qui font le gros du travail greptile-rerun.yml pour les re-exécutions canoniques, greptile-auto-resolve-threads.yml pour le nettoyage des fils obsolètes, et risk-policy-gate.yml pour la politique préalable.

Au-delà de la correction : la vérification visuelle

Tout ce qui précède permet de détecter si le code est correct ou non. Mais en pratique, il faut aussi vérifier à quoi ressemble le résultat.

Deux approches se distinguent.

L’explainer visuel de Nico Bailon rend les diffs de terminal sous forme de pages HTML plutôt qu’en ASCII, rendant les ensembles de modifications immédiatement lisibles d’un coup d’œil.

Le navigateur d’agent de Chris Tate prend une direction différente. Il compare les écrans réels du navigateur pixel par pixel pour détecter les ruptures CSS et de mise en page. Combiné avec bisect, il peut identifier exactement quel commit a provoqué la régression.

Je pense à tout cela en construisant codexBridge. Suivre quel agent a écrit quel code ne suffit pas avec de simples journaux de session. Il faut une structure de recherche qui facilite la récupération.

En résumé

La réponse à « qui vérifie le code écrit par les agents » n’est pas les humains. C’est une structure où des machines jugent les preuves produites par des machines. Voilà la réponse.