El código sale a producción más rápido de lo que cualquiera puede revisarlo.
Hace un año eso sonaba a queja de un tech lead con burnout. Hoy es una medición. La actividad de code review cayó del 25% a menos del 10% conforme creció la adopción de IA. La gente revisa menos el código que escribe la IA que el que solía escribir a mano. No es una opinión cultural — el 41% del código en producción fue generado por herramientas de IA (Wikipedia / reportes de industria, 2026), y el 92% de los desarrolladores en EE.UU. usa asistentes de IA a diario (JetBrains / Test-Lab, 2026).
El resultado era predecible. El 45% del código generado por IA falla tests de seguridad básicos (Veracode, 2026). Sherlock Forensics escaneó codebases generados por IA entre enero y abril 2026: 92% tenía al menos una vulnerabilidad crítica. Promedio: 8.3 hallazgos explotables por app.
Construí el Protocolo QA Nativo de IA para cerrar ese hueco. No por miedo a las herramientas (las uso todos los días). Porque la capa de verificación que necesitaban no existía. Así funciona, fase por fase, y dónde traza la línea.
Fase 1: Construir el Mapa
Lo primero no es análisis. Es orientación.
Clonar el repo. Identificar qué ya existe: suites de tests (casi nunca), pipelines de CI (a veces), documentación (rara vez), bugs reportados. La mayoría de los proyectos construidos con IA no tienen un documento de requerimientos. El código ES la especificación, y nadie escribió qué se supone que debe hacer.
Entonces lo extraemos. Del código, del README si existe, de la documentación del producto, de una llamada de 30 minutos con el equipo. Después construimos un inventario de componentes: cada componente visual, cada servicio de back-end, cada punto de integración, catalogado y etiquetado.
Del inventario, definimos happy paths y golden paths. No solo flujos de UI. Validaciones de base de datos. Puntos de integración de APIs. Los caminos que los usuarios reales toman por el sistema y los caminos que mantienen los datos correctos.
Después construimos el artefacto que hace medible todo lo que sigue: la matriz de trazabilidad. Componentes mapeados a paths mapeados a targets de cobertura. Este es el denominador. Sin él, "mejoramos la cobertura" es una frase sin número. Con él, cada iteración mueve el numerador.
Lo que sale de la Fase 1: un plan de análisis con alcance definido, un inventario de componentes, una matriz de trazabilidad, y benchmarks de cobertura por contexto. El proyecto no ha corrido un solo scanner todavía. Es intencional. Análisis estático sin contexto es ruido. Produce hallazgos sin priorización. El inventario convierte el codebase en un mapa con regiones etiquetadas antes de que cualquier otra cosa lo toque.
Algo que aprendí corriendo esto en proyectos reales: el inventario de componentes casi siempre saca a la luz puntos de integración que el equipo olvidó que había construido. Un callback de auth a un servicio externo. Un endpoint de webhook agregado hace tres meses y nunca testeado. Aparecen porque el inventario no depende de la memoria del equipo sobre lo que lanzaron a producción.
Fase 2: Análisis con Agentes Personalizados por Proyecto
Acá es donde el Protocolo deja de parecer "correr una herramienta" y empieza a parecer ingeniería.
Construimos agentes de IA personalizados por contexto de proyecto. No son scanners genéricos. Cada agente pasa por su propio ciclo de desarrollo: diseñado para el stack y los patrones del proyecto, construido con prompt engineering basado en investigación, testeado contra hallazgos conocidos, y validado antes de revisar una sola línea de código del cliente.
Conozco la objeción obvia: IA analizando código generado por IA crea riesgo de falla correlacionada. Misma familia de modelos, mismos puntos ciegos, mismas distribuciones de probabilidad. Exactamente por eso los agentes no son genéricos. Están diseñados con el contexto específico del proyecto: su stack, su dominio, sus criterios de aceptación de la Fase 1. Y pasan por su propio ciclo de QA. La investigación y validación ocurren antes del primer pase de análisis, no después.
Los agentes corren contra los criterios de aceptación mapeados en la Fase 1 y producen:
- Un reporte estructurado en formato SARIF con hallazgos etiquetados por severidad (Critical / High / Medium / Low / Info), cada uno mapeado a archivo y rango de líneas con rating de confianza y fix recomendado
- Screening de seguridad OWASP Top 10 en el mismo pase: gaps de autenticación, secrets expuestos, paths de inyección (SQL, XSS, log injection), defaults inseguros, rate limiting faltante, credenciales hardcodeadas
- Un reporte Markdown legible que unifica hallazgos de calidad y seguridad
- Un prompt de fix — un prompt estructurado que el equipo de dev le da a Cursor o Claude Code para aplicar fixes de forma autónoma
Ese último artefacto importa más de lo que la gente espera. El Protocolo no solo encuentra problemas. Le da al tooling de IA del equipo un camino estructurado para arreglarlos. El análisis encuentra causas raíz; el prompt de fix las traduce en instrucciones que las mismas herramientas que escribieron el código pueden ejecutar.
Lo que los datos muestran, proyecto tras proyecto: el análisis estático saca a la superficie ~4x más hallazgos de los que el equipo conocía antes del proceso. Las mismas categorías se repiten en código generado por IA (bugs de state management, gaps de auth, error handling faltante, defaults inseguros) sin importar la app ni el stack. Equipos que habían reportado bugs manualmente estaban persiguiendo síntomas. El análisis encuentra estructura.
Seguridad no es un engagement separado. Es el mismo pase. Las categorías de OWASP donde el código generado por IA falla más seguido se analizan por default porque no hay razón para separarlas. Una API key hardcodeada y un null check faltante están en el mismo reporte, ambos con severidad etiquetada, ambos en el prompt de fix.
Fase 3: Tests Que Evolucionan con el Código
Una auditoría puntual es un snapshot (una foto en el tiempo). Si el equipo lanza cada semana, el snapshot ya está viejo el viernes.
La Fase 3 construye una capa de tests que se mueve con el codebase. Cuando la lógica del código cambia (nuevo PR, nuevo feature, refactor) la capa de tests lo detecta. Desarrollamos test cases al nivel donde cada nuevo enhancement o release también verifica los paths a través del código.
El ciclo: un PR llega. El análisis identifica qué cambió. Los test cases se actualizan para cubrir nuevos paths. El siguiente PR se beneficia de la cobertura expandida. Cada iteración atrapa cosas que la anterior no pudo, porque el análisis tiene más contexto sobre cómo evoluciona el codebase.
Muchos equipos AI-native pushean directo a main. Cero disciplina de PRs. El Protocolo se adapta. El enhancement recursivo se dispara con pushes a main en vez de PRs. Menos granular, pero el loop no se rompe. Ofrecemos educación sobre PR workflows como parte del proceso. No lo requerimos.
La cobertura se mide contra los benchmarks de la matriz de trazabilidad. La métrica depende del contexto del proyecto. Proyectos pesados en UI miden cobertura de UI paths contra benchmarks. Proyectos pesados en endpoints miden cobertura de API. Proyectos pesados en base de datos miden cobertura de validación de datos. Cobertura es un número con un denominador de la Fase 1, no un sentimiento.
Acá es donde QA se vuelve preventivo en vez de reactivo. La brecha entre "código lanzado" y "código verificado" se achica con cada iteración en vez de crecer.
Fase 4: Automatización Permanente
Todo antes de esta fase podría depender de que nosotros lo corramos. La Fase 4 elimina esa dependencia.
Playwright cubre testing de flujos UI, suites de regresión, y verificación de paths críticos. Corre contra cada build candidato y cubre los paths más relevantes según el inventario de componentes de la Fase 1. El Protocolo no incluye testing manual. Playwright lo reemplaza por completo.
Cloudflare Workers manejan el monitoreo de back-end:
- Health checks programados para endpoints
- Monitoreo de salud de base de datos
- Testing automatizado de endpoints disparado por deploy o por schedule
- Validación determinística de datos. Checks de formato y disponibilidad — si un agregador falla, el Worker pide un retry de la sección fallida automáticamente.
- Puntuación de calidad de datos con IA. Una segunda capa puntúa la calidad de datos a través de múltiples dimensiones de validación. Output JSON estructurado le dice al agente exactamente de dónde viene cada puntuación. Esto no es "¿está up el endpoint?" Es "¿los datos son correctos y completos?"
- Un ciclo de retroalimentación en producción: Workers en producción detectan issues que alimentan de vuelta el ciclo de test enhancement recursivo de la Fase 3. Bugs que llegan a producción no solo se arreglan. Expanden el límite de cobertura del Protocolo para el siguiente ciclo.
Integración CI une todo. El análisis estático corre en cada PR (o push a main). Screening de seguridad en cada push. Las suites de tests se ejecutan automáticamente. Los hallazgos aparecen en la herramienta de project management que el equipo ya use. Linear, Jira, GitHub Issues, da igual.
Contract e integration testing previenen que cambios rompan servicios cruzados: ¿el servicio A sigue mandando lo que el servicio B espera después del deploy de hoy? Contract tests de API corren en el pipeline de CI. Los puntos de integración marcados durante el inventario de componentes en la Fase 1 quedan cubiertos por checks de contrato automatizados.
Para paths específicos de mobile: Playwright cubre flujos web e híbridos. Testing en device cloud (BrowserStack, AWS Device Farm) maneja paths nativos específicos: comportamiento por versión de OS, rendering por dispositivo, breakpoints responsivos. Paths que necesitan testing hardware-específico (Bluetooth, NFC, cámara, delivery de push notifications) se marcan durante el inventario de componentes y se documentan como responsabilidad del equipo. Ese límite es visible antes de que empiece el proceso.
La condición de salida de la Fase 4 no es "encontramos los bugs." Es "el sistema los sigue encontrando sin nosotros." Todo lo que se despliega en esta fase corre aunque Academ-ia no esté involucrado. El equipo es dueño de la infraestructura.
El Límite
Esta es la sección que hace creíble al Protocolo. Cualquier metodología que dice cubrirlo todo te está vendiendo humo.
El Protocolo es dueño de la infraestructura de verificación, el sistema que atrapa problemas. El equipo es dueño del código de producción y las decisiones de producción, qué sale y cuándo.
El Protocolo cubre:
- Inventario de componentes y matriz de trazabilidad
- Análisis estático con agentes personalizados (construidos, testeados, validados por proyecto)
- Screening de seguridad (pase superficial OWASP Top 10)
- Test enhancement recursivo (tests evolucionan con cada PR o push)
- Automatización UI (Playwright), automatización de endpoints (Workers), integración CI
- Validación de datos (determinística + puntuación IA)
- Monitoreo de salud de base de datos
- Contract e integration testing
- Prompts de fix que el equipo puede ejecutar
- Benchmarks de cobertura por contexto de proyecto
- Educación de PR workflow (o fallback push-to-main)
- Integración device cloud para paths mobile donde aplique
- Dashboards y reporting en la herramienta existente del equipo
- Ciclo de retroalimentación en producción: issues que llegan a producción expanden la cobertura del Protocolo para el siguiente ciclo
El equipo es dueño de:
- Aplicar los fixes. El Protocolo encuentra y prescribe; el equipo o su IA ejecuta
- Decisiones de deployment a producción. El Protocolo da señales de release, no autoridad de release
- Corrección de la lógica de negocio. El Protocolo verifica código contra requerimientos. Si los requerimientos están mal, los tests pasan y el producto sigue mal
- Testing exploratorio y edge cases fuera del inventario de componentes. El inventario cubre componentes conocidos; los unknown unknowns son territorio del equipo
- Test data más allá de lo que cubren las bases de datos personalizadas (cuentas sandbox de terceros, data seeding tipo producción para escenarios que el Protocolo no ha mapeado)
- Paths mobile nativos no cubribles por Playwright o device cloud: Bluetooth, NFC, cámara, comportamiento hardware-específico
El límite se define durante la Fase 1. Es visible desde el día uno. Y se mueve. El ciclo de retroalimentación en producción significa que cuando un bug llega a producción, puedes trazar si estaba dentro del límite de cobertura del Protocolo o fuera. Si estaba fuera, el siguiente ciclo expande el límite para incluirlo. La superficie de cobertura crece con cada iteración.
No garantizo cero bugs en producción. Ningún proceso lo hace, y quien diga lo contrario te está mintiendo. Lo que garantizo es que el límite entre "cubierto" y "no cubierto" es visible, medible, y se acumula.
Por Qué el Patrón Se Sostiene
La misma secuencia (inventario, agentes personalizados, testing recursivo, automatización) produce los mismos resultados si el equipo son cuatro personas o treinta, si el codebase es React Native o una API en Python, si el 20% o el 90% del código lo escribió una IA. Funciona porque trata QA como un sistema de ingeniería con un límite visible, no como un checkbox que alguien marca antes de un release.
La brecha de QA en el vibe coding no es un problema de herramientas. Las herramientas existen. Playwright, Workers, SARIF, agentes personalizados. Es un problema de orquestación. Correr esas herramientas dentro de un proceso de ingeniería con cobertura medible y un límite claro es lo que faltaba.
Describí cada fase con suficiente detalle para que un ingeniero senior pueda construir una versión propia. El valor del Protocolo no está en el secreto. Está en el efecto compuesto de correrlo. La matriz de trazabilidad se enriquece. Los agentes se afinan. El límite de cobertura se amplía. El primer pase encuentra mucho. El cuarto pase encuentra cosas que el primero no podía.
Si estás construyendo con herramientas de IA y lanzando a producción sin un proceso de QA, empieza por el inventario de componentes. Solo saber qué construiste, cada componente, cada punto de integración, cada path que los usuarios realmente toman, es el paso con más palanca. Todo lo demás se construye sobre ese mapa.
Preguntas Frecuentes
¿Qué es el Protocolo QA Nativo de IA?
Una metodología de QA en cuatro fases para codebases construidos con herramientas de IA. Empieza con un inventario de componentes y una matriz de trazabilidad, corre análisis estático a través de agentes personalizados, construye una capa de tests recursiva que evoluciona con cada PR, y despliega automatización permanente (Playwright, Cloudflare Workers, CI) que corre sin involucramiento continuo. El límite entre lo que cubre el Protocolo y lo que cubre el equipo se define desde el día uno.
¿Cómo se hace QA en aplicaciones vibe-coded?
Mapear cada componente primero: visual, back-end, e integración. Construir una matriz de trazabilidad. Correr análisis estático con alcance definido usando agentes personalizados por proyecto. Construir test cases que evolucionan con cada cambio de código. Automatizar UI paths, validación de endpoints, checks de calidad de datos, y contract tests. Medir cobertura contra benchmarks por contexto.
¿Funciona el análisis estático en código generado por IA?
El código generado por IA sigue patrones que el análisis estático atrapa bien: bugs de state management, gaps de auth, error handling faltante, defaults inseguros. Agentes personalizados construidos por contexto de proyecto sacan a la superficie ~4x más hallazgos de los que el equipo conocía. Los agentes pasan por su propio ciclo de desarrollo antes de revisar código.
¿Qué problemas de seguridad tiene el código generado por IA?
Las categorías OWASP que más se repiten: gaps de autenticación, secrets expuestos, paths de inyección (SQL, XSS, log injection), defaults inseguros, rate limiting faltante, credenciales hardcodeadas. El 45% del código generado por IA falla tests de seguridad básicos (Veracode, 2026). El 92% de los codebases generados por IA tiene al menos una vulnerabilidad crítica (Sherlock Forensics, ene–abr 2026). El Protocolo los analiza en el mismo pase que el análisis de calidad.
¿Puede la automatización de QA seguir el ritmo del desarrollo asistido por IA?
Sí — cuando la capa de tests evoluciona con el código. Suites de tests estáticas se degradan cuando equipos asistidos por IA lanzan rápido. Test enhancement recursivo (donde análisis y generación de tests corren en cada PR o push) significa que la cobertura se acumula en vez de erosionarse. La cobertura se mide contra una matriz de trazabilidad, no se asume.
¿Cuál es la diferencia entre herramientas de QA con IA y el Protocolo QA Nativo de IA?
Herramientas como Mabl, CodeRabbit, o QA Wolf generan tests o hacen code review. El Protocolo orquesta cuándo y cómo esas capacidades corren a lo largo del ciclo completo de release: inventario de componentes, análisis con agentes personalizados, testing recursivo, automatización permanente, y ciclo de retroalimentación en producción. La herramienta no es el problema; correr la herramienta dentro de un proceso de ingeniería sí lo es.
¿Qué NO cubre el Protocolo QA Nativo de IA?
El Protocolo construye infraestructura de verificación. El equipo es dueño del código de producción, las decisiones de deployment, la corrección de la lógica de negocio, y el testing exploratorio fuera del inventario de componentes. Paths mobile hardware-específicos (Bluetooth, NFC, cámara) se documentan como responsabilidad del equipo durante el inventario. El límite es visible y medible desde el día uno, y se expande con cada ciclo conforme el ciclo de retroalimentación en producción agrega cobertura.