Cómo revisar con seguridad el código escrito por IA: una lista de comprobación real para desarrolladores

La IA escribe código más rápido que cualquier persona. Eso es a la vez su mayor fortaleza y lo que debería quitarte el sueño. Cuando un desarrollador usa GitHub Copilot, ChatGPT o cualquier otro asistente de programación con IA, el resultado se ve pulido, compila sin errores y pasa las pruebas básicas. Lo que suele faltar es el tipo de razonamiento profundo y contextual que detecta el error que no encontrarás hasta la tercera semana en producción.

Revisar código generado por IA no es lo mismo que revisar código escrito por personas. Las personas cometen errores previsibles en lugares previsibles. La IA comete errores plausibles en cualquier parte, con total seguridad. Este artículo te ofrece un marco práctico para revisar código escrito por IA de forma segura, con vulnerabilidades de seguridad, trampas de lógica, un manejo de errores deficiente y las herramientas que hacen el proceso más rápido sin recortar en calidad.

Qué hace diferente al código de IA

Si llevas años revisando código, ya sabes que la persona que escribió una función normalmente entiende lo que debe hacer, aunque el código esté mal. Puede responder preguntas. Tiene intención.

La IA no tiene intención en ese sentido. Genera código estadísticamente probable a partir de un prompt. Ha visto millones de ejemplos de código, incluidos los defectuosos. Cuando produce un resultado, está haciendo coincidencia de patrones, no resolviendo problemas.

La ilusión de corrección

Lo más peligroso del código generado por IA es lo correcto que parece. Sigue las convenciones de nombres. Tiene comentarios. Usa sintaxis moderna. A menudo tiene la estructura adecuada. Una persona que lo repase rápido lo aprobaría sin dudar.

Pero hay modos de fallo concretos en los que la IA cae una y otra vez:

• Asume entradas de camino feliz: el código de IA rara vez contempla qué pasa cuando los datos están mal formados, son nulos o están fuera del rango esperado.
• Copia patrones vulnerables: si los datos de entrenamiento contenían código inseguro, el modelo puede reproducir esa falta de seguridad con total confianza.
• Simplifica en exceso la concurrencia: las condiciones de carrera, los interbloqueos y los problemas de seguridad en hilos casi nunca aparecen por defecto en la salida de la IA.
• Pasa por alto la lógica de negocio: la IA no conoce tu sistema. No puede saber que user.balance nunca debería bajar de cero en tu dominio.

Patrones que fallan en silencio

Estos son los patrones concretos que superan la revisión de código pero fallan en producción:

Antes de leer una sola línea

Una buena revisión de código no empieza con el diff. Empieza antes de abrir el archivo.

Adopta la mentalidad adecuada

Cuando revisas código de personas, les concedes el beneficio de la duda. Asumes que tenían una razón para sus decisiones. No ofrezcas esa cortesía a la salida de la IA. Acércate a ella como lo harías con el código de un estudiante en prácticas muy capaz en su primer día, alguien que ha leído todos los libros de programación que existen pero nunca ha publicado nada en producción.

Eso no es cinismo. Es calibración. El código generado por IA suele ser bueno. Pero necesita a una persona revisora con el escepticismo adecuado.

La pregunta nunca es "¿esto parece correcto?". Siempre es "¿qué tendría que ser cierto para que esto falle?"

Averigua qué se le pidió a la IA

Antes de revisar el código, averigua qué prompt lo generó. No siempre es posible, pero cuando lo es, léelo con atención. Los prompts vagos producen código vago. Si el prompt fue "escribe una función de inicio de sesión", la IA no tenía ni idea de tu gestión de sesiones, de tus requisitos de limitación de solicitudes ni de tu estándar de hash de contraseñas. Todo lo que haya asumido es un posible hueco.

Agujeros de seguridad que buscar primero

Es en la seguridad donde el código de IA causa más daño. Los riesgos no son teóricos. Son concretos y siguen patrones previsibles.

Vulnerabilidades de inyección

La IA genera con frecuencia SQL, comandos de shell o HTML concatenando cadenas. Es una de las vulnerabilidades más antiguas del desarrollo de software, y la IA la reproduce constantemente porque gran parte de sus datos de entrenamiento hace lo mismo.

Qué buscar:

# Red flag: AI-generated SQL with string concatenation
query = "SELECT * FROM users WHERE name = '" + username + "'"

# What it should look like
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (username,))

Copiar prompt

Siempre que la entrada del usuario llegue a una consulta de base de datos, a un comando de shell, a una ruta de archivo o a una plantilla HTML sin sanitizar ni parametrizar, hay riesgo de inyección. Busca específicamente concatenaciones de cadenas que incluyan variables que puedan proceder de la entrada del usuario.

Secretos incrustados en el código

A veces la IA genera código de ejemplo con claves de API, contraseñas o tokens directamente en el código fuente. Peor aún, a veces genera credenciales de aspecto realista pero falsas que los desarrolladores dejan porque piensan reemplazarlas más tarde y luego no lo hacen.

Ejecuta un escáner de secretos antes de fusionar cualquier código generado por IA. Herramientas como truffleHog, detect-secrets o gitleaks detectan esto automáticamente. Añádelas a tu pipeline de CI y trátalas como bloqueantes.

Cualquier credencial en el código fuente es una credencial filtrada, sea real o un marcador de posición que alguien olvidó reemplazar.

Dependencias inseguras

La IA puede sugerir paquetes desactualizados, sin mantenimiento o con CVE conocidos. No puede consultar los registros de paquetes para buscar vulnerabilidades. No sabe qué versión de una biblioteca recibió un parche de seguridad crítico el mes pasado.

Después de revisar el código generado por IA, ejecuta tus herramientas de auditoría de dependencias:

• npm audit para proyectos de Node.js
• pip-audit o safety para Python
• bundle-audit para Ruby

Cualquier dependencia que introduzca la salida de la IA debe verificarse frente a las bases de datos de vulnerabilidades actuales antes de fusionarla.

Comprobaciones de lógica y corrección

La seguridad acapara los titulares, pero los errores de lógica son los que más veces hacen fallar el código de IA. Estos errores compilan, pasan las pruebas y superan la revisión de código. Solo aparecen en condiciones concretas que la IA nunca consideró.

Casos límite que la IA omitió

La IA genera código para el camino feliz. Maneja la entrada descrita en el prompt. No maneja:

• Colecciones vacías o referencias nulas
• Entradas exactamente en el límite de un rango válido
• Llamadas concurrentes a la misma función
• Tiempos de espera de red o respuestas parciales
• Escenarios de disco lleno o agotamiento de memoria

Para cada función que revises, pregúntate: ¿qué pasa si la entrada más importante es nula? ¿Qué pasa si se llama a esta función con una lista vacía? ¿Qué pasa si la llamada de red devuelve un 200 con el cuerpo vacío?

Si la IA no respondió a estas preguntas en el código, tienes que añadir tú mismo el tratamiento o devolverlo para que lo revise.

Manejo de errores que no hace nada

A la IA le encanta generar bloques try-catch. El problema está en lo que mete dentro. Las capturas silenciosas abundan. Registrar console.log(err) y seguir como si nada hubiera pasado es habitual. Relanzar un error genérico cuando quien llama necesitaba uno específico es casi universal.

Cada manejador de excepciones en código de IA merece un examen individual:

• ¿Maneja de verdad el error o solo lo oculta?
• ¿El código que llama sabe que algo salió mal?
• ¿Se registra el error de forma que se pueda encontrar después?
• ¿La aplicación queda en un estado coherente tras ejecutarse este bloque catch?

Errores de límites y de desfase en una posición

En los límites de los bucles, la IA se equivoca con más frecuencia que las personas. El código de IA suele usar < donde hace falta <=, itera un elemento más allá del final de un array o empieza un rango en 1 cuando debería empezar en 0. Estos errores son invisibles en pruebas pequeñas y catastróficos al procesar datos reales a escala.

Para cualquier bucle o rango en código generado por IA, recorre manualmente la primera iteración, la última y un caso sin elementos.

Herramientas que aceleran tu revisión

La revisión manual es necesaria pero no suficiente. Las herramientas automatizadas detectan clases de problemas que las personas pasan por alto bajo presión de tiempo, y lo hacen de forma constante.

Análisis estático y linters

El análisis estático es tu primera línea de defensa. Se ejecuta antes de que cualquier persona mire el código y detecta automáticamente lo más evidente.

Herramientas recomendadas por lenguaje:

Configura estas herramientas para que se ejecuten automáticamente en cada pull request. Ningún código generado por IA que no supere el análisis estático debería pasar a la revisión humana.

Revisión de código asistida por IA

Aquí hay una ironía interesante: la IA también es una de las mejores herramientas para revisar código generado por IA. Un modelo distinto, que revise el código con un prompt centrado en la seguridad, detectará patrones que el primer modelo generó de forma incorrecta. Funciona porque los dos modelos se entrenaron de manera diferente y tienen puntos ciegos distintos.

Pasar la salida de la IA por otro revisor de IA no sustituye la revisión humana. Es un filtro que hace la revisión humana más rápida y más centrada.

Usa modelos de lenguaje (LLM) en PicassoIA para revisar código

Los modelos de lenguaje de gran tamaño de PicassoIA están diseñados para exactamente este tipo de trabajo de razonamiento. Puedes pegar un fragmento de código, darle un prompt centrado en la revisión y obtener un análisis estructurado en segundos, sin cambiar de herramienta ni gestionar claves de API.

Cómo usar GPT 5 para revisar código

GPT 5 es uno de los modelos más capaces para analizar código. Su fortaleza es el contexto amplio: puede mantener en memoria una función grande, identificar varios problemas que interactúan y explicar cada uno con claridad.

Paso a paso:

1. Abre GPT 5 en PicassoIA
2. Pega la función o el módulo generado por IA que quieres revisar
3. Usa esta estructura de prompt:

Review this code for: (1) security vulnerabilities, (2) unhandled edge cases,
(3) error handling issues, (4) logic errors. For each issue found, explain
the risk and suggest a specific fix. Reference line numbers or variable names.

Copiar prompt

4. Revisa el resultado con espíritu crítico. No aceptes las sugerencias a ciegas.
5. Pega el código revisado y pídele que vuelva a verificar los problemas concretos que señaló.

GPT 5.1 también está disponible para flujos de trabajo basados en agentes, si quieres automatizar canalizaciones de revisión de varios pasos.

Claude 4.5 Sonnet para auditorías de seguridad

Claude 4.5 Sonnet destaca especialmente al identificar problemas de seguridad sutiles. Mientras GPT tiende a la amplitud, Claude sobresale en profundidad en escenarios de seguridad concretos.

Para una revisión centrada en la seguridad, Claude 4.5 Sonnet es especialmente eficaz con prompts que le piden razonar paso a paso sobre un modelo de amenazas. Algo como: "Supón que un atacante controla el parámetro username. Traza cada camino que recorre ese parámetro por este código e identifica dónde podría explotarse."

Claude 4 Sonnet y Claude Opus 4.7 también están disponibles en PicassoIA para tareas de revisión más exigentes o bases de código más largas que requieren un razonamiento más profundo.

DeepSeek R1 para razonamiento profundo

DeepSeek R1 usa razonamiento en cadena de pensamiento, lo que lo hace especialmente bueno para seguir la lógica a través de rutas de código complejas. Si tienes una función con varias ramas, condicionales anidados o gestión de estado intrincada, DeepSeek R1 razonará cada rama de forma explícita en lugar de resumir a alto nivel.

DeepSeek V3.1 y Kimi K2 Instruct completan las opciones para quien quiera pasar el mismo código por varios modelos y comparar hallazgos. Lo que hay que corregir es la coincidencia entre lo que señala cada modelo. Las discrepancias merecen examen manual.

Pasar el mismo código generado por IA por dos o tres LLM distintos es uno de los pasos de revisión con mejor retorno que puedes dar. Lleva cinco minutos y detecta lo que se le escapa a una sola persona revisora.

Construye tu flujo de revisión

Un buen proceso de revisión no se improvisa cada vez. Es una lista de comprobación repetible que se convierte en hábito.

La lista de comprobación que puedes reutilizar

Aquí tienes una lista de comprobación resumida para código generado por IA. Úsala siempre, sin saltarte fases.

Fase 1: Antes de leer

• ¿Sé qué prompt generó este código?
• ¿He ejecutado las herramientas de análisis estático?
• ¿He ejecutado un escáner de secretos?
• ¿He comprobado las dependencias nuevas frente a las bases de datos de vulnerabilidades?

Fase 2: Seguridad

• ¿Hay concatenación de cadenas con entrada del usuario que llegue a SQL, shell o HTML?
• ¿Hay credenciales, tokens o claves de API en el código fuente?
• ¿Hay llamadas de red que no validen ni sanitizen las respuestas?
• ¿Hay operaciones con archivos que usen rutas controladas por el usuario?
• ¿Hay alguna función que omita comprobaciones de autenticación o autorización?

Fase 3: Lógica

• ¿Qué pasa con entradas nulas o vacías?
• ¿Qué pasa en los valores límite (0, -1, máximo)?
• ¿Los manejadores de excepciones gestionan los errores o los ocultan?
• ¿Son correctos los límites de los bucles? Recorre manualmente la primera y la última iteración.
• ¿Tiene esta función supuestos ocultos sobre el orden de llamadas o el estado?

Fase 4: Pruebas

• ¿Las pruebas existentes cubren las nuevas rutas de código?
• ¿Hay pruebas para los casos límite identificados arriba?
• ¿Las pruebas cubren las rutas de fallo, no solo el camino feliz?

Cuándo rechazar frente a cuándo iterar

No todo código de IA merece una revisión. Algo de él debería rechazarse directamente.

Rechaza cuando:

• Las vulnerabilidades de seguridad son estructurales, no superficiales (por ejemplo, todo el enfoque de autenticación está mal planteado)
• La lógica no coincide con el requisito de negocio y el desfase es demasiado profundo para parchearlo
• El código introduce un patrón de arquitectura que entra en conflicto con las convenciones existentes

Itera cuando:

• Los problemas se limitan a funciones o bloques concretos
• La estructura es correcta pero faltan casos límite puntuales
• El manejo de errores es insuficiente, pero la lógica central es sólida

El objetivo no es corregir el código de IA hasta que pase la revisión. El objetivo es publicar código seguro y correcto. A veces el camino más eficiente es reescribirlo desde cero con mejores prompts.

Pruébalo en PicassoIA

Si este artículo te ha hecho pensar en cómo los modelos de IA razonan sobre el código, lo mejor es probarlo tú mismo. PicassoIA te da acceso a GPT 5, Claude 4.5 Sonnet, DeepSeek R1, Kimi K2 Instruct, Gemini 3 Pro y decenas de otros modelos, todos en un solo lugar y sin ninguna configuración.

Toma un fragmento de código generado por IA que ya tengas. Pásalo por dos o tres modelos distintos usando los prompts de revisión de este artículo. Compara lo que encuentra cada uno. Verás enseguida cómo distintos estilos de razonamiento detectan problemas diferentes y tendrás una imagen más clara de tus lagunas reales en la revisión.

Los modelos disponibles en PicassoIA no sirven solo para escribir código. Sirven para razonar sobre él, auditarlo y hacerlo más seguro. Ese es el ciclo que hace que el desarrollo asistido por IA funcione de verdad: generar con un modelo, revisar con otro y publicar con confianza.