No mundo do software moderno, um novo tipo de trabalhador surgiu: uma inteligência artificial que pode escrever código, corrigir erros e construir programas por conta própria. Esses sistemas, frequentemente chamados de agentes de codificação, foram treinados em vastas bibliotecas de instruções escritas por humanos e demonstraram uma habilidade notável em linguagens de programação de propósito geral, como Python. Eles podem resolver enigmas que antes levavam horas para serem decifrados por engenheiros humanos. No entanto, o mundo real do software empresarial é raramente tão simples. Grande parte da infraestrutura crítica que sustenta o comércio global depende de linguagens especializadas projetadas para setores específicos, onde as regras são diferentes, as ferramentas são únicas e os riscos são altos. Um desses ambientes é o mundo do planejamento de recursos empresariais (ERP), onde as empresas gerenciam tudo, desde o estoque até a folha de pagamento. Aqui, o software fala uma linguagem chamada AL, um dialeto especializado usado para rodar o sistema Microsoft Business Central. Durante anos, não estava claro se esses poderosos agentes de IA poderiam navegar nesse cenário proprietário e complexo ou se o sucesso deles na codificação geral era um fenômeno que desaparecia ao enfrentar restrições comerciais reais.

Para responder a essa pergunta, pesquisadores da Microsoft criaram um novo campo de testes chamado BC-Bench. Eles não inventaram um enigma teórico; em vez disso, mergulharam no código real e vivo de dois enormes repositórios de software que alimentam negócios reais. A partir desses arquivos digitais, selecionaram cuidadosamente 101 tarefas específicas que engenheiros haviam resolvido no passado. Estes não eram exemplos inventados, mas problemas genuínos: um erro que fazia com que o registro de um cliente falhasse, uma funcionalidade ausente em um relatório de vendas ou um teste que precisava ser escrito para capturar um erro. Os pesquisadores então pediram a vários dos agentes de IA mais avançados do mundo que tentassem realizar essas mesmas tarefas. Os agentes receberam a descrição original do problema, que às vezes incluía capturas de tela do erro, e um instantâneo do código como ele existia antes da correção. O objetivo deles era escrever exatamente as alterações de código necessárias para resolver o problema, tal como um engenheiro humano faria. O sistema então executava o software em um ambiente simulado para verificar se o novo código realmente corrigia o problema sem quebrar mais nada.

Os resultados revelaram um cenário onde a identidade do modelo de IA importava muito mais do que a ferramenta específica que ela usava para realizar o trabalho. Quando os pesquisadores compararam diferentes versões dos agentes, descobriram que a escolha do "cérebro" subjacente — o modelo de linguagem de grande escala — tinha um impacto muito maior no sucesso do que a escolha do invólucro de software, ou "harness", que o guiava. Por exemplo, um dos modelos mais recentes, o Claude Opus 4.6, resolveu quase 69 por cento das tarefas de correção de bugs quando pareado com uma ferramenta padrão, enquanto uma versão mais antiga do mesmo modelo resolveu apenas cerca de 58 por cento. Em contraste, trocar a ferramenta propriamente dita, mantendo o mesmo modelo, produziu apenas diferenças ínfimas e estatisticamente insignificantes. Isso sugere que, para essas tarefas comerciais complexas, a inteligência do modelo é o principal motor do sucesso, não a interface específica que ele utiliza para acessar o código.

Talvez a descoberta mais impressionante tenha sido que as melhorias observadas em testes de codificação geral não se traduzem automaticamente para este mundo especializado. No mundo mais amplo da engenharia de software, modelos mais novos frequentemente mostram ganhos constantes e previsíveis sobre seus predecessores. No entanto, neste ambiente de negócios específico, um modelo que havia superado recentemente seu antecessor em benchmarks gerais não mostrou a mesma vantagem aqui. Um modelo que havia melhorado significamente em tarefas gerais não teve um desempenho superior ao seu irmão mais antigo ao enfrentar esses enigmas de lógica de negócios. Isso indica que as habilidades necessárias para corrigir um script Python genérico não são as mesmas necessárias para corrigir um cálculo financeiro em um sistema de negócios especializado. A natureza especializada da linguagem, com suas regras estritas sobre como os dados fluem e como a lógica de negócios é validada, cria uma barreira que o treinamento geral sozinho não consegue superar facilmente.

Os pesquisadores também analisaram de perto por que os agentes falhavam quando falhavam. Eles descobriram que as máquinas raramente falhavam porque não conseguiam construir o software ou porque o código não compilava; esses obstáculos técnicos eram facilmente superados. Em vez disso, as falhas eram quase sempre relacionadas à compreensão do problema. Em quase metade das tentativas fracassadas, o agente olhava para a parte errada do código inteiramente, editando arquivos que não tinham relação com o erro. Em outro grande grupo de falhas, o agente encontrava o arquivo e a seção de código corretos, mas ainda assim aplicava a lógica errada, implementando uma solução que parecia correta, mas que não corrigia de fato a regra de negócio. Por exemplo, um agente poderia identificar corretamente que o número do pedido de um cliente estava faltando, mas então escreveria um código que atribuía o tipo errado de número, deixando o sistema quebrado. Esses erros sugerem que os agentes têm dificuldade em navegar pela rede profunda e interconectada de regras de negócio que definem como uma empresa opera, muitas vezes perdendo o contexto sutil que um engenheiro humano compreenderia imediatamente.

A complexidade da tarefa também desempenhou um papel decisivo. Quando a correção exigia alterar apenas um único arquivo ou um pequeno número de linhas, os agentes eram bastante bem-sucedidos. No entanto, assim que a solução exigia modificar múltiplos arquivos ou escrever mais de algumas dezenas de linhas de código, a taxa de sucesso caía drasticamente. Essa queda foi dramática, com a precisão caindo em mais de vinte pontos percentuais quando a tarefa envolvia mais de um arquivo. Parece que, embora esses agentes possam lidar com reparos pequenos e isolados, eles ainda têm dificuldade em coordenar mudanças através de um sistema grande e interconectado. Além disso, o tipo de área de negócio importava; os agentes foram mais bem-sucedidos em corrigir problemas de gestão de estoque do que em logística de armazém, sugerindo que seus dados de treinamento podem ter sido mais ricos em alguns domínios de negócios do que em outros.

O estudo conclui que, embora a inteligência artificial tenha feito progressos incríveis na codificação geral, o caminho para a engenharia totalmente autônoma em ambientes de negócios especializados ainda não está claro. As ferramentas existem, e os modelos são poderosos, mas a lacuna entre a capacidade geral e o domínio específico permanece ampla. Os pesquisadores enfatizam que, para avançar, a indústria precisa focar nesses benchmarks especializados em vez de confiar em testes gerais. Eles também apontam que as limitações atuais não são apenas sobre inteligência bruta, mas sobre a capacidade de entender o contexto, navegar em bases de código complexas e aplicar a lógica de negócios correta. À medida que esses sistemas evoluem, a esperança é que eles eventualmente aprendam a navegar pelas regras intrincadas do software de negócios com a mesma facilidade que agora demonstram na programação geral, mas, por enquanto, o engenheiro humano continua sendo essencial para guiá-los através das complexidades do mundo real.