Las evaluaciones generales de LLM no predicen el éxito del agente en tu base de código
HumanEval y MMLU miden el razonamiento de un solo turno sobre problemas aislados. Tu agente no funciona así. Encadena 50 llamadas de herramientas en una base de código de 50k líneas, leyendo y reescribiendo archivos que medio recuerda, recuperándose de fallos de compilación, decidiendo si reintentar o escalar. SWE-Bench Verified se acerca más—incluye repositorios Python reales y razonamiento multietapa—pero sigue limitado a PRs pequeños y una única familia de lenguajes.
ScarfBench se enfoca en migraciones Java empresariales: Spring 4 a Spring 6, Java 8 a 17, cambios de espacio de nombres Jakarta EE. El tipo de trabajo que vive en sistemas bancarios de producción, plataformas de seguros, backends de telecomunicaciones. Un modelo que obtiene un 90% en HumanEval aún puede alucinar importaciones, dejar código muerto en 200 archivos, y reiniciar desde cero después de golpear un error de compilación. La brecha entre pass@1 de evaluación y confiabilidad de producción es donde los agentes mueren.
¿Por qué importa esto? Porque tu agente de producción—ya sea orquestando APIs internas, migrando una base de código, o triando tickets de soporte—vive en el mismo mundo. Tiene que mantener estado en 20+ llamadas de herramientas sin re-alucinar hechos que ya descubrió. Eso no es lo que miden los benchmarks de codificación.
Lo que ScarfBench realmente mide: confiabilidad de herramientas, no inteligencia
ScarfBench aísla tres ejes de fallo que se mapean directamente al riesgo de producción. El primero es la confiabilidad del uso de herramientas: ¿el agente llama a read_file, apply_patch, run_tests en el orden correcto sin argumentos malformados? Un modelo puede ser inteligente pero descuidado—pasando un número de línea cuando se requiere un desplazamiento de byte, u olvidando incluir el contexto completo en un parche. Estos pequeños errores se propagan en una ejecución de migración de 45 minutos.
El segundo es el thrashing de ventana de contexto. Un único archivo Java puede exceder 8k tokens. Cuando el agente tiene que dividirlo, recuperar múltiples piezas, y reconstruir contexto repetidamente, las matemáticas de latencia se rompen: 40 llamadas de herramientas × 800ms de recuperación por llamada = 32 segundos antes de que llegue el primer token de razonamiento. Para cuando el agente piensa de nuevo, ha olvidado lo que descubrió hace dos archivos. La indexación a nivel de símbolo—usando tree-sitter, LSP, o Sourcegraph SCIP para pasar solo los llamadores y llamados relevantes—es lo que separa el envío de las demostraciones.
El tercero es la recuperación de refactor parcial. El agente comienza a migrar un paquete, golpea un error de compilación a mitad de camino, y tiene que decidir: reintentar el archivo actual, hacer un checkpoint y continuar, o escalar a un humano. ScarfBench incluye ejecuciones donde las migraciones fallan intencionalmente a mitad de camino. ¿Puede el agente reanudar sin re-alucinar código ya migrado? ¿Puede detectar que javax.persistence ahora es jakarta.persistence y no reaplicar la misma corrección dos veces? El código muerto dejado atrás—métodos no utilizados que no fueron limpiados—es la señal de que el estado se perdió a mitad de ejecución.
El thrashing de contexto es el modo de fallo que nadie evalúa
El marketing habla sobre ventanas de contexto de 200k tokens. En la práctica, un agente relee el mismo archivo 12 veces por tarea. El tamaño de la ventana no importa si la recuperación es ingenua y costosa.
Hemos enviado suficientes prompts con alcance de recuperación para conocer el patrón: pasar solo los símbolos que el agente necesita para tomar la siguiente decisión. Si el agente está reescribiendo una clase Spring @Configuration, incluye los métodos públicos y sus sitios de llamada—no el paquete completo. A escala, la orquestación se resuelve. El verdadero cuello de botella es el enrutamiento de tokens—decidir qué buscar, cuándo almacenarlo en caché, y cuándo dejar que una versión anterior del contexto se vuelva obsoleta.
El almacenamiento en caché de prompts de Anthropic reduce el costo de contexto del sistema repetido en aproximadamente un 90% en relecturas. Úsalo. Registra la tasa de acierto de caché junto con el gasto de tokens; si está por debajo del 60%, tu estrategia de recuperación está rota. Los presupuestos de latencia importan más que la velocidad del modelo aquí: si quemas 800ms recuperando símbolos, un modelo 1ms más rápido no te ahorra.
La recuperación del estado parcial es lo que separa los agentes de las demostraciones
Cada llamada de herramienta necesita una clave de idempotencia. Los reintentos sin idempotencia son cómo terminas con un archivo parcheado tres veces. Haz un checkpoint después de cada archivo—mediante un commit de git, una fila de Postgres, o un mensaje en una cola durable. Nunca confíes en el estado en memoria en una ejecución de 45 minutos. Un cliente despliega tu agente el viernes por la tarde y se va. El lunes, alguien nota que la ejecución se bloqueó a las 4am del domingo, y el agente ya había migrado el 80% de los archivos. Necesitas saber exactamente dónde se detuvo.
La verdad fundamental es el bucle de compilación y prueba. El código de salida de mvn verify te dice si una migración funcionó. La autoevaluación del agente—"Creo que este archivo ahora es compatible con Jakarta EE"—vale menos que el registro de compilación. Cuándo construir un agente vs. un flujo de trabajo se reduce a esto: ¿puede tu tarea ser verificada automáticamente y lo suficientemente rápido para reintentar? Las migraciones pueden. Los tickets de soporte no. Diseña en consecuencia.
Usa una cola de letra muerta para archivos que el agente no pudo migrar limpiamente. Enrútalos a un carril de revisión humana. Reintenta errores de herramientas con backoff exponencial, pero limita a 3 intentos. Los bucles infinitos queman tokens más rápido de lo que arreglan bugs. Si el agente ha reintentado el mismo archivo tres veces, es hora de rendirse y escalar.
Por qué los fallos de migración predicen los fallos de agentes de producción
Los mismos modos de fallo que rompen las ejecuciones de ScarfBench rompen los agentes orientados al cliente. Un agente de soporte que pierde contexto en una conversación de 20 turnos es el mismo bug que uno que olvida qué archivos migró. Un agente de orquestación que llama a 15 APIs internas falla en el mismo desvío de esquema de herramientas que ScarfBench expone. Si tu evaluación no incluye recuperación de fallo parcial, estás enviando demostraciones.
Los equipos que ganan en agentes ejecutan un arnés estilo ScarfBench específico del dominio en CI. No tweaks de prompts basados en vibraciones. 20 tareas reales de tu base de código, puntuadas en finalización + compilación + paso de prueba. Ejecútalo en cada cambio de prompt e intercambio de modelo. Rastrea la tasa de éxito de llamadas de herramientas, relecturas de contexto por archivo, tasa de recuperación después de fallo, tiempo de reloj de pared para compilación verde. Si una métrica retrocede, lo sabes antes de desplegar.
La señal de costo también importa: un agente inestable que reintenta 4x en promedio es una factura de infraestructura 4x. Eso no es un problema de UX, eso es un problema de presupuesto. Tu CFO lo notará.
Cómo instrumentaríamos tu agente antes de que llegue a producción
Construye un arnés de dominio con 20 tareas reales de tu base de código. Para una migración Java, eso son 20 paquetes de tamaño y complejidad variados. Para un agente de orquestación, son 20 flujos de trabajo que ejercitan todas las APIs que llamará. Puntúa en finalización, resultado (paso de compilación, paso de prueba, sin código muerto), y tiempo de reloj de pared para resultado.
Registra cada llamada de herramienta con sus argumentos, latencia, y resultado en un almacén estructurado—Postgres o ClickHouse funcionan bien. Conecta cuatro métricas de observabilidad: tasa de éxito de llamadas de herramientas (¿la herramienta devolvió 200?), relecturas de contexto por archivo (¿cuántas veces el agente buscó el mismo símbolo?), tasa de recuperación después de fallo (¿el agente se reanudó limpiamente?), y tiempo de reloj de pared para compilación verde (tiempo total transcurrido, no tiempo de token).
Ejecuta el arnés en cada cambio de prompt e intercambio de modelo. No solo en el lanzamiento. Un nuevo prompt del sistema podría reducir la latencia en un 30% y romper la recuperación completamente. No lo sabrás si no estás midiendo.
Antes de actualizar al siguiente modelo fronterizo, ejecuta tu propio ScarfBench—20 tareas reales de tu repositorio, puntuadas en compilación y prueba, no vibraciones. Si quieres ayuda construyendo ese arnés, ese es exactamente el tipo de trabajo que enviamos. Así es como se ve realmente la observabilidad del agente en producción. Habla con nosotros en /contact.