La mayoría de los puntos de referencia de codificación de IA todavía plantean la pregunta: ¿el agente produce código que pasa las pruebas actuales?
Ésta es una pregunta útil, pero demasiado limitada. El desarrollo de software es iterativo. Los requisitos cambian y aparecen en casos extremos. Las viejas decisiones de diseño se convierten en obstáculos para nuevos trabajos. El código aprobado hoy aún podría hacer que los cambios posteriores sean más lentos y costosos, al tiempo que aumenta el riesgo.
El espaciado es aún más importante a medida que la IA aumenta la cantidad de cambios de código. Cuando la generación es barata, la verdadera pregunta pasa de “¿Puede trabajar el agente?” a ‘¿Qué tipo de código base construye un agente utilizado repetidamente con el tiempo?’
Un artículo reciente, SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks (Orlanski et al.), se acerca más a esa pregunta que la mayoría de los trabajos de referencia. En lugar de calificar como una solución única, extiende el código anterior de los agentes a 20 problemas y 93 puntos de control.
Cada punto de control cambia la especificación. Los agentes no empiezan de nuevo y no reciben un diseño interno a seguir. Tiene que vivir con decisiones anteriores.
Esta configuración está más cerca del desarrollo real que la mayoría de las suites de referencia, ya que los equipos reales heredan los atajos del ayer.
Las pruebas ecológicas pueden ocultar una base de código incorrecta
El artículo rastrea dos señales de calidad además de la precisión. La verbosidad mide código redundante o duplicado. La decadencia estructural mide cuánta complejidad del código base queda atrapada en funciones que ya son demasiado complejas.
Estos son modos de falla familiares para todo gerente de ingeniería. Un sistema puede pasar las pruebas cuando se introduce más lógica en la misma función grande y se incorporan casos más especializados. Es necesario tocar más archivos para cada función. El software todavía funciona, pero los cambios se vuelven más difíciles.
El ejemplo de búsqueda de código de prueba es un buen ejemplo de este problema. Primero, el sistema necesita encontrar código Python utilizando solo texto válido o expresiones regulares. Más adelante, necesitará manejar más idiomas, comprender la estructura del código (coincidencia AST) e incluso resolver problemas automáticamente.
Si el diseño inicial es demasiado rígido y hace suposiciones iniciales, puede pasar la primera prueba, pero no podrá manejar fácilmente requisitos posteriores complejos.
Los resultados son claros. Ninguno de los agentes evaluados resolvió ningún problema de principio a fin. La mejor tasa de arreglo duro fue del 17,2 por ciento, y la tasa de arreglo duro cayó al 0,5 por ciento en el punto de control final. En todas las trayectorias, la verbosidad aumentó en el 89,8 por ciento de las ejecuciones y el deterioro estructural se produjo en el 80 por ciento.
Las comparaciones con código mantenido por humanos son más útiles. Comparado con 48 repositorios de Python mantenidos, el código generado por el agente era 2,2 veces más detallado y estructuralmente más degenerado.
Cuando los autores rastrearon 20 de estos repositorios a lo largo del tiempo, el código humano era relativamente plano, mientras que el código del agente empeoraba con cada iteración.
Una suite de paso le indica que verifique que se cumpla con la última versión. No le dice que el código se está volviendo más frágil o más costoso de extender.
¿Por qué es importante para el control de calidad?
Para los líderes de control de calidad, existen dos formas principales. La primera es obvia: el código de producto creado por IA puede degradarse ante cambios repetidos, incluso si las pruebas actuales son verdes. Los equipos pueden continuar leyendo el resultado como evidencia de que el sistema está en buen estado. De hecho, pueden acumular costos de regresión futuros a altas velocidades.
El segundo está más cerca de casa. Los equipos de control de calidad ahora están utilizando herramientas de inteligencia artificial para escribir y mantener pruebas, especialmente la automatización efectiva de la interfaz de usuario en herramientas como Playwright. Ese trabajo sigue el mismo patrón que el artículo: el producto cambia, la prueba cambia, la siguiente característica agrega otra rama, otro selector, otra excepción, otro ayudante.
El documento trata en términos generales sobre codificación, no específicamente sobre conjuntos de pruebas de automatización, pero abarca el proceso. Un conjunto de pruebas puede volverse detallado y estructuralmente débil bajo una edición repetida asistida por IA.
Es difícil notar un conjunto de pruebas degradado en un código de producto degradado. Es posible que el oleoducto todavía esté verde y que el traje aún parezca grande en el papel. La cobertura se puede mejorar.
Mientras tanto, el activo original puede depreciarse. Estos pueden incluir selectores incorrectos, comprobaciones deficientes, pasos de prueba copiados, funciones auxiliares demasiado grandes y pruebas de interfaz de usuario que son difíciles de solucionar y fáciles de sospechar. Si bien la inestabilidad de las pruebas es obvia, es posible que problemas como las pruebas que no hacen mucho o se ejecutan demasiado lentamente no se noten de inmediato.
Para los líderes de control de calidad, cambia de trabajo. El control de calidad no puede dejar de validar los últimos resultados frente a los requisitos actuales. También se debe examinar si los cambios repetidos están dañando tanto el producto como el método de prueba que se supone debe proteger.
Los roles de liderazgo de calidad están cambiando; La garantía de calidad ahora debe ir más allá de simplemente verificar la última producción del producto con respecto a los requisitos actuales. Los líderes de control de calidad deben monitorear si el cambio continuo está impactando negativamente tanto la calidad del producto como la integridad del sistema de prueba diseñado para protegerlo.
La indicación por sí sola no lo resolverá
El artículo examinó si una mejor indicación podría controlar la deriva. Me ayudaron al principio, pero no por mucho tiempo. Las indicaciones conscientes de la calidad reducen la redacción temprana y el desgaste. Un aviso anti-pendiente reduce la verbosidad inicial en GPT-5.4 en aproximadamente un tercio.
Los cambios fueron mínimos. Los puntos de partida más limpios todavía se degradaban aproximadamente al mismo ritmo, y el código con mejor apariencia no mejoraba de manera confiable las tasas de aprobación. En algunos casos, las indicaciones han aumentado los costos.
Muchas organizaciones consideran Prompt como una capa de gobernanza. Si bien esto ayuda, no es suficiente. Si se le pide a un agente que extienda su propio código bajo el requisito de cambio de flujo de trabajo, la organización aún necesita control más allá del aviso.
Una buena forma de evaluar el desarrollo asistido por IA
Para gestionar bien el desarrollo asistido por IA, es necesario analizar los rápidos logros del pasado. Verifique los cambios de código después de algunos ajustes, no solo la primera revisión. Tenga cuidado con las partes complejas o repetitivas del código.
No confunda el éxito en las funciones actuales con la confianza en la estabilidad a largo plazo. Considere lo fácil que es mantener el código como riesgo de liberación, especialmente para sistemas que se ocupan de cosas como costos, ID de usuario, derechos de acceso, dinero o reglas.
La misma regla se aplica a los exámenes. Revise cómo cambia el código de prueba generado por IA después de varias iteraciones del producto. Busque suites que crezcan más rápido que sus pruebas de señal y de interfaz de usuario que absorban mejor el comportamiento cubierto en niveles inferiores.
Tenga también en cuenta el mantenimiento “autocurativo” que reduce sutilmente la energía necesaria. Un conjunto más grande no significa automáticamente un mejor control.
La calidad debe avanzar hacia arriba. Para cuando una característica alcanza la validación final, es posible que parte del daño que sufrió el sistema para llegar allí ya esté integrado.
El control de calidad necesita una voz en el circuito antes: definir restricciones de diseño, estándares de revisión, técnicas de regresión y estándares de cambio aceptables tanto para el código de producto como para el código de prueba.
En última instancia, pasar las pruebas sigue siendo importante, pero a medida que la IA aumenta la cantidad de cambios de código, la pregunta más útil es si cada cambio exitoso hace que la base del código sea más segura de extender o más peligrosa de tocar.
Hemos presentado el mejor creador de sitios web con IA.
Este artículo fue producido en parte Perspectiva profesional de TechRadarNuestro canal para mostrar las mejores y más brillantes mentes de la industria tecnológica actual.
Las opiniones expresadas aquí son las del autor y no necesariamente las de TechRadarPro o Future plc. Si está interesado en contribuir, obtenga más información aquí:
