¿Qué es la revisión de código con IA y cómo funciona?

Cómo funciona la revisión de código con IA en un pull request

Un revisor con IA trabaja en cinco pasos, y la verificación es la que más pesa en la calidad del resultado. Todo encaja en el mismo proceso de revisión de código (en inglés) que siguen las personas; las herramientas se diferencian en cuánto contexto leen y en lo estrictas que son al comprobar sus propios hallazgos.

1. Disparador. Se abre o se actualiza un pull request, o alguien pide una revisión en un comentario.
2. Contexto. El revisor lee el diff, los archivos que toca y el código que los llama, además de las reglas que el equipo guarda en archivos como REVIEW.md y AGENTS.md.
3. Posibles hallazgos. El modelo apunta todo lo que podría estar mal: errores de lógica, casos límite olvidados, problemas de seguridad, contratos rotos con quien llama al código e incumplimientos de reglas.
4. Verificación. Los mejores revisores comprueban cada posible hallazgo contra el código antes de publicarlo. HeyDeer es un agente de revisión de código con IA para pull requests de GitHub que comprueba cada posible problema contra el código y publica solo los que se sostienen.
5. Resultado. Comentarios en línea sobre las líneas afectadas, un resumen y, a menudo, un check de estado que puede bloquear la fusión. Algunas herramientas también abren una corrección.

La mayor parte de la diferencia de calidad sale de la verificación. Un revisor que se salta este paso publica cada sospecha; uno que lo aplica publica lo que puede respaldar con el código. Así es como la revisión Profunda de HeyDeer alcanza un 99,0 % de precisión en la vista predeterminada de ReviewBench, a noviembre de 2026 (los resultados de ReviewBench, explicados).

Un ejemplo real: un hallazgo de principio a fin

En nuestro benchmark, un agente de programación añadió a una app de analítica de código abierto una lista de direcciones IP excluidas por sitio web, para que los equipos dejaran de contar el tráfico de su propia oficina o de su VPN. La revisión de HeyDeer publicó este comentario en la línea 37 de src/app/api/websites/[websiteId]/route.ts:

• Hallazgo: Mantener las direcciones IP excluidas fuera de las respuestas que se comparten públicamente.
• Gravedad: Media. La app sigue funcionando, pero datos privados de la red llegan a personas que deberían quedar al margen.
• Evidencia: /api/share/[slug] emite un token para compartir, canViewSharedWebsite() lo acepta y este endpoint devuelve el objeto completo del sitio web. Como getWebsite() lee todos los campos, la nueva columna excludedIps le llega a cualquiera que tenga el enlace a un panel público.
• Corrección propuesta: Quitar excludedIps de las respuestas autorizadas con un token para compartir y actualizar el esquema de la respuesta para que coincida.

Cada parte se puede comprobar. La evidencia nombra la cadena de llamadas exacta, así que quien revisa puede abrir tres funciones y confirmar la fuga en un par de minutos, y la corrección es lo bastante pequeña para verificarla con un test que llame al endpoint con un token para compartir. Un comentario que se limitara a decir «esto podría exponer datos sensibles» dejaría todo ese trabajo a quien lo lee.

Qué detecta la revisión de código con IA

La revisión con IA rinde mejor con los problemas que se pueden comprobar contra el propio código (para ver en qué se diferencia de las herramientas basadas en reglas, consulta las alternativas a SonarQube, en inglés). En nuestro propio benchmark, en el que ocho agentes de programación construyeron las mismas dos funcionalidades, los problemas que encontraron los revisores eran fallos de comportamiento concretos: un rango de IP guardado que en realidad dejaba pasar todo el tráfico, un enlace para compartir que exponía las IP excluidas de la oficina y un error de red que avisaba a los visitantes de que su enlace había caducado.

• Errores sin gestionar y casos límite olvidados, como una entrada vacía o una petición fallida.
• Huecos de seguridad, como una consulta a la que le falta el filtro de permisos o un secreto dentro de una URL.
• Cambios que rompen código de otra parte del proyecto que llama a lo modificado y que sigue intacto.
• Valores que se calculan y luego quedan sin usar, y condiciones que siempre dan falso.
• Incumplimientos de reglas que el equipo ha puesto por escrito, como «guarda el dinero en céntimos enteros».

Ese enfoque cubre una carencia de la revisión humana que viene de lejos. El estudio de Microsoft Research sobre revisión de código vio que encontrar defectos era la principal motivación de los desarrolladores, pero solo el 14 % de los comentarios de revisión trataban de defectos; la mayoría proponían mejoras al código. La revisión con IA puede encargarse de la caza de defectos para que las personas revisen todo lo demás.

Qué se le sigue escapando a la revisión de código con IA

La revisión de código con IA flojea cuando la respuesta está fuera del repositorio, como la intención del producto, la dirección del diseño o el contexto externo, y todos los revisores pasan por alto una parte de los fallos reales.

• La intención del producto. Si la funcionalidad es la que hace falta, o si se comporta como esperan los clientes.
• La dirección del diseño. Si una abstracción aguantará cuando crezca el producto, o si este es el sitio adecuado para el cambio.
• El contexto externo. Acuerdos con otros equipos, la forma real de los datos en producción o incidencias que explican por qué el código es como es.
• Algunos fallos reales. Todos los revisores dejan algunos problemas sin reportar. La exhaustividad de HeyDeer en la vista predeterminada de gravedad alta de ReviewBench es del 51,4 %: más o menos la mitad de los problemas etiquetados.

Revisar código generado por IA: por qué pesan más los falsos positivos

El código generado por IA necesita como mínimo la misma revisión que el código humano, y los falsos positivos salen más caros cuando un agente de programación actúa sobre cada comentario. La investigación DORA de Google de 2025 sitúa la adopción de IA entre los profesionales del software en el 90 %, y algunos datos indican que el código escrito por agentes pide todavía más revisión; nuestra guía de seguridad en el vibe coding (en inglés) repasa los riesgos más comunes.

El 2025 GenAI Code Security Report de Veracode encontró que el 45 % de las muestras de código generado por IA suspendía las pruebas de seguridad e introducía vulnerabilidades del OWASP Top 10, y que los modelos más nuevos y más grandes obtenían resultados de seguridad similares. Un estudio de Stanford vio que los desarrolladores con un asistente de IA escribían código menos seguro y, a la vez, tenían más probabilidades de creer que era seguro.

Los modelos punteros también fallan. En nuestro benchmark de 16 pull requests escritos por ocho agentes de programación, todos los agentes entregaron código con problemas, y HeyDeer encontró un 78 % más que la revisión de código de GitHub Copilot con el mismo número de falsos positivos (método y datos, en inglés).

Qué herramientas revisan el código de Claude Code o Cursor antes de fusionarlo

Cualquier revisor que trabaje sobre el pull request revisa el código escrito por agentes igual que el escrito por personas. La revisión de código de GitHub Copilot, Codex (con @codex review), el /code-review de Claude Code y apps de GitHub como HeyDeer encajan en este paso; la guía de revisión de código en GitHub (en inglés) explica cómo activar cada una. Elige un revisor basado en un modelo distinto del agente que escribió el cambio, para que sus puntos ciegos sean otros que los del autor.

Antes, descartar un comentario de revisión equivocado le costaba a una persona un minuto. Ahora los agentes de programación actúan sobre los comentarios de revisión, y la investigación ha visto que siguen las peticiones de corrección incluso cuando son capaces de darse cuenta de que la petición está equivocada (Jaiswal et al., 2026). Cada falso positivo se convierte en un cambio que alguien tiene que revisar, y el fallo real puede colarse entre el ruido. Si revisas con un modelo de chat, un prompt de revisión de código (en inglés) que pida evidencias y admita la respuesta «sin hallazgos» recorta parte de ese ruido.

Los desarrolladores ya lo notan. En la Stack Overflow Developer Survey de 2025, el 84 % de los desarrolladores usa o piensa usar herramientas de IA, pero son más los que desconfían de su exactitud (46 %) que los que confían en ella (33 %), y la frustración más común, citada por el 66 %, son resultados «casi correctos, pero no del todo». Un revisor que suma más comentarios «casi correctos» agrava el problema.

Así que valora un revisor por dos números: la precisión, la proporción de sus hallazgos que son reales, y la exhaustividad, la proporción de problemas reales que encuentra. Los dos tiran en sentidos opuestos: un revisor que lo reporta todo encuentra más y se equivoca más a menudo. Nuestras 6132 ejecuciones de revisión en nuestros propios pull requests (en inglés) mostraron que ese equilibrio depende tanto del proceso de revisión como del modelo.

Cómo sacarle el máximo partido a la revisión de código con IA

Cinco hábitos hacen que los hallazgos de la revisión con IA sean más útiles y menos ruidosos:

• Mantén los pull requests pequeños. En Google, el cambio mediano toca 24 líneas y la revisión mediana tarda menos de cuatro horas. Los cambios pequeños son más fáciles de revisar bien, tanto para las personas como para los modelos.
• Pon las reglas por escrito. Guarda las reglas de revisión en REVIEW.md y las convenciones del proyecto en AGENTS.md, para que el revisor señale lo que de verdad le importa a tu equipo.
• Usa un revisor independiente para el código escrito por agentes. Un modelo distinto del que escribió el código puede detectar lo que ese modelo pasó por alto. Ayuda a destapar puntos ciegos, sin garantía de eliminarlos todos.
• Trata los comentarios como afirmaciones. Pide al revisor, o a tu agente, que señale la línea que demuestra un hallazgo antes de cambiar el código.
• Mide con tu propio código. Pasa las herramientas por los mismos pull requests recientes y puntúa los hallazgos útiles, los falsos positivos y el tiempo invertido. Nuestra guía de evaluación (en inglés) incluye una plantilla.

¿Listo para elegir herramienta? Consulta las mejores herramientas de revisión de código con IA, ordenadas por precisión.

Fuentes

1. Stack Overflow Developer Survey 2025: AI
2. Google: 2025 DORA State of AI-assisted Software Development
3. Veracode: 2025 GenAI Code Security Report
4. Perry et al. (Stanford): Do Users Write More Insecure Code with AI Assistants?
5. Bacchelli & Bird (Microsoft Research): Expectations, Outcomes, and Challenges of Modern Code Review
6. Sadowski et al. (Google): Modern Code Review: A Case Study at Google
7. Jaiswal et al.: los agentes de programación y los comentarios de revisión erróneos
8. ReviewBench