Los agentes de IA fallan al aplicar técnicas de testing incluso cuando se les instruye explícitamente
How well do agents use test/verification techniques?
Dan Luu evalúa 26 condiciones de prompting en agentes de codificación (Codex con GPT-5.6 Sol) para implementar Zstd en Rust, comparando técnicas como TDD, fuzzing, property-based testing y métodos formales (Lean 4, TLA+, Verus). Los resultados muestran que ninguna técnica supera claramente al comportamiento por defecto, y que los agentes tienden a usar las técnicas de forma superficial o incorrecta, escribiendo tests pobres que no detectan bugs. Incluso con instrucciones específicas, los agentes no aplican bien las técnicas, y las skills recomendadas por Codex (como ECC o Trail of Bits) rinden peor que una skill personalizada diseñada para alejarse del comportamiento por defecto. Luu sugiere que la falta de entornos de RL para entrenar a los agentes en testing efectivo es una oportunidad perdida para mejorar la calidad del software.
En general, independientemente del tipo de problema, los agentes no utilizaron métodos formales ni bibliotecas o técnicas de testing de manera efectiva.
- andai
Estoy desarrollando un juego indie, así que no estoy seguro de cuánto se aplica mi experiencia, pero he estado trabajando en un juego de navegador y el juego es bastante malo, pero hay una enorme cantidad de tests (según mis estándares). Así que puedes tener software malo con montones de tests. (¡También puedes tener software increíble con muy pocos tests!)
También tuve una experiencia divertida donde la IA implementó un cambio arquitectónico completamente al revés. La implementación no tenía sentido y empeoró las cosas en lugar de mejorarlas. Pero aun así obtuve "todos los tests en verde" jaja, porque simplemente demostró que la cosa incorrecta funcionaba correctamente.
Noté con cierta diversión que la verificación formal tampoco habría ayudado ahí, solo habría sido una prueba aún más fuerte de la "corrección" de algo que no debería existir en primer lugar.
- ivanzhaowy123
En mi experiencia, los agentes suelen pensar en más casos límite que los humanos al escribir tests unitarios. Pero bajo la guía de ciertas habilidades, pueden volverse mecánicos y perder de vista la lógica de negocio.
Por ejemplo, cuando uso el conjunto de habilidades Superpowers, el agente adopta proactivamente TDD para cada nueva funcionalidad. Pero su comprensión del testing a menudo se queda superficial: si el usuario pide una pantalla con un botón "Enviar", primero escribe un test que comprueba si el botón existe. El test falla, así que añade el botón para que pase.
Como resultado, la suite de tests se llena de casos de bajo valor que comprueban si una propiedad existe o si una cadena coincide exactamente. El agente sigue el flujo de trabajo de "escribir un test que falle, luego implementar la funcionalidad", pero nunca prueba realmente el comportamiento de negocio: ¿Cuándo se debería permitir el envío? ¿Qué debería pasar después del éxito o del fracaso? ¿Cómo se deberían manejar los envíos duplicados?
El problema no es que los agentes no puedan escribir tests. Es que parecen propensos a reducir TDD a una secuencia rígida de pasos, luchando por derivar de forma independiente casos de prueba significativos a partir de los requisitos de negocio y usarlos para guiar el desarrollo.
- siscia
Aún es pronto, pero creo que este experimento tiene poco o ningún sentido y apenas es útil.
La forma en que pruebas el código no puede (ni debería) desvincularse de la forma en que arquitecturas el propio código.
Más del 80% del testing efectivo no está en el framework de testing sino en la arquitectura del código.
El autor no menciona cómo se está arquitecturando y gestionando el código.
Por lo que vale, he encontrado que forzar a los agentes a usar arquitectura DI/hexagonal y forzar una comprobación trivial de cobertura es bastante útil y produce código suficientemente bueno con relativamente poco esfuerzo.
- movpasd
Esto es significativamente más exhaustivo que cualquier testing que haya hecho, y en un dominio totalmente diferente, pero mi experiencia anecdótica haciendo que los agentes usen Hypothesis fue bastante pobre.
El agente realmente luchó mucho para tender un puente entre el código y las reglas de negocio reales que se suponía que debía modelar. También le costó determinar qué funciones en qué capa eran apropiadas para escribir tests. Así que sus tests tendían a ser muy frágiles ante cambios en la lógica de dominio.
En esencia, los agentes siempre han parecido tener problemas con la modularidad y la descomposición de problemas. Un buen testing consiste en encontrar las cosas correctas que probar, lo que significa determinar cómo subdividir el estado de entrada en un estado de producto apropiado, y comprobar cada comportamiento de forma independiente. En mi opinión, esto es lo más difícil y complicado de la programación, así que no diré que le costó _más_ de lo que le costaría a un humano --- pero los humanos tienen la ventaja de poder dormir sobre ello.
Una cosa menor que observé fue que tendía a obsesionarse mucho con los casos límite de coma flotante (NaNs, infinitos). Quizás los casos límite de coma flotante están sobrerrepresentados en los datos de entrenamiento de property-based testing, pero es esencialmente irrelevante para mi caso de uso, al menos en lo que respecta a las reglas de negocio.
- anitil
¿Sabes cómo todo el mundo piensa que los agentes son malos en lo que ellos son buenos y buenos en lo que ellos son malos? Resulta que yo debo ser malo en testing, porque pensaba que hacían un trabajo razonable.