A comienzos de 2023 empezamos a experimentar con revisiones de código asistidas por IA en el equipo. Primero con un bot que comentaba pull requests usando GPT-3.5, luego con integraciones más sofisticadas, pasando por Copilot para Pull Requests, CodeRabbit, y herramientas específicas como Qodo. Dos años después, las costumbres se han asentado y tengo opiniones razonablemente firmes sobre qué funciona y qué no.
Este no es un repaso de productos, ni una lista de «mejores herramientas 2025». Es más bien el balance que me gustaría haber leído al empezar: dónde la IA en code review aporta valor real y dónde solo añade ruido que el equipo tiene que filtrar.
Lo que esperábamos
La expectativa inicial era que la IA acabaría sustituyendo la primera vuelta de revisión humana. La idea parecía razonable: los revisores pasan mucho tiempo señalando cosas de estilo, olvidos obvios, errores triviales. Si una herramienta pudiera cubrir todo eso automáticamente, el tiempo humano se podría dedicar a arquitectura y criterio.
Lo que ha pasado en la práctica es parcialmente eso y parcialmente otra cosa distinta.
Lo que ha funcionado
La IA es útil para detectar varios patrones muy concretos:
Primero, olvidos mecánicos. Cosas como un TODO sin referencia, un import que se añadió pero no se usa, una variable declarada y nunca leída, un test modificado que ya no se ejecuta. Todo esto sale en linters tradicionales, pero las herramientas con LLM tienen una ventaja: formulan el aviso en lenguaje natural y con contexto, lo que lo hace mucho menos ignorable que «unused import». En equipos grandes donde los linters se convierten en ruido de fondo, esto ayuda.
Segundo, inconsistencias entre el código y los comentarios o la documentación. Si cambias una función pero la docstring sigue diciendo otra cosa, la IA lo pilla con bastante fiabilidad. Los humanos también, pero es el típico caso donde nos saltamos el detalle. La herramienta tiene paciencia infinita.
Tercero, resúmenes útiles para el revisor. Un resumen automático de qué hace el PR, generado a partir del diff, es un punto de entrada muy razonable. Reduce la fricción para el revisor que no conoce el contexto, y si el resumen no cuadra con lo que el PR hace, eso ya es una señal útil.
Cuarto, generación de tests sugeridos. Las herramientas que proponen casos de test para el código modificado aportan un beneficio modesto pero consistente. No sustituyen al diseño de tests pensado por humanos, pero recogen casos límite olvidados, especialmente en funciones con muchos parámetros.
Lo que no ha funcionado
En el lado contrario, hay varias cosas que hemos dejado de esperar de estas herramientas.
Detección de bugs sutiles. Cuando una herramienta te dice «posible race condition» o «posible null dereference», la tasa de falsos positivos sigue siendo muy alta. Al principio los comentábamos todos, pero pronto descubrimos que el 80% eran imposibles en el contexto real (porque esa función solo se llama desde un lugar, porque la estructura ya garantiza que el valor no es null, etc.). Hoy filtramos estos comentarios en la mayoría de casos y los revisamos solo cuando el código es claramente de riesgo.
Juicio arquitectónico. «Esta función debería ser una clase», «este módulo debería estar en otro sitio», «deberías usar dependency injection aquí». Estos comentarios son técnicamente correctos a veces, pero sin entender el contexto del proyecto se vuelven ruido permanente. La IA no sabe que esa función tiene un propósito deliberadamente limitado, o que el módulo pertenece donde está por razones históricas conocidas.
Revisiones de seguridad profundas. Las herramientas detectan patrones obvios (credenciales hardcoded, SQL construido con concatenación de strings, uso de funciones marcadas como inseguras), y eso es valioso. Pero no sustituyen una auditoría de seguridad real, y hemos visto casos donde una herramienta aprueba un diff que tiene un problema claro porque el patrón no encaja con lo que fue entrenada a detectar.
El patrón que ha emergido
Después de probar varias configuraciones, el patrón que mejor ha funcionado en nuestro equipo es este:
La IA hace una primera pasada automática al abrir el PR. Deja un resumen de qué cambia, marca los olvidos mecánicos, identifica tests no cubiertos y flaggea cualquier patrón de riesgo conocido. Esa primera pasada llega antes que cualquier revisor humano.
El autor del PR procesa esa primera pasada: arregla los olvidos, responde a las preguntas de la herramienta, descarta los falsos positivos con una nota breve. Para cuando el revisor humano llega, el PR está más limpio de ruido.
El revisor humano se centra en lo que importa: arquitectura, elección de trade-offs, coherencia con el resto del sistema, legibilidad a largo plazo. Esa conversación es ahora más productiva, porque no se gasta energía en lo mecánico.
Un detalle importante: los comentarios de la IA no tienen autoridad de bloqueo en nuestro proceso. Son sugerencias explícitas. Nadie tiene que justificar por qué ignora un comentario automático. Esto era importante al principio porque la tasa de falsos positivos habría frustrado al equipo. Con el tiempo, la herramienta ha mejorado y el flujo se ha estabilizado.
Las decisiones que han hecho la diferencia
Hay tres decisiones concretas que creo que marcan la diferencia entre equipos que integran bien la IA en code review y los que la abandonan:
La primera es no exigir que todos los comentarios automáticos se resuelvan. Si haces eso, el ruido se vuelve insoportable en pocos meses. Los comentarios automáticos se ignoran si no aportan.
La segunda es elegir una sola herramienta y usarla consistentemente. Tener tres bots comentando el mismo PR es contraproducente: se solapan, se contradicen y aumentan el coste cognitivo del revisor humano.
La tercera es revisar periódicamente qué tipo de comentarios aporta valor y qué tipo no, y ajustar la configuración de la herramienta. Casi todas permiten desactivar categorías de reglas o subir el umbral de confianza. Con el tiempo hemos silenciado varias categorías que generaban ruido y hemos subido el filtro de otras.
Mirando adelante
Lo que veo venir en los próximos meses es una profundización de lo que ya funciona. Las herramientas van a ser mejores en los casos donde ya aportan (resúmenes, olvidos mecánicos, sugerencias de tests), y probablemente empezarán a integrarse con herramientas de depuración y con histórico de incidencias, de modo que un comentario pueda decir «este código es similar al que causó el incidente del trimestre pasado».
Lo que no espero, y creo que los anuncios optimistas van a seguir dando vueltas, es que la IA sustituya la revisión humana en decisiones arquitectónicas o en juicio de criterio. Esa parte se mantiene como trabajo humano, probablemente mejor asistida pero no delegada.
Para alguien que piensa adoptar estas herramientas hoy, mi consejo es pragmático: empieza con una sola, configura desactivaciones agresivas, no bloquees el merge por comentarios automáticos, y revalúa cada seis meses si la herramienta está aportando más de lo que cuesta mantener. Ese enfoque modesto es el que nos ha dejado con una mejora real sin haber perdido tiempo en promesas excesivas.
