La adopción es alta, pero la métrica importa
La encuesta de Stack Overflow de 2025 encontró que el 84% de quienes respondieron usaba o planeaba usar herramientas de IA en su proceso de desarrollo; entre desarrolladores profesionales, el 51% declaró usarlas a diario. La pregunta cubre herramientas de IA en general: no prueba que ese porcentaje genere código, ni describe específicamente a equipos de QA.
Para mirar el otro lado del flujo, DeviQA publicó en julio de 2026 una encuesta propia a 300 profesionales QA, SDET y líderes de testing. El 52% dijo percibir un aumento de bugs desde que desarrollo empezó a usar IA y el 58% percibió más carga de pruebas. Es una señal relevante para investigar, no una estimación representativa del sector: es una muestra interna de proveedor, basada en respuestas y experiencias autoinformadas.
La encuesta de DeviQA pregunta por cambios que los participantes asocian temporalmente con la adopción de IA; no compara repositorios equivalentes con y sin IA, ni controla tamaño de cambios, experiencia, velocidad de entrega o política de revisión. También puede influir que ahora se detecten o reporten más defectos. Por eso no corresponde concluir que la IA, por sí sola, cause un aumento general de bugs.
DORA 2025 propone leer la IA como amplificador del sistema de trabajo existente: feedback rápido, plataformas internas y prioridades claras ayudan; procesos débiles y cambios difíciles de revisar también se amplifican. La investigación informa asociaciones, no una regla causal universal. El mensaje práctico es medir el flujo completo, no atribuir una variación a una sola herramienta.
Qué medir antes de cambiar el proceso
Registra durante varias iteraciones cuántos cambios se hacen y de qué tamaño; cuántos defectos aparecen antes y después de publicar; su gravedad; cuántas veces se reabre un caso; cuánto tarda QA en recibir y dar respuesta; y cuánto trabajo se repite. Separa los cambios hechos con ayuda de IA solo si el equipo puede identificarlos de forma consistente y sin vigilar a cada persona.
Compara los periodos con cuidado: usa las mismas definiciones, anota cambios del producto o del equipo, y revisa tanto lo que detectan las pruebas como las alertas que resultan ser falsas. Si se publican más cambios, puede aumentar el número total de defectos aunque cada cambio tenga menos. Comparar los defectos con el número y tamaño de los cambios ayuda a entender qué pasó.
Imagina que antes el equipo publicaba diez cambios por semana y encontraba cuatro defectos; después de incorporar un asistente publica veinte cambios y encuentra seis. El total subió, pero la tasa pasó de 0,4 a 0,3 defectos por cambio. Sin el denominador, el titular “hay más bugs” mezcla volumen de entrega con calidad por unidad. También puede subir la detección porque se agregaron pruebas, mejores logs o una revisión más intensa. En ese caso, ver más fallos puede revelar que el sistema observa mejor, no que el producto empeoró.
Conviene separar cuatro medidas: defectos encontrados antes de publicar; defectos que llegaron a producción; gravedad e impacto; y costo de investigarlos y corregirlos. Encontrar más problemas leves durante las pruebas no equivale a tener más incidentes para usuarios. A la inversa, una tasa estable puede ocultar un riesgo mayor si crece el número de cambios o si los fallos se concentran en pagos, permisos o datos. Decide qué vas a contar antes de comparar.
Qué añade revisar el código generado, además de ejecutar tests
Que todas las pruebas pasen no demuestra por sí solo que un cambio sea fácil de mantener, respete las reglas del proyecto o tenga pruebas suficientes. En una investigación de 2026, METR pidió a cuatro responsables de mantenimiento de tres proyectos que revisaran 296 cambios preparados por agentes y aprobados por una evaluación automática. En promedio, los responsables aceptaron menos cambios que el evaluador: la diferencia fue de 24 puntos porcentuales. La muestra fue acotada y los agentes no pudieron corregir sus propuestas tras recibir comentarios; el resultado sí deja clara una distinción: “las pruebas pasaron” y “el equipo está dispuesto a integrar el cambio” no significan lo mismo.
Por eso, además de comprobar que la función haga lo esperado, revisa si el cambio afecta otras funciones, cómo maneja errores, si respeta la seguridad y si las nuevas pruebas detectan el problema de verdad. Una prueba generada puede repetir el mismo error que tiene el código. Pide que cada prueba se relacione con un requisito y comprueba que falle cuando se quita la función que debía proteger.
Durante cuatro a seis semanas, registra una línea base con definiciones estables y selecciona cambios comparables por tamaño, riesgo y componente. Si el equipo usa IA, etiqueta el cambio de forma voluntaria y a nivel de trabajo, no de persona. Compara grupos o periodos cuando sea viable, anota cambios simultáneos —nueva cobertura, refactor, rotación de equipo— y normaliza por cambios, líneas modificadas o exposición. No uses un único porcentaje como objetivo: puede incentivar ocultar defectos o reducir cobertura.
Un tablero útil muestra cuántos defectos aparecen, qué gravedad tienen y en qué etapa se detectan; cuántos llegan a producción o se reabren; cuánto tarda el equipo en recibir una respuesta; y cuántas alertas automáticas confirma una persona. Conserva ejemplos para entender de dónde vienen los problemas. Si el equipo trabaja más rápido, pero llegan más defectos graves a producción o aumenta el trabajo repetido, el proceso no mejoró. Si detecta más antes de publicar y llegan menos a producción, quizá ahora esté encontrando mejor los problemas.
Una encuesta reciente sobre el trabajo que recibe QA
Una encuesta distinta de DeviQA, publicada en septiembre de 2026 y respondida por 4.000 profesionales de QA, ayuda a describir el otro extremo del flujo. El 65% dijo que las funciones llegan antes a testing; el 64% señaló que llegan más funciones al mismo tiempo; el 55% observó una cola de QA más larga; y el 52% informó más ciclos de prueba, corrección y repetición. Estas cifras no deben mezclarse con el sondeo anterior de 300 personas: son instrumentos, muestras y preguntas diferentes. Tampoco miden defectos por cambio ni prueban que la IA sea la causa. Sí muestran una tensión concreta que un equipo puede comprobar: implementar más rápido no elimina la revisión, la regresión ni la coordinación, y puede concentrar el trabajo que recibe QA.
La consecuencia práctica no es asignar más pruebas a ciegas. Conviene preguntar dónde se forma la cola: espera por ambiente, requisitos incompletos, revisión tardía, datos difíciles de preparar, fallos intermitentes o demasiadas alertas sin confirmar. Cada causa pide una respuesta distinta. Si el equipo no sabe cuándo llegará una entrega ni qué cambió, una segunda herramienta de IA puede sumar ruido; si conoce el diff, el riesgo y el resultado esperado, puede priorizar mejor. Mide el tiempo de espera separado del tiempo efectivo de prueba: así se distingue un problema de capacidad de un problema de flujo.
Un recuento absoluto responde cuántos defectos se encontraron; no indica por sí solo si cada cambio es peor. Supongamos que un equipo revisaba diez cambios y detectaba cuatro defectos, y luego revisa veinte y detecta seis. El total creció, pero bajó la tasa por cambio. Aun esa tasa puede engañar si los cambios nuevos son más grandes, tocan componentes distintos o reciben más cobertura. Usa varios denominadores según la decisión: cambios revisados para carga de triage, tamaño y riesgo para comparar exposición, ejecuciones para estabilidad, y usuarios o transacciones para estimar impacto. No conviertas líneas de código en una medida universal de calidad: sirven como contexto, no como sustituto del riesgo funcional.
También separa severidad, momento de detección y costo. Un defecto bloqueante detectado antes de liberar puede ser una señal de que las pruebas funcionan; uno menor en producción puede ser menos grave que una falla de permisos aunque ambos cuenten como “un bug”. Registra si el problema estaba en requisito, implementación, integración, datos o ambiente. Esta clasificación sirve para corregir el proceso y no culpar al autor ni a la herramienta. Conserva ejemplos representativos y revisa qué cambió entre periodos; una métrica sin una explicación del caso puede empujar al equipo a optimizar el número equivocado.
Cómo evaluar una herramienta con criterios para descartarla
Antes de sumar IA al ciclo, define una pregunta que admita una respuesta negativa: por ejemplo, “¿la propuesta de pruebas basada en historias reduce omisiones sin aumentar el tiempo de revisión?”. Elige un flujo acotado, fija una línea base y acuerda qué cuenta como omisión, duplicado, alerta válida y retrabajo. Compara varias iteraciones y cambios de riesgo parecido. Si es posible, alterna tareas o equipos; si no, deja anotados los cambios de cobertura, personal, release y herramientas que podrían explicar una diferencia. No atribuyas causalidad a una comparación antes/después si hubo otros cambios al mismo tiempo.
La prueba controlada también necesita una regla de parada. Si la herramienta no tiene contexto suficiente, usa datos reales sin autorización, modifica un entorno no aislado o produce resultados que nadie puede reproducir, debe detenerse y dejar la ejecución pendiente. La revisión humana se concentra en los riesgos relevantes, no en aceptar todo lo que genera el modelo. Al cierre, presenta resultados junto con límites de la muestra, falsos positivos, defectos escapados y costo del tiempo de revisión. Si los datos no permiten concluir, esa es una conclusión válida: el siguiente paso es mejorar la medición, no declarar éxito.
Una alerta automática es una observación que todavía debe clasificarse. Puede señalar un defecto nuevo, una regresión conocida, una diferencia visual sin impacto, un problema del ambiente o una prueba que ya no representa el comportamiento esperado. Si el tablero suma todo como “bugs”, la herramienta parecerá encontrar más problemas aunque gran parte sean duplicados o ruido. Conserva estados distintos para hallazgo recibido, revisado, reproducible, confirmado, duplicado y descartado; registra además el motivo del descarte. Así el equipo puede medir precisión y costo de triage sin ocultar una señal válida debajo de un promedio.
El análisis también debe mirar el tiempo. Una falla detectada en minutos no tiene el mismo costo que un reporte que aparece al final de una suite nocturna; una alerta correcta que nadie ve hasta después del release tampoco mejora la prevención. Anota cuánto tardó el sistema en informar, cuándo la revisó alguien y cuándo se cerró. Si aumenta el número bruto de alertas pero cae el porcentaje confirmado y crece el tiempo de revisión, el siguiente experimento debería mejorar selección y contexto, no generar todavía más casos. Si aumenta la detección temprana de defectos relevantes y baja el retrabajo posterior, hay una señal más sólida de utilidad.