Revisar código generado por IA: apps hechas con Cursor

Cursor facilita producir rápidamente mucho código que parece funcionar. Esa velocidad es el objetivo, y también el problema: puede acabar siendo dueño de una base de código que nadie, usted incluido, ha leído línea por línea. Antes de que lleguen usuarios reales, alguien tiene que hacerlo. Esta guía muestra cómo revisar código generado por IA para que su app hecha con Cursor esté realmente lista para producción, y por dónde empezar si quiere una primera lectura rápida de su situación con el AI App Health Check gratuito.

Por qué el código de Cursor necesita su propia revisión

Cursor es un editor de código asistido por IA. No aloja su app, así que, a diferencia de un constructor alojado, no hay ninguna plataforma que decida cómo funcionan su base de datos, su autenticación o su despliegue. Su código está en un repositorio que usted mismo despliega, lo que le da control total y responsabilidad total. Nada está oculto, pero nada se comprueba por usted.

El código generado por IA tiende a fallar de formas reconocibles. Es localmente plausible pero globalmente incoherente: cada archivo parece correcto, mientras que la misma regla se implementa de tres maneras distintas a lo largo del proyecto. Las cuestiones transversales, como la autorización, la validación y la gestión de errores, son las primeras que faltan, porque ningún prompt concreto las pidió. Para el ángulo de la seguridad en particular, consulte nuestro artículo sobre los riesgos de seguridad del vibe coding antes del lanzamiento. Este artículo trata del código en sí.

Paso 1: automatice primero las comprobaciones baratas

No dedique atención humana a lo que una máquina puede comprobar en segundos. Configure esto una vez y ejecútelo en cada cambio.

Comprobaciones de tipos y linting

Active la comprobación estricta de tipos (por ejemplo, el modo estricto de TypeScript) y un linter. El código de IA a menudo recurre a tipos laxos, variables sin usar y errores ignorados en silencio. Un compilador estricto convierte muchos de ellos en fallos visibles. Corrija los errores en lugar de silenciarlos con comentarios de ignorar, y cuente cuántas supresiones existen ya: un número elevado es una señal en sí mismo.

Comprobaciones de dependencias y licencias

Ejecute el comando de auditoría de su gestor de paquetes y revise el resultado. Después lea la lista de dependencias con ojo escéptico: los paquetes que sugirió el modelo pueden estar abandonados, ser imitaciones con el nombre mal escrito o simplemente innecesarios. Compruebe que cada uno exista, esté mantenido y tenga una licencia compatible con la forma en que piensa vender el producto. Elimine lo que no use.

Escaneo de secretos, incluido el historial

Escanee los archivos actuales y todo el historial de git en busca de claves de API, tokens y cadenas de conexión. Una clave borrada en un commit posterior sigue estando en el historial, así que rote todo lo que se haya subido alguna vez en lugar de limitarse a quitarlo. Añada un escaneo de secretos en pre-commit o en CI para que no vuelva a ocurrir.

Un pipeline de CI que condicione las fusiones

Incorpore las comprobaciones anteriores, además de sus pruebas y una compilación de producción, a la integración continua, y bloquee la fusión cuando fallen. Es la salvaguarda más útil para el trabajo asistido por IA, porque hace que el estándar sea independiente del prompt que produjo el cambio.

Paso 2: qué necesita un revisor humano

La automatización detecta los problemas mecánicos. Esto requiere criterio.

Arquitectura y fronteras

Dibuje el mapa: ¿por dónde entran los datos, dónde se almacenan, dónde se conectan los servicios de terceros? Busque lógica de negocio enterrada en componentes de interfaz, llamadas a la base de datos dispersas por los archivos y código exclusivo del servidor que podría acabar en el bundle del navegador. Si no puede describir la estructura en un párrafo, las nuevas funcionalidades seguirán chocando entre sí. Nuestra introducción a la arquitectura de software explica el vocabulario.

Código muerto y duplicado

Iterar con un asistente de IA deja restos: archivos abandonados, tres versiones de la misma función auxiliar y rutas antiguas que siguen respondiendo. El código muerto no es inofensivo. Los endpoints olvidados siguen siendo accesibles, y los duplicados se van separando, de modo que un arreglo en una copia nunca llega a las demás. Elimine lo que no se use y consolide lo duplicado antes de añadir nada nuevo.

Autorización en cada ruta

Haga una lista de cada ruta, manejador de API y acción de servidor, y para cada una anote quién puede llamarla y cómo lo hace cumplir el código. Iniciar sesión no es lo mismo que tener permiso. El fallo clásico es un manejador que acepta el ID de un registro y lo devuelve sin comprobar que el registro pertenece a quien llama. Si su capa de datos usa reglas a nivel de fila, lea los errores habituales de RLS de Supabase en apps creadas con IA.

Validación de entradas e inyección

Todo lo que llega del exterior, como campos de formulario, cadenas de consulta, archivos subidos, webhooks y la salida de un modelo, no es de confianza. Compruebe que se valida en el servidor, no solo en el navegador, y que las consultas a la base de datos están parametrizadas en lugar de construirse concatenando cadenas. Si su app pasa texto de usuarios a un LLM o muestra la salida del modelo como HTML, trate eso también como entrada no fiable.

Gestión de errores y logs

Busque bloques catch vacíos, errores tragados para que la pantalla parezca estar bien, y respuestas que filtran trazas de pila o mensajes internos. Producción necesita errores que se capturen, se muestren a los usuarios con palabras sencillas y se registren en algún lugar que realmente vaya a mirar. Sin eso, la primera señal de un problema es el correo de un cliente.

Pruebas que prueban de verdad el comportamiento

Las herramientas de IA escriben pruebas con entusiasmo, y no todas valen mucho. Desconfíe de las pruebas que simulan (mock) justo aquello que dicen probar, de las aserciones que no pueden fallar y de los snapshots aceptados sin leerlos. Una comprobación rápida: rompa una regla a propósito, por ejemplo quitando una comprobación de autorización, y vea si alguna prueba se pone en rojo. Si ninguna lo hace, las pruebas son decoración. Escriba pruebas de comportamiento para el inicio de sesión, los permisos, los pagos y todo lo que modifique datos.

Archivos de reglas y deriva de los prompts

Muchos proyectos de Cursor incluyen reglas del proyecto o archivos de instrucciones que guían al asistente. Léalos. Acumulan instrucciones contradictorias, convenciones obsoletas y, a veces, datos sensibles que no deberían estar en un repositorio. Si las reglas dicen una cosa y el código hace otra, el código generado en el futuro seguirá las reglas, así que manténgalas breves, actualizadas y coherentes con cómo está construido realmente el proyecto.

Lista de comprobación para revisar código generado por IA

Úsela como una lista de aprobado o suspendido. Todo lo que no pueda confirmar cuenta como suspendido.

• El proyecto se compila desde un checkout limpio con pasos documentados.
• La comprobación estricta de tipos y el linting pasan sin supresiones generalizadas.
• Auditoría de dependencias revisada; paquetes sin uso y sin mantenimiento eliminados; licencias comprobadas.
• Sin secretos en los archivos actuales ni en el historial de git; claves filtradas rotadas.
• Cada ruta y acción de servidor tiene una regla de acceso declarada y aplicada.
• Toda entrada externa se valida en el servidor; las consultas están parametrizadas.
• Los errores se gestionan, se registran y nunca exponen detalles internos a los usuarios.
• Las pruebas cubren permisos, pagos y cambios de datos, y fallan cuando el comportamiento se rompe.
• El código muerto y los duplicados se han eliminado; la estructura se puede explicar de forma sencilla.
• Los archivos de reglas y los prompts están actualizados y no contienen secretos.
• La CI ejecuta las comprobaciones y la compilación, y un despliegue puede revertirse.

Para una visión más amplia del lanzamiento, que incluye cuentas, pagos y operaciones, combínela con nuestra lista para dejar una app lista para producción.

Un camino de rescate paso a paso

Si la revisión descubre más de lo que puede corregir en un fin de semana, hágalo en este orden para que cada paso haga más seguro el siguiente.

1. Congele las funcionalidades. Deje de generar código nuevo hasta que se hayan comprobado los cimientos.
2. Haga una instantánea y proteja. Etiquete el estado actual, traslade el repositorio a una ubicación privada que usted controle y rote los secretos expuestos.
3. Active las barreras automáticas. Tipos, linting, auditoría, escaneo de secretos y CI, corrigiendo los fallos a medida que aparezcan.
4. Mapee y priorice. Haga una lista de rutas, almacenes de datos e integraciones, y ordene los riesgos empezando por lo que podría dañar a los usuarios o al dinero.
5. Corrija la autorización y la validación. Son los cambios con las consecuencias más graves.
6. Añada pruebas de comportamiento en torno a lo que acaba de corregir, para que se mantenga corregido.
7. Limpie. Elimine el código muerto y los duplicados, y actualice los archivos de reglas.
8. Staging y luego lanzamiento. Despliegue en un entorno de staging, pruebe los flujos reales, añada monitorización y tenga lista una reversión.

¿No sabe si está en el paso 1 o en el 8? Nuestro artículo sobre cuándo dejar de usar prompts y contratar a un ingeniero le ayuda a decidirlo.

Dónde encaja UnlockLive

No necesita entregar su proyecto para beneficiarse de la lectura de un experto. Nuestra auditoría técnica de apps con IA (AI App Technical Audit) le ofrece una revisión independiente de la arquitectura, las rutas de código relevantes para la seguridad, las dependencias y las pruebas, con una lista priorizada de qué corregir. Si prefiere que lo corrijamos nosotros, AI App Repair & Launch abarca el trabajo de reparación, refuerzo y despliegue para que la app pueda salir a producción con confianza. Nuestros ingenieros trabajan desde Toronto y desde nuestro centro de ingeniería en Dhaka, y trabajamos con gusto junto a Cursor, no contra él. Si no sabe qué tipo de revisión necesita, consulte auditoría técnica, prueba de penetración y revisión de código.

Su siguiente paso

Empiece por las comprobaciones baratas: active los tipos estrictos, ejecute la auditoría y escanee su historial en busca de secretos. Después ejecute el AI App Health Check gratuito para ver qué áreas necesitan atención primero. Ninguna herramienta puede prometer que el código sea impecable, pero una revisión medida y repetible le dirá mucho más que el simple hecho de que la app funcione en su portátil.