El problema no es la IA, es la cola de PRs
Llevo un tiempo con IA metida en la revisión de código, no solo en la escritura. Y la tentación inicial es siempre la misma: meter un bot que revise cada pull request y confiar en que filtre lo obvio para que yo solo mire lo importante.
Funciona. Pero solo si lo montas con cuidado. Si lo montas mal, tienes un pipeline que genera comentarios automáticos que nadie lee, o peor, que aprueba cosas que no debería.
La diferencia entre un pipeline útil y uno decorativo está en tres decisiones: qué automatizas, dónde pones el corte humano, y qué haces con el ruido que genera.
Qué meto en el pipeline y qué no
Hay una categoría de revisión que delego sin dudar: estilo, convenciones, imports sin usar, nombres inconsistentes, funciones que superan un tamaño razonable. Eso es mecánico, objetivo, y no necesita criterio. Un linter clásico ya hacía parte de esto; una IA añade contexto semántico que el linter no tiene, como detectar que dos funciones hacen básicamente lo mismo con nombres distintos.
Lo que no delego: decisiones de arquitectura, trade-offs de rendimiento con contexto de negocio, y cualquier cosa que toque seguridad o datos sensibles. Ahí un modelo puede señalar un patrón sospechoso, pero la decisión de si es un problema real la tomo yo. No porque desconfíe del modelo en general, sino porque esas decisiones dependen de contexto que no está en el diff: por qué se tomó tal decisión hace tres meses, qué limitación de la plataforma la forzó, qué vamos a tocar la semana que viene.
Regla práctica que sigo: si la revisión requiere memoria del proyecto que no cabe en el propio PR, no se la doy a la IA sin supervisión.
Dónde pongo el corte humano
El pipeline nunca aprueba merges por sí solo. Esto no es una opinión filosófica, es una consecuencia de haber visto qué pasa cuando no lo haces así: los comentarios automáticos se acumulan, algunos son ruido, y si el bot puede aprobar, en algún momento aprueba algo que no debería porque el diff parecía correcto en aislamiento pero rompía una invariante que solo existe en otro archivo.
El corte que uso es simple: la IA comenta, yo decido. Un comentario automático no bloquea el merge por sí mismo, pero sí lo marca como pendiente de revisión humana si toca ciertas rutas del proyecto (lógica de negocio, cualquier cosa con IO externo, cualquier cosa con datos de usuario). El resto puede pasar con revisión más ligera.
Esto también resuelve un problema de responsabilidad: si algo se rompe en producción, quiero poder señalar exactamente qué decisión humana lo dejó pasar. Un pipeline donde "lo aprobó el bot" es la respuesta a "por qué se mergeó esto" es un pipeline mal diseñado.
El coste oculto: el ruido
Nadie habla de esto lo suficiente. Un bot de revisión mal calibrado no falla por dar comentarios incorrectos: falla por dar demasiados comentarios correctos pero irrelevantes. Y eso mata la herramienta igual de rápido.
Si cada PR recibe quince comentarios de estilo menor, la gente deja de leerlos. Y cuando deja de leerlos, se pierde también el comentario dieciséis, que sí era importante. Es el mismo problema que las alertas de monitorización mal configuradas: si todo dispara alerta, nada dispara atención.
Lo que me ha funcionado es tratar la configuración del pipeline como algo que se poda activamente, no que se configura una vez. Cada dos o tres semanas reviso qué tipo de comentarios se están generando y silencio las categorías que nadie está actuando sobre ellas. Si un tipo de aviso lleva un mes sin que nadie lo resuelva ni lo descarte explícitamente, no es que el equipo sea vago: es que el aviso no aporta suficiente valor para el coste de leerlo.
Cómo lo tengo montado ahora mismo
En la práctica, el pipeline tiene dos capas separadas. Una capa rápida que corre en cada push y cubre lo mecánico: estilo, duplicación obvia, funciones sin tests donde el proyecto exige tests. Esta capa es barata y no necesita revisión, simplemente falla el check si algo no cumple el mínimo.
Una segunda capa, más cara, corre solo en el PR final antes de pedir revisión humana, y genera un resumen: qué cambia, qué riesgos ve, qué archivos toca que no se tocan normalmente juntos. Ese resumen no sustituye mi lectura del diff, la acelera. Leo el resumen, decido cuánto tiempo dedicarle a cada parte del cambio, y entro directo a lo que parece más delicado en vez de leer todo con la misma atención.
Esto es lo importante: el resumen cambia mi orden de lectura, no mi decisión.
La recomendación
Si vas a montar esto, empieza solo con la capa mecánica y déjala correr sin bloquear nada durante un par de semanas. Mide cuántos de esos avisos son accionables de verdad. Solo cuando esa capa esté limpia de ruido, añade la capa de resumen para PRs grandes. Nunca le des al pipeline la capacidad de aprobar un merge por sí solo, ni siquiera para cambios "pequeños": el tamaño del diff no predice el riesgo del cambio.
Relacionado: Automatizar tareas sin perder el control del resultado