Garage Eight eliminó las aprobaciones de otros revisores en 69 MR de un servicio interno con revisión por IA

El equipo aceleró la escritura de código con IA y después se encontró con un cuello de botella en la revisión: no había más revisores. En Garage Eight, una sola funcionalidad de Android que abarcaba 35 solicitudes de integración, o merge requests, podía pasar una semana esperando dos aprobaciones para cada una. La pregunta práctica es sencilla: ¿qué cambios pueden pasar tras la revisión de un bot para que las personas tengan tiempo de analizar los errores con consecuencias realmente costosas?

Según Anna Sabotovich, responsable de la implantación del revisor de IA, en octubre se integraron 69 MR en el servicio interno de analítica del desarrollo sin la aprobación de otra persona. En el repositorio del propio revisor, solo seis de los 35 MR contaban con una aprobación ajena al autor. Es un caso útil para equipos con una cola de cambios creciente, pero no supone un permiso universal para prescindir de los revisores.

El número de revisores depende del coste del error

Garage Eight divide los servicios en cuatro niveles de riesgo. A efectos de la revisión, lo importante es qué ocurre si el servicio devuelve un resultado incorrecto. Los arquitectos de dominio asignan la clasificación según el peor escenario posible; un servicio sin clasificar se considera del máximo riesgo.

Por ejemplo, un error en un experimento interno puede afectar solo a sus autores. Un error en el cálculo de un pago ya afecta al dinero del cliente. Exigir el mismo número de aprobaciones para ambos cambios resulta cómodo desde el punto de vista administrativo, pero consume la atención del equipo sin tener en cuenta las consecuencias.

La empresa empezó por los repositorios internos, donde resulta más fácil detectar las consecuencias de un error y revertir los cambios. En el esquema previsto, los autores de cambios en los dos niveles de riesgo más bajos podrán integrarlos por su cuenta tras la revisión por IA y la superación de las comprobaciones automáticas. Para las funciones secundarias orientadas al cliente, se prevé mantener un revisor humano en los MR sencillos y normales, y dos en los complejos. La complejidad se determina en una etapa independiente del revisor: esa valoración no se deja en manos del autor.

En el nivel más alto, donde están en juego el dinero y los requisitos regulatorios, se mantienen dos revisores humanos. Hasta que exista un mecanismo automático para restablecer la aprobación humana obligatoria, la empresa mantiene la intervención de personas en los dos niveles superiores de riesgo.

Resolver un comentario no significa haber corregido un bug

La primera métrica parecía convincente: se resolvía el 92% de los comentarios del bot. Pero, en los repositorios móviles, GitLab impide integrar cambios mientras quede alguna discusión abierta. Entre los comentarios analizados en MR ya integrados, estaban resueltos los 647 de 647. En la práctica, la métrica reflejaba el cumplimiento de una condición para la integración.

Por eso, el equipo empezó a comprobar si el código cercano a la línea comentada cambiaba antes de la integración. Después comparó el resultado con una referencia: con qué frecuencia cambiaba un punto aleatorio del mismo archivo.

Durante el tercer trimestre, el bot dejó 585 comentarios sobre problemas graves en 12 repositorios. En 219 casos se modificó el código cercano: un 37%, frente al 7% de referencia. De 27 casos comprobados manualmente, en 25 la modificación estaba efectivamente relacionada con el comentario. Según la estimación de quien firma el artículo, durante el trimestre se corrigieron antes de la integración unos 200 problemas graves, incluidos 98 bugs.

Conviene no llevar la conclusión más allá de lo que permiten los datos. Un cambio en el código cercano es una señal indirecta de que se atendió el comentario. Estas cifras no miden la proporción de todos los errores detectados ni demuestran que el bot revise mejor que una persona. Sí resultan mucho más útiles que contar hilos resueltos a la hora de decidir si el revisor compensa su coste en un repositorio concreto.

El bot también necesita una cola, comprobaciones y mecanismos de protección

La infraestructura pronto pasó a formar parte de la calidad de la revisión. Una revisión con un modelo interno tardó unos 50 minutos y retrasó los demás MR. En septiembre, el revisor permaneció en silencio durante siete días; en octubre, otras 30 horas. En ambas ocasiones se había agotado el presupuesto de la API. A raíz de ello se añadieron alertas por falta de actividad, comprobaciones atascadas y saldo disponible.

Para evaluar los cambios de modelo, el equipo reunió 42 MR históricos; en 32 de ellos, una persona había confirmado problemas reales. Un conjunto así permite comparar versiones del revisor, aunque no basta para extraer conclusiones generales sobre su fiabilidad.

También está el problema de las discusiones interminables: en un MR, el bot revisó 27 commits y señaló 45 hallazgos; el agente del autor respondió a 44. El equipo considera necesario limitar el número de ciclos y revisar únicamente el nuevo diff.

La conclusión práctica es empezar por un repositorio con un coste del error claro y una cola de revisión humana medible. Después, comprobar qué comentarios dan lugar a correcciones útiles, cuánto ruido genera el bot y qué ocurre cuando falla. Garage Eight todavía tiene previsto restablecer automáticamente la intervención humana cuando aumenten las reversiones. Precisamente ese punto pendiente limita la eliminación de más requisitos de aprobación.