SWE-agent: Como o Design de Interface Desbloqueia a Engenharia de Software Automatizada

Na semana passada, li o artigo do SWE-bench e saí com uma conclusão simples: o GPT-4 puro resolve apenas 1,96% dos problemas reais do GitHub. Esta semana, quis entender a pergunta seguinte — o que realmente faz esse número subir? O SWE-agent de Yang et al. (NeurIPS 2024) responde a isso, e a resposta é deceptivamente comum: interfaces melhores.

O artigo

O SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan e Ofir Press; Princeton / Stanford) introduz o conceito de uma Interface Agente-Computador (ACI) — uma camada de software construída propositalmente que fica entre um LLM e um ambiente Linux, projetada não para usuários humanos, mas para a forma como os modelos de linguagem realmente processam informações. A alegação é que o design desta interface, e não o modelo subjacente, é o principal gargalo para agentes autônomos de engenharia de software.

O sistema opera em problemas do GitHub do SWE-bench: ele lê o problema, navega no repositório, localiza o código relevante, edita-o e executa testes para verificar a correção. A contribuição inovadora não é um novo modelo ou procedimento de treinamento, mas um conjunto de primitivas de comando e formatos de feedback cuidadosamente projetados que substituem o shell Linux padrão.

Ideias principais

• A interface supera o shell puro em 10,7 pontos percentuais. Em uma ablação sobre 300 instâncias do SWE-bench Lite, o SWE-agent resolve 10,7pp a mais de problemas do que um agente idêntico colocado em um shell Linux comum. Essa é a maior alavanca individual do artigo.
• Visualizador de arquivos com janelas de 100 linhas. Em vez de dar um cat em arquivos inteiros, a ACI mostra cerca de 100 linhas por vez com comandos de rolagem. Pouco contexto (30 linhas) custa 3,7pp; contexto demais (arquivo inteiro) faz o modelo perder o foco. O ponto ideal é estreito.
• Um linter no loop de edição. Cada comando de edição executa um verificador de sintaxe antes de confirmar a alteração. Isso evita que o modelo fique preso em estados de código quebrado que são difíceis de escapar apenas via linguagem natural.
• Busca de diretório minimalista. Em vez de grep -r com contexto circundante (que sobrecarregava o modelo), a ACI retorna apenas uma lista de nomes de arquivos correspondentes. Menos é mais quando o modelo precisa decidir onde olhar em seguida.
• Resultado total do benchmark: 12,47% no SWE-bench com GPT-4 Turbo, versus um sistema RAG não interativo de 3,8% e 1,96% para a linha de base de recuperação simples do artigo original do SWE-bench. O HumanEvalFix atingiu 87,7%.
• O design da ACI se generaliza. Uma variante de cibersegurança (SWE-agent EnIGMA) aplicou a mesma filosofia de ACI a desafios de CTF, alcançando 13,5% — três vezes mais forte do que sistemas anteriores — usando ferramentas de agente interativas que mantêm sessões de shell simultâneas.

O que se sustenta — e o que não se sustenta

O insight central — que o design de interface para agentes é tão importante quanto a engenharia de prompt — é bem fundamentado e eu o considero genuinamente útil. A ablação é honesta: os autores isolam componentes e mostram o que cada um contribui. O ganho de 10,7pp sobre a linha de base do shell puro é um resultado claro que não pode ser explicado por diferenças de modelo.

O que me convence menos: o benchmark em si. O conjunto de testes do SWE-bench contém problemas que variam enormemente em complexidade, ambiguidade e quão bem o patch de referência é especificado. A alta variância na qualidade do problema significa que o número de 12,47% é, em parte, uma afirmação sobre quais problemas acabaram caindo no conjunto de avaliação. Os autores observam isso implicitamente ao relatar resultados no SWE-bench Lite (300 problemas) para as ablações, mas a variância dentro desse subconjunto ainda é alta.

A maior limitação é o escopo: o SWE-bench mede a resolução de problemas únicos isoladamente. Não há memória de sessão entre problemas, não há compreensão do histórico da base de código e não há rastreamento de dependência entre múltiplos problemas. O SWE-Bench Pro (arXiv:2509.16941, 2025) mostrou posteriormente que mesmo os modelos de fronteira caem abaixo de 25% quando os problemas exigem mudanças coordenadas em vários arquivos — o desempenho decai acentuadamente conforme o número de arquivos aumenta. A ACI ajuda dentro de um único problema, mas o problema difícil é o caso de longo prazo e de múltiplos arquivos para o qual o SWE-agent nunca foi projetado para resolver.

Há também uma questão de reprodutibilidade à qual sempre retorno: as escolhas de design da interface (janela de 100 linhas, saída de busca minimalista) foram encontradas por experimentação iterativa no conjunto de treinamento/desenvolvimento. Essas escolhas não são obviamente transferíveis para novos domínios sem um esforço de ajuste semelhante. Esse é um custo real.

Por que isso importa para a IA financeira

O enquadramento da ACI mapeia diretamente o problema de design do agente Beancount. Um livro razão (ledger) do Beancount não é uma linha de comando, mas é um artefato estruturado que um modelo precisa ler, navegar e escrever. As lições se transferem:

• Um visualizador de livro razão que mostra de 20 a 50 transações por vez — com comandos de rolagem e filtro — superará um que despeja 10 anos de dados de uma só vez. O estouro da janela de contexto é o mesmo modo de falha.
• Um validador de escrita que verifica o saldo de partidas dobradas e a existência da conta antes de confirmar um lançamento é o equivalente contábil ao linter do SWE-agent. Sem ele, um agente que produz um lançamento sintaticamente errado não tem caminho de recuperação.
• A busca minimalista importa: consultar "mostre-me todas as transações na conta X entre as datas Y e Z" deve retornar uma lista compacta e escaneável, não um despejo detalhado com contexto circundante.

O artigo também define um benchmark prático para o que esperar das primeiras versões de um agente de escrita (write-back) do Beancount. Uma taxa de resolução de 12,47% em problemas bem definidos do GitHub é o teto atual para um agente de problema único cuidadosamente projetado. A escrita no livro razão envolve uma estrutura de tarefa semelhante — uma intenção do usuário, um arquivo estruturado, uma saída necessária, um verificador — e eu esperaria taxas comparáveis em tarefas bem definidas, com degradação acentuada em fluxos de trabalho de múltiplos lançamentos e múltiplas contas.

O que ler a seguir

• MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] — O gerenciamento de contexto do SWE-agent é reativo (truncar no estouro); o MemGPT propõe memória em camadas proativa, o que parece necessário para agentes que precisam raciocinar sobre livros razão Beancount de vários anos.
• SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] — Acompanha diretamente onde o SWE-agent falha; os dados de degradação em múltiplos arquivos são leitura essencial para projetar segurança de escrita em livros razão complexos.
• Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] — Se a ACI trata do design de interface, o Gorilla trata da recuperação de APIs; os dois se combinam em uma visão mais completa de como os agentes devem selecionar e invocar ferramentas de forma confiável.