Qualidade em IA: Como Gastar Tokens de Propósito e Entregar Código Melhor

Ricardo Sierra 1 de setembro de 2026 · 12 min de leitura

Se você assina Antigravity, Cursor, Claude Code ou outra ferramenta agentic — e já reparou que, no fim do dia, tokens sobraram mas a feature saiu meia-boca — este texto é pra você. A ideia aqui é simples: parar de economizar prompt e começar a investir prompt onde dá retorno real na qualidade do código.

Não existe número mágico publicado pelo Google ou pela Anthropic dizendo "cada /boost custa X tokens". O que existe é uma arquitetura bem documentada de agentes, orquestradores e revisores[1][2] — e a partir dela dá pra montar uma hierarquia prática de quanto cada recurso consome vs. quanto ele melhora o resultado.

O que segue é essa hierarquia, montada a partir da documentação oficial das ferramentas e de uso real em projetos em produção.

Mapa de Consumo vs. Retorno

A tabela abaixo classifica cada técnica por consumo relativo de tokens (mais 🔥 = mais caro) e ganho percebido na qualidade do resultado (mais ⭐ = melhor).

O Arsenal Detalhado

1. /teamwork-preview — Equipe completa de agentes

O recurso mais pesado disponível. Não é "a IA pensa mais por mais tempo" — é um sistema que monta uma equipe de agentes especializados, divide o projeto em milestones, cria workstreams paralelos e roda auditoria independente no resultado[1].

A diferença concreta entre as camadas:

• Agente normal: implementação direta, contexto único.
• /boost: vários agentes investigando em paralelo, um orquestrador consolida.
• /teamwork-preview: organização inteira — planejamento, execução paralela, revisão cruzada, tudo dentro de um único comando.

Faz sentido para: reescrever um módulo financeiro, migrar arquitetura, auditar e corrigir um sistema inteiro, implementar uma feature que toca dezenas de arquivos. Não faz sentido para adicionar um campo numa tela — não precisa de sete agentes para criar um <input>.

2. /boost — Investigação profunda com múltiplos agentes

Na prática, é onde a maioria dos devs vai ter mais retorno por token gasto. O /boost cria uma hierarquia onde um orquestrador divide o trabalho entre investigadores e programadores (DeepCoder/DeepInvestigator). Cada um trabalha em contexto isolado, explora hipóteses diferentes, executa testes — e o orquestrador pega a melhor solução[2].

Funciona particularmente bem para: bug que some quando você adiciona um console.log, race condition, memory leak, refactor complexo, query SQL que demora 40 segundos, ou código legado que ninguém no time sabe explicar.

Para o desenvolvimento pesado do dia a dia, /boost costuma dar mais retorno que /teamwork-preview — é mais cirúrgico e menos burocrático.

3. GSD (Get Shit Done) — Método científico forçado

O GSD[3] não é uma feature de UI — é um workflow completo que força etapas: entender → pesquisar → especificar → planejar → executar → testar → verificar → revisar.

No modo mais potente (perfil Quality, granularidade fina, planejamento e execução paralela com multi-AI review), o sistema usa uma IA para planejar, outra para executar e uma terceira para conferir. Isso elimina aquele cenário clássico em que você implementa tudo de uma vez e depois passa duas horas consertando testes quebrados.

4. Revisor independente — Não peça à mesma IA que se avalie

Um padrão que custa pouco e muda o resultado: nunca peça "implemente X e confirme se ficou certo". A mesma IA que cometeu um erro vai racionalizar por que o erro na verdade está certo. O que funciona é separação de responsabilidades:

• Agente A implementa.
• Agente B verifica requisitos.
• Agente C procura regressões.
• Agente D roda testes.

O retorno desse padrão é desproporcional ao custo.

5. Revisão adversarial (Red Team)

Um passo além do revisor: um agente cuja única missão é provar que a implementação está errada. Ele procura regressões, falhas de segurança, inconsistências e edge cases que passariam despercebidos numa revisão cooperativa.

Particularmente valioso em backend para: policies, gates, transações financeiras, multi-currency, idempotência de webhooks e qualquer coisa que envolva dinheiro.

6. /goal — Loop autônomo até funcionar

Menos "pensar com várias cabeças" e mais "não pare até terminar". O sistema entra num loop código → build → erro → correção → teste sem precisar de intervenção. O caso de uso clássico: "Faça todos os testes desse módulo passarem sem remover cobertura nem alterar comportamento público."

7. Planning Mode — Pesquisa antes de escrever

O modo de planejamento faz o agente pesquisar o projeto em profundidade, criar um artefato com o plano de implementação, e só depois executar. Gasta mais que uma instrução direta, mas qualquer alteração que cruze Controller, Service, Model, Queue e Frontend compensa o investimento.

8. /grill-me — Entrevista antes de construir

Antes de escrever código, rode /grill-me Quero implementar X. O agente faz perguntas difíceis sobre arquitetura, edge cases e performance antes de uma linha de código existir. Parece desperdício de tokens — até você comparar com o custo de reescrever uma feature inteira porque a premissa inicial estava errada.

9. Subagentes explícitos — Especialistas em paralelo

Em vez de pedir a um agente que "analise tudo", divida: um agente para arquitetura, outro para segurança, outro para banco, outro para backend, outro para frontend. Um agente principal consolida no final. Custa mais pela reconstrução de contexto, mas encontra problemas que análises sequenciais não enxergam.

10. Seleção estratégica de modelos

• Tarefa trivial: Gemini Flash ou modelo leve. Renomear variáveis, formatar código, ajustes de CSS.
• Arquitetura e planejamento: Gemini 2.5 Pro[5] ou Sonnet 4 Thinking. Análise profunda, planejamento de features complexas.
• Problema realmente difícil: Claude Opus 4 Thinking[4] ou /boost. Debugging intrincado, decisões arquiteturais com trade-offs pesados.

Usar Opus Thinking para renomear variáveis é contratar um engenheiro aeroespacial para trocar uma lâmpada. Funciona, mas o orçamento não faz sentido.

11. Browser Agent — Validação no navegador real

Testes unitários passando não significa que a feature funciona. O Browser Agent abre o navegador, loga, clica, verifica console e tráfego de rede. Para qualquer stack web, é a diferença entre "os testes passam" e "o usuário consegue usar".

12. MCP (Model Context Protocol) — Dados reais, não deduzidos

O MCP[6] conecta o agente a fontes reais: banco de dados, API do GitHub, logs, documentação interna. Em vez de deduzir o schema lendo código — e inventar colunas que não existem — o agente consulta a fonte de verdade. Consome mais, mas elimina um tipo de erro que nenhuma revisão de código pega.

13. Worktrees + Agentes paralelos

Para projetos grandes, isole agentes em worktrees diferentes (/auth, /payments, /notifications). O custo aumenta pela reconstrução de contexto em cada worktree, mas você ganha paralelismo real sem conflitos de merge.

14. Skills e Rules — O melhor custo-benefício

Definir skills específicas (ex: security-review) e rules absolutas (ex: "Nunca altere migration antiga", "Todo endpoint precisa de rate limiting") adiciona um custo fixo pequeno de contexto a cada execução. Em compensação, reduz retrabalho e garante consistência do projeto — especialmente em times onde vários devs usam a mesma ferramenta.

Combinações Práticas

A combinação equilibrada (dia a dia)

Para uma feature grande em produção, esta combinação costuma dar o melhor retorno:

1. GSD com Skills e Rules do projeto configuradas.
2. /boost apenas nos pontos de complexidade real da arquitetura.
3. Revisor independente antes do merge.
4. Validação E2E com Browser Agent.

Guarde o /teamwork-preview para épicos e migrações estruturais.

A combinação máxima

Quando o objetivo é o melhor resultado possível independente de quota:

GSD (Quality Profile + granularidade fina) → Research → /teamwork-preview → Subagentes especializados → Modelos Pro/Thinking nos checkpoints → Validação de Browser → Adversarial Review → Reteste.

Cuidado: não empilhe GSD + Teamwork sem pensar. Os dois fazem orquestração pesada. Combinar os dois sem necessidade é pagar para um sistema multiagente organizar outro sistema multiagente que gerencia mais agentes. É overhead, não qualidade.

Referências

1. Google DeepMind — Antigravity: Teamwork & Multi-Agent Architecture. Documentação oficial do recurso /teamwork-preview, incluindo workstreams, milestones e auditoria independente. deepmind.google/technologies
2. Google DeepMind — Antigravity: Boost Mode (DeepCoder/DeepInvestigator). Arquitetura de orquestrador com investigadores e programadores paralelos. deepmind.google/technologies
3. GSD (Get Shit Done) — Workflow Framework for Agentic Development. Sistema de fases com planejamento, execução paralela e multi-AI review. github.com/coleam00/gsd
4. Anthropic — Claude Opus 4 & Extended Thinking. Modelo com raciocínio estendido para problemas complexos e multi-step reasoning. docs.anthropic.com/en/docs/about-claude/models
5. Google DeepMind — Gemini 2.5 Pro. Modelo para análise profunda e planejamento com janela de contexto de 1M+ tokens. deepmind.google/technologies/gemini
6. Anthropic — Model Context Protocol (MCP). Protocolo aberto para conectar modelos de IA a fontes de dados externas: bancos, APIs, documentação. modelcontextprotocol.io
7. Cursor — AI Code Editor. Editor com integração nativa de IA para desenvolvimento assistido. cursor.com
8. Anthropic — Claude Code: Agentic Coding Tool. Ferramenta agentic de linha de comando para desenvolvimento de software. docs.anthropic.com/en/docs/claude-code

Escrito por Ricardo Sierra · Setembro 2026 · Rio de Janeiro