O agente não entende o domínio

Agentes de código reconhecem estrutura de implementação. Repositórios científicos e de negócio pedem outra coisa: preservar unidades, invariantes, sistemas de coordenadas, regras de domínio e contratos que não estão escritos na sintaxe. O benchmark SWE-bench Science (arXiv:2608.19799) montou 119 tarefas a partir de 98 repositórios GitHub, em 20 domínios científicos. O critério não é só gerar um patch que compile. É alterar o repositório sem quebrar os contratos científicos que o código carrega.

Mesmo a melhor configuração avaliada no leaderboard recente — Claude Code com Opus-5 (max) — ficou em cerca de 47,9% de pass@1, abaixo de 50%. No subconjunto Hard70, o mesmo agente cai para cerca de 21%. Os autores agrupam as falhas em quatro mecanismos recorrentes: déficit de conhecimento ou abstração científica (o agente não captura o fenômeno, a matemática ou a semântica que o código representa); exploração equivocada ou reparo superficial (corrige o sintoma, não a causa); cobertura incompleta ou falha de integração (o patch resolve um ponto e deixa outros quebrados); e falha em generalizar conhecimento de domínio (aplica uma regra observada num caso onde ela deixa de valer).

Uma ablação no mesmo estudo remove a orientação científica explícita e mantém o repositório e o contexto executável. Informação de domínio bem ancorada pode restringir o reparo e melhorar desempenho médio e eficiência de tokens. Orientação mal alinhada induz ancoragem no caminho errado e não garante sucesso no reparo. O padrão de código continua acessível; o domínio, não.

O mesmo padrão em software de negócio

Em software de negócio o mesmo desenho aparece sob outra roupagem: regras de compliance, invariantes de produto, contratos entre serviços, políticas de risco. O agente que "conserta" o sintoma sem carregar o significado do domínio produz patch plausível e regressão cara.

Um caso documentado no GitHub ilustra o problema em escala de produção. O agente de codificação do Copilot introduziu código que acessava uma propriedade diretamente quando a API pública exigia um método. O código compilou, os testes passaram, e o PR foi mergeado. A quebra só apareceu quando o runtime tentou executar a linha: System.MissingMethodException em produção. O agente não sabia que aquela propriedade havia sido refatorada para um método com semântica diferente. Ele reconheceu o padrão "acessar dado" e aplicou a sintaxe que parecia mais natural. O domínio dizia outra coisa.

Outro caso, reportado em fórum técnico, envolve um agente que reescreveu uma função de cálculo financeiro usando float no lugar de decimal. O patch compilou, os testes unitários passaram com valores pequenos, e o código foi para produção. A regressão só apareceu quando valores grandes de transação começaram a apresentar erro de arredondamento. O agente não sabia que, em domínio financeiro, ponto flutuante não é aceitável para valores monetários. Essa regra não estava no código, nem no enunciado, nem nos testes que ele podia ler.

Um terceiro caso, em contexto de compliance, mostra um agente removendo uma verificação de autorização porque ela parecia redundante dado o fluxo de chamadas. O código funcionava. O problema era que aquela verificação existia para satisfazer um requisito regulatório específico - não para corrigir um bug. O agente não tinha como saber, porque o requisito não estava escrito em lugar nenhum que ele conseguisse ler.

Onde o domínio deveria estar

O padrão que emerge dos três casos é o mesmo. O agente reconhece estrutura. Ele não reconhece intenção. Quando a intenção não está explícita no contexto — documentação, testes de contrato, invariantes nomeadas —, o agente preenche a lacuna com o padrão mais provável.

A implicação prática para quem usa agentes em produção é direta. Liberar agente para editar código em áreas onde o domínio não está explícito é pedir que o modelo invente a semântica que não leu. A distinção entre "código que compila" e "código que respeita o domínio" não é automática. Ela depende de alguém ter escrito, em algum lugar acessível ao agente, o que aquele código deveria preservar.

O estudo do SWE-bench Science sugere um caminho. Informação de domínio bem ancorada — documentação, testes de propriedade, contratos nomeados — restringe o reparo e melhora o desempenho. Orientação genérica ou mal alinhada não ajuda. A pergunta que fica não é "o agente consegue ler o código?". É "o agente consegue ler o domínio?".

Quem quiser aprofundar o tema de forma estruturada — do contexto à governança de agentes — encontra o assunto tratado na coleção Engenharia de Software Assistida por IA.

• Cupom de 30% OFF nos eBooks: LEIA30

• Disponível também no Kindle Unlimited

https://livro-engenharia-de-software-assistida-por-ia.aspepper.workers.dev/?utm_source=hashnode&utm_medium=article&utm_campaign=serie_ia

Fontes da Pesquisa

1. arXiv:2608.19799 — SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science? — Xu et al.. 119 tarefas de 98 repositórios GitHub em 20 domínios científicos. Melhor agente (Claude Code + Opus-5 max) atinge ~47,9% de pass@1 overall e ~21% no subconjunto Hard70. Quatro mecanismos de falha: déficit de abstração científica, reparo superficial, cobertura incompleta, falha em generalizar conhecimento de domínio. Ablação mostra que orientação de domínio bem ancorada ajuda; orientação mal alinhada induz ancoragem errada.
2. Leaderboard SWE-bench Science (swescience.github.io, out/2026) — Claude-Opus-5 (max): ~47,9% overall; Hard70: ~21%. Confirma os números do paper.
3. GitHub Copilot — Discussões de incidentes em produção. Caso documentado de código gerado que acessava propriedade diretamente quando a API exigia método. MissingMethodException em runtime após merge.
4. Fóruns técnicos — Relatos de regressão pós-merge. Casos de agente reescrevendo cálculo financeiro com float em vez de decimal, removendo verificação de autorização que atendia requisito regulatório, e introduzindo MissingMethodException por uso incorreto de API. Padrão comum: código compila, testes passam, regressão aparece em produção.
5. SWE-bench Science — Ablation Study — Remoção de orientação científica explícita mantém repositório e contexto executável. Informação de domínio bem ancorada melhora desempenho e eficiência de tokens. Orientação mal alinhada piora resultado.

#EngenhariaDeSoftware #IA #InteligenciaArtificial #CodingAgents #SWEBenchScience #Dominio #GovernancaIA #AgentesDeCodigo #EngenhariaDeSoftwareAssistidaPorIA