La IA agéntica necesita más profesionales de pruebas, no menos

La IA agéntica está cambiando la forma de desarrollar y entregar software. Los asistentes redactan solicitudes de cambios, los agentes inician migraciones y los bots de revisión aseguran que un cambio es seguro antes de que una persona termine su café. La industria suele presentar esto como una vía para reducir el número de profesionales de calidad. Ese planteamiento es erróneo. A medida que las máquinas escriben una parte mayor del código, la habilidad escasa no es generar código, sino verificarlo de manera independiente.

La Encuesta para desarrolladores de Stack Overflow de 2025 reveló que el 84% de las personas encuestadas usan o planean usar herramientas de IA durante el desarrollo y que el 51% de los desarrolladores profesionales las usan a diario. La opinión positiva cayó al 60%, y son más los desarrolladores que desconfían activamente de la precisión de la IA (46%) que los que confían en ella (33%). La principal frustración, señalada por el 66%, eran las soluciones que casi aciertan, pero no del todo. La investigación de DORA informó en 2025 que la adopción de la IA entre los profesionales del desarrollo de software alcanzaba el 90%; más del 80% afirmaba que la IA había mejorado su productividad, pero solo el 24% decía confiar mucho o muchísimo en ella. La utilidad sin confianza es precisamente lo que amplía el trabajo de quienes hacen pruebas, no lo reduce.

La velocidad no es una prueba

Trabajo como ingeniero de calidad de software, especializado en pruebas agénticas y controles de CI para código generado por IA. En nuestra empresa, lanzamos un revisor de PR y un generador de casos de prueba. Ambos son herramientas para elaborar borradores. Ninguno evalúa su propio trabajo. Esa regla importa porque los agentes se expresan con seguridad. La seguridad al expresarse no equivale a tener razón.

Lo aprendimos por las malas. Durante una prueba piloto de un revisor de PR creado con IA, un cambio superó la CI en menos de 4 minutos. Dos días después, un panel posterior mostró temperaturas imposibles. En una ruta de código que la batería de pruebas nunca ejecutaba, se había invertido la conversión de Celsius a Fahrenheit. La canalización aparecía en verde. El producto estaba mal. Una CI en verde que nunca plantea la pregunta difícil es puro teatro.

Ese incidente forma parte de una tendencia más amplia. El Informe sobre el estado de la generación de código con IA frente a la generación humana de CodeRabbit analizó 470 solicitudes de cambios de código abierto en GitHub (320 con coautoría de IA y 150 solo de autores humanos). Los cambios escritos con IA generaron aproximadamente 1,7 veces más problemas en total; los problemas de lógica y corrección fueron un 75% más comunes, y los hallazgos de seguridad, hasta 2,74 veces más frecuentes. El Informe sobre la seguridad del código generado con IA de Veracode de 2026 puso a prueba modelos en distintas tareas de seguridad y encontró una tasa media de aprobación de seguridad del 56%, apenas por encima del 55% del informe anterior, mientras que aproximadamente el 44% de las tareas de generación de código con IA introdujeron una vulnerabilidad conocida. La sintaxis está prácticamente resuelta. El comportamiento seguro y correcto, no. Quienes hacen pruebas son quienes se niegan a confundir esas dos cosas.

Las dependencias inventadas son un problema de pruebas

La generación también inventa paquetes. El estudio de USENIX Security de 2025, ¡Tenemos un paquete para usted!, evaluó las alucinaciones de paquetes en 16 modelos de lenguaje grandes (LLM) que generan código y en 576.000 muestras. En promedio, los modelos comerciales alucinaron paquetes al menos el 5,2% de las veces; los modelos de código abierto registraron un promedio del 21,7%, con 205.474 nombres inventados únicos. Los paquetes fantasma que permanecen disponibles crean un objetivo perfecto para los ataques de apropiación de nombres de paquetes inventados: los atacantes registran el nombre inventado y esperan a que un desarrollador o un agente lo instale.

Las comprobaciones del origen de las dependencias deben estar al mismo nivel que las pruebas funcionales. Si un agente inventa un paquete de NuGet o npm, la integración del cambio debe fallar antes de que nadie debata si las pruebas unitarias fueron exhaustivas. Verificar el origen no es una práctica de higiene opcional. Es un control de calidad para los cambios escritos con IA.

Controles que escalan con los agentes

Cuando llevamos a cabo en toda la organización una actualización de .NET 8 a .NET 10 en unas dos semanas mediante automatización asistida por IA, me encargué de los controles de calidad. La velocidad fue real. También lo fue la necesidad de contar con comprobaciones que no den por bueno el resumen del agente. Estos son los controles que aplico al código modificado:

• Objetivos de puntuación de mutación de entre el 60% y el 70% en la lógica modificada, para que la batería de pruebas tenga que detectar mutaciones reales y no se limite a cubrir líneas
• Pruebas basadas en propiedades para la lógica de alto riesgo, donde los ejemplos por sí solos no especifican el comportamiento con suficiente precisión
• Comprobaciones del origen de las dependencias para detectar ataques de apropiación de nombres de paquetes inventados y paquetes alucinados
• Indicadores de duplicación y cambios excesivos que detectan el caos de copiar y pegar de los agentes
• Verificación independiente de las afirmaciones de los agentes, como «migración completada», porque una afirmación no es más que una hipótesis hasta que se presentan pruebas

La puntuación de mutación no es una métrica para presumir. Indica si las pruebas detectan un fallo introducido deliberadamente. La cobertura puede aumentar y, aun así, la batería de pruebas pasar por alto la ruta de Celsius. Las comprobaciones basadas en propiedades obligan al modelo del sistema a mantenerse válido en distintos rangos, no solo en una ruta ideal. Verificar el origen cierra la puerta a los paquetes inventados. Los cambios excesivos y la duplicación permiten detectar la costumbre de los agentes de reescribir la misma idea de tres maneras. En conjunto, todo esto define una postura: dar por hecho que el agente se equivoca hasta que la batería de pruebas demuestre lo contrario. Mantengo ese criterio de calibración durante las revisiones.

Nada de esto sustituye las pruebas de API, las pruebas de autenticación, las pruebas de humo ni la automatización de la interfaz de usuario. FlaUI y PowerShell siguen detectando lo que se les escapa a las API. Los paquetes distribuidos mediante NuGet, MSI y MSM siguen necesitando validaciones de instalación y de instalación silenciosa. Los flujos de trabajo agénticos amplifican el volumen. No eliminan esas disciplinas.

Más profesionales de pruebas, un trabajo diferente

El temor es que los agentes escriban las pruebas y que los humanos se vuelvan prescindibles. Los agentes pueden redactar casos de prueba. No deberían certificar sus propios borradores. Entre quienes respondieron en Stack Overflow y planean usar IA para realizar pruebas en el futuro, la desconfianza humana sigue ocupando un lugar central: cuando pedirían ayuda a otra persona, la principal razón era que no confiaban en las respuestas de la IA. Ese instinto es el mayor activo de la profesión.

Es importante contratar y brindar oportunidades a personas que han seguido trayectorias no tradicionales. Me pasé al área de calidad después de trabajar en operaciones de recursos humanos y análisis de datos, terminé una maestría en Sistemas de Información en UMBC en mayo de 2024 y ahora dedico mis días a hacer que los controles de los agentes sean prácticos. La IA agéntica no esperará a que todos tengan una trayectoria académica o profesional idéntica. Necesita más personas capaces de diseñar pruebas que aporten evidencia, no menos personas que aprueben sin cuestionar las compilaciones marcadas en verde.

La pregunta sobre el producto es sencilla. Si los agentes lanzan productos más rápido de lo que tu capacidad de verificación puede evaluar, no estás ganando productividad. Estás posponiendo un incidente. Invierte en profesionales de pruebas que pongan en duda todas las afirmaciones de los agentes, integren las pruebas de mutación y la procedencia en la integración continua (CI) y mantengan un criterio independiente allí donde el modelo se expresa con mayor fluidez y es menos fiable. La IA agéntica necesita más profesionales de pruebas, no menos.