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ú mismo el comportamiento antes de leer cualquier línea de código. Después, revisa las zonas donde el código de IA más a menudo falla: 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 pediste tocar.

La IA escribe código que normalmente funciona y que a menudo se ve ordenado. Eso facilita aprobarlo sin comprobarlo de verdad. Esta guía es una rutina de revisión que sirve 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 pregunta directamente a la IA:

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

Señales de alarma en esta fase: 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. Antes de leer:

• Prueba el cambio como usuario normal, en escritorio y en una pantalla de tamaño de teléfono.
• Pruébalo con entradas incorrectas: campos vacíos, textos muy largos, números negativos, una fecha pasada.
• Pruébalo sin sesión iniciada y como otro usuario distinto.
• 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 informe de error.

Paso 3: Comprueba los permisos en el servidor

Lo más importante de revisar. Las herramientas de IA a menudo ocultan 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 lee o cambia 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 incluye 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 integran en el código que se ejecuta en el navegador.

Consulta cómo mantener seguras las claves de API.

Paso 5: Revisa entradas y 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 entradas del 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 claro.
• Ningún detalle interno mostrado a los usuarios: las trazas de error y los errores de base de datos pertenecen a los registros.

Paso 6: Comprueba que es real

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

• Paquetes: cada nueva dependencia debe ser un paquete real y mantenido con ese nombre exacto. Desconfía de nombres que parezcan erratas de otros populares.
• Funciones y opciones de API: si el código llama a una función de librería o a una opción de API externa que nunca has visto, consulta 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í hacer que la app sea más difícil de cambiar después:

• Duplicación. La misma lógica copiada en varios sitios acabará desincronizándose.
• Coherencia. Debe seguir los patrones que 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 algún código del proyecto que ahora no se use por este cambio, o lógica duplicada en otro sitio? No cambies nada; solo enuméralo.

Errores habituales

• Aprobar porque se ve limpio. Un código ordenado también puede saltarse una comprobación de permisos.
• Leer en lugar de probar. Prueba primero; lee después.
• Probar solo el camino feliz. Prueba entradas incorrectas, el usuario equivocado y la falta de sesión.
• Ignorar cambios en 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 confirma probando.
• Revisar una semana de cambios de golpe. 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 incorrectas, sin sesión y como otro usuario.
• Cada ruta de datos comprueba en el servidor el inicio de sesión y la propiedad del registro.
• No hay secretos 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 con 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 Preguntar responde preguntas sobre el código sin editarlo: ideal para peticiones como «explica cada cambio» o «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), para que leas tú mismo lo que cambió. Consulta Editor de código.
• /test hace que el agente pruebe la vista previa como un usuario y te informe de 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