Cómo revisar código generado por IA

Para revisar código generado por IA, empieza por lo que cambió —qué archivos y por qué—, y prueba tú el comportamiento antes de leer ninguna línea de código. Después, revisa las áreas donde el código de IA más suele fallar: falta de comprobaciones de permisos en el servidor, secretos expuestos al navegador, entradas sin validar, paquetes o funciones que no existen y ediciones de cosas que nunca le pediste tocar.

La IA escribe código que normalmente funciona y que a menudo se ve ordenado. Eso hace fácil aprobarlo sin comprobarlo de verdad. Esta guía es una rutina de revisión que funciona tanto si lees código con soltura como si no lo lees en absoluto.

Ajusta la revisión al riesgo

No todos los cambios necesitan la misma atención.

Paso 1: Mira qué cambió

Antes de juzgar el código, obtén la lista de cambios:

• Si el proyecto está en Git, mira el diff: los archivos y líneas que cambiaron desde el último commit. Consulta cómo usar Git con una app creada con IA.
• O pregúntale directamente a la IA:

Enumera todos los archivos que cambiaste en el último cambio, y para cada uno explica en una frase qué cambió y por qué.

Señales de alarma en este paso: archivos no relacionados con la petición, archivos borrados, cambios en la configuración o en dependencias que no pediste.

Paso 2: Prueba primero el comportamiento

Leer el código te dice qué se supone que hace; probarlo te dice qué hace de verdad. Antes de leer:

• Prueba el cambio como un usuario normal, en escritorio y en una pantalla del tamaño de un teléfono.
• Prueba con entradas incorrectas: campos vacíos, textos muy largos, números negativos, una fecha pasada.
• Pruébalo sin sesión iniciada y con otro usuario.
• Repite los flujos más importantes: registro, inicio de sesión, la acción principal, el pago.

Si la prueba falla, te has ahorrado tiempo de lectura: repórtalo con claridad y deja que la IA lo arregle. Consulta cómo escribir un buen reporte de error.

Paso 3: Comprueba los permisos en el servidor

Lo más importante de revisar. Las herramientas de IA suelen ocultar un botón en la página pero dejan que el servidor realice la acción para cualquiera que la pida.

Para cada ruta o función que lea o cambie datos, pregunta:

• ¿Comprueba que el usuario ha iniciado sesión?
• ¿Comprueba que este usuario tiene permiso para acceder a este registro?
• ¿Esa comprobación está en el servidor, no solo en la página?

Para cada ruta de API que añadiste o cambiaste, dime qué comprobación de permisos hace en el servidor, citando la línea. Marca cualquier ruta que no tenga una.

Después pruébalo: inicia sesión como usuario A, anota el ID de un registro, inicia sesión como usuario B y pide ese registro. La lista de comprobación de seguridad para apps creadas con IA tiene la prueba completa.

Paso 4: Busca secretos expuestos

• Busca en los archivos modificados cualquier cosa que parezca una clave o una contraseña.
• Comprueba que las claves secretas se leen de variables de entorno y solo se usan en código de servidor.
• Vigila los prefijos públicos como VITE_ o NEXT_PUBLIC_ en variables secretas: se incorporan al código que se envía al navegador.

Consulta cómo mantener seguras las claves de API.

Paso 5: Revisa las entradas y los errores

• Validación en el servidor. Las comprobaciones del navegador se pueden saltar. Los campos obligatorios, las longitudes, los formatos y los valores permitidos también deben comprobarse en el servidor.
• Las consultas a la base de datos usan parámetros, no texto construido uniendo lo que escribe el usuario en una consulta.
• Los errores no se tragan. Un try/catch que no hace nada oculta fallos. Los errores deben registrarse, y los usuarios deben ver un mensaje sencillo.
• No se muestran detalles internos a los usuarios: las trazas de error y los errores de base de datos pertenecen a los registros.

Paso 6: Comprueba que sea real

Los modelos de IA a veces producen código que parece correcto pero hace referencia a cosas que no existen.

• Paquetes: cada dependencia nueva debe ser un paquete real, mantenido y con ese nombre exacto. Desconfía de nombres que parecen erratas de paquetes populares.
• Funciones y opciones de API: si el código llama a una función de librería o a una opción de una API externa que no conoces, comprueba la documentación oficial.
• Código de relleno: busca TODO, mock, fake, datos de ejemplo escritos a mano o funciones que devuelven un valor fijo.

¿Añadiste paquetes nuevos? Para cada uno, dame el nombre exacto, para qué sirve y si podríamos prescindir de él.

Paso 7: Comprueba que encaja

El código puede funcionar y, aun así, dificultar cambiar la app más adelante:

• Duplicación. La misma lógica copiada en varios sitios se desincronizará.
• Coherencia. Debe seguir los patrones que ya usa el resto de la app.
• Tamaño. Una petición de 20 líneas que produjo 600 merece una pregunta.
• Código muerto. Versiones antiguas que quedaron junto a las nuevas.

¿Hay código en el proyecto que ahora no se use por este cambio, o lógica duplicada en otro lugar? No cambies nada; solo enuméralo.

Errores comunes

• Aprobar porque parece limpio. Un código pulcro puede seguir saltándose una comprobación de permisos.
• Leer en lugar de probar. Prueba primero; lee después.
• Probar solo el camino feliz. Prueba entradas malas, el usuario equivocado y sin sesión iniciada.
• Ignorar cambios de archivos no relacionados. Pregunta por qué cambió cada archivo.
• Confiar del todo en una autorrevisión. Usa la revisión de la IA como primera pasada y confírmala probando.
• Revisar una semana de cambios de una vez. Revisa los cambios pequeños a medida que ocurren.

Lista de comprobación

• Sé qué archivos cambiaron y por qué, y nada no relacionado cambió.
• El cambio funciona en escritorio y en teléfono, con entradas malas, sin sesión y con otro usuario.
• Cada ruta de datos comprueba en el servidor el inicio de sesión y la propiedad del registro.
• Ningún secreto en el código ni en los paquetes del navegador.
• Las entradas se validan en el servidor; las consultas usan parámetros.
• Los errores se registran, no se tragan, y no se muestran en detalle a los usuarios.
• Los paquetes nuevos son reales y necesarios; no quedan funciones inventadas ni código de relleno.
• Los cambios de alto riesgo tuvieron una lectura cuidadosa y, si hacía falta, una segunda persona revisora.

Revisar código en Mythex

• El modo Ask responde preguntas sobre el código sin editarlo; ideal para peticiones del tipo «explica cada cambio» y «qué rutas no tienen comprobación de permisos». Consulta Chat.
• La vista de código muestra el árbol de archivos, el editor y la terminal en todos los planes (solo lectura en Free, editable en Pro), así que puedes leer tú mismo lo que cambió. Consulta Editor de código.
• /test hace que el agente recorra la vista previa como un usuario y reporte los flujos rotos.
• Los puntos de control te permiten revertir un cambio que no pase la revisión.

Si un desarrollador revisa por ti, cómo trabajar con un desarrollador en una app creada con IA explica el traspaso; si la revisión saca a la luz un error, consulta cómo depurar una app creada con IA.

Preguntas