Resumo Técnico: Quando Restringir um Agente de Codificação a execute_code é Benéfico?

Declaração do Problema

O campo dos agentes de codificação opera atualmente sob três alegações mutuamente incompatíveis em relação à "superfície de ferramenta" ideal (o conjunto de interfaces expostas ao agente):

1. Primitivas de IDE Especializadas são Necessárias: Interfaces estruturadas (ex: Interface Agente-Computador ou ACI) superam significamente o acesso bruto ao shell, como argumentado pelo SWE-agent.
2. Bash é Suficiente: Scaffolds mínimos apenas de bash podem alcançar desempenho competitivo em benchmarks de engenharia de software sem primitivas de IDE.
3. Execução de Código é Ótima: Roteamento das ações do agente através de uma única ferramenta execute_code (via Model Context Protocol, MCP) reduz drasticamente o uso de tokens em comparação com a chamada de ferramentas nativas diretamente.

Trabalhos anteriores falharam em resolver essas contradições porque estudos existentes fixam uma única variável (ex: comparar ACI vs. shell em um modelo específico) sem cruzar o regime de tarefa (computação vs. modificação de código) e o design do agente (diferentes famílias de modelos). Consequentemente, o campo carece de uma compreensão unificada de quais condições favorecem cada superfície de ferramenta.

Metodologia

Os autores conduzem uma "comparação cruzada ausente" usando um estudo de ablação de três braços com integridade limpa. O design experimental é uma estrutura fatorial $3 \times 2 \times 2$:

• Três Superfícies de Ferramenta:
  • Baseline: A superfície de ferramenta padrão do agente (ex: Read, Grep, Edit, Write, Bash).
  • Bash_Only: Restrito ao bash nativo mais navegação de leitura (Read, Glob, Grep); todas as primitivas de edição de arquivo (Edit, Write) são removidas.
  • Code_Only: Toda a superfície nativa é substituída por uma única ferramenta MCP (mcp__codebox__execute_code) executando um REPL persistente de Python+Bash. Todos os built-ins nativos são proibidos.
• Dois Agentes: Claude Code (modelo claude-son-4-6) e OpenAI Codex CLI (modelo gpt-5.5).
• Dois Regimes de Tarefa:
  • Computação: Um novo conjunto "Artifact" ($n=93$) consistindo de tarefas autossuficientes definidas por um workspace, um avaliador oculto e uma saída de referência.
  • Modificação: SWE-bench Mini ($n=100$), um subconjunto curado de tarefas de modificação de repositório.

Controles Experimentais:

• Integridade: O harness impõe um protocolo estrito do SWE-bench onde os patches de teste são aplicados após a terminação do agente. Os estados do sistema de arquivos são isolados entre os braços usando fuse-overlayfs para evitar contaminação cruzada.
• Contabilidade de Custo: Para abordar a variabilidade de cache de prompt no lado do servidor, os autores empregam uma métrica de "custo ajustado por cache". Isso aplica um ajuste de piso da mediana aos tokens de entrada da primeira vez, normalizando a loteria de cache "quente/frio" sem alegar isolamento total de cache.
• Rigor Estatístico: A unidade de inferência é a tarefa, não a semente. Os resultados são analisados usando testes de postos sinalizados de Wilcoxon pareados nas diferenças por tarefa através de três sementes independentes.

Principais Contribuições

1. Uma Estrutura de Custo Condicional ao Agente de Quatro Células

O estudo revela que a custo-efetividade de restringir um agente a execute_code não é universal, mas determinada conjuntamente pelo regime de tarefa e pelo design do agente.

• Três de quatro células favorecem code_only:
  • Artifact/Claude: Redução significativa de custo ($-24,6\%$, $p=7,4 \times 10^{-14}$).
  • Artifact/Codex: Redução direcional de custo ($-6,7\%$, não significativo).
  • SWE-bench/Codex: Redução significativa de custo ($-19,9\%$, $p=2,0 \times 10^{-9}$).
• Uma célula inverte a tendência:
  • SWE-bench/Claude: code_only é direcionalmente mais caro ($+14,4\%$, não significativo).

Esta descoberta demonstra que as três alegações anteriores na literatura não são contraditórias, mas sim verdadeiras apenas sob combinações específicas de (regime, agente).

2. Decomposição Causal de Três Mecanismos

Os autores decompõem as variações de custo observadas em três mecanismos distintos:

• Custo de Caminho (Fricção de Edição): Para o Claude no SWE-bench, o code_only força cada edição de arquivo a ser expressa como um script Python. Isso escala os tokens de saída com o volume de edição (Spearman $\rho=0,488$), criando um "imposto" sobre tarefas de alta edição.
• Custo de Falha: O excesso de custo para o Claude no SWE-bench é localizado em trajetórias de "execução condenada" (instâncias onde todos os braços falham). No subconjunto de instâncias de aprovação unânime, a lacuna de custo colapsa de $+14,4\%$ para $+4,1\%$ (não significativo).
• Assimetria de Preços (Batching): No Codex para o SWE-bench, o code_only alcança economias significativas ($-19,9\%$) principalmente através da redução de tokens de entrada ($-24,8\%$). Isso é impulsionado pelo agrupamento de chamadas de ferramenta (um script Python substitui múltiplas chamadas de ferramentas nativas) e supressão programática de saída (o agente restringe o volume de saída, evitando os limites rígidos de saída das ferramentas nativas).

3. Invariância de Capacidade

Em todas as quatro células e três superfícies de ferramenta, as taxas de aprovação estão estatisticamente empatadas (diferenças $<3$ pontos percentuais, todas não significativas).

• A matriz de concordância mostra que para a maioria das instâncias ($\ge 91\%$ sob voto majoritário), todos os braços passam ou falham juntos.
• Isso confirma que a seleção da superfície de ferramenta altera o caminho e o custo para resolver uma tarefa, mas não a capacidade de resolvê-la, consistente com o "Princípio da Sobreposição de Capacidade".

Resumo de Resultados

O artigo fornece um mapa "num relance" de quando code_only é benéfico:

• Tarefas de Computação (Artifact): Restringir a execute_code é mais barato para ambos os agentes, com uma vitória significativa para o Claude.
• Tarefas de Modificação (SWE-bench) com Codex: Restringir a execute_code é significativamente mais barato devido ao agrupamento de tokens de entrada e controle de saída.
• Tarefas de Modificação (SWE-bench) com Claude: Restringir a execute_code é direcionalmente mais caro. Isso é impulsionado pela "fricção de edição" (maiores tokens de saída para edições) e "custos de falha" (trajetórias de falha caras), em vez de uma penalidade em edições bem-sucedidas.

Significância e Alegações

O artigo afirma resolver as "três alegações contraditórias" do campo ao demonstrar que nenhuma superfície de ferramenta única é ótima em todos os contextos.

• Custo vs. Capacidade: O sinal principal da escolha da superfície de ferramenta é o custo, não a taxa de aprovação. Como as taxas de aprovação são invariantes, a escolha da superfície é uma decisão de engenharia de custo, não de aumento de capacidade.
• Determinação Conjunta: A superfície ótima é determinada pela interseção do regime de tarefa (computação vs. modificação) e do design específico do agente (como ele lida com batching, limites de saída e primitivas de edição).
• Receita Empírica: O estudo fornece a primeira evidência empírica apoiando a desigualdade do "imposto de uso de ferramenta": uma superfície de ferramenta entrega benefício líquido apenas quando seu ganho de capacidade específica da tarefa excede o custo por chamada de sua definição.

Os autores declaram explicitamente que suas descobertas são alegações de engenharia de custo, não de capacidade. Eles não propõem que code_only é universalmente superior, nem alegam que seus resultados se generalizam para todos os modelos ou ferramentas MCP externas sem validação adicional. A significância reside no framework metodológico que permite a desambiguação dos efeitos de design de agente e de regime, movendo o campo de relatos anedóticos da indústria para estudos de ablação controlados e cruzados.