L'équipe d'Avito a intégré le processus de travail des agents IA dans le code, avec deux points d'approbation

Vous demandez à un agent de d'abord faire valider un plan, puis d'écrire le code et de le vérifier sur un banc de test. Une heure plus tard, il apporte une PR toute prête, mais la validation a été sautée et, à la place des résultats de vérification, on trouve une explication assurée de la raison pour laquelle tout devrait fonctionner. On peut ajouter un avertissement de plus dans AGENTS.md. Cela ne donnera toutefois aucune garantie d'exécution.

Valeri Potchtarev, de l'équipe Checks, qui s'occupe de l'antifraude chez Avito, a décrit une autre approche : transférer les exigences vérifiables des instructions vers des scripts et des hooks. Ceux-ci déterminent à quelle étape se trouve la tâche, si les modifications sont autorisées et si le résultat peut être soumis en revue. Le setup s'appelle af-checks-context ; l'auteur est en train de l'étendre de son usage personnel à l'ensemble de l'équipe.

Comment une exigence devient un blocage

Le socle du système est un dépôt git distinct contenant le contexte de l'équipe : spécifications, plans, connaissances et description du processus. Les dépôts des services se trouvent à côté. La session de l'agent démarre avec le contexte de l'équipe, afin qu'une tâche inter-services ne se réduise pas au contenu d'un seul projet.

Ensuite intervient une séquence d'étapes : tâche, plan, approbation, implémentation, vérification sur un banc de test séparé, approbation du résultat et PR en revue. La position de la tâche est calculée par un script à partir des artefacts existants. Le modèle ne peut pas simplement déclarer qu'une étape obligatoire a déjà été franchie.

Prenons le cas d'un agent qui modifie une vérification d'accès. Tant que le plan n'est pas approuvé, un hook bloque les modifications du code dans le répertoire de travail de la tâche. L'humain confirme le plan dans un message séparé contenant la clé de la tâche. Le hook crée un marqueur éphémère, à partir duquel la commande enregistre l'approbation. L'agent n'a pas le droit de créer ce marqueur lui-même.

Après l'implémentation, un rapport issu du banc de test est nécessaire. On y vérifie le verdict pass et le hash du commit vérifié. Si, après une exécution réussie, l'agent a ajouté une modification supplémentaire, l'ancien rapport ne confirme plus la version courante. Même un petit changement exige une preuve de vérification à jour.

Là où les premières restrictions étaient poreuses

La partie la plus utile du texte est la description des contrôles qui ont échoué. Un des premiers gates acceptait n'importe quel champ d'approbation non vide : la valeur false passait aussi. Un autre ne vérifiait que l'existence du chemin vers le rapport, si bien qu'un simple répertoire portant le bon nom le satisfaisait. Formellement, l'étape était close ; dans les faits, il n'y avait aucune preuve.

Un problème distinct est apparu avec un bot qui distinguait les modifications du processus de celles du contenu ordinaire. Il lisait la liste des chemins protégés dans la PR en cours de vérification. Une modification pouvait retirer son propre répertoire de la liste et tomber dans la catégorie autorisant une fusion sans intervention humaine. La correction : prendre les règles dans la branche cible et toujours considérer une modification du config lui-même comme une modification du processus.

La vérification par un autre agent ne garantit pas non plus d'avoir raison. Un jour, le vérificateur a trouvé une contradiction entre la spécification et un service voisin. Sa copie locale avait 36 commits de retard ; le comportement attendu existait déjà. Désormais, de telles trouvailles sont d'abord recoupées avec l'origin à jour. La séparation des rôles est utile, mais il faut malgré tout vérifier la fraîcheur des données sources.

Ce qu'il vaut la peine de transposer dans votre processus

On peut commencer par une seule transition qui casse régulièrement chez vous. Par exemple, interdire la soumission d'une PR en revue sans rapport réussi pour le commit courant. Il faut ensuite tester le gate lui-même : que se passe-t-il avec un rapport vide, un mauvais type de fichier, un nouveau commit ou une erreur de chargement du script de vérification ?

Le contrôle se paie en maintenance. Chez l'auteur, le hook de démarrage s'exécutait en 14,6 à 18 secondes pour un timeout de 15 secondes, si bien que le contexte n'arrivait parfois silencieusement pas jusqu'à l'agent. Des coches de service modifiaient le hash du plan et déclenchaient de nouvelles validations. Il a fallu simplifier le système, séparer les vérifications rapides des lentes et exclure les lignes de service du calcul de la version du plan.

Il est encore trop tôt pour mesurer l'ampleur de l'effet : l'extrait présenté s'interrompt sur un tableau de mesures personnelles de l'auteur et ne donne pas une image complète de la productivité de l'équipe. Mais la technique d'ingénierie est déjà claire. Pour chaque action obligatoire, il faut définir un résultat vérifiable et fermer la transition qui s'en passe. Puis s'assurer que l'agent ne peut pas réécrire lui-même les motifs sur lesquels son travail est accepté.