--- title: "QA para Código Generado por IA" canonical: https://wavect.io/es/blog/qa-for-ai-generated-code/ language: es description: "Qué se rompe en código generado por IA de Lovable, Cursor, Claude Code y Replit antes del lanzamiento, y la checklist de production-readiness de Wavect." image: "https://wavect.io/img/blog/headers/header_qa-for-ai-generated-code.png" --- [**Volver**](/es/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/es/team/christof-jori/) [Christof Jori](/es/team/christof-jori/) https://linkedin.com/company/wavect 8 min de lectura · 08 Jun 2026 [**Siguiente**](/es/blog/why-ai-agent-projects-get-cancelled/) # QA para Código Generado por IA: Qué Se Rompe Antes del Lanzamiento y Cómo Detectarlo Resumen El código generado por IA escribe bien el happy path y se rompe en los mismos sitios cada vez: huecos de autorización, entradas sin validar, secrets en el cliente, queries que no escalan y race conditions. Eso es justo lo que lo hace testeable. Este es el proceso de QA que aplicamos a builds asistidos por IA antes de producción; una pasada de hardening lleva de una a tres semanas según cuánto dinero o datos sensibles toca. Servicio relacionado: [Vibe Coding Rescue](/es/services/vibe-coding-rescue/) 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. ![Christof Jori](/img/team/christof.webp) "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](/es/glossary/tdd/) 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](/es/services/software-quality-assurance/). 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](/es/glossary/technical-debt/), 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. Para un paso estrecho de discovery, nuestra [review de Cisco Antares sobre localización local por CWE](/es/blog/cisco-antares-local-vulnerability-localization/) explica por qué sus archivos candidatos todavía necesitan un especialista. ## 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. ## Reflexiones finales El código generado por IA no es peor código. Es código sin revisar. El prototipo que llevó un fin de semana se saltó las mismas semanas de hardening que necesita todo sistema en producción, y la factura de esas semanas no desaparece porque un modelo escribiera el primer borrador. Solo se mueve al día del lanzamiento, cuando es más cara. Recorre la checklist antes de poner usuarios reales delante de un build asistido por IA. Si las secciones de autorización, entradas y caminos de fallo te ponen nervioso, esa es la señal para conseguir un segundo par de ojos antes del lanzamiento, no después del incidente. ## También te puede gustar.. [**Benchmark de QA externa: los primeros 30 días** Qué respalda la investigación de defectos, qué métricas son comparables y por qué no existe una cuota universal honesta.](/es/blog/external-qa-benchmark-first-30-days/) [**Wavect vs Dotbite** Una comparación justa de dos estudios de software austriacos, y cuál encaja en un build de IA liderado por founders frente a un proyecto de software a medida en Viena.](/es/compare/wavect-vs-dotbite/) QA y preparación para producción ## Continúa por este clúster - [Benchmark de QA externa: qué encontramos en los primeros 30 días](/es/blog/external-qa-benchmark-first-30-days/) - [Cuánto Cuesta Mantener Software Después del Launch: Benchmark SaaS DACH](/es/blog/software-maintenance-cost-benchmark-dach-saas/) - [Desingeniería ágil](/es/blog/agile-de-engineering/) - [Due diligence de apps Lovable, Bolt y Replit](/es/blog/lovable-bolt-replit-app-due-diligence/) - [La checklist de production-readiness para vibe-code](/es/blog/vibe-code-production-readiness-checklist/) Tu bandeja, sin ruido ## Sigue el trabajo que te importa Recibe un correo breve cuando publiquemos algo nuevo. Sigue todo el blog o solo los temas que te interesan. [**Volver**](/es/blog/overview/) [![Christof Jori](/img/team/christof.webp)](/es/team/christof-jori/) [Christof Jori](/es/team/christof-jori/) https://linkedin.com/company/wavect 8 min de lectura · 08 Jun 2026 [**Siguiente**](/es/blog/why-ai-agent-projects-get-cancelled/) Nuevos artículos por correo × × Recibe nuevos artículos por correo Un correo breve cuando publicamos. Gratis y sin seguimiento. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/es/blog/qa-for-ai-generated-code/#webpage", "@type": "WebPage", "dateModified": "2026-07-07", "inLanguage": "es", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-07", "url": "https://wavect.io/es/blog/qa-for-ai-generated-code/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "El código generado por IA escribe bien el happy path y se rompe en los mismos sitios cada vez: huecos de autorización, entradas sin validar, secrets en el cliente, queries que no escalan y race conditions. Eso es justo lo que lo hace testeable. Este es el proceso de QA que aplicamos a builds asistidos por IA antes de producción; una pasada de hardening lleva de una a tres semanas según cuánto dinero o datos sensibles toca.", "articleBody": " Resumen del blog/Entrega y QA/QA y preparación para producción QA para Código Generado por IA: Qué Se Rompe Antes del Lanzamiento y Cómo Detectarlo Resumen El código generado por IA escribe bien el happy path y se rompe en los mismos sitios cada vez: huecos de autorización, entradas sin validar, secrets en el cliente, queries que no escalan y race conditions. Eso es justo lo que lo hace testeable. Este es el proceso de QA que aplicamos a builds asistidos por IA antes de producción; una pasada de hardening lleva de una a tres semanas según cuánto dinero o datos sensibles toca. Servicio relacionado: Vibe Coding Rescue 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. 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. 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. 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. Cobertura del camino de fallo. Fuerza el fallo de cada llamada externa y confirma que la app degrada con elegancia en vez de caerse. 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. Test de concurrencia. Dispara requests paralelos y duplicados contra todo lo que escribe dinero o estado. Añade idempotencia donde falte. Escaneo de dependencias y licencias. Revisa cada paquete por vulnerabilidades conocidas y licencias incompatibles. Suite de regresión. Escribe los tests que el prototipo nunca tuvo, para que el siguiente cambio asistido", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/" }, "dateModified": "2026-07-07", "datePublished": "2026-06-08", "description": "El código generado por IA escribe bien el happy path y se rompe en los mismos sitios cada vez: huecos de autorización, entradas sin validar, secrets en el cliente, queries que no escalan y race conditions. Eso es justo lo que lo hace testeable. Este es el proceso de QA que aplicamos a builds asistidos por IA antes de producción; una pasada de hardening lleva de una a tres semanas según cuánto dinero o datos sensibles toca.", "headline": "QA para Código Generado por IA", "image": "https://wavect.io/img/blog/headers/header_qa-for-ai-generated-code.svg", "inLanguage": "es", "mainEntityOfPage": { "@id": "https://wavect.io/es/blog/qa-for-ai-generated-code/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/es/blog/qa-for-ai-generated-code/", "wordCount": 1590 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/es/", "name": "Inicio", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/overview/", "name": "Resumen del blog", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/topics/delivery-qa/", "name": "Entrega y QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/clusters/qa-production/", "name": "QA y preparación para producción", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/es/blog/qa-for-ai-generated-code/", "name": "QA para Código Generado por IA | ", "position": 5 } ] } ```