Databricks ha publicado uno de los benchmarks más interesantes del momento para agentes de programación, no porque use una batería pública de ejercicios, sino porque se apoya en su propio código. La compañía ha evaluado modelos y harnesses de agentes sobre tareas reales extraídas de pull requests internos, con cambios sobre un codebase de millones de líneas y múltiples lenguajes, entre ellos Python, Go, TypeScript, Scala, Rust y Java.

El resultado más llamativo es que GLM 5.2, un modelo open source de Z.ai, aparece en el grupo alto de capacidad y queda estadísticamente empatado con Claude Opus 4.8 en calidad dentro de esta prueba interna de Databricks. La diferencia está en el coste: GLM 5.2 aparece con 1,28 dólares por tarea, frente a 1,94 dólares por tarea de Opus 4.8 en la configuración comparada.

La conclusión no es que un modelo sustituya automáticamente a otro en todos los escenarios. La lectura útil es otra: en tareas reales de ingeniería, la frontera de eficiencia ya no pertenece a un solo proveedor. Según Databricks, la frontera de Pareto de sus pruebas incluye modelos de OpenAI, Anthropic y open source, lo que apunta a un futuro donde las empresas no elegirán “el mejor modelo” de forma fija, sino rutas distintas según coste, complejidad y tipo de tarea.

El benchmark que las empresas deberían construir por su cuenta

Databricks explica que los benchmarks públicos como SWE-bench o TerminalBench son útiles, pero no resolvían sus dudas internas. La razón es clara: las tareas públicas pueden filtrarse con el tiempo en los datos de entrenamiento y, además, no siempre reflejan la realidad de una base de código empresarial concreta. Por eso la compañía construyó su evaluación a partir de PRs reales, recientes y revisados, con tests de calidad y cambios acotados a módulos concretos.

Ese enfoque marca una diferencia. Un benchmark público mide una capacidad general. Un benchmark interno mide si un agente ayuda a resolver los problemas reales de una compañía, con sus patrones, sus frameworks, sus convenciones, sus sistemas de build y sus decisiones históricas.

Databricks filtró cambios generados por bots, cuentas de servicio, commits totalmente generados por IA y código autogenerado. Después convirtió los PRs seleccionados en tareas: resumió la intención, eliminó pistas sobre la solución, separó los tests y evaluó si el agente era capaz de reproducir una implementación correcta. La compañía también evitó usar un juez LLM para decidir si la respuesta era válida, porque considera que ese enfoque puede premiar respuestas convincentes aunque no sean correctas.

Otro detalle técnico importante fue el control de fugas internas. En sus primeros experimentos, Databricks detectó que algunas soluciones parecían demasiado buenas porque el agente podía recuperar la implementación correcta desde el historial de Git. Para corregirlo, sellaron el historial durante la ejecución de cada tarea, de modo que el agente no pudiera avanzar por commits previos hasta encontrar la respuesta.

Esto convierte el experimento en una señal interesante para cualquier equipo de ingeniería: muchas empresas ya tienen su propio benchmark sin saberlo. Está en sus PRs cerrados, sus tests, sus incidencias resueltas y sus cambios revisados por humanos.

El modelo importa, pero el harness importa casi igual

El punto más técnico del estudio está en la separación entre modelo y harness. En un agente de código, el modelo razona, propone cambios y escribe código. El harness es la capa que le permite operar: buscar archivos, ejecutar comandos, leer salidas, gestionar contexto, decidir qué información enviar en cada turno y mantener la tarea bajo control.

La industria tiende a comparar modelos como si funcionasen aislados. Databricks muestra que eso es insuficiente. En sus pruebas, al ejecutar el mismo modelo con el mismo esfuerzo de razonamiento a través de dos harnesses distintos, el coste por tarea cambió más de 2 veces en algunos casos mientras la calidad se mantenía. La causa principal fue la cantidad de contexto que cada harness reenviaba al modelo en cada turno.

Pi, el harness interno destacado en el análisis, envió alrededor de tres veces menos contexto por turno. Según Databricks, gestionó mejor el conjunto de trabajo, mantuvo una ventana más ajustada y completó tareas en menos ejecuciones.

Ese dato cambia la conversación sobre costes. No basta con mirar el precio por millón de tokens. Si un agente lee demasiado, reenvía contexto innecesario, itera más de la cuenta o no sabe mantener el foco, puede salir más caro aunque el modelo tenga una tarifa menor.

Elemento	Qué decide en un agente de código
Modelo	Razonamiento, generación de código, comprensión de instrucciones
Harness	Contexto enviado, herramientas disponibles, comandos, lectura de ficheros
Tests	Verificación real de la solución
Routing	Elección del modelo según dificultad y coste
Pipeline interno	Seguridad, trazabilidad, permisos y repetibilidad

El coste por token puede engañar

Databricks pone un ejemplo que debería aparecer en cualquier análisis de adopción empresarial de IA. Sonnet 5 era aproximadamente 1,7 veces más barato por token que Opus 4.8, pero en sus tareas terminó costando más por tarea: 2,09 dólares frente a 1,94 dólares, con una tasa de finalización inferior, 81 % frente a 87 %. La razón fue que Sonnet 5 consumió alrededor de 1,9 veces más tokens para llegar al resultado.

La métrica importante, por tanto, no es el precio unitario del token, sino el coste total de resolver una tarea válida. En agentes de código eso incluye tokens de entrada, tokens de salida, razonamiento, llamadas a herramientas, reintentos, tiempo de ejecución, lecturas de contexto y fallos.

Este matiz será cada vez más importante en empresas que pasen de probar copilotos a operar agentes a escala. Un ahorro aparente en tarifa puede desaparecer si el modelo necesita muchas más vueltas para completar el trabajo o si el harness le alimenta con demasiada información irrelevante.

GLM 5.2 y el nuevo papel del open source

GLM 5.2 no aparece en este benchmark como una curiosidad barata, sino como una opción capaz de competir en tareas de alto nivel dentro de un entorno real. Z.ai presenta GLM 5.2 como un modelo open source con licencia MIT y orientado a tareas de largo horizonte, lo que refuerza su atractivo para empresas que quieren evaluar modelos abiertos junto a alternativas cerradas.

Esto no significa que todos los equipos puedan descargarlo y ejecutarlo sin coste operativo. Los modelos abiertos grandes requieren infraestructura, GPUs, memoria, ingeniería de inferencia, seguridad, observabilidad y operación. Pero sí cambia el equilibrio estratégico: una empresa puede incorporar modelos abiertos a su sistema de routing, usarlos para ciertas tareas, mantener alternativas cerradas para otras y medir todo contra sus propios resultados.

La lectura empresarial es especialmente clara. El proveedor único empieza a tener menos sentido cuando la calidad, el coste y la eficiencia cambian según tarea, modelo y harness. Una arquitectura madura de IA para desarrollo debería permitir probar, enrutar y sustituir modelos sin rehacer todo el flujo.

Databricks apunta en esa dirección al mencionar su interés por usar capacidades de routing inteligente en Unity AI Gateway y Omnigent para ayudar a sus desarrolladores a elegir agentes más adecuados manteniendo eficiencia y control.

Lo que deberían aprender los equipos de ingeniería

El estudio de Databricks deja varias lecciones prácticas. La primera es que los benchmarks públicos son solo el punto de partida. Sirven para explorar el mercado, pero la decisión real debe tomarse con tareas propias, tests propios y métricas propias.

La segunda es que el agente completo es la unidad de evaluación. Modelo, harness, herramientas, permisos, contexto, tests y flujo de revisión forman un sistema. Comparar solo modelos puede llevar a malas decisiones.

La tercera es que el routing será una pieza central. No todas las tareas necesitan el modelo más caro. Databricks observó que cerca de una cuarta parte de las tareas analizadas eran de baja complejidad y alrededor del 60 % de complejidad media, aunque los modelos caros tendían a usarse por defecto.

La cuarta es que el open source ya no puede quedarse fuera de la mesa. Si un modelo abierto puede entrar en el grupo alto de calidad con menor coste por tarea, al menos debe evaluarse. No siempre ganará, pero ignorarlo por defecto será cada vez más difícil de justificar.

La ingeniería asistida por IA entra así en una fase más adulta. Ya no basta con preguntar qué modelo escribe mejor código en una demo. Hay que medir qué agente resuelve mejor tareas reales, cuánto cuesta cada tarea completada, cuánta supervisión exige, qué riesgos introduce y cómo encaja en la arquitectura de desarrollo de la empresa.

El futuro de los agentes de código no estará dominado solo por el modelo más potente. Estará dominado por quien sepa combinar modelos, harnesses, tests y routing con datos propios. Databricks acaba de enseñar una forma bastante seria de empezar.

Preguntas frecuentes

¿Qué ha probado Databricks exactamente?
Ha evaluado agentes de código sobre tareas reales derivadas de pull requests internos, en un codebase de millones de líneas y con tests propios para validar si la solución funcionaba.

¿Por qué es importante GLM 5.2 en este benchmark?
Porque aparece en el grupo alto de capacidad y queda estadísticamente empatado con Opus 4.8 en calidad, pero con un coste por tarea inferior en la prueba de Databricks.

¿Qué es un harness en agentes de código?
Es la capa que gestiona herramientas, contexto, búsqueda de archivos, comandos de terminal, salidas de tests y la interacción entre el modelo y el repositorio.

¿Por qué el precio por token no basta para comparar modelos?
Porque un modelo más barato por token puede consumir muchos más tokens o necesitar más iteraciones. Lo relevante es el coste por tarea completada correctamente.

¿Deberían las empresas crear sus propios benchmarks?
Sí, especialmente si usan agentes de código a escala. Los PRs históricos, los tests y los cambios reales permiten medir rendimiento sobre tareas que reflejan su ingeniería, no problemas genéricos.