Análise Codeflash: 118 Bugs de Desempenho Encontrados em Dois PRs Escritos com Claude Code

Análise de Desempenho de Código Gerado por IA

A Codeflash usou sua própria ferramenta de otimização para analisar dois pull requests escritos com Claude Code. Os recursos analisados foram suporte à linguagem Java (52.000 linhas entre parsers, extratores de contexto, instrumentação, executores de teste, transformadores de asserção) e suporte ao framework React (24.000 linhas abrangendo descoberta de componentes, profiling, benchmarking e substituição de código).

Principais Descobertas

Apenas nesses dois PRs, a Codeflash identificou 118 funções com desempenho significativamente pior do que o necessário. Estas não eram casos isolados — eram funções no caminho crítico de seu otimizador, executando em cada trabalho de otimização para cada usuário.

Padrões de Ineficiência

• Algoritmos catastróficamente ineficientes: Uma função de extração de tipos no módulo de contexto Java era 446 vezes mais lenta do que o necessário, implementada com varredura ingênua de strings em vez de extração baseada em tree-sitter. Um localizador de funções auxiliares era 74 vezes mais lento por razões semelhantes.
• Computação redundante: Funções estavam re-analisando dados já analisados, re-percorrendo árvores já percorridas, reconstruindo strings caractere por caractere. Um construtor de chamadas de destino de asserção era 19 vezes mais lento devido à reconversão de bytes de origem em cada invocação em vez de usar cache. Um utilitário de inserção de importação no PR React era 36 vezes mais lento devido a travessias redundantes de árvores.
• Falta de cache: Funções chamadas repetidamente com as mesmas entradas computavam resultados do zero cada vez. Um extrator de definição de tipos no PR React era 16 vezes mais lento sem memorizar resultados intermediários, e um verificador de exportação era 9 vezes mais lento pelo mesmo motivo.
• Estruturas de dados subótimas: Listas onde conjuntos deveriam ter sido usados, buscas lineares onde pesquisas de hash funcionariam, concatenação de strings em loops em vez de junções. Um parser de balanceamento de chaves era 3 vezes mais lento devido a escolhas ineficientes de estruturas de dados.

Exemplo Concreto: Melhoria de Desempenho de 19x

O Claude Code escreveu esta função para converter deslocamentos de byte em posições de caractere:

# Chamado para cada nó AST encontrado no arquivo
start_char = len(content_bytes[:start_byte].decode("utf8"))
end_char = len(content_bytes[:end_byte].decode("utf8"))

A Codeflash substituiu por:

# Constrói uma tabela de pesquisa uma vez, depois busca binária para cada nó
from bisect import bisect_right
cum_bytes = [0]
for ch in source.decode("utf8"):
    cum_bytes.append(cum_bytes[-1] + len(ch.encode("utf8")))
start_char = bisect_right(cum_bytes, start_byte) - 1
end_char = bisect_right(cum_bytes, end_byte) - 1

O código original decodifica todo o prefixo de bytes desde o início do arquivo em cada chamada — O(n) por pesquisa. Para um arquivo com centenas de nós AST, isso significa re-decodificar os mesmos bytes centenas de vezes. A versão otimizada constrói uma tabela de pesquisa uma vez e usa busca binária — O(n) uma vez, depois O(log n) por pesquisa.

O artigo enfatiza que isso não é sobre usar ou não agentes de codificação de IA (eles recomendam usá-los), mas sobre o que acontece com o código depois que você os usa. Esses problemas de desempenho representam uma nova categoria de dívida técnica que agentes de IA introduzem sistematicamente ao focar em correção e legibilidade em vez de otimização de desempenho.