La revisión de código suele ser lenta e irregular: las diferencias esperan en cola y los comentarios dependen de quién esté conectado.

La revisión de código con IA solo ayuda cuando el revisor cuenta con un contexto real de la base de código.

La revisión de código con IA funciona mejor cuando el revisor ya tiene acceso a todo el repositorio, los cambios recientes, las pruebas y un conjunto claro de reglas. Con este contexto, la revisión de código con IA detecta problemas que un bot independiente centrado en una sola diferencia nunca vería. La revisión resulta más útil como parte del mismo sistema que generó el cambio.

#Qué cambió en la revisión de código

Los agentes de programación no inventaron las PR largas, pero hicieron que los cálculos tradicionales de revisión dejaran de funcionar más rápido.

Los desarrolladores que trabajan con agentes de programación están entregando cambios más grandes. Los datos de millones de sesiones de Cursor muestran que las líneas agregadas por PR (p75) aumentaron alrededor de 2,5 veces interanual. Las mega PR, con más de 1.000 líneas modificadas, representan una proporción cada vez mayor de las fusiones, con un claro salto en enero de 2026 a medida que mejoraron los agentes y los modelos. Las sesiones de Agente también se volvieron más profundas: el promedio de llamadas a herramientas por sesión subió alrededor de un 30 % en una ventana reciente de dos meses. Una mayor parte del código escrito por IA perdura. Las líneas de IA aceptadas que seguían presentes después de 60 minutos aumentaron de aproximadamente un 76 % a un 81 % desde comienzos de 2026. Los cambios generados por Agente que llegan a commits sin un paso independiente de aceptación manual de diferencias crecieron más de 5 veces durante ese período.

La capacidad de revisión humana no creció al ritmo de nada de eso. Las recomendaciones clásicas de revisión entre pares llevan mucho tiempo considerando que unos pocos cientos de líneas de lectura cuidadosa son el rango en el que se mantiene la calidad.

La revisión de código con IA es la forma de mantener un control de calidad cuando el volumen de cambios supera la cantidad de ingenieros sénior que pueden leer cada diferencia.

Una mayor parte del código bajo revisión fue escrita con asistencia de IA. Los humanos son buenos para detectar “esto no coincide con cómo construimos aquí”. Son peores cuando tienen que enfrentarse a un parche grande, plausible y en su mayor parte correcto generado por un agente para encontrar esa única falla sutil, que es donde ayuda un revisor con contexto real del repositorio. Escribir un cambio grande y revisarlo son habilidades distintas, y la revisión es esa comprobación.

#Preguntas antes de lanzar la revisión de código con IA

Si estás evaluando herramientas de revisión de código con IA, revisa primero estos conceptos.

#¿Qué es la revisión de código con IA?

La revisión de código con IA es un software que lee un cambio (normalmente una PR; a veces, una diferencia local) y señala errores, regresiones y riesgos antes de fusionarlo. Las versiones útiles analizan más que las líneas modificadas que tienen delante. Toman en cuenta archivos relacionados, pruebas, configuración y reglas del equipo. Las versiones más flojas se limitan a reformular la diferencia en prosa o a insistir con comentarios y nombres.

#¿En qué se diferencia del linting o de CI?

Los linters y los verificadores de tipos codifican reglas que ya sabes definir. CI ejecuta las comprobaciones que automatizaste. La revisión con IA es para lo que queda: errores de lógica, condiciones de carrera, fallos de autenticación, fallos en carpetas situadas a unas pocas carpetas de distancia, documentación y comportamiento que no coinciden. Se solapa con CI. No lo sustituye.

#¿La revisión de código con IA reemplaza la revisión humana?

No. Cambia en qué invierten su tiempo las personas. Al fin y al cabo, solo alrededor de la mitad de los comentarios de revisión humana acaban dando lugar a un cambio en la misma PR. Las culturas de revisión saludables incluyen notas para corregir más adelante y contexto meramente informativo. Conviene despejar errores claros y abordables por la máquina, para que las personas puedan centrarse en la arquitectura, el riesgo del producto y el conocimiento tácito que el modelo aún no tiene.

#¿Qué hace que la revisión con IA genere ruido?

El ruido viene de comentarios que la gente no quiere recibir de un bot. Las quejas sobre estilo, las notas vagas de "agrega tests" sin ninguna prueba fallida y las sugerencias de reescritura que no detectan ningún error hacen que la gente ignore la revisión. Distingue entre lo que el modelo puede detectar y lo que la gente realmente quiere que señale. La revisión de código con IA debería señalar errores reales, commits accidentales, problemas de rendimiento y de seguridad, y casos en los que la documentación y el código no coinciden. Cuando Graphite acotó sus revisiones con IA a esa intersección, alrededor del 52% de los comentarios llevaron a un cambio en el código (aproximadamente la misma tasa que los revisores humanos), con menos del 4% de votos negativos.

#¿Qué deberíamos medir?

Tasa de resolución: al fusionar, ¿la incidencia señalada realmente se solucionó en el código final? La tasa de resolución es más importante que el volumen de comentarios.

También es la métrica que Cursor usó para mejorar Bugbot: la resolución pasó del 52 % a más del 70 % a lo largo de 40 experimentos, los errores señalados por ejecución pasaron de 0,4 a 0,7, y los errores resueltos por PR de aproximadamente 0,2 a cerca de 0,5, en más de dos millones de PR revisadas al mes. En mayo de 2026, la tasa de resolución con el esfuerzo predeterminado había alcanzado cerca del 80 % de errores resueltos al fusionar. Si tu tasa de resolución cae mientras aumenta el volumen de comentarios, el bot está generando ruido.

El panel de Bugbot muestra gráficamente la tasa de resolución a lo largo del tiempo para cada repositorio, junto con el volumen de incidencias encontradas y solucionadas, para que puedas comprobar si las revisiones detectan problemas reales y se resuelven antes de ampliar el alcance de los comentarios del bot.

#¿Cuándo debería ejecutarse la revisión: localmente, en la PR o en ambos?

En ambos casos, pero con funciones distintas. La revisión local (después de una tarea de Agente, antes de hacer push) detecta incidencias mientras el contexto sigue fresco y todavía no existe el hilo. La revisión de PR es el contrato del equipo: reglas compartidas, historial compartido y un criterio común para fusionar. Las comprobaciones centradas en la seguridad pueden ir en cualquiera de los dos lados, según cómo publiques.

#¿Necesitamos que la herramienta de revisión esté en el mismo producto que el agente?

Puedes comprar una herramienta de revisión independiente. Muchos equipos lo hacen. El costo es el cambio de contexto y una visión más limitada de cómo se generó el código. Cuando la revisión se ejecuta en el mismo sistema que escribió el cambio, ya conoce los archivos abiertos, el mapa del repositorio y las reglas que mantienes junto al código. Las correcciones pueden incluir enlaces directos al editor o iniciar un agente con el hallazgo ya cargado. Ese ciclo es difícil de replicar con una solución acoplada.

#Cómo ejecutar la revisión de código con IA en Cursor

El flujo de Cursor consiste en una revisión local en el editor, Bugbot en la PR y, después, un ciclo de corrección que te devuelve al mismo conjunto de herramientas.

Local. Después de trabajar con el agente, ejecuta Agent Review. Puedes escribir /agent-review en la entrada del agente, ejecutarlo desde la pestaña Source Control para comparar los cambios locales con tu rama principal o activar las revisiones automáticas después de cada commit. Antes de hacer push, también puedes ejecutar Bugbot o un Agente de Seguridad de forma local con las skills /review-bugbot y /review-security. Aquí puedes resolver los problemas evidentes mientras la sesión aún conserva el contexto.

En la PR. Bugbot revisa PR en GitHub, GitLab y Bitbucket. Define las invariantes del equipo en .cursor/BUGBOT.md, además de las reglas del equipo y del repositorio. Las reglas aprendidas (@cursor remember) incorporan los comentarios a futuras ejecuciones. Supervisa la tasa de resolución en Bugbot Automations antes de ampliar las categorías de comentarios.

Ciclo de corrección. Los hallazgos aparecen en la PR con enlaces para volver a Cursor (Fix in Cursor y Fix in Web). Autofix de Bugbot puede iniciar un Cloud Agent para proponer correcciones. En cuanto a seguridad, los Security Agents de Cursor cubren dos funciones: Security Reviewer revisa las PR antes de fusionarlas y Vulnerability Scanner analiza la base de código en reposo.

Empieza. La documentación explica la configuración de principio a fin: cómo conectar tu repositorio, elegir qué repositorios y personas activan las revisiones, el nivel de esfuerzo y .cursor/BUGBOT.md. Consulta cursor.com/docs/bugbot.

#Automatiza el enrutamiento y las aprobaciones

Encontrar errores no es todo el trabajo de revisión. Dos automatizaciones de Cursor se encargan de las tareas mecánicas.

Aprueba automáticamente los cambios de bajo riesgo. Los Agentes de aprobación evalúan el riesgo de cada PR y aprueban las que superan el umbral que establezcas. Un ajuste de texto o una actualización de configuración pueden fusionarse sin esperar a una persona. Todo lo que supere tu umbral de riesgo queda retenido. Los hallazgos de Bugbot y del Agente de seguridad influyen en esa decisión para evitar que se aprueben sin más cambios arriesgados.

Asigna los revisores adecuados. Cuando una PR requiere la intervención de una persona, los Agentes de aprobación asignan revisores según la parte de la base de código que modifica, mediante políticas de enrutamiento por área que defines. El cambio se envía al equipo responsable de ese código en lugar de a una cola compartida.

#Mantén la revisión cerca del código

La revisión de código con IA es cómo los equipos mantienen un control de calidad mientras los agentes aumentan el alcance y la velocidad de los cambios. Las versiones que funcionan tienen contexto del repositorio, una política de comentarios estricta y una métrica que hace seguimiento de si los hallazgos se corrigen.

La revisión debe estar cerca de donde se generó el código, con las mismas reglas y el mismo proceso de corrección. Activa Bugbot en un repositorio con mucha actividad, observa la tasa de resolución en Bugbot Automations durante una semana y solo entonces decide qué categorías merecen más volumen.