En un rincón de la industria de la inteligencia artificial, hay un problema que casi nadie ve hasta que llega la factura: evaluar a un agente de software cuesta más que entrenarlo. Los primeros en tropezar con este muro fueron los equipos que intentan medir qué tan bien resuelve un modelo tareas reales de programación, como arreglar un bug o implementar una función en un repositorio. Cada intento requiere que el agente explore el código, edite archivos y ejecute pruebas, un proceso que consume tiempo de cómputo y dinero.
En SWE-bench, un estándar de la industria, una sola corrida completa con un agente puede superar los 8.000 dólares en costos de inferencia, según PTA-IRT. Por eso, cada vez más investigadores y empresas buscan atajos: en lugar de ejecutar los 2.000 problemas del benchmark, quieren elegir un subconjunto pequeño y representativo que les dé una estimación confiable del desempeño general.
La trampa del aprobado/fallido
El enfoque clásico para recortar costos es usar Teoría de Respuesta al Ítem (IRT), una técnica estadística que selecciona tareas basándose solo en si el agente pasó o falló. Pero reducir una trayectoria completa —cómo el agente exploró el contexto, qué herramientas usó, en qué orden, dónde se quedó atascado— a un simple aprobado/fallido descarta información valiosa. Los autores de PTA-IRT proponen algo distinto: usar las trayectorias históricas como información privilegiada para calibrar la selección de tareas y estimar la habilidad del agente. Su método, que llaman PTA-IRT, convierte cada trayectoria en resúmenes semánticos estructurados que alimentan un modelo de cuatro parámetros. Los resultados experimentales muestran que esta técnica supera a los baselines de IRT en recuperar puntajes y rankings con presupuestos de calibración bajos. En otras palabras, el mismo presupuesto de evaluación rinde más cuando se mira el proceso, no solo el resultado.
No basta con la respuesta final: hay que ver las manos del agente
El mismo problema aparece en la evaluación del uso de herramientas. Un agente puede llamar a la API equivocada y aun así llegar a la respuesta correcta usando conocimiento interno, algo que han observado los equipos detrás de TRAJECT-Bench. Este benchmark, presentado en ICLR 2026, introduce herramientas ejecutables de alta fidelidad en dominios prácticos (finanzas, viajes, clima) y métricas de trayectoria: si el agente seleccionó la herramienta correcta, si los argumentos eran válidos, si respetó el orden de dependencias. Al analizar más de mil herramientas y trayectorias que van de 3 a más de 10 llamadas, encontraron modos de falla específicos: confusión entre herramientas similares y selección ciega de parámetros. El punto es que medir solo la respuesta final oculta dónde se rompe el proceso, y eso es exactamente lo que las empresas necesitan saber para mejorar sus agentes.
Los agentes siguen fallando en tareas largas
Si el problema fuera solo el costo de evaluar, ya sería suficiente motivo para repensar las métricas. Pero hay otro hallazgo incómodo: los agentes de última generación todavía son débiles en tareas de desarrollo de software a largo plazo. RoadmapBench construyó 115 tareas basadas en actualizaciones de versiones reales de repositorios de código abierto, donde la mediana exige modificar 3.700 líneas en 51 archivos. El mejor modelo evaluado, Claude-Opus-4.7, apenas resolvió el 39,1% de las tareas, mientras que el más débil llegó al 5,2%. Comparado con los benchmarks tradicionales donde los mismos modelos superan el 80%, esta brecha revela que el desarrollo de software real sigue siendo un problema sin resolver. Los modos de falla también varían por nivel de capacidad: los modelos fuertes fallan en lógica de implementación (58% de sus errores), mientras que los débiles ni siquiera logran compilar correctamente.
Qué significa esto para las empresas en América Latina
Para un equipo de ingeniería en México, Colombia o Argentina que está considerando adoptar agentes de código, estos números deberían poner freno al hype. La evaluación no es un problema teórico: es una decisión de presupuesto. Si una corrida completa en un benchmark cuesta miles de dólares, ¿cuánto costará validar a un agente interno en la base de código propia? Las métricas basadas en trayectoria, como las que proponen PTA-IRT y TRAJECT-Bench, ofrecen una alternativa viable: permiten estimar el desempeño con un subconjunto de tareas y diagnosticar los modos de falla específicos antes de desplegar el agente en producción.
Además, los resultados de RoadmapBench sugieren que las empresas latinoamericanas que planean usar agentes para tareas complejas de mantenimiento de software deberían empezar con expectativas realistas: el mejor modelo disponible hoy resuelve menos del 40% de las tareas largas. La adopción inteligente, entonces, pasa por definir qué tareas son adecuadas para agentes, medir el proceso de resolución y no solo el resultado, y presupuestar el costo de validación como un costo de infraestructura más.
En síntesis, la industria está convergiendo hacia evaluaciones que privilegian la trayectoria sobre el resultado binario. Para los equipos de IA en la región, la lección es doble: medir bien a los agentes es tan importante como construirlos, y hacerlo con métricas de proceso permite detectar fallas que las métricas de precisión tradicionales ocultan. La buena noticia es que ya existen benchmarks y métodos que abordan este problema, y están disponibles públicamente, como el código de PTA-IRT en GitHub.
