🤖 AI

When Does Restricting a Coding Agent to execute_code Help? A Regime $\times$ Agent-Design Ablation

Este artículo demuestra que restringir a los agentes de codificación a una única herramienta `execute_code` es a menudo tan efectivo como y frecuentemente más económico que utilizar entornos ricos en herramientas, revelando que la superficie de herramientas óptima está determinada conjuntamente por la interacción entre los regímenes de tareas y los diseños de agentes específicos, en lugar de por cualquiera de los dos factores por sí solo.

Autores originales: Hong Yang, Qi Yu, Travis Desell

Publicado 2026-07-14

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Hong Yang, Qi Yu, Travis Desell

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

Imagina que tienes un asistente robot superinteligente cuyo trabajo es arreglar código roto o resolver acertijos matemáticos. Ahora mismo, hay un gran debate en el mundo tecnológico sobre cómo este robot debería hablar con la computadora para lograr su objetivo.

Algunos dicen: "¡Dale una caja de herramientas completa con botones especiales para cada tarea!" (Como un IDE sofisticado).
Otros dicen: "¡Solo dale una línea de comandos y deja que escriba comandos de shell!" (Como un hacker en una película).
Un tercer grupo dice: "¡No! ¡Simplemente deja que el robot escriba un script de Python y lo ejecute todo de una vez!" (El enfoque execute_code).

Este artículo es como un juez gigante y justo que organiza una carrera para ver qué método realmente ahorra dinero y logra el trabajo. No solo adivinaron; corrieron exactamente el mismo robot (dos modelos diferentes: Claude y Codex) en las mismas tareas, pero cambiaron solo las herramientas que se les permitía usar.

Aquí está lo que encontraron, desglosado en historias simples.

El Descubrimiento Principal: Depende del Robot y del Trabajo

¿La mayor sorpresa? No existe una única "mejor" herramienta. El ganador cambia dependiendo de quién es el robot y qué está haciendo.

Piénsalo así:

El Trabajo de "Acertijo Matemático" (Tareas de Artifact): Si el robot está haciendo cálculos o procesamiento de datos, el método de "escribir un script y ejecutarlo" (code_only) es el claro ganador. Es como contratar a un chef que simplemente escribe una receta perfecta y cocina toda la comida de un tirón.
- Para el robot Claude, este método ahorró un 24.6% en costos.
- Para el robot Codex, ahorró aproximadamente un 6.7% (aunque el artículo dice que este resultado es un poco inestable, como el lanzamiento de una moneda).
- Veredicto: Para matemáticas y datos, el método del script es más barato y tan bueno como el otro para resolver el problema.
El Trabajo de "Arreglar un Código Desordenado" (Tareas de SWE-bench): Esto es donde se pone complicado. Estas tareas implican editar muchos archivos en un proyecto complejo.
- Si usas el robot Codex: ¡El método del script sigue siendo el campeón! Ahorró un 19.9% en costos. ¿Por qué? Porque el método del script permite al robot agrupar muchas solicitudes pequeñas en un solo paquete grande, como un camión de reparto que transporta 50 paquetes en lugar de una persona caminando 50 veces.
- Si usas el robot Claude: ¡Oh, no! El método del script fue en realidad más caro (un 14.4% más), aunque el artículo señala que esta no fue una diferencia estadísticamente "probada", solo una tendencia fuerte. ¿Por qué? Porque para Claude, escribir un script para editar un archivo es como intentar cambiar una llanta construyendo primero un auto nuevo. Requiere demasiadas palabras (tokens) para explicar la edición en código, creando "fricción de edición".

Lo que el Artículo Descarta

El artículo argumenta explícitamente en contra de la idea de que una superficie de herramienta sea siempre mejor para todos.

Descarta: "Los botones de un IDE especial son siempre requeridos". (Porque el método del script ganó en Codex).
Descarta: "Los comandos Bash son siempre suficientes". (Porque el método del script fue más barato para Claude en tareas de matemáticas).
Descarta: "La ejecución de código es siempre la más barata". (Porque fue más cara para Claude en correcciones de código complejas).

Los autores son muy claros: No puedes elegir una herramienta basándote solo en la herramienta misma. Tienes que mirar la combinación del cerebro del robot y el tipo de trabajo.

La Sorpresa de la "Tasa de Aprobación"

Aquí está la parte más importante: El costo cambió, pero la tasa de éxito no.

Imagina a dos corredores. Uno corre con botas pesadas (herramientas caras) y otro corre con zapatillas (herramientas baratas). El artículo encontró que ambos corredores terminaron la carrera exactamente a la misma velocidad.

Ya fuera que el robot usara la caja de herramientas elegante, los comandos bash o el método del script, el porcentaje de tareas que resolvieron correctamente fue casi idéntico (dentro de un margen de 3 puntos porcentuales).
El método del "script" no hizo al robot más inteligente o más tonto; solo cambió cómo caminaba hacia la meta. A veces ese caminar fue un sprint (barato), y otras veces fue un tropezón (caro).

¿Por qué Cambiaron los Costos?

El artículo investiga por qué el método del script fue más barato o más caro.

El Impuesto de la "Fricción de Edición" (Para Claude): Cuando Claude tenía que usar el método del script para arreglar un archivo, tenía que escribir un largo script de Python solo para decir "cambia la línea 5". Esto consumió muchos "tokens de salida" (palabras que el robot tenía que escribir). Fue como pagar un peaje cada vez que querías pasar una página. Esto sucedió principalmente en las tareas donde el robot fallaba o tenía dificultades, haciendo que esas ejecuciones específicas fueran muy caras.
El Bono de "Agrupación" (Para Codex): Cuando Codex usó el método del script, pudo empaquetar muchos comandos pequeños en un solo script. En lugar de pedirle a la computadora "Lee el archivo A", luego "Lee el archivo B", luego "Lee el archivo C" (tres viajes separados), le pidió "Lee A, B y C" de una sola vez. Esto ahorró muchísimos "tokens de entrada" (palabras que el robot tenía que leer).
El Efecto de la "Ejecución Condenada": El costo adicional para Claude en las tareas de corrección de código ocurrió principalmente cuando el robot ya iba a fallar. Fue como un auto quedándose sin gasolina mientras conduce en círculos. El método del script no causó el fallo; solo hizo que el intento fallido costara más dinero.

¿Qué tan Seguros Estamos?

Los autores están muy seguros de los resultados en las tareas matemáticas y del robot Codex. Corrieron estas pruebas en 93 tareas matemáticas y 100 de corrección de código, usando tres "semillas" (puntos de partida aleatorios) diferentes para cada una para asegurar que los resultados no fueran solo suerte. Los ahorros para Codex en las tareas de corrección de código fueron estadísticamente significativos (una caída del 19.9% con un p-valor de 2.0 × 10⁻⁹, que es básicamente cero probabilidad de ser al azar).

Sin embargo, para el robot Claude en las tareas de corrección de código, el resultado es un poco más difuso. El costo aumentó un 14.4%, pero la prueba estadística dijo que esto no fue una prueba "contundente" (p-valor de 0.12). Los autores lo llaman "direccional", lo que significa que la tendencia está ahí, pero necesitarían realizar las pruebas más veces para estar 100% seguros de que no es una casualidad.

La Conclusión Final

Si estás construyendo un agente de programación:

No adivines. La "mejor" herramienta depende de tu robot específico y de tu trabajo específico.
Para Matemáticas/Datos: Prueba el método de "escribir un script". Es más barato y funciona igual de bien.
Para Corrección de Código: Depende. Si usas Codex, el método del script es genial. Si usas Claude, es posible que quieras mantener las herramientas de edición estándar, especialmente para problemas difíciles, porque el método del script podría estancarse en la "fricción de edición".
No te preocupes por la inteligencia: Cambiar las herramientas no hará a tu robot más inteligente o más tonto; solo cambia el precio del viaje.

El artículo concluye que la forma "más barata" de ejecutar un agente no es una regla universal; es un rompecabezas donde tienes que hacer coincidir la herramienta con el robot y la tarea.

Resumen Técnico: ¿Cuándo ayuda restringir un Agente de Codificación a `execute_code`?

Planteamiento del Problema

El campo de los agentes de codificación opera actualmente bajo tres afirmaciones mutuamente incompatibles respecto a la superficie de herramientas óptima (el conjunto de interfaces expuestas al agente):

Se requieren primitivas de IDE especializadas: Las interfaces estructuradas (por ejemplo, la Interfaz de Agente-Computadora o ACI) superan significativamente al acceso directo a la shell (como argumenta SWE-agent).
Bash es suficiente: Los andamiajes mínimos de solo bash pueden lograr un rendimiento competitivo en benchmarks de ingeniería de software sin las primitivas de un IDE.
La ejecución de código es óptima: Dirigir las acciones del agente a través de una única herramienta execute_code (vía Model Context Protocol, MCP) reduce drásticamente el uso de tokens en comparación con llamar a herramientas nativas directamente.

Los trabajos previos han fallado en resolver estas contradicciones porque los estudios existentes fijan una sola variable (por ejemplo, comparar ACI vs. shell en un modelo específico) sin cruzar el régimen de la tarea (computación vs. modificación de código) y el diseño del agente (diferentes familias de modelos). En consecuencia, el campo carece de una comprensión unificada de qué condiciones favorecen cada superficie de herramientas.

Metodología

Los autores llevan a cabo una "comparación cruzada faltante" utilizando un estudio de ablación de tres brazos con integridad limpia. El diseño experimental es una estructura factorial de $3 \times 2 \times 2$ :

Tres Superficies de Herramientas:
- Baseline (Base): La superficie de herramientas predeterminada del agente (ej. Read, Grep, Edit, Write, Bash).
- Bash_Only (Solo Bash): Restringido a bash nativo más navegación de solo lectura (Read, Glob, Grep); todas las primitivas de edición de archivos (Edit, Write) son eliminadas.
- Code_Only (Solo Código): Toda la superficie nativa es reemplazada por una única herramienta MCP (mcp__codebox__execute_code) que ejecuta un REPL persistente de Python+Bash. Todas las funciones integradas nativas están prohibidas.
Dos Agentes: Claude Code (modelo claude-sonnet-4-6) y OpenAI Codex CLI (modelo gpt-5.5).
Dos Regímenes de Tarea:
- Computación: Una nueva suite "Artifact" ( $n=93$ ) que consiste en tareas autónomas definidas por un espacio de trabajo, un evaluador oculto y una salida de referencia.
- Modificación: SWE-bench Mini ( $n=100$ ), un subconjunto curado de tareas de modificación de repositorios.

Controles Experimentales:

Integridad: El entorno de ejecución impone un protocolo estricto de SWE-bench donde los parches de prueba se aplican después de que el agente termina. Los estados del sistema de archivos están aislados entre brazos usando fuse-overlayfs para evitar la contaminación cruzada.
Contabilidad de Costos: Para abordar la variabilidad del almacenamiento en caché de prompts en el servidor, los autores emplean una métrica de "costo ajustado por caché". Esto aplica un ajuste de mediana-suelo a los tokens de entrada del primer turno, normalizando la lotería de caché "caliente/fría" sin pretender un aislamiento total de la caché.
Rigor Estadístico: La unidad de inferencia es la tarea, no la semilla. Los resultados se analizan mediante pruebas de rango firmado de Wilcoxon pareadas sobre las diferencias por tarea a través de tres semillas independientes.

Contribuciones Clave

1. Una Estructura de Costo Condicional al Agente de Cuatro Celdas

El estudio revela que la rentabilidad de restringir un agente a execute_code no es universal, sino que está determinada conjuntamente por el régimo de la tarea y el diseño del agente.

Tres de las cuatro celdas favorecen a code_only:
- Artifact/Claude: Reducción significativa de costos ( $-24.6\%$ , $p=7.4 \times 10^{-14}$ ).
- Artifact/Codex: Reducción de costos direccional ( $-6.7\%$ , no significativo).
- SWE-bench/Codex: Reducción significativa de costos ( $-19.9\%$ , $p=2.0 \times 10^{-9}$ ).
Una celda revierte la tendencia:
- SWE-bench/Claude: code_only es direccionalmente más costoso ( $+14.4\%$ , no significativo).

Este hallazgo demuestra que las tres afirmaciones previas en la literatura no son contradictorias, sino que son ciertas solo bajo combinaciones específicas de (régimen, agente).

2. Descomposición Causal de Tres Mecanismos

Los autores descomponen las variaciones de costo observadas en tres mecanismos distintos:

Costo de Ruta (Fricción de Edición): En Claude para SWE-bench, code_only obliga a que cada edición de archivo se exprese como un script de Python. Esto escala los tokens de salida con el volumen de edición (Spearman $\rho=0.488$ ), creando un "impuesto" en tareas de alta edición.
Costo de Fallo: El exceso de costo para Claude en SWE-bench se localiza en las trayectorias de "ejecución condenada" (instancias donde todos los brazos fallan). En el subconjunto de instancias de aprobación unánime, la brecha de costo colapsa de $+14.4\%$ a $+4.1\%$ (no significativo).
Asimetría de Precios (Loteo): En Codex para SWE-bench, code_only logra ahorros significativos ( $-19.9\%$ ) principalmente a través de la reducción de tokens de entrada ( $-24.8\%$ ). Esto es impulsado por el loteo de llamadas a herramientas (un script de Python reemplaza múltiples llamadas a herramientas nativas) y la supresión programática de la salida (el agente restringe el volumen de salida, evitando los límites duros de salida de las herramientas nativas).

3. Invarianza de Capacidad

A través de las cuatro celdas y las tres superficies de herramientas, las tasas de aprobación están estadísticamente empatadas (diferencias $<3$ puntos porcentuales, todas no significativas).

La matriz de acuerdo muestra que para la mayoría de las instancias ( $\ge 91\%$ bajo voto de mayoría), todos los brazos pasan o fallan juntos.
Esto confirma que la selección de la superficie de herramientas altera el camino y el costo de resolver una tarea, pero no la capacidad para resolverla, lo cual es consistente con el "Principio de Solapamiento de Capacidad".

Resumen de Resultados

El artículo proporciona un mapa "de un vistazo" de cuándo es beneficioso code_only:

Tareas de Computación (Artifact): Restringir a execute_code es más barato para ambos agentes, con una victoria significativa para Claude.
Tareas de Modificación (SWE-bench) con Codex: Restringir a execute_code es significativamente más barato debido al loteo de tokens de entrada y al control de salida.
Tareas de Modificación (SWE-bench) con Claude: Restringir a execute_code es direccionalmente más costoso. Esto se debe a la "fricción de edición" (mayores tokens de salida para ediciones) y a los "costos de fallo" (trayectorias fallidas costosas), en lugar de una penalización en las ediciones exitosas.

Significancia y Reivindicaciones

El artículo afirma resolver las "tres afirmaciones contradictorias" del campo demostrando que ninguna superficie de herramientas única es óptima en todos los contextos.

Costo vs. Capacidad: La señal principal de la elección de la superficie de herramientas es el costo, no la tasa de aprobación. Dado que las tasas de aprobación son invariantes, la elección de la superficie es una decisión de ingeniería de costos más que una mejora de capacidad.
Determinación Conjunta: La superficie óptima está determinada por la intersección del régimen de la tarea (computación vs. modificación) y la implementación específica del agente (cómo maneja el loteo, los límites de salida y las primitivas de edición).
Evidencia Empírica: El estudio proporciona la primera evidencia empírica que respalda la desigualdad del "impuesto por uso de herramientas" en los agentes de codificación: una superficie de herramientas ofrece un beneficio neto solo cuando su ganancia de capacidad específica de la tarea supera el costo por llamada de su definición.

Los autores declaran explícitamente que sus hallazgos son reivindicaciones de ingeniería de costos, no de capacidad. No proponen que code_only sea universalmente superior, ni afirman que sus resultados se generalicen a todos los modelos o herramientas MCP externas sin validación adicional. La significancia reside en el marco metodológico que permite la desambiguación de los efectos de diseño del agente y del régimen, moviendo el campo de los reportes anecdóticos de la industria hacia estudios de ablación controlados y cruzados.