Guía del Desarrollador para Revisar Código Generado por IA

La revisión de código siempre ha consistido en detectar errores antes de que lleguen a producción. Pero cuando el código fue escrito por un asistente de IA en lugar de un colega humano, la dinámica de la revisión cambia fundamentalmente. Los errores que comete la IA son diferentes de los errores que comete un humano, y las cosas que necesitas verificar no son las mismas que verificarías en una revisión entre pares.

Esta guía cubre lo que los equipos experimentados han aprendido sobre la revisión de código generado por IA. Está organizada por las categorías de problemas que los modelos de IA producen consistentemente, para que puedas seguir una lista de verificación sistemática en lugar de depender de la intuición desarrollada para código escrito por humanos.

Por qué el código generado por IA necesita criterios de revisión diferentes

Los desarrolladores humanos cometen errores que se agrupan en torno a la fatiga, la distracción y las lagunas de conocimiento — un desarrollador cansado pasa por alto un caso borde, uno distraído olvida manejar un error, uno junior usa un anti-patrón porque no sabe más. Los modelos de IA cometen errores que se agrupan en torno a ejes completamente diferentes: alucinación, ceguera de contexto e inconsistencia estilística.

Un humano que escribe una función que no maneja entradas nulas probablemente sabe más y solo lo olvidó. Una IA que escribe la misma función genuinamente no sabe si null es posible en tu base de código a menos que se lo hayas dicho explícitamente. Esta distinción importa porque la solución es diferente: un humano necesita un recordatorio, pero la IA necesita una restricción codificada en el prompt o detectada en la revisión.

Entender esta diferencia es la base de una revisión efectiva de código de IA. No estás verificando si el desarrollador fue cuidadoso. Estás verificando si la IA tenía suficiente contexto para producir código correcto, y si su resultado coincide con las convenciones implícitas de tu base de código que no pudo ver.

Elemento de verificación 1: APIs e importaciones alucinadas

El problema más común en el código generado por IA es el uso de librerías, funciones o APIs que no existen. Los modelos de IA están entrenados para producir código plausible, y generarán con confianza importaciones para paquetes que nunca fueron publicados y llamarán a métodos que nunca existieron. Esto no es malicioso — es el modelo interpolando entre paquetes reales que vio durante el entrenamiento e inventando un puente que parece razonable.

// AI-generated code that looks plausible but imports a non-existent function
import { renderAsync } from 'react-dom'; // renderAsync does not exist
import { optimize } from 'lodash/fp/string'; // This path does not exist in lodash

// What you actually need
import { renderToString } from 'react-dom/server';

La solución para esto es simple pero importante: verifica cada importación y cada llamada API contra la documentación real. No asumas que porque el código compila, las APIs son correctas — algunas funciones alucinadas tienen firmas de aspecto razonable que pasan la verificación de TypeScript pero fallan en tiempo de ejecución. La revisión debería incluir una comprobación rápida de cualquier importación que no reconozcas.

Elemento de verificación 2: Manejo de errores faltante

Los modelos de IA tienden a generar el camino feliz. Son notablemente buenos escribiendo la lógica principal de una función — el bucle, la transformación, el valor de retorno — y notablemente malos manejando lo que sucede cuando las cosas salen mal. Las solicitudes de red carecen de bloques catch. Las operaciones de archivo carecen de manejo de errores. Las funciones asíncronas carecen de manejadores de rechazo.

Esto no se debe a que la IA no pueda escribir manejo de errores. Si se lo pides explícitamente, la IA producirá una lógica try-catch exhaustiva. El problema es que el comportamiento predeterminado del modelo es escribir la versión funcional más simple, y el manejo de errores no es parte de ese valor predeterminado. Toda revisión de código generado por IA debería incluir una pasada que mire solo los caminos de error.

• Toda función asíncrona debe tener un catch o manejador de rechazo.
• Toda llamada API externa debe manejar errores de red, timeouts y formatos de respuesta inesperados.
• Toda transformación de datos debe manejar null, undefined y tipos inesperados.
• Toda operación de archivo o base de datos debe manejar errores de permiso y recursos faltantes.

Una técnica útil es ejecutar una prueba simple: elimina los bloques try-catch del código generado por IA y observa si la lógica restante sigue teniendo sentido. Si es así, probablemente la IA no pensó profundamente en el manejo de errores. Si la lógica depende del manejo de errores para funcionar, la IA lo integró correctamente.

Elemento de verificación 3: Desajustes de estilo y convenciones

Toda base de código tiene convenciones de estilo no escritas. El equipo usa retornos tempranos, no ifs anidados. Los mensajes de error siguen un formato específico. Los nombres de variables usan un patrón particular. Los modelos de IA entrenados en millones de repositorios públicos generarán código que refleje el promedio estadístico de todos esos repositorios, no las convenciones específicas de tu base de código.

El resultado es código que funciona pero se siente extraño. Usa una convención de nomenclatura diferente, una estructura de módulos diferente, o un patrón de manejo de errores diferente del código circundante. Este tipo de inconsistencia se acumula rápidamente — cinco funciones generadas por IA escritas con cinco estilos implícitos diferentes crean una base de código que se siente incoherente y es más difícil de mantener.

La mejor mitigación es incluir ejemplos de estilo en tus prompts. Pega una función representativa del mismo módulo y di usa este estilo. Esto le da a la IA una referencia concreta que anula su valor predeterminado de entrenamiento. Durante la revisión, verifica que el código generado podría haber sido escrito por la misma persona que escribió el módulo circundante.

Elemento de verificación 4: Sobrediseño y abstracción innecesaria

Los modelos de IA tienen un fuerte sesgo hacia la abstracción. Dado un problema simple, a menudo generarán una jerarquía de clases, una interfaz, una fábrica y tres funciones auxiliares — donde una sola función habría bastado. Esta tendencia proviene de los datos de entrenamiento, que sobrerrepresentan librerías open-source bien factorizadas y subrepresentan scripts simples y funciones únicas.

Los modelos de IA por defecto tienden al sobrediseño. Tu revisión debería tender por defecto a la simplicidad. Cada abstracción que la IA introdujo necesita justificar su existencia frente a una alternativa más simple.

Durante la revisión, pregúntate: ¿este código necesita una clase, o funcionaría con una función? ¿Esta interfaz es usada por más de una implementación? ¿Extraer esta utilidad ahorraría suficiente repetición para justificar la indirección? Si la respuesta a alguna de estas es no, probablemente la IA lo sobrediseñó, y la versión más simple es mejor.

Elemento de verificación 5: Vulnerabilidades de seguridad

Los modelos de IA son entrenados con código que contiene vulnerabilidades de seguridad. Aprenden patrones de ese código, incluyendo los vulnerables. Aunque los modelos modernos son mejores para evitar problemas obvios como la inyección SQL, todavía producen código con problemas de seguridad sutiles que un revisor necesita detectar.

• Verifica que no haya secretos hardcodeados, claves API o credenciales en el código generado.
• Confirma que la entrada del usuario sea validada y sanitizada antes de usarse.
• Revisa que las comprobaciones de autenticación y autorización estén presentes en operaciones protegidas.
• Asegúrate de que las consultas SQL generadas usen declaraciones parametrizadas, no concatenación de cadenas.
• Verifica que las rutas de archivo no se construyan a partir de entradas no confiables sin sanitización.

Una pasada de revisión centrada en seguridad es innegociable para código generado por IA que maneje datos sensibles o entrada de usuarios. La IA no sabe qué partes de tu sistema son críticas para la seguridad a menos que se lo digas. En caso de duda, ejecuta una herramienta de análisis estático sobre el código generado antes de fusionar.

Elemento de verificación 6: Consistencia con la arquitectura existente

Los modelos de IA ven cada solicitud de forma aislada. No saben que tu equipo acordó el trimestre pasado usar React Query para todas las obtenciones de datos, que la API siempre devuelve claves en camelCase, o que el proyecto usa un patrón específico de gestión de estado. El código que generan será internamente consistente pero puede violar decisiones arquitectónicas que no son visibles en el archivo actual.

Aquí es donde el revisor humano aporta más valor. Tú conoces las decisiones que están documentadas en tus ADRs, los patrones que surgieron de discusiones de equipo, y las restricciones de diseño que no están capturadas en ningún archivo individual. Revisa el código generado por IA contra estas restricciones invisibles, no solo contra corrección y estilo.

Construyendo un proceso de revisión sostenible

A medida que la IA genera más de tu base de código, el proceso de revisión necesita escalar. Un equipo de cuatro revisando cada línea generada por IA manualmente se agotará. El enfoque sostenible combina verificaciones automatizadas con revisión humana enfocada.

Las verificaciones automatizadas deberían detectar importaciones alucinadas, violaciones de estilo, manejo de errores faltante y problemas de seguridad comunes antes de que un humano vea el código. Esto reduce la revisión específica de IA a un conjunto más pequeño de preocupaciones: consistencia arquitectónica, decisiones de diseño y los problemas sutiles que los linters no pueden detectar.

El objetivo no es eliminar la revisión humana del código generado por IA. Es hacer que esa revisión sea lo más eficiente posible filtrando los problemas que las herramientas pueden detectar automáticamente y reservando la atención humana para los juicios que solo los humanos pueden hacer. Con el proceso correcto, revisar código generado por IA se vuelve más rápido y confiable que revisar código escrito por humanos — porque los errores de la IA son más predecibles.