Cómo revisar código generado por IA antes de publicarlo
Una lista práctica para revisar código de Cursor, Claude Code o Copilot antes de publicarlo: alcance, seguridad, datos, dependencias, pruebas y herramientas.
Read in English →
Para revisar código generado por IA antes de publicarlo, lee los cambios y no el resumen del agente, confirma que solo cambió lo que pediste, pruébalo tú y después busca los errores que más cometen estas herramientas: claves secretas en el código del navegador, permisos que no se comprueban en el servidor, cambios peligrosos en la base de datos, paquetes que no deberían estar, errores que se tragan en silencio y pruebas debilitadas para que pasen. Las herramientas de revisión automática ayudan como segunda mirada, no como la única.
Esta guía te da una lista que puedes seguir aunque no programes, te dice dónde mirar en cada punto y repasa las herramientas de revisión de GitHub, Cursor y Claude Code.
¿Por qué no puedo confiar en el resumen del agente?
El resumen cuenta lo que el agente quiso hacer. Los cambios muestran lo que hizo. Difieren más de lo que imaginas: un agente puede decir que las pruebas pasan sin haberlas corrido, nombrar un archivo cuando cambió seis o describir un arreglo que solo cubre el caso que le mostraste. Usa el resumen como índice y los cambios como el texto.
¿Cómo leo los cambios si no soy desarrollador?
Empieza por la lista de archivos modificados, no por las líneas. En GitHub, abre el pull request y entra en Files changed; en Cursor, revisa los cambios del agente archivo por archivo antes de aceptarlos.
Algunos nombres de archivo deberían hacerte ir más despacio siempre:
.envo cualquier archivo consecret,keyoconfigen el nombre- Migraciones de base de datos (
supabase/migrations/…,prisma/migrations/…) package.jsony los archivos de bloqueo (dependencias nuevas)- Todo lo que tenga
auth,middleware,policy,admin,paymentowebhooken la ruta - Archivos de prueba borrados
Si un pedido como "cambia el color del botón" tocó alguno de estos, pídele al agente que explique por qué antes de seguir leyendo.
¿Qué reviso, paso a paso?
1. El alcance
¿El cambio hace lo que pediste, y solo eso? Las reorganizaciones que nadie pidió, los archivos renombrados y los "ya que estaba, limpié esto" son donde se esconden los errores nuevos. Pídelos como tareas aparte.
2. ¿Funciona?
Baja la rama, levanta la app y haz aquello para lo que era el cambio. Después haz una o dos cosas que no tienen que ver, como iniciar sesión y abrir la pantalla principal. Corre tú la compilación y las pruebas.
3. Seguridad
- Nada de claves secretas en el código del frontend. Todo lo que llega al navegador es público. En apps con Vite solo llegan al navegador las variables que empiezan con
VITE_, así que unVITE_STRIPE_SECRET_KEYes una alarma. - Los permisos se comprueban en el servidor o en la base de datos, no solo escondiendo un botón.
- Las tablas nuevas tienen reglas de acceso. En Supabase eso significa Row Level Security activado y con políticas; mira Row Level Security de Supabase en Lovable y Bolt.
- Lo que escribe el usuario y termina en una consulta, una ruta de archivo o un prompt de IA se valida.
4. Cambios en los datos
Lee cada migración. Busca DROP, DELETE, TRUNCATE, columnas renombradas y columnas obligatorias nuevas sin valor por defecto. Cualquiera de estas puede romper o borrar datos existentes. Deben correr primero en una base de pruebas.
5. Dependencias
A veces las herramientas de IA sugieren paquetes viejos, innecesarios o que directamente no existen, y hay atacantes que registraron nombres que los modelos suelen inventar. Por cada paquete nuevo, abre su página en npm: ¿existe, se mantiene, lo usa mucha gente y de verdad lo necesitas? Ejecuta npm audit para ver vulnerabilidades conocidas.
6. Manejo de errores
Busca en los cambios bloques catch vacíos y errores que solo se imprimen en la consola. Cuando algo falla, el usuario debería ver un mensaje y tú deberías poder averiguar por qué.
7. Pruebas
¿Se agregaron pruebas para lo nuevo? ¿Se borró, se saltó (.skip, .only) o se aflojó alguna para que pase? Una prueba que cambia en el mismo commit que el código que prueba merece una mirada atenta.
8. Duplicados
¿Escribió una función que ya existía en otro lado? Los duplicados son la forma en que dos partes de la app empiezan a aplicar la misma regla de maneras distintas.
¿Qué herramientas de revisión me ayudan?
| Herramienta | Qué hace | Dónde |
|---|---|---|
| Copilot code review | Revisa pull requests y deja comentarios | GitHub, en los planes de Copilot que la incluyen |
| Cursor Bugbot | Revisa pull requests en busca de errores y problemas de seguridad; toma contexto del proyecto de .cursor/BUGBOT.md | GitHub y GitLab, de forma automática o con un comentario cursor review |
/code-review de Claude Code | Revisa tus cambios locales o una rama, y puede aplicar arreglos | En una sesión de Claude Code |
| Secret scanning de GitHub | Avisa o bloquea los push que contienen formatos de claves conocidos | Configuración de seguridad del repositorio |
npm audit | Lista dependencias con vulnerabilidades conocidas | Tu terminal o la integración continua |
Un truco más: abre una sesión nueva, pega el pedido original y los cambios, y pide una revisión crítica. Un contexto nuevo no está atado a las decisiones que tomó la primera sesión.
¿Cuándo hace falta que revise una persona?
Cuando el cambio toca dinero, inicio de sesión, permisos o datos personales, o cuando no puedes explicar en una frase qué hace. Ahí es donde un error silencioso cuesta más. El OWASP Top 10 es la lista de referencia de riesgos de seguridad web que usa cualquier revisor, y nuestro checklist de seguridad para apps hechas con IA la baja a comprobaciones concretas.
Respuestas rápidas
¿Cuánto debería durar una revisión? Si pasa de quince o veinte minutos, el cambio seguramente es demasiado grande. Pide tareas más chicas.
¿Una IA puede revisar el código de otra? Sí, y encuentra problemas reales, pero ambas pueden tener los mismos puntos ciegos. Úsala además de probar el código tú.
¿Cuál es la comprobación más importante? Ejecutarlo. Una cantidad sorprendente de cambios hechos con IA falla al primer clic.
¿También reviso los cambios de Lovable o Bolt? Sí, si el código se sincroniza con GitHub. Cada commit ahí es un cambio que puedes leer igual.
¿Quieres una revisión profesional?
Si la app está por recibir usuarios reales o pagos, una revisión externa es un seguro barato. En nuestras páginas de ayuda con proyectos de Cursor y de proyectos de Devin Desktop y Windsurf explicamos cómo revisamos código hecho con agentes, empezando por un informe escrito. Combínalo con pruebas para código generado con IA, pasa la app por la revisión gratuita o escríbenos.
