Por qué el código generado por IA necesita revisión humana (y por qué no pasa nada)

El desarrollo de software vive un cambio brutal. Herramientas como Claude o ChatGPT te llevan de una idea a código ejecutable en días, no en semanas. Describes la función, aceptas cambios, ajustas y lanzas. Esto acelera todo de verdad.

Pero hay un pero.

Revisé hace poco un código hecho así: una herramienta interna simple, no crítica, pero típica de cómo muchos enviamos código en 2024. No encontré locuras tipo "IA rebelde". Lo preocupante eran 28 fallos distintos, casi todos de seguridad, y la mayoría de vulnerabilidades clásicas del OWASP Top 10 desde hace 20 años.

No se trata de que la IA sea un peligro. Es que la velocidad para crear funciones supera el pensamiento estructural que evita problemas futuros.

El fallo no está en la IA, sino en la pregunta que no hiciste

El código era sólido. Arquitectura lógica. Componentes bien divididos. Librerías adecuadas. Si lo hubiera escrito yo un fin de semana, parecería igual a primera vista.

El problema está en lo que pasa antes de programar.

La IA brilla cumpliendo órdenes. Le pides un sistema de gestión de usuarios y te lo da. Pero no pregunta lo esencial: ¿quién accede? ¿Qué datos son sensibles? ¿Dónde va la autenticación? ¿Y si alguien salta el frontend?

Genera funciones. No diseña la seguridad que te deja dormir tranquilo.

Ejemplo real: la función admin sin protección

Imagina una función serverless para tareas admin: crear usuarios, resetear contraseñas, borrar cuentas. Básico. El equipo acertó guardando credenciales potentes en el servidor, sin exponerlas al navegador.

Pero la función no tenía ni un chequeo de autenticación.

Cero. Ni flojo ni equivocado. Nada. Cualquiera abría DevTools, veía la URL del endpoint y enviaba un POST para crear admins, resetear passwords o vaciar la base de datos.

El frontend tenía un control perfecto que ocultaba el botón admin a no-admins. Parecía seguro. Pero era humo: la seguridad por interfaz de usuario no existe.

Es un bypass de autorización clásico, en las listas desde 2003. ¿Por qué la IA no lo vio? El prompt fue "crea una función para que admins creen usuarios". Lo hizo. Y dejó que no-admins lo usaran porque no le dijiste que no.

Lección clave: la IA ignora lo que olvidas pedir.

La base de datos segura... en teoría

Otro caso común. Tu database usa row-level security (RLS) para limitar filas por usuario. Ideal si el frontend envía API keys en JavaScript.

Un dev pide a la IA soporte multiusuario. Ella escribe migraciones con tablas nuevas y RLS activado. Bien.

Pero las cinco tablas existentes, con tus datos reales, se quedaron intactas. ¿Tenían RLS? La migración no miró, no activó nada, no avisó.

Ejecutas npm run db:push en un entorno nuevo y las tablas legacy quedan abiertas a quien sepa la URL de tu API.

La IA no falló. Fue incompleta. Resolvió lo pedido (RLS en tablas auth nuevas) sin cuestionar lo obvio (¿quieres proteger todo?).

Cómo cambiar tu forma de trabajar

No renuncies a la IA. La velocidad cuenta. Iterar rápido y lanzar vale oro. Pero exige revisiones de ingenieros con experiencia, enfocadas en arquitectura, no solo sintaxis.

Lo que funciona:

Crea una checklist de seguridad antes de empezar. Preguntas como: ¿quién llama este endpoint? ¿Qué pasa si lo llaman sin permiso? ¿Es este dato público? ¿Todas las tablas necesitan RLS? Documéntalas como supuestos.

Deja threat modeling a seniors, no revisiones línea por línea. Mis 28 fallos eran fallos estructurales, no errores tontos. IA para generar código. Humanos para pensar en riesgos.

Especifica auth en prompts. No digas "crea endpoint de usuarios". Prueba "crea endpoint de usuarios solo para admin logueado, y explica tus supuestos de autenticación". Así sacas su razonamiento.

Prueba autorizaciones por separado. Tests que confirmen que no-autenticados no pueden hacer nada, no solo que autenticados pueden.

El patrón que debes pillar

La IA no genera código inseguro. Cumple al pie de la letra lo que pides, pero pasa por alto lo no mencionado.

Eso es una virtud: responde a tus prompts sin inventar. Pero la responsabilidad es tuya. No contratas IA para diseñar seguridad. La usas para ejecutar tus diseños a lo grande.

En mi revisión, bastó un humano diciendo "este endpoint necesita auth". Arreglarlo tomó minutos. Una vulnerabilidad de 20 años contra flujos de 2024. Ganó el flujo, gracias a ojos expertos.

Modelo ideal para los próximos años: IA para velocidad, humanos para arquitectura. Los dos son clave.

¿Quieres esquivar estos errores en tu código? En NameOcean, ayudamos a startups que crecen rápido y acumulan deuda técnica por envíos veloces. Nuestro hosting en la nube incluye seguridad estructural de base: rate limiting, gestión de API keys y audit logging automáticos. Funcionan siempre, preguntes o no. Una preocupación menos al shippear a toda máquina.