O benchmark resolve a issue. Seu agente precisa sobreviver à conversa
O estudo da JetBrains mostra como requisitos em etapas alteram custo e resolução, exigindo avaliações mais próximas da sessão inteira.
A JetBrains Research comparou 4.782 sessões de agentes em IDEs, com cerca de 14 mil mensagens de desenvolvedores, a coleções públicas e ao SWE-Bench Pro.[6] No uso observado, correções e novas funcionalidades somavam menos da metade dos pedidos; no benchmark, 93,8% das tarefas se concentravam nessas duas categorias, entregues em uma especificação única.[6]
A diferença é relevante para escolher ferramentas. Resolver um pedido completo é uma habilidade. Manter requisitos enquanto recebe perguntas, ajustes e novas restrições é outra dimensão que merece medição própria.
O que muda para quem desenvolve
O SWE-TaskFlow propõe dividir uma issue em três pedidos sequenciais e, em parte dos casos, inserir perguntas sobre o código.[6] No piloto com quatro modelos, a apresentação em etapas elevou o custo por tarefa entre 2,0 e 2,6 vezes; três modelos tiveram quedas médias de resolução de 4 a 5 pontos, enquanto outro permaneceu estável.[6]
O recado não é que conversar seja um erro. Minha leitura é que preço por token e desempenho em patch isolado são informações insuficientes para estimar o custo de uma colaboração. O orçamento deve considerar explicação, retomada, correção e verificação, não só a primeira implementação.
O estudo também encontrou 50,9% de sessões com uma única mensagem, e sua análise interativa se concentrou nas sessões com pelo menos três.[6] Portanto, não convém substituir um retrato simplificado por outro: há diferentes padrões de uso.
Como aplicar
Monte uma avaliação com um repositório descartável e um requisito pequeno, cujo resultado possa ser verificado por testes. Prepare duas versões do mesmo roteiro.
Na primeira, apresente todos os requisitos juntos. Na segunda, apresente a implementação inicial, depois acrescente uma restrição e, por fim, peça explicação e revisão. Mantenha os requisitos finais equivalentes para não comparar dificuldades diferentes sem perceber.
Registre custo total, tempo, testes aprovados e restrições esquecidas. Acrescente uma checagem de escopo: o agente alterou arquivos que não precisava? Conseguiu explicar a mudança sem inventar símbolos? O experimento não precisa gerar um ranking universal. Precisa responder qual ferramenta funciona no fluxo que você pretende adotar.
Defina antecipadamente como tratar falhas de execução e pedidos de esclarecimento. Caso contrário, uma sessão interrompida pode parecer barata apenas porque não terminou o trabalho.
Cuidados e limites
Os autores não apresentam o piloto como ranking definitivo; há limitações de amostra, classificação e interação, pois as mensagens são fixadas antes da execução e não reagem ao agente.[6] Também alertam que comportamentos raros e perigosos exigem testes específicos.[6]
Por isso, recomendo manter dois conjuntos: um representativo das tarefas frequentes e outro voltado a falhas de alto impacto. Frequência e gravidade não são o mesmo eixo. Uma avaliação que imita bem a rotina ainda pode deixar justamente o pior caso fora do campo de visão.