QA para Código Generado por IA: Qué Se Rompe Antes del Lanzamiento y Cómo Detectarlo

Un prototipo de IA hecho con Lovable, Cursor, Claude Code o Replit te lleva a una demo funcional en un fin de semana. No te lleva a producción. La brecha entre "funciona en mi pantalla" y "sobrevive a usuarios reales, carga real y una revisión de seguridad" es justo donde el código generado por IA falla en silencio. Este es el proceso de QA que aplicamos a los builds asistidos por IA antes de que salgan a producción, y los modos de fallo que más vemos.

Nada de esto es un argumento contra construir con IA. Nosotros también construimos con ella. Es un argumento a favor de testear el resultado igual que testearías cualquier código que está a punto de tocar dinero real, datos reales y usuarios reales.

Por qué se rompe el código generado por IA en producción?

Las herramientas de coding con IA optimizan una sola cosa: producir algo que corre y que encaja con el prompt. No optimizan las cosas que deciden si el software sobrevive al contacto con usuarios. El modelo no tiene visión de tu threat model, tus volúmenes de datos, tus edge cases ni tus obligaciones de compliance. Escribe bien el happy path y se salta casi todo lo demás, porque nadie lo pidió.

El resultado es código que demuestra limpio y se rompe de forma predecible. Las roturas no son aleatorias. Se agrupan en los mismos sitios cada vez, y eso es justo lo que las hace testeables.

Qué se rompe realmente en el código generado por IA?

Esta es la lista que recorremos en cada build asistido por IA, ordenada por la frecuencia con que muerde.

• Huecos de autenticación y autorización. La pantalla de login funciona. La comprobación que impide que el usuario A lea los datos del usuario B falta o se aplica solo en el frontend. Es el defecto grave que más encontramos, con diferencia.
• Entradas que nunca se validan. Los formularios aceptan cualquier cosa. Sin límites de longitud, sin checks de tipo, sin sanitización. Los datos de la demo eran limpios, así que el hueco nunca se vio.
• Secrets en el sitio equivocado. API keys, URLs de base de datos y tokens hardcodeados en código de cliente o commiteados al repo. Las herramientas de IA los pegan inline porque así corre el ejemplo.
• Sin manejo de errores. El happy path está cubierto. Una llamada de red fallida, un timeout o un resultado vacío lanza una excepción no manejada y la pantalla se queda en blanco.
• Queries que no escalan. Código que mete una llamada a base de datos dentro de un render, o que trae una tabla entera para contar filas. Bien con 10 registros, fatal con 100.000.
• Race conditions y dobles envíos. Dos clics crean dos pedidos. Dos requests en paralelo pasan ambos un check de saldo y ambos retiran.
• Dependencias que nadie revisó. El modelo mete paquetes desactualizados, abandonados o con vulnerabilidades conocidas.
• Estado que miente. La UI dice que el pago salió bien; el backend nunca lo registró. Updates optimistas sin reconciliación.

"La IA no escribe código inseguro a propósito. Escribe el código que pediste y nada de lo que olvidaste pedir. Producción es la suma de todo lo que olvidaste pedir."

La checklist de production-readiness para builds asistidos por IA

Esta es la estructura de una revisión de Wavect. Puedes hacer una primera pasada tú mismo antes de llamar a nadie.

1. Auditoría de autorización. Para cada endpoint y cada lectura de datos, confirma que el servidor comprueba quién pregunta y si tiene permiso. Los checks de frontend no cuentan.
2. Test de límites de entrada. Lanza entradas malformadas, sobredimensionadas y hostiles a cada punto de entrada. Confirma que se rechazan limpio, no que se absorben.
3. Barrido de secrets. Escanea el repo y el bundle de cliente buscando keys, tokens y credenciales. Rota lo que se haya filtrado y muévelo al servidor.
4. Cobertura del camino de fallo. Fuerza el fallo de cada llamada externa y confirma que la app degrada con elegancia en vez de caerse.
5. Revisión de carga y queries. Perfila la base de datos con volúmenes de datos realistas. Mata las queries N+1 y las lecturas sin límite antes de que te maten a ti.
6. Test de concurrencia. Dispara requests paralelos y duplicados contra todo lo que escribe dinero o estado. Añade idempotencia donde falte.
7. Escaneo de dependencias y licencias. Revisa cada paquete por vulnerabilidades conocidas y licencias incompatibles.
8. Suite de regresión. Escribe los tests que el prototipo nunca tuvo, para que el siguiente cambio asistido por IA no rompa en silencio lo que ya funciona. Mira desarrollo guiado por tests para entender por qué esto importa más, no menos, cuando la IA escribe el código.

Este es el núcleo de nuestro servicio de QA de software. El entregable no es un PDF de quejas. Es una base de código arreglada y testeada, y la suite de tests que la mantiene arreglada.

Puedo simplemente pedirle a la IA que arregle su propio código?

En parte. Una herramienta de IA añadirá con gusto un check de validación o envolverá una llamada en manejo de errores en cuanto le señales el sitio. Lo que no puede hacer es decidir dónde mirar. No tiene un modelo de tu deuda técnica, ni memoria del orden en que se construyeron las cosas, ni instinto para el edge case que un usuario real toca el segundo día. Encontrar los huecos es trabajo humano. Cerrarlos es, cada vez más, trabajo compartido. Así es exactamente como llevamos estos engagements.

Cuánto se tarda en dejar listo para producción el código generado por IA?

Para un MVP vibe-coded típico, una pasada enfocada de revisión y hardening lleva de una a tres semanas. La variación la marcan dos cosas: cuánto dinero real o datos sensibles toca el producto, y hasta dónde corrió la IA sin supervisión. Un prototipo de fin de semana que maneja pagos y datos personales necesita más de un fin de semana de QA. Una herramienta interna de solo lectura necesita mucho menos. Lo dimensionamos tras un primer vistazo, no antes.

Cuándo el código no tiene salvación?

Pocas veces, pero pasa. Si el modelo de datos está fundamentalmente mal, o el mismo patrón roto está copiado en cien archivos, reconstruir el núcleo es más barato que parchearlo. Te lo decimos en la primera llamada en vez de cobrarte un mes por parchear un cimiento que hay que volver a verter. La honestidad aquí es más barata para todos.