SberDevices crea agentes de frontend sobre GigaChat para revisar merge requests

En SberDevices decidieron no enviar su código a revisión en servicios externos y construyeron un sistema propio de agentes para frontend. GitHub Copilot Code Review y GigaCode Agent de GitVerse no encajaron en este esquema: ambos son externos y el equipo no quiere abrirles sus repositorios. Aurora, responsable de la infraestructura de frontend de la compañía, contó la arquitectura en Habr. El anuncio no incluye métricas, así que a continuación se detalla lo que está confirmado y la lógica de ingeniería detrás de las decisiones.

Por qué uno propio y no una solución ya hecha

La confianza en las herramientas externas depende del perímetro, no de la calidad del modelo. El revisor lee diffs, la estructura del proyecto, bibliotecas internas y convenciones. Para una gran empresa, es justo el código que no sale del perímetro de seguridad. Aurora describe el camino habitual de los grandes equipos como la creación de una «bicicleta con el número justo de ruedas y pedales». Es una elección deliberada: los productos externos resuelven un problema general, mientras que el stack interno se ajusta a repositorios y procesos concretos.

El sistema se basa en GigaChat. El título del artículo original contrapone agentes «con GigaChat y sin él», es decir, la automatización con modelo frente a los enfoques clásicos.

Dos modos en un solo sistema

La decisión arquitectónica principal: el equipo combinó dos enfoques en lugar de elegir uno.

• Bucle agéntico. El modelo recibe un objetivo y un conjunto de herramientas, y decide por sí mismo qué pasos dar. Es flexible, pero menos predecible.
• Workflow determinista. El modelo ejecuta tareas concretas y limitadas dentro de una secuencia fijada. Los resultados son más fáciles de verificar y reproducir.

El enfoque híbrido parece razonable. La revisión de un merge request se compone de operaciones acotadas: encontrar un error típico, comprobar una convención, evaluar un fragmento concreto. Conviene encerrarlas en un guion rígido. Las tareas abiertas, como «investiga y propón una corrección», se dejan mejor a un bucle con herramientas. Lo primero aporta estabilidad; lo segundo, cobertura.

Qué se promete en el artículo completo

La autora destaca tres temas:

• estadísticas de errores de los desarrolladores de frontend a partir de los datos del revisor de IA, es decir, qué defectos se repiten con más frecuencia;
• un parser que acota el contexto del modelo para que solo vea el código relevante;
• una función del sistema que «de repente» resultó ser la más demandada.

El parser merece atención. El frontend genera mucho ruido: marcado, estilos, configuraciones, archivos generados. Si se le pasa todo al modelo sin filtrar, aumentan el coste y el tiempo de respuesta, y la calidad de las observaciones baja. Un resumen previo basado en la estructura del código ayuda a plantear la tarea con más precisión y a caber en la ventana de contexto.

El anuncio no revela qué función concreta resultó ser la más demandada. Habrá que esperar al texto completo.

Qué aprovechar de todo esto

Si estás construyendo un revisor de IA interno o un agente para desarrollo, puedes tomar varias ideas del enfoque de SberDevices.

Divide las tareas según su grado de libertad. Todo lo que admita un algoritmo claro, impleméntalo como workflow determinista y reserva el bucle agéntico para las tareas abiertas.

No le pases al modelo todo el repositorio. Primero acota el contexto con un parser o con análisis estático y después llama al LLM.

Recopila estadísticas de las observaciones del revisor. Muestran los errores recurrentes del equipo, y a menudo resulta más rentable resolverlos con un linter o una plantilla que comentarlos cada vez en el merge request.

Observa qué se usa más. La autora reconoce abiertamente que la función más demandada no fue la que esperaban. Incorpora telemetría al sistema desde el principio.

Para el mercado, es otro ejemplo de cómo las grandes compañías pasan de los servicios de IA externos a plataformas agénticas internas. Las razones son prácticas: el control sobre el código y la posibilidad de ajustar el comportamiento a sus propios procesos.