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

Un prototipo asistido por IA de Lovable, Cursor, Claude Code, Replit u otra herramienta puede llegar rápido a una demo, pero la preparación para producción depende de usuarios, datos, exposición, arquitectura y evidencia. La brecha entre "funciona en mi pantalla" y "cumple requisitos definidos de calidad, seguridad y operación" debe verificarse, no inferirse por cómo se creó el código. Este es un proceso de QA basado en riesgo para builds asistidos por IA antes del lanzamiento.

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é puede fallar el código generado por IA en producción?

Un asistente de código solo dispone de los requisitos y el contexto que se le facilitan. Su salida puede contener patrones inseguros, dependencias inventadas o supuestos que no coinciden con el sistema desplegado. El código humano puede tener las mismas clases de defecto. Trata el código generado como no fiable hasta revisar arquitectura, dependencias, flujos de datos y comportamiento frente a requisitos explícitos.

El riesgo depende de la aplicación y su exposición. Usa un modelo de amenazas y un estándar de verificación en vez de asumir que el código generado es inseguro o que una demo exitosa demuestra preparación.

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

Estas son áreas de revisión comunes, no un ranking medido de defectos para todos los builds asistidos por IA. Adáptalas al sistema y al riesgo objetivo.

• Autenticación y autorización. Prueba límites de objeto, función, propiedad y tenant en código fiable de servidor. Un login funcional no demuestra que el usuario A no acceda a datos del usuario B.
• Manejo de entradas y salidas. Define tipos, longitudes, formatos, codificaciones, valores permitidos y rechazo en cada límite de confianza. La sanitización depende del contexto y no sustituye universalmente a la validación y las API seguras.
• Credenciales y configuración sensible. Revisa fuente, historial, artefactos, logs y bundles de cliente. Revoca o rota credenciales expuestas y mueve operaciones privilegiadas detrás de límites fiables.
• Condiciones excepcionales. Prueba timeouts, fallos parciales, reintentos, resultados vacíos, respuestas malformadas, agotamiento de recursos y recuperación sin filtrar detalles sensibles.
• Rendimiento y límites de recursos. Perfila volúmenes y concurrencia representativos. Busca lecturas sin límite, consultas repetidas, límites ausentes y trabajo costoso activado por entradas no fiables.
• Concurrencia y replay. Prueba solicitudes duplicadas y paralelas para operaciones que cambian estado, y aplica comportamiento transaccional o idempotente cuando lo exija la regla de negocio.
• Dependencias e integridad del build. Inventaría componentes directos y transitivos, comprueba identidad y procedencia cuando sea viable, versiones soportadas, avisos y obligaciones de licencia.
• Reconciliación de estado. Confirma que el estado visible siga al backend autoritativo y que las operaciones asíncronas o fallidas puedan reconciliarse.

"El generador no es el límite de garantía. Define el objetivo, inspecciona el sistema, reproduce hallazgos materiales y conserva evidencia de que los controles funcionan."

La checklist de production-readiness para builds asistidos por IA

Esta es la estructura de una primera pasada de Wavect, revisada el 2 de septiembre de 2026. No es un plan completo para todo sistema. Selecciona controles según arquitectura, exposición, modelo de amenazas, regulación y nivel de servicio.

1. Auditoría de autorización. Para cada operación protegida y ruta de datos, confirma que un límite fiable de servidor o serverless comprueba al actor y la acción. Los checks de cliente ayudan a la experiencia, pero no son una frontera de seguridad.
2. Test de límites de entrada. Prueba entradas malformadas, sobredimensionadas, hostiles e inesperadas en puntos relevantes. Confirma rechazo o manejo seguro.
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 de fallos. Simula fallos externos materiales y confirma reintentos, fallback, mensajes, logging y recuperación definidos.
5. Revisión de carga y consultas. Perfila cargas y volúmenes representativos. Limita lecturas y corrige consultas repetidas o inesperadamente costosas.
6. Test de concurrencia. Dispara requests paralelos y duplicados contra todo lo que escribe dinero o estado. Añade idempotencia donde falte.
7. Revisión de dependencias y licencias. Usa inventario y avisos automáticos y después revisa hallazgos relevantes, procedencia, soporte y obligaciones. Un scanner no demuestra que toda dependencia sea segura o compatible.
8. Evidencia de regresión. Añade pruebas automáticas y manuales proporcionales para comportamiento crítico, de modo que los cambios se comparen con una línea base. El desarrollo guiado por tests es una forma de estructurar expectativas ejecutables.

Si quieres que la IA ayude a crear y mantener esas pruebas de regresión, necesita un límite de garantía separado. Nuestra guía piloto de testing agéntico frente a automatización explica qué tareas puede asumir un agente, qué aserciones deben seguir siendo deterministas y cómo medir 30 días.

Este es el núcleo de nuestro servicio de QA de software. Los entregables dependen del alcance y pueden incluir hallazgos, evidencia reproducida, arreglos, pruebas, controles de despliegue y notas de riesgo residual. Ninguna revisión demuestra que no existan defectos.

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

En parte. Las herramientas de IA pueden proponer pruebas y arreglos, buscar en un repositorio y razonar sobre contexto de arquitectura o incidencias. También pueden perder alcance, introducir regresiones, usar conocimiento obsoleto o validar sus propios supuestos. Mantén un límite de garantía independiente: las personas responden por requisitos y aceptación del riesgo; los hallazgos y parches generados requieren pruebas reproducibles y revisión. Para un paso estrecho de discovery, nuestra review de Cisco Antares sobre localización local por CWE explica por qué sus archivos candidatos aún necesitan un especialista.

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

No existe una duración universal defendible. El alcance depende de arquitectura objetivo, calidad de código y pruebas, datos, exposición, integraciones, despliegue, regulación, pruebas especializadas, acceso al repositorio y profundidad de remediación. Empieza con una revisión acotada, declara sus límites y estima el refuerzo tras recopilar evidencia.

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

Compara remediación y reemplazo cuando los defectos son sistémicos, la arquitectura no cumple requisitos, hay dependencias sin soporte o domina el riesgo de migración. Reconstruir no es automáticamente más barato: añade riesgo de paridad funcional, migración, corte, formación y nuevos defectos. Registra supuestos, opciones, aceptación, rollback y riesgo residual antes de decidir.

Fuentes primarias del enfoque de verificación

Estas fuentes respaldan desarrollo y verificación seguros basados en riesgo. No establecen tasas de defectos del código generado por IA ni certifican una aplicación concreta.

• NIST Secure Software Development Framework 1.1
• NIST IR 8397, estándares mínimos de verificación de software
• OWASP Application Security Verification Standard 5.0.0
• OWASP Top 10:2025
• OWASP Secure Coding with AI Cheat Sheet