Automatización del Code Review: cómo las redes neuronales están asumiendo el trabajo rutinario de los desarrolladores

Por qué es necesaria la automatización

En Avito se crean mil pull requests por semana, hasta 300 simultáneos en las horas pico. Esto genera una carga enorme sobre los desarrolladores, que se distraen de su trabajo principal para hacer code review. El resultado: los PRs pueden pasar días en cola de revisión, aumenta el time-to-market de las nuevas funciones, el equipo se agota y puede pasar por alto errores críticos.

El equipo de ingenieros de LLM se planteó tres objetivos para la automatización:

• Acelerar el desarrollo — eliminar las colas de revisión • Reducir el impacto del factor humano — el cambio constante de contexto hace que los desarrolladores pierdan concentración • Unificar el proceso — distintos revisores hacen observaciones distintas, y a menudo surge subjetividad

Arquitectura del sistema

El sistema consta de tres componentes conectados en un flujo de trabajo claro:

1. Stash — la interfaz donde el desarrollador deja el comentario ai_review en el PR 2. Servicio en Go — recibe el evento del Data Bus, analiza el comando, toma el diff y los metadatos del repositorio, guarda la revisión en la base de datos con estado STATE_REQUESTED y envía una RPC al servicio de ML 3. Servicio Python ML Pipeline — procesa el contexto y devuelve los comentarios generados

El servicio de ML responde con 200 OK de inmediato para no bloquear al servicio en Go, ya que la generación puede tardar un buen rato.

El pipeline de ML: tres etapas

RuleChecker (generación). El modelo identifica todos los problemas potenciales, apoyándose en una taxonomía de errores extraída de PRs reales del equipo. Está optimizado para un alto recall, incluso a costa de falsos positivos. La salida es un JSON con números de línea y recomendaciones.

ReviewFilter (validación). Una segunda pasada mejora la precisión. El modelo trabaja con un patrón Conclusion First: recibe el mismo contexto más un comentario concreto y responde si esa observación es importante o no. Elimina el 90% de las alucinaciones y falsos positivos.

CommentAggregator (deduplicación). El sistema construye embeddings de los comentarios con BAAI/bge-m3 y calcula la similitud coseno. Si la similitud supera 0,85, los comentarios se agrupan. De cada grupo queda solo el más sustancioso. La salida es una lista final de observaciones únicas.

Elección del modelo y rendimiento

En el benchmark MERA-RuCodeReviewer (689 ejemplos en Java, Python, Scala y Go) lidera Gemini 2.5 Flash, pero el equipo eligió Qwen3-Coder-30B-Instruct-FP8 (segundo puesto) porque es de código abierto y permite hospedarlo en infraestructura propia. Esto es crítico: el código no sale hacia APIs externas, y el self-hosting resulta más económico a gran escala (los PRs requieren entre 2.000 y 10.000 tokens).

Rendimiento: • PRs pequeños (hasta 3 archivos): 10–20 segundos • PRs grandes (10+ archivos): ~60 segundos • Máximo de 650 revisiones en paralelo

Las métricas de calidad se recopilan a través de los likes de los desarrolladores: • Precisión: el 85% de los comentarios se clasifican como buenos • Tasa de obsolescencia: 32% (comentarios que el desarrollador cerró corrigiendo el problema). Para Infra y DevOps llega al 60%.

Conclusiones clave

La idea central: separar Recall y Precision funciona mejor que una única solicitud. Incluso con un contexto largo, el modelo se pierde, por lo que se necesita un sistema de varias etapas. La validación que elimina alucinaciones es crítica: es la base de la confianza de los usuarios.

El modelo debe ver el código completo de los archivos y la estructura del repositorio: el diff no es suficiente para un análisis de calidad. La IA se encarga de la rutina, pero las personas deben seguir controlando el proceso.