IDE-Bench: Evaluating Large Language Models as IDE Agents on Real-World Software Engineering Tasks
O IDE-Bench introduz um framework de avaliação abrangente e dockerizado, apresentando 80 tarefas em oito repositórios nunca publicados para avaliar as capacidades de agentes de IDE de IA em tarefas de engenharia de software multilingues do mundo real por meio de uma interface de ferramenta estruturada e nativa de IDE.
Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo
Imagine que você está contratando um novo desenvolvedor júnior para trabalhar em seu projeto de software. Você quer saber se ele realmente consegue fazer o trabalho: encontrar bugs, adicionar novos recursos e consertar códigos quebrados sem quebrar todo o resto.
Por muito tempo, testamos assistentes de codificação de IA dando a eles um único enigma para resolver em uma sala vazia. Mas o desenvolvimento de software real não é um enigma em uma sala; é como trabalhar em uma oficina movimentada e de alta tecnologia, repleta de ferramentas, plantas e outros trabalhadores.
IDE-Bench é uma nova "oficina" projetada para testar modelos de IA exatamente como eles serão usados no mundo real. Aqui está o detalhamento do que o artigo descobriu, usando analogias simples.
1. O Novo Teste: De "Lápis e Papel" para "A Oficina Completa"
Testes anteriores (como o SWE-Bench) eram como dar a um estudante um problema matemático em uma folha de papel e pedir que ele escrevesse a resposta. Eles não podiam usar uma calculadora ou consultar fórmulas; apenas tinham que adivinhar a resposta com base no que memorizaram.
O IDE-Bench é diferente. Ele dá à IA uma oficina Dockerizada (uma sala digital segura e isolada) e um conjunto completo de ferramentas, exatamente como as que os desenvolvedores usam em aplicativos como Cursor ou Windsurf.
- As Ferramentas: A IA pode pesquisar o código, ler arquivos, editar linhas, executar testes e até verificar bancos de dados.
- O Objetivo: A IA tem que agir como um engenheiro real. Ela não pode apenas adivinhar; ela tem que explorar, fazer mudanças, verificar se funcionam e corrigir erros se algo quebrar.
2. Os Livros de Receitas "Secretos"
Para garantir que a IA não tenha apenas memorizado as respostas da internet, os pesquisadores criaram 80 tarefas totalmente novas em 8 bases de código secretas.
- A Analogia: Imagine uma competição de culinária onde os juízes criam 8 receitas novas e nunca antes vistas. Os competidores (os modelos de IA) têm que cozinhá-las. Como essas receitas nunca foram publicadas online, a IA não pode trapacear procurando a solução em seus dados de treinamento.
- A Variedade: As receitas cobrem diferentes "cozinhas" (linguagens de programação): C/C++ (programação de sistemas), Java (aplicativos empresariais) e MERN (aplicativos web modernos).
3. Os Resultados: Quem é o Mestre Cuca?
Os pesquisadores testaram 15 modelos de IA diferentes. Aqui está o que eles descobriram:
- O Nível Superior (Os Mestres Cucas): Alguns modelos, liderados pelo GPT-5.2, resolveram cerca de 95% das tarefas. Eles eram como chefs que conseguiam ler a receita, pegar as ferramentas certas e cozinhar o prato perfeitamente na primeira tentativa.
- O Nível Intermediário (Os Cozinheiros Competentes): Modelos como Claude Sonnet e Claude Haiku resolveram cerca de 85–88% das tarefas. Eles são muito bons, mas podem precisar de uma segunda tentativa para chegar à perfeição.
- O Nível Inferior (Os Novatos): Muitos modelos de código aberto tiveram dificuldades, resolvendo menos de 50% das tarefas. Eles frequentemente se perdiam na oficina ou quebravam o código ao tentar consertá-lo.
4. O Problema do "Quase Lá"
Uma das descobertas mais interessantes é que pontuações binárias (Passou/Falhou) escondem muita nuance.
- A Analogia: Imagine um aluno que faz uma prova e acerta 11 de 12 questões. Em um sistema de avaliação rigoroso, ele recebe um "F" porque não atingiu 100%.
- A Realidade: No IDE-Bench, muitos modelos acertaram o núcleo do código, mas falharam por causa de detalhes minúsculos, como uma vírgula faltando ou uma formatação ligeiramente errada. O artigo chama isso de "quase acertos" (near misses).
- A Lição: Um modelo pode estar a 90% de uma solução, mas se ele errar os detalhes minúsculos, o teste o marca como um fracasso total. Isso sugere que, para o uso no mundo real, talvez não precisemos descartar o código e começar do zero; talvez só precisemos que um humano corrija os pequenos erros de formatação.
5. Eficiência vs. Minuciosidade
O artigo também analisou o quão "caro" era para a IA resolver uma tarefa (medido em "tokens", ou palavras de pensamento).
- O Rápido e Barato: Alguns modelos (como o Grok 4.1 Fast) foram muito eficientes. Eles resolveram as tarefas rapidamente e usaram menos recursos, mas falharam com mais frequência.
- O Lento e Minucioso: Outros modelos (como o Claude Opus) levaram muito tempo, leram muitos arquivos e pensaram profundamente. Eles tinham maior probabilidade de sucesso, mas custavam muito mais em termos de tempo e poder de computação.
- A Conclusão: Não existe um único "melhor" modelo. Se você quer velocidade e baixo custo, escolhe um tipo. Se precisa de alta confiabilidade e não se importa com o custo, escolhe outro.
6. Como Eles Falham
Os pesquisadores categorizaram como os modelos de IA falharam, o que é como um mecânico diagnosticando por que um carro não liga:
- Edição Prematura (63% das falhas): A IA começou a alterar o código antes mesmo de entender a planta. Foi como tentar consertar o motor de um carro sem abrir o capô primeiro.
- Oscilação/Thrashing (28%): A IA ficava alterando o mesmo arquivo para frente e para trás, desfazendo o próprio trabalho, como uma pessoa que não consegue decidir qual caminho seguir e fica andando em círculos.
- Perda de Contexto (27%): A IA esqueceu o que deveria estar fazendo no meio da tarefa, como um chef que começa a fazer um bolo, mas esquece que deveria estar fazendo uma pizza.
Resumo
O IDE-Bench prova que os melhores modelos de IA já são capazes de agir como verdadeiros engenheiros de software em um ambiente complexo e rico em ferramentas. No entanto, também mostra que:
- A especialização importa: Alguns modelos são ótimos em aplicativos web, mas ruins em código de sistemas de baixo nível.
- A perfeição é difícil: Chegar a 99% de uma solução é comum, mas o último 1% (os detalhes minúsculos) é onde a maioria dos modelos falha.
- A estratégia importa: A melhor abordagem pode ser usar um modelo "rápido" primeiro e, se ele falhar, mudar para um modelo "minucioso" para terminar o trabalho.
O artigo conclui que precisamos parar de olhar para uma única "pontuação" para julgar a IA e começar a observar como elas trabalham, no que são boas e quanto custa para realizar o trabalho.
Afogado em artigos na sua área?
Receba digests diários dos artigos mais recentes que correspondam às suas palavras-chave de pesquisa — com resumos técnicos, no seu idioma.