La IA ya escribe su código. Los incidentes por pull request han subido un 242 %.
El código generado por IA supera a la revisión de código: incidentes por PR +242 %, bugs por desarrollador +54 %.Por qué las pruebas end-to-end son la barrera de calidad que escala.
10 min de lecturaPor el equipo de GUI Test Studio
Qué midió Faros AI
En abril de 2026, Faros AI publicó The AI Engineering Report 2026: The Acceleration Whiplash.No es una encuesta sobre cómo se sienten los desarrolladores.Recoge unos dos años de telemetría de 22 000 desarrolladores en más de 4000 equipos, y compara los periodos de menor y mayor adopción de la IA dentro de cada organización.
El primer hallazgo sitúa el contexto.En el 80 % de los equipos, más de la mitad de los desarrolladores usa herramientas de IA cada semana, y la proporción de código generado por IA que aceptan los desarrolladores pasó del 20 % al 60 %.
«La IA no está asistiendo a los desarrolladores. En la mayoría de las organizaciones, los está liderando.»
La buena noticia es real, y el informe lo dice.Con una alta adopción de la IA, los equipos completan más trabajo.
+66%
Épicas completadas por desarrollador
+33.7%
Tareas completadas por desarrollador
+16.2%
Pull requests fusionadas por desarrollador
Luego llega el latigazo.Los mismos equipos generan más incidentes y más bugs, y la curva se está volviendo más pronunciada, no más plana.
Calidad en producción con una alta adopción de la IA
Incidentes por pull request
Los incidentes por cambio fusionado se producen con una frecuencia más de tres veces mayor.
Incidentes mensuales
Caídas, eventos de seguridad y fallos que llegan a los usuarios.
Bugs por desarrollador, informe de 2026
Bugs por desarrollador, informe de 2025
La tasa de defectos se está acentuando, no estabilizando.
Bugs por pull request
¿Por qué aumentan los bugs y los incidentes con el código generado por IA?
Un incidente es lo que siente un usuario: una caída, un evento de seguridad, un fallo del sistema.Entre una baja y una alta adopción de la IA, la proporción de incidentes por pull request fusionada aumentó un 242.7 %, y los incidentes mensuales aumentaron un 57.9 %.
«Por cada PR fusionada, los incidentes se producen con una frecuencia más de tres veces mayor.»
Los bugs siguen la misma línea.El informe de Faros de 2025, The AI Productivity Paradox, midió un aumento del 9 % de los bugs por desarrollador.En este conjunto de datos, la cifra sube un 54 %, y la propia página del informe sitúa los bugs por pull request un 28.7 % por encima.Cuanto más depende un equipo de la IA, más rápido crecen los defectos.
Estas cifras describen lo que ocurrió, no una causa única, y Faros tiene cuidado de decirlo.Pero todas apuntan en la misma dirección.Llega más código a producción, más rápido, y cada cambio conlleva más riesgo que antes.
¿Por qué la revisión de código no puede seguir el ritmo de los agentes de programación con IA?
La revisión de código se diseñó para código escrito a velocidad humana.Un agente de programación con IA escribe una pull request en minutos, y un equipo con cinco agentes abre en un día más pull requests de las que sus ingenieros sénior pueden leer en una semana.
La revisión de código ante el volumen generado por IA
Mediana del tiempo en revisión
Mediana del tiempo hasta una primera revisión
Pull requests fusionadas sin ninguna revisión
Ni una persona ni un agente de IA las examinó.
Faros midió la cola: la mediana del tiempo hasta una primera revisión sube un 156.6 %, la mediana del tiempo en revisión sube un 441.5 %.Y la presión encuentra una salida.Las pull requests fusionadas sin ninguna revisión, ni humana ni agéntica, aumentan un 31.3 %.
«El código está llegando a los sistemas de producción sin ninguna supervisión a un ritmo significativamente mayor.»
Incluso una revisión cuidadosa tiene un punto ciego.
- Un revisor lee un diff, y un diff nunca muestra la aplicación en funcionamiento.
- Un botón oculto por un nuevo estilo, un total mal calculado en la página de pago, un diálogo que se abre detrás de la ventana: nada de eso es visible en el código que lo causó.
¿Qué detecta los bugs que la revisión pasa por alto?
La primera idea es pedir al agente más pruebas unitarias.Hágalo, pero no se quede ahí.Las pruebas escritas por el agente que escribió el código comparten su interpretación de la tarea: si entendió mal el requisito, el código y sus pruebas coinciden entre sí, y ambos están mal.
La red de seguridad que va al ritmo de la IA tiene tres propiedades.
| Propiedad | Por qué importa con el código generado por IA |
|---|---|
| Automatizada | Se ejecuta en cada pull request y en cada build, a la velocidad de los agentes, sin esperar a un revisor. |
| Independiente | Está a cargo de una persona, y no depende del código ni de la IA que lo escribió, así que no puede compartir sus errores. |
| Comprueba lo que ven los usuarios | Maneja la aplicación real a través de su interfaz y verifica la pantalla, donde se sienten los incidentes. |
Eso es una prueba end-to-end: una prueba de toda la aplicación a través de su interfaz, como la recorre un usuario, desde el inicio de sesión hasta el pago.A eso se reduce probar código generado por IA, y es lo que piden las cifras de Faros: una comprobación que crece con el volumen de cambios, no con el número de revisores.
Un agente abre una PR
Minutos de trabajo, muchos archivos
Las pruebas unitarias se superan
La propia interpretación del agente
Se ejecutan las pruebas end-to-end
Lo que ve el usuario, a cargo de una persona
Se fusiona, o se bloquea
Un fallo espera una corrección
¿Cómo se convierten las pruebas end-to-end en una puerta de calidad de CI/CD?
Definición
Una puerta de calidad es una comprobación que un cambio debe superar antes de fusionarse o desplegarse.
- Cinco hábitos convierten las pruebas end-to-end en una puerta que un agente no puede esquivar con argumentos.
- 1
Enumerar los recorridos que nunca deben romperse
Registro, inicio de sesión, búsqueda, pago, el informe que sus clientes exportan cada lunes.Entre cinco y diez recorridos, cada uno con el resultado que espera un usuario.Esa lista es la especificación, y pertenece a una persona, no al agente.
- 2
Probar la pantalla, no el código
Verifique lo que un usuario lee y ve: el total, el mensaje, el botón, la disposición.Un agente renombra clases y reescribe componentes con total libertad.Una prueba anclada en la pantalla resiste eso, y aun así falla cuando la pantalla está mal.
- 3
Ejecutar en cada pull request, y bloquear ante un fallo
Un resultado que solo avisa pronto se ignora.Haga que una prueba end-to-end fallida haga fallar el build, para que el cambio espere una corrección en lugar de llegar a los usuarios.
- 4
Mantener las pruebas fuera del alcance del agente
El agente puede ejecutar las pruebas y leer los resultados.Un cambio en lo que espera una prueba necesita la aprobación de una persona, o las pruebas derivan hacia lo que el código resulte hacer.
- 5
Hacer los fallos legibles, y registrarlos
Un fallo debería decir qué paso falló y en qué se diferencia la pantalla, con imágenes, para que el agente pueda proponer una corrección y una persona pueda decidir.Y debería convertirse en un bug en su gestor de incidencias sin que nadie copie capturas de pantalla: consulte convertir las pruebas fallidas en bugs de Jira.
Una advertencia: una puerta que falla sin motivo es peor que no tener puerta, porque la gente aprende a ignorarla.Una puerta necesita pruebas que distingan una regresión real del ruido inofensivo.Ese es el tema de las pruebas inestables y los falsos positivos.
Hacer
- Pruebas end-to-end de los recorridos de los que dependen los usuarios
- Una ejecución fallida que bloquea la fusión
- Una persona que aprueba cada cambio en lo que espera una prueba
- Fallos con imágenes y pasos, registrados como bugs
Evitar
- Las propias pruebas del agente como única red de seguridad
- Fusionar cuando los revisores están demasiado ocupados para mirar
- Una ejecución end-to-end en rojo que solo avisa
- Puertas tan inestables que nadie confía en ellas
Probar el código generado por IA en cada build con GUI Test Studio
GUI Test Studio está construido exactamente para esta puerta.Prueba de extremo a extremo aplicaciones web, aplicaciones de escritorio de Windows, teléfonos y videojuegos, a través de su interfaz, sin código de prueba que escribir ni mantener.
Una prueba en minutos: grábela, o descríbala
Grabe un flujo de trabajo una vez en GUI Test Runner-Recorder, haciendo clic y escribiendo en la aplicación real.O descríbalo en una petición a Claude, a ChatGPT con Codex o a un modelo de IA local, uno nuestro o uno suyo, y la prueba se crea por usted.Cada comprobación que añade un asistente se evalúa en el momento y se rechaza si no pudiera superarse en la pantalla ahora mismo.
En ambos casos, la prueba comprueba lo que muestra la pantalla.
- Una aserción visual compara la imagen de un elemento, una aserción de texto lee sus palabras.
- El GTS Engine + AI encuentra cada elemento preguntando primero a la aplicación, mediante su información de accesibilidad o los propios elementos de la página web, y visualmente cuando la aplicación no lo dice.
- Una clase renombrada o un componente reescrito no rompen la prueba.
Una puerta en su pipeline, con gtr-cli
gtr-cli ejecuta las mismas pruebas en una máquina de compilación Windows y responde como espera un pipeline: su código de salida hace fallar el build, un archivo JUnit rellena la pestaña de pruebas y un resumen en Markdown está listo para la pull request.Con una sola opción, una prueba fallida se convierte en una incidencia de Jira con los pasos para reproducirla y las imágenes esperada y encontrada.
gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
--summary results\summary.md --artifacts results\artifacts --jira on-failureFunciona en TeamCity, Jenkins, GitHub Actions, GitLab y Azure DevOps: consulte Ejecutar pruebas en su pipeline, y Ejecute sus pruebas end-to-end en cada build para una configuración de TeamCity paso a paso.
¿Una regresión real, o ruido inofensivo?
Cada ejecución termina en un Informe de confianza: para cada comprobación, si se encontró el elemento en la Fase de búsqueda y si coincide con lo grabado en la Fase de verificación.
- Cuando una imagen difiere, el Análisis inteligente con IA echa una segunda mirada.
- Ignora el ruido de renderizado, y aun así detecta una palabra cambiada, una insignia que falta o un botón que se volvió gris, y luego dice qué cambió en palabras sencillas.
El agente también puede ejecutar la puerta
A través de su conector, el asistente que escribe su código puede ejecutar sus pruebas, leer el veredicto y proponer un cambio en una prueba, que espera su confirmación.Una persona sigue al cargo de lo que esperan las pruebas.El ciclo completo está en Desarrollo con agentes de IA (ADLC).
Lo esencial
- 1La IA es ahora la principal autora del código. El volumen de trabajo sube, y también los incidentes: +242.7 % por pull request fusionada, +57.9 % al mes.
- 2Los bugs se aceleran, no se estabilizan. Los bugs por desarrollador subieron un 54 %, frente al 9 % del informe de 2025.
- 3La revisión ha llegado a su límite. Un 31.3 % más de pull requests se fusionan sin ninguna revisión.
- 4La red de seguridad debe ser automatizada e independiente: pruebas end-to-end de lo que ven los usuarios, a cargo de una persona, ejecutadas en cada build.
- 5Conviértala en una puerta. Un fallo bloquea la fusión, registra un bug y dice qué cambió.
Preguntas
¿El código generado por IA provoca más bugs?
El AI Engineering Report 2026 de Faros AI comparó los periodos de menor y mayor adopción de la IA dentro de cada organización, en 22 000 desarrolladores.Con una alta adopción, los bugs por desarrollador aumentaron un 54 % y los incidentes por pull request fusionada aumentaron un 242.7 %.El informe mide lo que ocurrió, no una causa única, pero la tasa de defectos sube a medida que se intensifica la adopción.
¿Por qué la revisión de código no basta para el código generado por IA?
El tiempo de revisión crece con el volumen de código, y la IA multiplica el volumen.Faros midió un aumento del 156.6 % en la mediana del tiempo hasta una primera revisión y del 31.3 % en las pull requests fusionadas sin ninguna revisión.Además, un revisor lee un diff, nunca la aplicación en funcionamiento, así que una pantalla rota puede superar una revisión cuidadosa.
¿Cómo se prueba el código generado por IA antes de que llegue a producción?
Mantenga pruebas end-to-end de sus flujos de trabajo críticos a cargo de una persona, independientes del código y del agente que lo escribió.Ejecútelas en cada pull request o build, y deje que un fallo bloquee la fusión.Comprueban lo que ven los usuarios, lo haya escrito quien lo haya escrito.
¿Qué es una puerta de calidad de CI/CD?
Una puerta de calidad es una comprobación de su pipeline que un cambio debe superar antes de fusionarse o desplegarse.Una prueba end-to-end fallida hace fallar el build, así que el cambio espera una corrección en lugar de llegar a los usuarios.
¿Puede un agente de programación con IA crear y ejecutar pruebas de GUI Test Studio?
Sí.Claude, ChatGPT con Codex, Copilot Chat en VS Code o un modelo de IA local, uno nuestro o uno suyo, pueden crear una prueba desde una petición y ejecutarla a través del conector de GUI Test Studio.En un pipeline, gtr-cli ejecuta las mismas pruebas sin ningún asistente.
Cifras: Faros AI, The AI Engineering Report 2026: The Acceleration Whiplash (abril de 2026), y su página del informe para los bugs por pull request.Faros AI, Claude, ChatGPT, Codex, Copilot, OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps y YouTube son marcas comerciales de sus respectivos propietarios.
¿Listo para grabar su primera prueba?
Todas las funciones, durante 15 días.
¿Prefiere verlo con el tipo de aplicación que prueba?Reserve una llamada gratuita de 30 minutos con nuestro equipo.