# Otimizar desempenho de código com IA: meça primeiro

URL: https://agentvera.dev/pt/blog/optimize-code-performance-with-ai/ · Publicado: 2026-10-27

Otimize o desempenho do código com agentes de IA: faça o profiling antes, entregue perfis reais ao agente, corrija N+1 e bundles inchados e prove cada ganho.

**Resumo:**

- Nunca peça a um agente para “deixar mais rápido” sem dados. Faça o profiling antes com Chrome DevTools, Lighthouse, node --cpu-prof, py-spy ou cProfile, e entregue o perfil, não o seu palpite.
- Escreva um benchmark ou uma medição repetível antes da mudança; é a etapa de verificação. Uma mudança que não mexe no número é revertida, por mais esperta que pareça.
- Os grandes ganhos de sempre são sem graça: queries N+1, índices faltando, bundles grandes demais, trabalho repetido que pode ir para cache. Agentes acham e corrigem isso bem quando veem a evidência.
- Proteja os ganhos contra regressões: asserções de número de queries, orçamentos de tamanho de bundle e benchmarks no CI, para que a próxima mudança não desfaça o trabalho em silêncio.

**Para otimizar o desempenho do código com IA, meça antes de escrever o prompt: faça o profiling do caminho lento, entregue o perfil ao agente, peça a menor mudança que remove o hotspot e só aceite quando um benchmark mostrar a diferença.** Agentes de código como Claude Code, Codex e Gemini CLI são rápidos para ler um flame graph, rastrear uma função quente até quem a chama e reescrever uma query. Sem dados, eles fazem o que qualquer um faz: chutam. E otimizações no chute são as caras, porque deixam o código mais difícil de ler sem deixá-lo mais rápido.

Este guia mostra um fluxo que funciona na prática: definir o objetivo, fazer o profiling, entregar a evidência, mudar uma coisa, verificar com um benchmark e travar o ganho com uma proteção contra regressão. No caminho, aborda os problemas que causam a maior parte da lentidão em apps reais: queries N+1, tamanho do bundle e caches que faltam.

## Comece com um número, não com uma impressão

“O dashboard está lento” não é uma tarefa. Transforme isso em algo que um agente consiga verificar:

- **O que** está lento: um endpoint, o carregamento de uma página, um comando de CLI, um job em lote.
- **Quão lento** está agora, medido: latência p95 de um endpoint, tempo até a interatividade de uma página, tempo de execução de um script.
- **O que significa “rápido o suficiente”**: uma meta, como “abaixo de 300 ms no p95” ou “a importação termina em menos de um minuto para 100 mil linhas”.
- **Em quais condições**: tamanho dos dados, cache frio ou quente, build de produção ou servidor de desenvolvimento.

Esse último ponto evita muito trabalho jogado fora. Um app React no servidor de desenvolvimento, um serviço Node sem `NODE_ENV=production` ou um job Python com dez linhas de dados de teste mostram hotspots que não existem em produção. Meça o que você entrega.

## Etapa 1: faça o profiling do caminho lento

Escolha o profiler que combina com onde o tempo é gasto.

### No navegador

O painel **Performance** do Chrome DevTools grava um trace: tarefas longas, scripting, layout, cascatas de rede. O **Lighthouse** dá uma nota de laboratório com oportunidades concretas. A CLI do Lighthouse é útil porque grava um arquivo que você pode entregar a um agente:

```bash
npm install -g lighthouse
lighthouse https://localhost:3000/dashboard \
  --only-categories=performance \
  --output=json --output-path=./lighthouse.json
```

Se o seu agente suporta MCP, o servidor MCP do Chrome DevTools permite que ele inicie um trace de desempenho e leia os insights sozinho:

```json
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}
```

### No Node.js

O Node tem um profiler por amostragem embutido. O `--cpu-prof` grava um arquivo `.cpuprofile` quando o processo termina, que você pode abrir no painel Performance do DevTools ou entregar a um agente:

```bash
node --cpu-prof --cpu-prof-dir=./profiles server.js
# run the slow request a few times, then stop the server
```

A flag mais antiga `--prof` grava um log do V8 que o `node --prof-process` transforma num relatório em texto, muito fácil de um agente ler:

```bash
NODE_ENV=production node --prof server.js
node --prof-process isolate-0x*-v8.log > processed.txt
```

Para problemas de memória, o `--heap-prof` grava um `.heapprofile` do mesmo jeito.

### No Python

O `py-spy` faz amostragem de um processo em execução sem mudar o seu código, o que o torna a escolha segura para um serviço no ar:

```bash
py-spy top --pid 12345                    # live view, like top
py-spy record -o profile.svg --pid 12345  # flame graph
py-spy record -o profile.svg -- python import_job.py
```

Para um script que você mesmo pode iniciar, o `cProfile` da biblioteca padrão dá contagens exatas de chamadas:

```bash
python -m cProfile -s cumtime import_job.py | head -40
```

Em outubro de 2026, o Python 3.15 também traz um pacote `profiling` com um profiler estatístico (`python -m profiling.sampling`) e mantém o `cProfile` como alias do seu profiler de tracing; em versões anteriores, `cProfile` e py-spy são as ferramentas a usar.

### No banco de dados

Para o tempo de queries, o banco de dados já sabe a resposta: o log de queries lentas, o `pg_stat_statements` no PostgreSQL e o `EXPLAIN ANALYZE` para uma query. [Escrever SQL com IA](/pt/blog/write-sql-with-ai/ "Escrever SQL com IA") explica como ler planos de query e escolher índices com um agente, então este guia não vai repetir.

## Etapa 2: entregue a evidência ao agente

Agora o agente tem algo real para trabalhar. Entregue o perfil e o contexto, e peça análise antes de código:

```text
The /api/orders endpoint takes about 1.8 s at p95 in production; the target
is 300 ms. Attached: processed.txt from node --prof-process for 50 requests,
and the slow query log for the same period.
Don't change code yet. List the top three hotspots, with the evidence from
the profile for each one (function, self time or total time, call count),
the likely cause in our code (file and line), and a proposed fix. Order
them by expected impact.
```

Alguns hábitos fazem essa etapa funcionar:

- **Entregue a saída bruta, não o seu resumo.** O seu resumo já contém o seu palpite.
- **Peça evidência para cada afirmação.** “Esta função é lenta” deve vir com um número do perfil.
- **Mantenha o agente no caminho quente.** Código que consome 2% do tempo não vale uma reescrita, por mais feio que seja.

Se o agente disser algo como “o perfil não mostra o gargalo com clareza”, acredite, e capture um perfil melhor com mais carga ou com o build de produção. É um resultado muito melhor do que um chute confiante.

## Etapa 3: escreva o benchmark antes da correção

O benchmark é a sua etapa de verificação. Escreva, rode no código atual e salve a linha de base antes de qualquer mudança.

Para um comando ou script, o `hyperfine` roda muitas vezes e mostra a média e a dispersão:

```bash
hyperfine --warmup 3 'node scripts/build-report.js'
```

Para uma função, use o suporte a benchmarks da sua stack: `go test -bench=. -benchmem` em Go, `pytest-benchmark` em Python, o suporte a bench do seu test runner JavaScript. Para um endpoint, um teste de carga curto com um número fixo de requisições contra um build de produção.

Depois, diga ao agente a regra:

```text
Here's the benchmark and its baseline result. Make one change at a time.
After each change, run the tests and the benchmark three times and report
before/after. If a change doesn't improve the result beyond the noise,
revert it and tell me, even if you think it should help.
```

Dois detalhes importam. Compare na mesma máquina com os mesmos dados, porque notebooks reduzem a velocidade sob calor e caches esquentam. E mantenha os testes rodando junto com o benchmark: uma função mais rápida que devolve a resposta errada é um bug. Se o código que você está otimizando não tem testes, adicione-os antes; [escrever testes unitários com IA](/pt/blog/write-unit-tests-with-ai/ "Escrever testes unitários com IA") mostra como conseguir testes úteis de um agente.

## Onde o tempo costuma ir

Em apps reais, um pequeno conjunto de problemas responde pela maior parte da lentidão. São os primeiros a verificar.

### Queries N+1

O clássico: carregar uma lista e depois rodar uma query extra por item dentro de um loop ou de um template. Parece tudo bem com dez linhas em desenvolvimento e desmorona com duas mil em produção. A correção é carregar os dados relacionados em uma ou duas queries, com a ferramenta que o seu ORM oferece:

| Stack | Eager loading |
| --- | --- |
| Django | `select_related` (joins), `prefetch_related` (query separada) |
| Rails | `includes`, e a gem Bullet para detectar N+1 em desenvolvimento |
| SQLAlchemy | `selectinload`, `joinedload` |
| Prisma | `include` |

Os agentes são bons nessa correção quando sabem onde ela acontece. Ative o log de queries, abra a página lenta uma vez e entregue o log ao agente: um padrão de query repetido com IDs diferentes é a impressão digital. Depois peça a correção e um teste que confira o número de queries daquela página, para que o problema não volte sem ninguém perceber.

### Tamanho do bundle

No desempenho de front-end, o JavaScript que você entrega costuma ser a maior alavanca. Primeiro meça o que está no bundle com o `source-map-explorer` ou o `webpack-bundle-analyzer` (ou o analisador do seu bundler), depois procure as causas de sempre:

- uma biblioteca grande importada por causa de uma função,
- um conjunto inteiro de ícones ou um pacote de locales puxado por um único import,
- componentes pesados carregados na primeira renderização que poderiam ser lazy-loaded,
- a mesma dependência empacotada duas vezes em versões diferentes.

Entregue ao agente a saída do analisador e peça mudanças ordenadas por bytes economizados. Depois compare a saída do build antes e depois, do mesmo jeito que compara um benchmark.

### Trabalho repetido e cache

Um cache é a resposta certa quando o mesmo resultado caro é calculado várias vezes com as mesmas entradas. É a resposta errada quando o cálculo poderia simplesmente ficar barato, ou quando ninguém decidiu o que acontece quando os dados mudam. Antes de aceitar um cache de um agente, pergunte:

```text
For this cache: what's the key, what invalidates it, what's the maximum
staleness we accept, how much memory can it use, and what happens on a
cold start? Show me the measured hit rate or the profile that justifies it.
```

Se as respostas forem vagas, o cache vai virar um relatório de bug mais tarde. Muitas vezes a melhor correção está antes na cadeia: um índice faltando, uma query que busca todas as colunas, um loop que recalcula o mesmo valor a cada iteração.

### Problemas de algoritmo

Às vezes o perfil mostra uma única função com uma contagem de chamadas enorme: um loop aninhado sobre duas listas, um `.find()` dentro de um `.map()`, um sort dentro de um loop. Trocar uma busca linear por um `Map` ou `Set` é uma correção clássica de agente, e o benchmark diz na hora se fez diferença.

## Evite otimização prematura e especulativa

Agentes adoram otimizar. Peça a um para “melhorar o desempenho” de um arquivo e ele vai memoizar componentes, reescrever loops e adicionar caches por todo lado. A maioria dessas mudanças não mexe em nada mensurável e deixa o código mais difícil de mudar. Regras que vale escrever com todas as letras nas instruções do projeto:

```markdown
## Performance work
- No optimization without a profile or benchmark that shows the problem.
- One change per commit, with before/after numbers in the message.
- Readability wins over micro-optimizations outside measured hot paths.
- Don't add caches, workers or new dependencies without asking.
```

O mesmo vale para as sugestões do próprio agente durante um trabalho não relacionado. Se ele propuser “já que eu estava aqui, também otimizei…”, peça os números ou peça para reverter. Quando algo quebrar depois de uma otimização, [depurar código com IA](/pt/blog/debug-code-with-ai/ "Depurar código com IA") mostra como isolar o problema sem chutar.

## Etapa 4: proteja o ganho

O desempenho piora em silêncio, uma mudança razoável de cada vez. Transforme cada correção numa verificação que falha alto:

- **Testes de número de queries.** Confira que a página de pedidos roda no máximo um número fixo de queries. A maioria dos frameworks tem um helper para isso, como o `assertNumQueries` no Django.
- **Orçamentos de bundle.** Ferramentas como o `size-limit` fazem o build falhar quando um bundle passa de um tamanho definido.
- **Lighthouse no CI.** Rode a CLI do Lighthouse contra um build de preview e falhe abaixo de uma nota mínima nas páginas que importam.
- **Benchmarks contra uma linha de base.** Guarde a linha de base e compare; em Go, o `benchstat` compara duas execuções de benchmark e diz se a diferença é significativa.

Os agentes são bons em escrever essas proteções, e vale pedir uma na mesma tarefa da correção: “corrija o N+1 e adicione um teste que teria pegado o problema”.

## Fazendo isso no AgentVera

O AgentVera é um app desktop que roda CLIs de agentes de código como Claude Code, Codex e Gemini CLI lado a lado. Vários recursos dele se encaixam nesse ciclo:

- **Um navegador que o agente consegue controlar.** O [navegador do agente](/pt/features/agent-browser/ "Navegador do agente") é um perfil separado do Chrome que os agentes usam pelo Playwright MCP, com DevTools e console embutidos, então o agente pode abrir a página lenta sozinho e você pode acompanhar.
- **Envie evidências com um atalho.** O [Send to agent](/pt/features/send-to-agent/ "Send to agent") (⌘⇧L) envia a saída do terminal, uma seleção do editor, um diff ou o console do navegador para um agente. A saída do profiler no terminal vai para o agente sem copiar e colar; saídas muito longas são cortadas em 12.000 caracteres, então envie o topo do relatório ou salve num arquivo.
- **Planos de query ao lado do código.** O [gerenciador de banco de dados](/pt/features/database-manager/ "Gerenciador de banco de dados") (Pro) abre PostgreSQL, MySQL e SQLite com um editor SQL que mostra planos EXPLAIN, e os agentes podem consultar o banco pela ferramenta embutida dele.
- **Benchmarks como critério de aceite.** Escreva “os testes passam e o benchmark está pelo menos 30% mais rápido que a linha de base” na sua mensagem, e o [Verify](/pt/features/verify/ "Verify") confere isso no fim do turno com um verificador que roda comandos, mas não consegue editar arquivos.
- **Desfaça uma otimização que não compensou.** Os [checkpoints](/pt/features/checkpoints-and-replay/ "Checkpoints e replay") tiram um snapshot de cada turno, então reverter um experimento é um clique.
- **Teste duas abordagens ao mesmo tempo.** Na grade do [workspace](/pt/features/workspace/ "Workspace"), rode dois agentes em worktrees separados, digamos um no cache e outro na query, e fique com o que tiver os melhores números.

## Conclusão

Otimizar o desempenho do código com IA é a mesma disciplina de otimizar sem ela, só que mais rápido: uma meta clara, um perfil, a evidência entregue, uma mudança de cada vez, um benchmark como prova e uma proteção para manter o ganho. O agente faz a leitura e a reescrita; os números decidem. Se a lentidão veio com uma atualização de dependência, o fluxo de [atualizar dependências com IA](/pt/blog/upgrade-dependencies-with-ai/ "Atualizar dependências com IA") ajuda a isolar qual pacote causou o problema.

Para experimentar esse fluxo no seu próprio projeto, [baixe o AgentVera](/pt/download/ "Baixar o AgentVera").

## Perguntas frequentes

**Um agente de IA consegue achar problemas de desempenho lendo o código?** Ele consegue apontar suspeitos prováveis, como uma query dentro de um loop, mas não tem como saber qual deles importa para os seus dados e o seu tráfego. Dê a ele um perfil, um log de queries lentas ou um trace, e ele pode focar no código que realmente consome o tempo.

**Qual profiler devo usar?** No navegador, o painel Performance do Chrome DevTools e o Lighthouse. No Node.js, o node --cpu-prof, que grava um .cpuprofile que você abre no DevTools. No Python, o py-spy para processos em execução e o cProfile para um script que você mesmo pode iniciar.

**Como sei que a otimização funcionou?** Meça a mesma coisa antes e depois, várias execuções de cada, na mesma máquina. Uma ferramenta de benchmark como o hyperfine para comandos, ou o suporte a benchmarks do seu framework de testes, faz as execuções repetidas por você. Se a diferença está dentro do ruído, não funcionou.

**Por que os agentes sugerem otimizações que não ajudam?** Sem medições, um modelo recorre a conselhos genéricos: memoize isso, use um loop mais rápido, adicione um cache. Essas mudanças acrescentam complexidade e muitas vezes não mexem em nada. Peça a evidência por trás de cada sugestão e rejeite o que não estiver ligado a um hotspot medido.

**Como evito que o desempenho piore de novo?** Transforme cada correção numa verificação: um teste que confere o número de queries de uma página, um orçamento de tamanho de bundle no CI ou um benchmark comparado com uma linha de base. A verificação falha antes de a regressão chegar aos usuários.

---

**Sobre o AgentVera.** AgentVera é um app desktop para macOS, Windows e Linux, desenvolvido pela Solviera Teknoloji. Ele roda 18 agentes de programação com IA (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) lado a lado, por projeto, em terminais reais com as instalações e logins de CLI do próprio usuário. O plano gratuito tem agentes ilimitados. Baixar: https://agentvera.dev/pt/download/ · Preços: https://agentvera.dev/pt/pricing/