Code review de código de IA: seis patrones que la revisión clásica pasa por alto

Una revisión de código generado por IA debe buscar cosas distintas que una revisión clásica. Una IA apenas produce erratas ni descuidos. Produce código que parece plausible y que en ciertos puntos omite sistemáticamente algo: las comprobaciones de permisos, el tratamiento de errores, el cotejo con la lógica ya existente.

¿Por qué funciona peor el code review clásico con código de IA?

Porque está diseñado para una distribución de errores que ya no existe como tal. El código humano contiene típicamente falta de atención: variables intercambiadas, casos límite olvidados, nombres poco claros. Estos errores parecen erróneos, y para eso está entrenado un revisor.

El código de IA parece correcto. Los nombres son coherentes, la estructura es convencional, hay comentarios. La vista no encuentra ningún punto de apoyo. En la Stack Overflow Developer Survey 2025, el 66 % de los encuestados citó «casi correcto, pero no del todo» como su mayor frustración con las herramientas de IA: es exactamente la descripción de una clase de errores que no se detecta con solo mirar.

A ello se suma el volumen. Una revisión de 800 líneas generadas no recibe la atención de 80 escritas a mano. A partir de cierto tamaño, toda revisión se convierte en un muestreo, sin que nadie lo decida.

¿A qué debo prestar especial atención en una revisión de código de IA?

A seis patrones que aparecen con una frecuencia superior a la media en el código generado.

• Falta de comprobación de permisos. La lógica de negocio es correcta, pero nunca se planteó la pregunta «¿puede este usuario hacer esto?». El control de acceso defectuoso sigue ocupando el primer puesto del OWASP Top 10:2025.
• Errores tragados. Un bloque catch vacío, un valor de retorno ignorado, un valor por defecto que disfraza un fallo de éxito. Desde 2025, categoría propia de OWASP (A10).
• Lógica reinventada junto a la existente. El modelo no conoce su función auxiliar y escribe una segunda. Ambas funcionan, ambas habrá que mantenerlas en el futuro.
• Nuevas dependencias inadvertidas. Revise los archivos de paquetes del diff con la misma atención que el código fuente.
• Pruebas que confirman el código en lugar de comprobarlo. Las aserciones derivadas del comportamiento actual consolidan los errores existentes; véase Cobertura de pruebas en código de IA.
• Cambios demasiado amplios. Si de paso se tocaron archivos que no pertenecen a la tarea, eso no es ordenar, sino un efecto secundario sin revisar.

¿Cómo debería desarrollarse una revisión de código de IA?

En cuatro pasos, de los cuales los dos primeros son automáticos y la persona no interviene hasta el tercero.

• Paso 1: la máquina despeja lo evidente. Formato, análisis estático, reglas de seguridad, revisión de dependencias y licencias, ejecución de pruebas. Todo lo que una herramienta pueda decidir no debe costarle tiempo a una persona.
• Paso 2: comprobar el alcance. ¿Encaja el diff con la tarea? Los cambios demasiado amplios se devuelven antes de que nadie los lea. Esta regla ahorra más tiempo de revisión que cualquier otra.
• Paso 3: la persona comprueba la intención. ¿Resuelve el cambio el problema planteado? ¿Encaja en la arquitectura? ¿Existe ya en otro sitio? ¿Se han tenido en cuenta los permisos y los casos de error?
• Paso 4: evidencia en lugar de promesa. La aprobación incluye la salida de la ejecución de las pruebas, no la afirmación de que se ejecutaron.

¿Puede una IA encargarse del code review?

Como primera instancia sí, como última no, y por una razón estructural.

Los revisores asistidos por IA son buenos en lo que se puede reconocer en el propio código: patrones, incoherencias, problemas de seguridad evidentes, falta de tratamiento de errores. Son poco fiables ante la única pregunta que realmente cuenta: ¿es este el comportamiento correcto? Esa pregunta no puede responderse desde el código, sino solo desde el conocimiento de para qué sirve el software.

A ello se añade un razonamiento circular que se pasa por alto con facilidad: cuando el mismo modelo primero escribe y luego revisa, comparte ambas veces los mismos puntos ciegos. Un segundo modelo ayuda en parte, pero no sustituye a la persona que conoce el problema de negocio.

¿Cuánto tiempo debería costar una revisión?

Menos que hoy, si los pasos 1 y 2 son realmente automáticos. En la Stack Overflow Developer Survey 2025, el 45 % de los encuestados indicó perder mucho tiempo depurando código de IA. Una parte de ello es tiempo de revisión gastado en el lugar equivocado: las personas revisan el formato y el estilo mientras la laguna de permisos se cuela.

La regla práctica fiable es esta: lo que una herramienta puede decidir, no lo decide una persona. Lo que solo una persona puede decidir, no lo decide una herramienta. Todo lo demás es desperdicio en un lado y riesgo en el otro.

Preguntas frecuentes sobre el code review

¿Debo revelar que el código se ha creado con IA?

Según el estado actual, no existe una obligación legal general al respecto. Para la revisión, la información resulta útil de todos modos: orienta lo que se busca. Muchos equipos lo resuelven con una marca en la pull request en lugar de con una regla.

¿Cómo trato los cambios generados muy grandes?

Devolverlos y hacer que se dividan. Un diff demasiado grande para leerlo no se revisa con más cuidado por ser urgente: solo se revisa con más superficialidad, sin que nadie lo diga.

¿Basta una revisión por parte de una persona?

Para la mayoría de los cambios, sí. Para la autenticación, el pago, los cambios de esquema y el despliegue, un segundo par de ojos es el seguro más barato.

¿Y si nadie en el equipo entiende el código generado?

Entonces ese es el hallazgo, no un obstáculo para el hallazgo. Un código que nadie entiende no es mantenible, con independencia de su corrección, y no debería fusionarse.

Una persona que revisa el formato es un linter contratado a precio de oro. Code Guardian adelanta los controles automáticos (una auditoría justo después del cambio, a lo largo de niveles fijos como lógica, redundancia y seguridad) para que en la revisión queden las preguntas para las que realmente hace falta una persona.

Fuentes

• Stack Overflow Developer Survey 2025, sección «AI» (66 % «almost right», 45 % de pérdida de tiempo en depuración).
• OWASP Top 10:2025, categorías A01 y A10.

Fecha: 27 de julio de 2026. Valoración técnica de carácter general, no constituye asesoramiento jurídico.