SberDevices a construit des agents frontend sur GigaChat pour la revue des merge requests

Chez SberDevices, l'équipe a décidé de ne pas confier la revue de son code à des services externes et a construit son propre système d'agents pour le frontend. GitHub Copilot Code Review et GigaCode Agent de GitVerse, des solutions prêtes à l'emploi, ne cadraient pas avec ce schéma : les deux sont externes, et l'équipe ne veut pas leur ouvrir ses dépôts. Avrora, responsable de l'infrastructure frontend de l'entreprise, a détaillé l'architecture sur Habr. L'annonce ne contient aucune métrique ; ce qui suit s'en tient donc à ce qui est confirmé et à la logique d'ingénierie derrière ces choix.

Pourquoi du sur-mesure plutôt que du prêt-à-l'emploi

La méfiance envers les outils externes ne tient pas à la qualité du modèle, mais au périmètre. Un reviewer lit les diffs, la structure du projet, les bibliothèques internes et les conventions. Pour une grande entreprise, c'est précisément le code qui ne doit pas sortir du périmètre sécurisé. Avrora décrit le parcours typique des grandes équipes comme la création de leur propre « vélo avec le bon nombre de roues et de pédales ». C'est un choix assumé : les produits externes répondent à un besoin générique, tandis qu'une stack interne s'ajuste à des dépôts et à des processus précis.

Le système repose sur GigaChat. Le titre de l'article oppose les agents « avec GigaChat et sans », c'est-à-dire l'automatisation par modèle et les approches classiques.

Deux modes dans un même système

La décision d'architecture centrale : l'équipe a combiné deux approches au lieu d'en choisir une.

• Boucle agentique. Le modèle reçoit un objectif et un ensemble d'outils, puis décide seul des étapes à suivre. Cette approche est souple, mais moins prévisible.
• Workflow déterministe. Le modèle exécute des tâches circonscrites au sein d'une séquence fixée. Le résultat est plus simple à vérifier et à reproduire.

L'hybride paraît ici raisonnable. La revue d'une merge request se compose d'opérations étroites : repérer une erreur type, vérifier une convention, évaluer un fragment précis. Mieux vaut les intégrer à un scénario rigide. Les tâches ouvertes, du genre « analyse le problème et propose un correctif », sont plus à leur place dans une boucle avec outils. Le premier apporte de la stabilité, le second de la couverture.

Ce que promet l'article complet

L'auteure met en avant trois sujets :

• des statistiques sur les erreurs des développeurs frontend d'après les données du reviewer IA, autrement dit les défauts qui reviennent le plus souvent ;
• un parseur qui réduit le contexte du modèle pour qu'il ne voie que le code pertinent ;
• une fonctionnalité du système qui s'est « soudain » révélée la plus demandée.

Le parseur mérite l'attention. Le frontend produit beaucoup de bruit : balisage, styles, configurations, fichiers générés. Si l'on donne tout au modèle sans tri, le coût et le temps de réponse augmentent, tandis que la qualité des remarques baisse. Un pré-filtrage selon la structure du code permet de formuler la tâche plus précisément et de tenir dans la fenêtre de contexte.

L'annonce ne dit pas quelle fonctionnalité est devenue la plus demandée. Il faudra attendre l'article complet.

Ce qu'on peut en retenir

Si vous construisez un reviewer IA interne ou un agent pour le développement, l'approche de SberDevices offre plusieurs pistes.

Séparez les tâches selon leur degré de liberté. Tout ce qui se prête à un algorithme précis doit passer par un workflow déterministe ; gardez la boucle agentique pour les tâches ouvertes.

N'envoyez pas tout le dépôt au modèle. Réduisez d'abord le contexte avec un parseur ou une analyse statique, puis appelez le LLM.

Collectez des statistiques sur les remarques du reviewer. Elles révèlent les erreurs récurrentes de l'équipe, et il est souvent plus rentable de les éliminer avec un linter ou un template que de les commenter à chaque fois dans une merge request.

Observez ce que les utilisateurs emploient le plus. L'auteure reconnaît elle-même que la fonctionnalité la plus demandée n'était pas celle qu'on attendait. Intégrez la télémétrie au système dès le départ.

Pour le marché, c'est un exemple de plus de grandes entreprises qui quittent les services IA externes au profit de plateformes d'agents internes. Les raisons sont pratiques : le contrôle du code et la possibilité d'adapter le comportement à ses propres processus.