🤖 AI

The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation

Este artículo demuestra que el entorno de evaluación influye significativamente en el rendimiento y la eficiencia de los agentes de codificación —a menudo más que la elección del modelo subyacente— al revelar variaciones de hasta 40 veces en el uso de tokens y patrones de falla independientes del modelo, argumentando así a favor del reporte de las especificaciones completas del entorno y de métricas de tokens/latencia junto con las comparaciones de modelos.

Autores originales: Naman Vats, Oleg Golev

Publicado 2026-07-28

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Naman Vats, Oleg Golev

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

La mano invisible detrás del programador robot

Imagina que estás viendo una competencia de cocina. Ves a dos chefs brillantes, el Chef A y el Chef B, ambos intentando hornear el pastel de chocolate perfecto. Los jueces usualmente solo miran el pastel final y dicen: "¡El Chef A hizo un mejor pastel!". Pero, ¿qué pasaría si los jueces olvidaran mencionar que el Chef A estaba usando una cocina de alta tecnología, automatizada, que picaba cada ingrediente y precalentaba el horno al segundo exacto, mientras que el Chef B trabajaba en un cobertizo polvoriento con un cuchillo oxidado y una estufa rota? El resultado no se trata solo del talento de los chefs; se trata de la cocina que se les entregó.

En el mundo de la inteligencia artificial, específicamente de los "agentes de codificación" (programas de IA que escriben software), hemos estado haciendo exactamente eso. Hemos estado clasificando los modelos de IA basándonos en cuántos problemas de programación resuelven, mientras ignoramos la "cocina" en la que están trabajando. Esta cocina se llama harness (arnés o entorno de ejecución). Piensa en un harness como el asistente invisible que le entrega a la IA sus herramientas, gestiona su memoria y decide cuándo dejar de trabajar. Algunos harnesses son como un mayordomo robótico supereficiente que lo organiza todo perfectamente; otros son como un pasante caótico que sigue haciendo la misma pregunta una y otra vez, desperdiciando tiempo y energía. La gran pregunta que los investigadores se plantean es: ¿Importa más el cerebro de la IA, o la calidad de su asistente?

El gran experimento de la "cocina"

Un equipo de investigadores decidió dejar de suponer y empezar a medir. Organizaron un experimento masivo para ver qué sucede cuando intercambias la "cocina" (harness) manteniendo al "chef" (el modelo de IA) exactamente igual. Seleccionaron dos modelos de IA de codificación muy inteligentes, Qwen 3.6 Plus y MiniMax M2.5, y les pidieron resolver 50 acertijos de programación diferentes. Pero aquí está el giro: ejecutaron estos mismos modelos a través de tres harnesses de código abierto diferentes, llamados Goose, OpenCode y OpenHands-SDK.

Los resultados fueron impactantes, por decir lo menos.

Cuando los investigadores observaron cuántos acertijos resolvía la IA (la "tasa de éxito" o pass rate), la diferencia entre los harnesses fue mínima. Ya fuera que la IA estuviera usando Goose, OpenCode u OpenHands-SDK, resolvía aproximadamente el mismo número de problemas, generalmente entre el 38% y el 50%. Cambiar el harness no hizo que la IA se convirtiera repentinamente en un genio o en un fracaso; la tasa de éxito se mantuvo mayormente plana.

Sin embargo, cuando analizaron el costo de resolver esos problemas, la historia cambió por completo. Los investigadores midieron esto en "tokens", que son básicamente las unidades de datos que la IA procesa (como palabras o fragmentos de código). Encontraron que la elección del harness cambió el costo de manera asombrosa: 40 veces.

Para ponerlo en perspectiva: si el harness Goose ayudó a la IA a resolver un acertijo usando unos 28,000 tokens, el harness OpenCode hizo que esa misma IA utilizara más de 1.1 millones de tokens para resolver el mismo acertijo. ¡Esa es una diferencia de costo de 40 veces por el mismo resultado! Es como si un chef usara un solo huevo para hornear un pastel, mientras que el otro chef usa 40 huevos para el mismo pastel, simplemente porque sus herramientas de cocina son ineficientes.

El impuesto del "turno ocioso"

¿Por qué aumentó tanto el costo? Los investigadores descubrieron un culpable oculto: los turnos ociosos (idle turns).

Imagina que estás hablando con un amigo que intenta reparar tu computadora. A veces, simplemente se queda ahí pensando: "Hmm, déjame revisar esto...", sin escribir nada realmente o sin cambiar nada en la pantalla. En el mundo de la IA, estos se llaman "turnos de no acción". El harness OpenCode hizo que la IA se quedara en estos bucles de pensamiento aproximadamente 2 veces por tarea, mientras que el harness Goose solo hacía esto unas 0.2 veces.

Cada vez que la IA se queda en uno de estos bucles, tiene que enviar todo su historial de conversación de vuelta al servidor para mantener el registro de dónde se encuentra. Esto es como enviar un diario de 100 páginas cada vez que haces una pausa para pensar. Debido a que OpenCode hizo que la IA hiciera pausas para pensar con mucha más frecuencia, consumió tokens a un ritmo masivo. Los investigadores llaman a esto el "impuesto de espera por tarea" (per-task wait tax). No es solo un costo de dinero; es un costo de tiempo. Un desarrollador humano que observa a la IA tiene que esperar a través de estos bucles ociosos, mirando una pantalla que no está haciendo nada, simplemente quemando dinero y paciencia.

La "huella digital" del fracaso

El estudio también encontró que cada harness tenía su propia forma única de fallar, como una huella digital. Estos patrones no cambiaban según el modelo de IA utilizado; eran causados por el propio harness.

Goose era el cauteloso. Cuando se quedaba atascado, se detenía y decía: "No puedo hacer esto", en lugar de adivinar. Rara vez perdía tiempo intentando verificar una mala idea.
OpenHands-SDK era el persistente. Seguía intentando verificar sus respuestas o ejecutándose hasta alcanzar un límite estricto de cuántas veces podía intentarlo (el límite de "máximos turnos" o max turns).
OpenCode era el que se quedaba atrapado en bucles. Se quedaba sin tiempo (el límite de "tiempo de pared" o wall-time) o se quedaba en un estado de "congelamiento" (hang), dando vueltas sin terminar nunca.

Esto significa que, si eres un desarrollador, no solo estás eligiendo una IA; estás eligiendo un estilo de fracaso. ¿Quieres una IA que se rinda rápido y honestamente, o una que siga dando vueltas hasta que te quedes sin paciencia?

La gran conclusión

La principal lección de este artículo es que hemos estado viendo los benchmarks de codificación de IA de la manera incorrecta. Hemos estado clasificando modelos como Qwen o MiniMax como si fueran lo único que importa. Pero este estudio demuestra que el harness (la cocina) es tan importante como el modelo (el chef).

Si quieres saber cuánto te costará realmente una IA o cuánto tiempo tardará en terminar un trabajo, no puedes solo mirar el nombre del modelo. Tienes que mirar el par: el modelo y el harness en el que se está ejecutando. Un modelo inteligente en un mal harness puede ser 40 veces más caro que un modelo inteligente en un buen harness.

Los investigadores sugieren que, en el futuro, no deberíamos limitarnos a reportar la "Tasa de Éxito" (Pass Rate). Necesitamos reportar el costo por tarea resuelta, el número de turnos ociosos y los patrones de falla. Porque para un desarrollador humano real, la diferencia entre una tasa de éxito del 50% que cuesta $1 y una tasa de éxito del 50% que cuesta $40 es la diferencia entre una herramienta útil y un pozo sin fondo de dinero. El "Efecto Andamio" (Scaffold Effect) es real, y es hora de que dejemos de ignorar la mano invisible que guía al robot.

Resumen Técnico: El Efecto Andamio en los Agentes de Codificación

Declaración del Problema
Las tablas de clasificación públicas actuales para agentes de codificación clasifican principalmente los sistemas por nombre de modelo y tasa de éxito, tratando el "andamio" circundante (el harness que emite herramientas, gestiona el contexto y determina la terminación) como una constante fija o subespecificada. Este enfoque confunde el rendimiento del modelo con la eficiencia del andamio. Cuando los andamios varían, las métricas de rendimiento (tasa de éxito) y las métricas de eficiencia (uso de tokens, latencia) se entrelazan, oscureciendo el verdadero costo y la carga de supervisión requerida para desplegar un agente. El artículo argumenta que, para una evaluación centrada en el ser humano, la unidad de comparación debe ser el par andamio–modelo, no el modelo por sí solo, ya que el andamio dicta los costos del mundo real y la naturaleza de la supervisión humana requerida.

Metodología
Los autores realizaron un estudio controlado para aislar los efectos del andamio del modelo.

Modelos: Se evaluaron dos modelos de codificación agénticos recientes: Qwen 3.6 Plus y MiniMax M2.5.
Andamios (Harnesses): Se probaron tres andamios de código abierto distintos, cada uno con diferentes filosofías de andamiaje:
- Goose: Un agente de IDE pesado con inyección proactiva de árbol de archivos.
- OpenCode: Un agente de bucle de herramientas persistente sin precarga automática de contexto.
- OpenHands-SDK: Una arquitectura de micro-agente que cuenta con delegación de sub-agentes, reintentos internos y pasos de verificación explícitos.
Tareas: Se extrajo un subconjunto estratificado de 50 tareas del conjunto de datos Terminal-Bench Pro, que cubre ocho arquetipos (Corrección de errores, Construcción, Datos, Implementación, ML, Acertijos, Seguridad, Sistema). Todas las tareas utilizaron suites de evaluación pytest deterministas.
Protocolo: Todos los ensayos se ejecutaron a través de la API de OpenRouter con instrucciones de tarea e instrucciones de sistema idénticas (variando solo en el vocabulario específico de las herramientas). El estudio mantuvo constantes el manifiesto de la tarea, el entorno de sandbox y el límite de tiempo de ejecución (900 segundos), permitiendo que cada andamio operara con sus propias APIs de herramientas, gestión de contexto y lógica de reintento interna.
Métricas: El estudio midió las tasas de éxito, el total de tokens por tarea resuelta, los turnos promedio, los "turnos sin acción" (turnos sin ediciones de archivos o nuevos comandos) y una taxonomía de fallos de seis clases (RAZONAMIENTO, VERIFICACIÓN, TIEMPO, MÁXIMO DE TURNOS, COLGARSE, ERROR). La significancia estadística se evaluó mediante intervalos de confianza de bootstrap de tareas emparejadas del 95% ( $B=10,000$ ).

Resultos Clave

Disparidad de Costo de Tokens (La brecha de 40×): La elección del andamio indujo una diferencia masiva en la eficiencia. OpenCode consumió aproximadamente 40× más tokens por tarea resuelta que Goose (por ejemplo, ~1.5M de tokens frente a ~37K tokens para MiniMax). En contraste, actualizar el modelo manteniendo fijo el andamio resultó en una diferencia de solo 1.0–1.3× en el uso de tokens.
Estabilidad de la Tasa de Éxito: Dentro de un modelo fijo, las diferencias de tasa de éxito entre andamios fueron pequeñas, variando de 0 a 8 puntos porcentuales. La mayoría de las diferencias por pares fueron estadísticamente indistinguibles de cero (los CI del 95% incluían el cero), excepto la brecha más grande.
Huellas Dactilares de Fallos: Los modos de fallo específicos se replicaron en ambos modelos, lo que indica que son propiedades del andamio, no del modelo:
- Goose: Dominado por fallos de RAZONAMIENTO (detenerse cuando se queda atascado) con cero fallos de VERIFICACIÓN.
- OpenHands-SDK: Caracterizado por fallos de VERIFICACIÓN y MÁXIMO DE TURNOS, indicando una tendencia a persistir hacia el cierre o agotar los límites de iteración.
- OpenCode: Caracterizado por fallos de TIEMPO y COLGARSE (agotar los límites de tiempo de ejecución) con cero MÁXIMO DE TURNOS (debido a la falta de un indicador de presupuesto de turnos) y cero VERIFICACIÓN.
Turnos Sin Acción como Impuesto de Supervisión: OpenCode exhibió 10× más turnos sin acción (bucles de razonamiento inactivos) que Goose. Estos turnos acumulan tokens de contexto sin progresar, creando un "impuesto de espera por tarea" para los usuarios humanos que deben monitorear estos bucles inactivos.
Eficiencia de Pareto: Goose dominó la frontera de Pareto, ofreciendo tasas de éxito comparables a otros andamios a una fracción del costo de tokens. OpenCode fue dominado en Pareto por ambos otros andamios.

Contribuciones Clave

Cuantificación del Efecto Andamio: El estudio proporciona evidencia controlada de que la elección del andamio impulsa una brecha de 40× en los costos de tokens mientras desplaza las tasas de éxito en un máximo de 8 puntos porcentuales, demostrando que la eficiencia es mayoritariamente una propiedad del andamio.
Huella Dactilar de Fallos Independiente del Modelo: Los autores identifican que los modos de fallo específicos (por ejemplo, RAZONAMIENTO vs. VERIFICACIÓN vs. TIEMPO) son consistentes entre diferentes modelos cuando el andamio es fijo, probando que estos son sesgos estructurales del andamio.
Proxy Mecanicista para la Supervisión: El artículo introduce los "turnos sin acción" como un proxy de la carga de supervisión humana, enmarcándolos como un costo (tanto financiero como temporal) que un usuario con humano en el bucle debe absorber, distinto de los simples costos de tokens.
Unidad de Evaluación Propuesta: Los autores argumentan que el par andamio–modelo es la unidad correcta de comparación para la evaluación centrada en el humano, en lugar del nombre del modelo por sí solo.

Significancia y Reivindicaciones
El artículo afirma que el reporte actual de los benchmarks es incompleto porque aísla al modelo del andamio. Al reportar solo las tasas de éxito, las tablas de clasificación oscurecen el costo real, la latencia y el esfuerzo de supervisión requeridos para desplegar un agente. Los autores afirman que para el despliegue práctico, los desarrolladores deben evaluar los pares andamio–modelo bajo presupuestos específicos de tokens/latencia. Recomiendan que las evaluaciones futuras reporten tokens por tarea resuelta, promedio de turnos sin acción y vectores de categorías de fallos junto con las tasas de éxito para proporcionar una visión holística de la capacidad de despliegue de un agente. El estudio no pretende resolver el problema de la evaluación de agentes, sino sistematizar la observación de que la "elección del andamio" es un motor primario de la eficiencia y los perfiles de fallo, superando a menudo las actualizaciones del modelo.