O Ponto Cego de Performance: Agentes de IA Escrevem Código Lento

O código passou em todos os testes. O linter estava limpo. O verificador de tipos estava satisfeito. A revisão de código aprovou. A função era 446 vezes mais lenta do que precisava ser.¹

O Codeflash, uma ferramenta de otimização de performance de código, analisou dois pull requests gerados inteiramente pelo Claude Code: 76.000 linhas em um módulo de suporte à linguagem Java e uma integração com framework React.¹ Eles encontraram 118 funções com problemas significativos de performance. As lentidões variaram de 3x a 446x. O pior caso: uma função de extração de tipos que reescaneava uma AST inteira a cada chamada em vez de armazenar a travessia em cache. Comportamento correto. Performance catastrófica.

A descoberta não é uma anomalia. O SWE-fficiency, um benchmark de 498 tarefas de otimização em repositórios como NumPy, Pandas e SciPy, constatou que os agentes de LLM com melhor desempenho alcançaram menos de 0,15x a aceleração que um desenvolvedor especialista obteve nas mesmas tarefas.² Um estudo separado testando Claude 3.5, OpenAI o1 e Llama 3.2 em 26 códigos de computação de alto desempenho constatou que o Claude 3.5 alcançou uma aceleração de 1,02x em otimização serial (funcionalmente zero de melhoria) enquanto produziu código incorreto em 30% dos casos.³ A própria análise do Codeflash de 100.000 funções open-source constatou que 90% das otimizações sugeridas por IA são incorretas ou não fornecem benefício mensurável, e entre as corretas, 73% entregaram ganhos abaixo de 5%.⁴

Performance é a dimensão que as ferramentas de programação com IA não enxergam. Toda validação de qualidade padrão (linters, verificadores de tipos, suítes de testes, revisão de código) valida a correção. Nenhuma valida a eficiência. O resultado: um imposto invisível sobre cada linha de código gerado por IA que passa em todas as verificações e degrada cada sistema em que entra.

Resumo

Agentes de IA escrevem código correto, mas lento. O Codeflash encontrou 118 problemas de performance em 76.000 linhas de saída do Claude Code, com lentidões de 3x a 446x.¹ Benchmarks acadêmicos confirmam o padrão: LLMs alcançam menos de 0,15x a aceleração de um especialista em tarefas de otimização.² A causa é estrutural: os dados de treinamento recompensam correção, e as validações de qualidade padrão não medem performance. Superar isso requer infraestrutura de performance: benchmarks junto com testes unitários, detecção de padrões baseada em AST em hooks e profiling como etapa padrão do fluxo de trabalho.

Principais Conclusões

Para desenvolvedores individuais. Adicione time ou um profiler à etapa de verificação após cada função gerada por IA em um caminho crítico. A lentidão de 446x passou em todos os testes e todos os linters. A única barreira que teria detectado isso é um benchmark. Trate “funciona” como necessário, mas não suficiente. Pergunte “quão rápido funciona?” como acompanhamento padrão.

Para líderes de equipe. Regressão de performance é a forma invisível do Platô do Bom o Suficiente. Código gerado por IA que passa em todos os testes funcionais cria uma falsa sensação de completude. Adicione benchmarks de performance ao CI junto com os testes unitários. Os dados da Faros AI mostram que equipes assistidas por IA completam 21% mais tarefas enquanto geram 9% mais bugs.⁵ Bugs de performance não são contados nesse 9% porque ninguém os mede.

Para engenheiros de plataforma. Construa a barreira que falta. Linters verificam estilo. Verificadores de tipos verificam contratos. Suítes de testes verificam comportamento. Nada verifica complexidade algorítmica ou características de tempo de execução no pipeline de CI padrão. Detecção de padrões baseada em AST (regras Semgrep, padrões ast-grep ou hooks personalizados) pode capturar os anti-padrões de performance mais comuns: travessias redundantes, memoização ausente e cópias desnecessárias.

Como São 118 Bugs

A análise do Codeflash de dois PRs do Claude Code fornece o conjunto de dados público mais granular sobre problemas de performance gerados por IA.¹ Os dois PRs totalizaram 76.000 linhas: 52.000 para suporte à linguagem Java e 24.000 para suporte a React. Ambos eram funcionais. Ambos passaram em suas suítes de testes. Ambos continham código que degradaria sob carga real.

As causas raiz se agrupam em quatro categorias:

Algoritmos ineficientes. A categoria dominante. Uma função que convertia offsets de bytes para posições de linha usava varredura O(n) em vez de busca binária O(log n) com uma tabela de consulta pré-computada. O código era legível. Os nomes das variáveis eram descritivos. A lógica estava correta. A classe de complexidade estava errada.

Computação redundante. Funções que re-parseavam, re-percorriam ou recomputavam valores que poderiam ser armazenados em cache. O localizador de funções auxiliares re-parseava o mesmo arquivo fonte a cada chamada. Um decorator de memoização teria reduzido a sobrecarga de 74x para zero após a primeira invocação.

Ausência de cache e memoização. Intimamente relacionado à computação redundante, mas distinto porque os dados estavam disponíveis em um escopo mais amplo. O extrator de definição de tipos percorria a AST completa a cada vez em vez de construir um índice no primeiro acesso. O padrão: o agente escreve cada função isoladamente sem considerar como ela será chamada em um loop.

Estruturas de dados subótimas. Varreduras de listas onde conjuntos ou dicionários forneceriam consulta O(1). O verificador de exports iterava por uma lista para testar pertencimento. Uma conversão para conjunto teria eliminado a sobrecarga de 9x inteiramente.

Por Que Agentes Produzem Código Lento

O ponto cego de performance não é um bug em nenhum modelo específico. A causa é estrutural, operando em três níveis: dados de treinamento, critérios de avaliação e premissas de fluxo de trabalho.

Dados de Treinamento Recompensam Legibilidade

LLMs aprendem a partir da distribuição de código em seus dados de treinamento. A implementação mais comum de qualquer algoritmo é a ingênua. Código de tutoriais prioriza clareza. Respostas do Stack Overflow priorizam correção. Código open-source contém versões otimizadas para performance, mas elas são superadas em número por implementações diretas em ordens de magnitude.

O padrão se estende além da performance. Stanford constatou que desenvolvedores assistidos por IA escreveram código inseguro com mais frequência em quatro de cinco tarefas de segurança, e esses mesmos desenvolvedores tinham maior probabilidade de acreditar que seu código era seguro.⁸ A lacuna de confiança se aplica igualmente à performance: o código parece limpo, é fácil de ler e produz saída correta, então o desenvolvedor confia nele. Os pesquisadores do SWE-fficiency constataram que agentes têm dificuldade em localizar oportunidades de otimização e raciocinar sobre execução entre funções.² LLMs fazem edições pequenas e específicas para a entrada em vez de melhorias algorítmicas. Quando solicitado a otimizar, o modelo recorre à transformação correta mais próxima (adicionar um cache, inlinar uma função) em vez de reconsiderar a abordagem algorítmica. O resultado é micro-otimização sobreposta a estruturas fundamentalmente ineficientes.

Nenhuma Barreira de Avaliação Mede Performance

As barreiras de qualidade padrão validam aquilo para o que foram projetadas:

Toda barreira que a indústria padronizou opera sobre correção. Testes de performance existem (profilers, frameworks de benchmarking, ferramentas de teste de carga), mas ocupam um fluxo de trabalho separado que a maioria das equipes não integra ao pipeline de CI e que agentes de IA nunca invocam espontaneamente.

O vácuo de verificação que explica o muro de 10% de produtividade se estende mais fundo do que a correção funcional. O vácuo não é apenas “o código funciona?” mas “o código tem boa performance?” e nenhuma barreira padrão faz a segunda pergunta.

Agentes Escrevem Funções, Não Sistemas

A causa mais profunda é arquitetural. Um agente de IA gera código uma função, um arquivo, uma tarefa por vez. O escopo de cada geração é o requisito imediato. Problemas de performance emergem nas fronteiras: quando uma função escrita para invocação única é chamada em um loop, quando um parser escrito para entradas pequenas recebe arquivos grandes, quando uma consulta escrita para correção recebe requisições a cada request.

O modo de falha Visão de Túnel da taxonomia de falhas de agentes descreve esse padrão no nível funcional: o agente aperfeiçoa um componente sem verificar pontos de integração. O ponto cego de performance é a Visão de Túnel aplicada às características de tempo de execução. A função é perfeita isoladamente. O sistema degrada porque as características de performance da função nunca foram avaliadas em contexto.

O Imposto Invisível

O ponto cego de performance seria um problema menor se o código gerado por IA fosse uma fração pequena dos sistemas em produção. Os números atuais o tornam um risco sistêmico.

A DX mede o código de autoria de IA em 26,9% do código merged em produção e crescendo.⁶ A Faros AI (uma fornecedora de analytics para DevOps) constatou que equipes assistidas por IA fazem merge de PRs que são 154% maiores que as baselines pré-IA, completam 21% mais tarefas e geram 9% mais bugs por desenvolvedor.⁵ O número de 9% conta defeitos funcionais. Regressões de performance estão ausentes da métrica inteiramente porque a maioria das equipes não tem uma baseline de performance contra a qual regredir.

A matemática composta importa. O ensaio controlado randomizado do METR constatou que desenvolvedores experientes levaram 19% mais tempo com ferramentas de IA, mas acreditavam que a IA os acelerou em 20%.⁹ Se os próprios desenvolvedores não conseguem avaliar com precisão o impacto, a dívida de performance se acumula sem ser detectada. Com 26,9% do código merged carregando potencial dívida de performance e a organização sem nenhuma barreira de performance, a dívida se acumula a cada sprint. O relatório DORA 2025 constatou que a adoção de IA se correlaciona com aumento de instabilidade na entrega mesmo com melhora no throughput.⁷ O relatório não atribui a instabilidade especificamente à performance, mas o mecanismo se encaixa: mais código, merged mais rápido, com características de performance que nunca foram medidas.

52% dos líderes de engenharia entrevistados pelo Codeflash relataram que o aumento do uso de IA leva a problemas de performance em suas bases de código.⁴ O número é autorrelatado e vem de um fornecedor (o Codeflash vende ferramentas de otimização de performance), mas a direção é consistente com cada conjunto de dados independente. Mais código gerado por IA, merged com barreiras de qualidade padrão, produz sistemas que funcionam corretamente e executam lentamente.

O muro de 10% de produtividade tem uma dimensão de performance que os dados originais não revelam. Se a IA acelera a geração de código em 10% mas o código gerado carrega dívida de performance que aparece semanas ou meses depois como incidentes em produção, o ganho líquido de produtividade encolhe ainda mais. O muro não é apenas “IA não torna desenvolvedores mais rápidos.” O muro inclui “IA torna o código mais lento de formas que ninguém mede.”

Como É a Detecção

A detecção de performance para código gerado por IA requer infraestrutura que a maioria das organizações não possui. As ferramentas existem. A integração não.

Barreiras de Benchmark no CI

A correção mais direta: fazer benchmark de caminhos críticos e falhar o build em regressões. Frameworks existem para toda linguagem principal: pytest-benchmark para Python, JMH para Java, criterion para Rust, benchmark.js para JavaScript. O desafio não é ferramental, mas prático. Benchmarks requerem baselines, e baselines requerem que alguém escreva o benchmark inicial antes que o código gerado por IA possa regredir contra ele.

A implementação mínima viável: identifique as 10-20 funções no caminho crítico, escreva benchmarks para elas e adicione ao CI. Os 118 bugs que o Codeflash encontrou estavam concentrados em parsers e funções de travessia de AST: o núcleo computacional, não o código de cola. Problemas de performance se concentram nos mesmos lugares sempre.

Detecção de Padrões Baseada em AST

Análise estática pode capturar os padrões mais flagrantes sem executar o código. Semgrep e ast-grep suportam regras personalizadas que detectam:

• List comprehensions ou loops dentro de outros loops onde a coleção interna não muda (candidato a cache)
• Verificações .index() ou in contra listas que poderiam ser conjuntos
• I/O de arquivo ou chamadas de rede dentro de loops sem batching
• Chamadas de função repetidas com os mesmos argumentos (candidato a memoização)

Essas regras não substituem profiling. Elas capturam os padrões que representam a maioria dos 118 bugs: computação redundante, cache ausente, estruturas de dados erradas.

Consciência de Performance Baseada em Hooks

Para usuários do Claude Code, um hook PreToolUse pode injetar consciência de performance no fluxo de trabalho do agente. A abordagem é paralela ao padrão de barreira de evidências usado para correção:

check_performance_patterns() {
    local file_path="$1"
    local ext="${file_path##*.}"

    case "$ext" in
        py)
            # Detect nested loops with repeated computation
            if grep -Pn 'for .+ in .+:\n.*for .+ in .+:' "$file_path" 2>/dev/null; then
                echo "WARNING: Nested loops detected in $file_path"
                echo "Verify inner loop does not recompute invariant values."
            fi
            # Detect list membership checks that should be sets
            if grep -n '\bin\b.*\[' "$file_path" 2>/dev/null | grep -v '#'; then
                echo "WARNING: List membership check in $file_path"
                echo "Consider converting to a set for O(1) lookup."
            fi
            ;;
        js|ts)
            # Detect Array.includes or indexOf in loops
            if grep -n '\.includes\|\.indexOf' "$file_path" 2>/dev/null; then
                echo "NOTE: Array search detected in $file_path"
                echo "If called in a loop, consider a Set or Map."
            fi
            ;;
    esac
}

O hook não é um profiler. Ele aumenta a consciência. O objetivo é o mesmo de qualquer outra barreira de qualidade: tornar o invisível visível para que o desenvolvedor (ou o agente em uma iteração subsequente) possa resolver antes que o código seja enviado.

A Infraestrutura que Falta

O padrão em cada ponto de dados é o mesmo que explica o muro de 10% de produtividade e os sete modos de falha: a IA amplifica qualquer infraestrutura que existe, incluindo a ausência de infraestrutura.

Organizações com benchmarks de performance no CI vão capturar regressões de performance geradas por IA da mesma forma que capturam as geradas por humanos. Organizações sem eles vão acumular dívida de performance invisivelmente. A descoberta do DORA sobre “amplificador” se aplica diretamente: a IA não cria o ponto cego de performance. A IA o escala.⁷

Três investimentos mínimos fecham a lacuna:

1. Faça benchmark de caminhos críticos antes que a IA gere código ao redor deles. O benchmark é a baseline. Sem ele, nenhuma regressão é detectável. Identifique as 10-20 funções que representam a maioria do tempo de computação e escreva benchmarks para elas primeiro.

2. Adicione linting de performance baseado em AST ao pipeline de CI. Regras Semgrep ou ast-grep que sinalizam os quatro anti-padrões dominantes (computação redundante, cache ausente, estruturas de dados erradas, complexidade desnecessária). As regras são leves e composíveis com etapas de linting existentes.

3. Injete consciência de performance nos fluxos de trabalho de agentes. Para Claude Code: um hook que sinaliza padrões relevantes para performance em arquivos modificados. Para outras ferramentas: um prompt que inclua “verifique a complexidade algorítmica” como instrução padrão. O objetivo não é otimização automatizada, mas consciência: trazer à tona a pergunta “isso é rápido o suficiente?” em um fluxo de trabalho que atualmente não a faz.

O ponto cego não é a IA. O ponto cego é a ausência de infraestrutura de performance. Toda barreira de qualidade padrão que a indústria construiu valida correção. Nenhuma valida eficiência. A lacuna existia antes da IA. A IA a transformou em um problema de 26,9% do código em produção.

Fontes