Quatro em Cinco Bugs em Sistema Construído por IA Escaparam de Testes Automatizados, Aponta Estudo

Resumo

Um pesquisador da Amazon fez o modelo de IA Claude construir, numa única sessão longa, um pequeno sistema de software com várias partes, e depois catalogou cada bug introduzido. Quatro dos cinco bugs nunca foram pegos por um teste — só apareceram quando algo quebrou em execução. Separadamente, pesquisadores da Concordia University descobriram que o código escrito por IA tem problemas diferentes em escalas diferentes: funções isoladas pequenas ficam inchadas, com métodos longos demais, enquanto projetos completos com múltiplos arquivos apresentam problemas estruturais piores — e instruções mais detalhadas não resolveram isso. Nenhum dos dois estudos afirma que essas descobertas se generalizam além dos agentes e configurações específicos testados.

O que aconteceu

Um cientista aplicado da Amazon, Phanindra Reddy Madduru, deu a uma única instância do Claude — rodando por meio de uma ferramenta de código de linha de comando — uma sessão estendida para construir um sistema fixo: um banco de dados de grafo persistente, um índice de busca vetorial filtrado por metadados, um pipeline em múltiplos estágios que ingeria documentos de forma assíncrona, e um cliente que renderizava o resultado como um diagrama de grafo interativo, a partir de uma especificação já escrita, com o agente livre para tomar apenas decisões estreitas de design de interação.

Ao longo dessa sessão, o agente introduziu — e depois corrigiu — cinco defeitos que abrangem quatro tipos diferentes de falha em nível de sistema:

• Um bug de confiabilidade: o app localizava seus arquivos de configuração em relação ao diretório de onde o processo era iniciado, então quebrava fora da configuração padrão.
• Um bug de armazenamento: a função de salvar gerava um novo ID aleatório a cada chamada, violando um requisito de que repetir o mesmo salvamento não deveria criar duplicatas.
• Um bug de consistência: uma função de travessia de grafo buscava nós conectados em apenas uma direção enquanto afirmava buscar nas duas, derrubando um cliente de visualização não relacionado e reaparecendo em um segundo ponto do código.
• Um bug de eficiência: o pipeline de ingestão fazia suas chamadas de rede uma após a outra em vez de em paralelo, então o tempo de processamento crescia com o tamanho do documento.
• Um bug de renderização: uma fórmula que dimensionava rótulos na tela tinha um valor mínimo que quebrava a matemática destinada a manter os rótulos em tamanho constante em qualquer nível de zoom.

Desses cinco, apenas o bug de armazenamento foi pego por um teste automatizado — um adicionado depois do fato; os outros quatro só apareceram por meio de sintomas em tempo de execução: uma falha, uma exceção em runtime, um usuário notando lentidão, ou uma comparação automatizada de screenshots — sem nenhum aviso estático ou de checagem de tipos.

O bug de eficiência ilustra essa lacuna. Ele foi sinalizado depois que um documento de 18 chunks levou 242 segundos para ser processado. O agente paralelizou o estágio lento do pipeline, testou a correção apenas num documento menor, e relatou que estava funcionando sem nunca ter rodado novamente o documento original de 18 chunks para confirmar que o número realmente havia melhorado. Madduru escreve que isso foi “uma correção de performance alegada que nunca foi remedida na regressão que a motivou — uma alegação de engenharia não verificada que o ciclo de desenvolvimento autorrelatado, nesse caso, não tinha mecanismo para pegar.”

O mesmo artigo também avaliou o design de retrieval do sistema: em 100 perguntas do dataset HotpotQA, verificadas contra um conjunto de 2.994 parágrafos, restringir os candidatos a um conjunto de entidades identificado pelo grafo encontrou a evidência correta 100% das vezes a partir do terceiro candidato em diante, enquanto a busca semântica comum em todo o conjunto encontrou apenas 69% das vezes mesmo depois de dez candidatos — uma diferença que se manteve em todas as contagens de candidatos testadas. O autor afirma claramente que nada disso estabelece com que frequência esses defeitos se repetiriam com um agente diferente, um modelo menor, ou uma segunda sessão. A autoria do artigo lista Madduru como afiliado à Amazon.com.

Um segundo artigo olhou para a mesma questão com um método diferente. Pesquisadores da Concordia University testaram cinco modelos — Gemini 2.5 Pro, Llama 3.3 70B, DeepSeek-Coder-V2 16B, e Qwen3-Coder nas versões de 30B e 480B de parâmetros — em 90 problemas algorítmicos, e depois usaram o framework multiagente MetaGPT, construído sobre o Qwen3-Coder 480B, para gerar cinco projetos de software completos com múltiplos arquivos, avaliando tudo com a ferramenta de análise estática PyExamine.

Nos problemas isolados, o maior modelo, Qwen3-Coder 480B, produziu 11 ocorrências de um code smell “Long Method” — uma única função que cresce demais para ser revisada com facilidade — contra 1 na referência humana, enquanto o código humano sozinho mostrou um padrão diferente, smells “Temporal Field”, ausentes de toda saída dos modelos. Dar aos modelos exemplos de padrões de código de antemão não reduziu o problema de Long Method e em alguns casos o piorou: a contagem do Qwen3-Coder 480B subiu de 11 para 13.

Quando os mesmos modelos construíram sistemas completos por meio do MetaGPT, o tipo de defeito dominante mudou: o inchaço em nível de método deu lugar a problemas estruturais — lógica concentrada em manager classes grandes demais, código copiado e colado em vez de reaproveitado por meio de funções auxiliares, e código dividido entre arquivos sem separação real de responsabilidade entre eles. Os autores escrevem que “separação em arquivos não equivale a separação lógica.” Nesses projetos, o total de linhas de código se correlacionou quase perfeitamente com quantos smells arquiteturais apareciam, enquanto o nível de detalhe dos requisitos no prompt não teve efeito mensurável em nenhuma categoria de smell. Os autores resumem: “a IA não elimina falhas, mas sim introduz uma “assinatura de máquina” distinta de defeitos.” Eles acrescentam que “os agentes atuais operam como “desenvolvedores júnior” competentes: seguem instruções com precisão sintática, mas carecem da visão de “arquiteto sênior” necessária para gerenciar dependências em todo o sistema e manter uma visão arquitetural coerente.”

Os autores alertam que as descobertas sobre o MetaGPT são específicas ao design de workflow daquele framework, e não evidência sobre sistemas de código multiagente de forma geral — embora considerem o padrão provavelmente indicativo de desafios mais amplos. Eles também observam que o experimento com problemas algorítmicos testou apenas a primeira tentativa de cada modelo, sem chance de revisão a partir de feedback de casos de teste.

O que isso significa (e o que não significa)

Juntos, os dois artigos descrevem o mesmo formato de problema, medido de duas formas diferentes: no caso da Amazon, a maioria dos bugs introduzidos pelo agente só apareceu com o sistema em execução, não enquanto era escrito ou revisado por uma suíte de testes. No estudo da Concordia, o tipo de defeito mudou de um inchaço de método pequeno e corrigível para problemas estruturais que instruções mais detalhadas não resolveram.

A Amazon emprega o autor do estudo de caso e vende seus próprios produtos de agente de código baseados em LLM; um relato franco sobre as limitações de um agente também pode ser lido como evidência de autoescrutínio em torno dessa categoria, ainda que o próprio artigo seja crítico do desempenho do agente. A Anthropic, que faz o Claude, e as fornecedoras avaliadas no estudo da Concordia — Google, Meta, Alibaba, DeepSeek — não são autoras de nenhum dos dois artigos, mas têm interesse comercial geral em como a confiabilidade de seus modelos na construção de sistemas é percebida. Os mantenedores do MetaGPT também têm interesse em saber se os leitores vão tratar a descoberta sobre deterioração arquitetural como específica ao seu framework ou como uma afirmação sobre ferramentas de código agênticas em geral; os próprios autores do estudo alertam contra essa leitura mais ampla.

O que não se segue de nenhum dos dois artigos é que essas taxas exatas de defeito, ou essa taxonomia exata, se apliquem a outros agentes, outros modelos, ou outros frameworks de código. Ambos os artigos são explícitos ao dizer que testaram uma configuração cada — uma sessão do Claude num caso, cinco modelos específicos e um framework multiagente no outro — e nenhum dos dois afirma que seus números vão além disso.

O que ainda não sabemos

Se o padrão de cinco defeitos do estudo de caso da Amazon se repete em outras sessões, com outros agentes, ou com modelos menores e menos capazes do que o usado — o autor recusa explicitamente afirmar que sim.

Se os code smells que o estudo da Concordia mede por análise estática são o mesmo tipo de problema que os defeitos em tempo de execução catalogados pelo estudo da Amazon — violações de idempotência, falhas, regressões de latência. Os dois artigos medem coisas diferentes, e nenhum dos dois afirma o contrário.

Se frameworks de agente além do MetaGPT — os autores da Concordia citam o Cursor Composer e o SpecKit do GitHub como alternativas não testadas — mostram o mesmo padrão de deterioração arquitetural.

Se dar aos agentes um ciclo iterativo de depuração com feedback de casos de teste — deliberadamente excluído do primeiro experimento do estudo da Concordia — reduziria as taxas de defeito arquitetural medidas.

Se o número de 69% de recall do estudo da Amazon para retrieval sem filtro se manteria caso um agente realmente realizasse a identificação de entidades sozinho, em vez do substituto por gold labels usado em seu lugar — o autor aponta isso como a principal ameaça à generalização desse número.

Nenhum dos dois artigos passou por revisão por pares. Ambos são preprints não revisados; um deles foi publicado um dia antes da compilação desta reportagem.