SberDevices monta agentes de frontend com GigaChat para revisar merge requests

A SberDevices decidiu não entregar seu código para revisão por serviços externos e montou um sistema próprio de agentes para frontend. O GitHub Copilot Code Review e o GigaCode Agent do GitVerse, ambos prontos para uso, não se encaixaram nessa arquitetura: os dois são externos, e a equipe não quer abrir seus repositórios para eles. Avrora, responsável pela infraestrutura de frontend na empresa, falou sobre a arquitetura no Habr. O anúncio não traz métricas, então abaixo está o que foi confirmado e a lógica de engenharia por trás das decisões.

Por que um sistema próprio, e não um pronto

A desconfiança em relação a ferramentas externas tem menos a ver com a qualidade do modelo e mais com o perímetro de segurança. O revisor lê diffs, a estrutura do projeto, bibliotecas internas e convenções. Para uma grande empresa, esse é exatamente o código que não pode sair do seu ambiente controlado. Avrora descreve o caminho típico de grandes equipes como a criação da própria «bicicleta com o número certo de rodas e pedais». É uma escolha deliberada: os produtos externos resolvem um problema genérico, enquanto o stack interno é ajustado a repositórios e processos específicos.

O GigaChat está na base do sistema. O título do material contrapõe agentes «com GigaChat e sem», ou seja, automação com modelo e abordagens clássicas.

Dois modos em um só sistema

A principal decisão de arquitetura: a equipe combinou duas abordagens em vez de escolher uma só.

• Ciclo agêntico. O modelo recebe um objetivo e um conjunto de ferramentas e decide por conta própria quais passos dar. É flexível, mas menos previsível.
• Workflow determinístico. O modelo executa tarefas isoladas e limitadas dentro de uma sequência definida. O resultado é mais fácil de verificar e reproduzir.

O modelo híbrido parece razoável aqui. A revisão de um merge request consiste em operações estreitas: encontrar um erro típico, checar uma convenção, avaliar um trecho específico. Vale mais a pena embuti-las em um roteiro rígido. Tarefas abertas, como «investigue e proponha uma correção», ficam melhor com um ciclo com ferramentas. O primeiro garante estabilidade; o segundo, abrangência.

O que a análise completa promete

A autora destaca três temas:

• estatísticas dos erros de quem trabalha com frontend, com base nos dados do revisor de IA, ou seja, quais defeitos mais se repetem;
• um parser que reduz o contexto do modelo para que ele veja apenas o código relevante;
• uma função do sistema que «de repente» se tornou a mais requisitada.

O parser merece atenção. O frontend tem muito ruído: marcação, estilos, configurações, arquivos gerados. Se tudo for entregue ao modelo, o custo e o tempo de resposta crescem, e a qualidade dos comentários cai. Uma filtragem prévia pela estrutura do código ajuda a formular a tarefa com mais precisão e a caber na janela de contexto.

O anúncio não revela qual função se tornou a mais requisitada. Resta esperar o texto completo.

O que aproveitar na prática

Se você está construindo um revisor de IA interno ou um agente para desenvolvimento, a abordagem da SberDevices oferece algumas lições.

Separe as tarefas por grau de liberdade. Tudo o que pode ser resolvido por um algoritmo claro deve virar um workflow determinístico, e o ciclo agêntico fica reservado para tarefas abertas.

Não alimente o modelo com o repositório inteiro. Primeiro reduza o contexto com um parser ou análise estática e só depois chame o LLM.

Colete estatísticas dos comentários do revisor. Elas mostram os erros recorrentes da equipe, e muitas vezes compensa eliminá-los com um linter ou um template, em vez de comentar no merge request toda vez.

Observe o que as pessoas mais usam. A autora admite abertamente que a função mais requisitada não foi a esperada. Inclua telemetria no sistema desde o início.

Para o mercado, é mais um exemplo de grandes empresas migrando de serviços externos de IA para plataformas internas de agentes. Os motivos são práticos: controle sobre o código e a possibilidade de ajustar o comportamento aos próprios processos.