São Paulo · Brasil guia de agente

15 de mai. de 2026 · guia operacional

Claude Code e Codex sem teatro

Como usar agentes de código em tarefas pequenas, testáveis e revisáveis sem entregar o repo inteiro para uma mudança mal definida.

  • Claude Code
  • Codex
  • Hermes Agent
  • agente Markdown genérico

Coding agent não é operador geral

Claude Code e Codex brilham quando o trabalho está dentro de um repositório: arquivo, diff, teste, branch, PR, erro, revisão.

Eles pioram quando você usa como oráculo genérico para “melhorar o sistema”, “dar uma organizada”, “refatorar tudo” ou “publicar se estiver bom”. Isso parece produtividade. Muitas vezes é só mudança grande demais sem verificação proporcional.

Onde ajudam

Use coding agent para:

  • explicar um erro com stack trace;
  • localizar arquivos prováveis;
  • escrever teste pequeno;
  • alterar uma função;
  • atualizar documentação técnica;
  • revisar diff;
  • criar script interno;
  • fazer refactor com escopo estreito;
  • rodar build e reportar erro;
  • abrir PR com descrição clara.

A unidade boa é pequena e verificável.

Onde atrapalham

Evite quando:

  • ninguém sabe qual problema está sendo resolvido;
  • não existe teste, rota, screenshot, lint ou verificação;
  • a tarefa cruza produto, copy, design, infra e dados ao mesmo tempo;
  • o repo tem segredo exposto;
  • o agente precisa de acesso de produção para “testar”;
  • a mudança exige julgamento comercial ou jurídico;
  • você não vai revisar diff.

Agente de código sem revisão é estagiário com commit access e confiança demais.

Checklist de tarefa boa

Antes de rodar Claude Code ou Codex, escreva:

  • Qual é o objetivo em uma frase?
  • Quais arquivos ou áreas são prováveis?
  • O que está fora do escopo?
  • Qual teste, build ou comando valida?
  • O agente pode instalar dependência?
  • O agente pode editar snapshot, schema ou migration?
  • O agente pode fazer commit?
  • O agente pode abrir PR?
  • O que exige parar e perguntar?
  • Como revisar o diff depois?

Se você não consegue responder, a tarefa ainda é briefing, não execução.

Prompt operacional

Um pedido bom parece assim:

Objetivo: corrigir o botão de copiar no template detail.
Escopo provável: src/pages/templates/[slug].astro e teste relacionado.
Fora do escopo: redesign, dependências novas, deploy.
Verificação: pnpm run build e teste da rota /templates/agente-pessoal-vps-hermes-checklist/.
Regra de parada: se o problema estiver em analytics global ou exigir mudança de schema, pare e explique.

Isso é chato. Também é o que impede o agente de “melhorar” metade do projeto.

Onde MCP entra sem virar bagunça

A busca por Claude Code + Codex + MCP normalmente esconde uma pergunta maior: como dar ferramenta e contexto para um agente sem abrir acesso demais?

MCP é um padrão para conectar aplicações de IA a dados, ferramentas e fluxos externos. Isso pode ser ótimo para documentação, busca, arquivos locais, sistemas internos e workflows repetidos. Também pode ser perigoso quando vira atalho para dar ao agente acesso amplo sem escopo.

Use MCP primeiro para contexto de baixo risco:

  • documentação oficial;
  • busca em repositório;
  • leitura de arquivos permitidos;
  • ferramentas internas sem escrita;
  • consultas que não mexem em produção.

Só depois considere ações com escrita. Mesmo assim, defina ambiente, permissão, log e regra de parada. Um servidor MCP mal escolhido pode transformar uma tarefa pequena em acesso operacional grande demais.

Claude Code, Codex e Hermes juntos

Não trate tudo como concorrente.

Um fluxo real pode ser:

  1. Hermes recebe a tarefa pelo Telegram e registra o contexto.
  2. Você decide que a parte de código deve ir para um agente de código.
  3. Claude Code ou Codex trabalha no repo com escopo claro.
  4. Hermes ou você revisa resumo, diff e verificação.
  5. Só depois entra commit, PR ou deploy.

O papel de cada agente muda pelo ambiente. Hermes como operador pessoal. Claude Code/Codex como executor de repo. Chat comum como conversa e rascunho.

Verificação mínima

Toda tarefa de código precisa terminar com uma destas coisas:

  • teste passando;
  • build passando;
  • lint passando;
  • screenshot comparável;
  • diff revisado;
  • rota checada;
  • erro explicado e reproduzível;
  • motivo claro para bloquear.

“Parece bom” não é verificação.

Quando vira Zild

Coding agent local geralmente não exige contratação. Para tarefa de repo, aprendizado, refactor pequeno, teste, documentação e revisão segura, o caminho faça você mesmo é suficiente. Para esse uso, não precisa chamar empresa.

Mas se o código controla atendimento, cliente, CRM, produção, governança, QA, evidência ou handoff, a conversa muda. O risco não é só bug. É operação quebrada com cliente do outro lado.

Se você prefere ver em vídeo

sinal de demanda

Quer um vídeo para este guia: Claude Code e Codex: onde agentes de código ajudam e onde atrapalham

Se bastante gente pedir, este assunto entra na fila de gravação. Não é promessa. Uma boa demonstração mostraria briefing, execução, teste, diff e revisão, não só o agente digitando código. O pedido ajuda a priorizar demonstrações práticas.

materiais úteis

Entenda o limite aqui. Depois baixe o checklist ou a skill para usar no trabalho real.

acompanhar por fora do site

Continuo essas notas no LinkedIn.

Sigo publicando ali bastidores, leituras e decisões práticas sobre CRM, atendimento, WhatsApp, IA e agentes. Se esse texto ajudou, me acompanhe por lá também.