Réduction des coûts multi-agents et prévention des hallucinations : leçons tirées du système uReview d'Uber
Comment filtrer les fragments de code inutiles avant l'appel LLM grâce à l'analyse AST
Injecter directement des diffs Git bruts et l'ensemble du code source dans un monolithe hérité entraîne une explosion des coûts. En 2025, la plateforme uReview dévoilée par Uber a analysé automatiquement 90 % des 65 000 modifications hebdomadaires provenant de 6 monorepos. Cependant, si l'on soumet un modèle à une base de code aux frontières de modules floues sans nettoyage préalable, les coûts en jetons sont multipliés par 6. Ne comprenant pas les classes de fabrique (factory) globales, le modèle exige des vérifications de pointeur nul superflues et provoque des hallucinations. Dès l'instant où des commentaires inutiles s'accumulent, les développeurs désactivent les notifications et développent une insensibilité aux avertissements.
Il est nécessaire de concevoir un moteur de prétraitement utilisant le module standard ast de Python pour extraire uniquement les signatures de fonctions modifiées et les variables locales concernées. Après avoir nettoyé les métadonnées statiques, les modifications non fonctionnelles sans rapport avec les changements sont éliminées par comparaison de hachage. Ensuite, on effectue un rétro-parsing de la signature du nœud de fonction le plus bas contenant la ligne modifiée ainsi que du code réellement modifié pour créer une charge utile JSON légère.
En exécutant un benchmark sur 100 modules hérités, la différence est frappante. L'injection de fichiers bruts consomme 42 000 jetons et 0,273 $ par PR. En revanche, l'utilisation de la compression JSON avec prétraitement AST réduit ces chiffres à 6 100 jetons et 0,068 $ par PR. Les coûts d'API diminuent de 47,3 % et le taux de faux positifs dus aux hallucinations descend à 9,4 %.
Comment rompre les boucles infinies entre agents grâce aux schémas de machines à états
Associer un agent de sécurité et un agent de logique métier dans un chat de groupe interactif les conduit à se renvoyer mutuellement leurs sorties, les plongeant dans une boucle de ping-pong infinie. L'analyse d'une seule PR prend alors plusieurs dizaines de minutes et les coûts d'API s'envolent. Il ne faut pas laisser les agents communiquer directement entre eux. Il est indispensable de structurer un cadre de machine à états finis en exploitant les schémas Pydantic et LangGraph.
Chaque agent spécialisé ne reçoit que l'état central du pipeline et renvoie le résultat de son évaluation, selon ses propres règles de domaine, uniquement sous le format de modèle prédéfini. À l'aide de Pydantic, on définit des classes de données qui imposent l'identifiant, le chemin du fichier, la sévérité et le score de confiance de la sortie de l'agent. Des arêtes conditionnelles sont configurées pour interrompre de force la machine à états dès que le nombre d'itérations atteint 2 ou que la confiance de tous les commentaires converge au-delà de 0,85.
Conformément au standard OpenTelemetry GenAI Semantic Conventions, il convient d'envelopper l'exécution de chaque agent dans une plage (span) unique et d'enregistrer l'utilisation des jetons dans un backend de traçage distribué. L'application de cette structure permet de réduire de plus de 6 heures par semaine le temps de débogage que passait le tech lead à corriger les dysfonctionnements des agents.
Comment atteindre un taux d'acceptation de 70 % par les développeurs grâce à un script de validation sur liste blanche
Selon les données d'exploitation de Tricorder, l'outil d'analyse statique interne de Google, peu importe la précision des remarques d'un outil : si les développeurs estiment qu'elles ne valent pas la peine d'être corrigées, l'hostilité ne fait que croître. Un vérificateur dont le taux de faux positifs utiles dépasse 5 % est immédiatement retiré. Pour faire accepter plus de 67 % des commentaires de revue automatique, il est nécessaire de procéder à un déploiement progressif, en commençant par les modules à faible risque.
On sélectionne des couches sans effets de bord, telles que la couche de validation DTO et les fonctions pures, pour y exécuter en mode « shadow » (masqué) pendant 3 semaines sans afficher les commentaires. Après avoir vérifié une précision de 85 %, on active les commentaires en ligne sur le code backend de 3 squads de domaine et on suit le taux d'acceptation. En collectant les journaux de retours de manière hebdomadaire, on exécute un script de boucle de rétroaction qui retire automatiquement de la liste blanche les règles à fort taux de faux positifs dont l'acceptation est inférieure à 67 % pour les envoyer dans une liste d'isolation. En intégrant ce script de validation sur liste blanche dans le pipeline, les règles inutiles qui agacent les développeurs sont rapidement éliminées, permettant d'atteindre un taux d'acceptation de 70 % pour le système de revue au sein de l'équipe.