Meu harness de IA: como trabalho com o Claude Code no dia a dia
Meu harness de IA: como trabalho com o Claude Code no dia a dia
O modelo de IA é só uma parte do trabalho. O resto é o que fica em volta dele: as instruções que ele lê, o que ele lembra entre sessões, as ferramentas que pode usar, o que ele pode fazer sem pedir e o que roda antes de cada comando. Esse conjunto se chama harness. Neste post mostro o meu, peça por peça, com links para você montar o seu.
Uso o Claude Code no terminal como ferramenta principal. As ideias valem para outros agentes também.
Neste post:
- Instruções em camadas
- Memória entre sessões
- Ferramentas via MCP
- Skills e plugins
- Permissões e auto mode
- Hooks: o caso do RTK
- Verificação no app de verdade
- Como começar
Instruções em camadas
O Claude Code lê arquivos CLAUDE.md no início de cada sessão. Tenho três níveis:
- Global (
~/.claude/CLAUDE.md): vale para todos os projetos. O meu tem só regras de escrita, porque é onde a IA mais escorrega. Proíbe frases de enchimento ("Vamos mergulhar"), travessões, conclusões que repetem a introdução e títulos vagos. Essas regras vieram da skill unslop, que por sua vez se baseia na lista da Wikipédia de sinais de texto escrito por IA. - Repositório: o
CLAUDE.mdna raiz do meu monorepo explica os comandos, os apps e o que roda antes de cada push. - App: cada app tem o seu, com a arquitetura e as armadilhas daquele código.
Também uso arquivos em ~/.claude/rules/ para regras de uma ferramenta específica, e um arquivo pode importar outro com @arquivo.md.
A regra que mais funciona: escreva o que a IA não consegue descobrir lendo o código. "O projeto usa Next.js" ela descobre sozinha. "Nunca rode prisma db push, as migrações são aplicadas pelo deploy" ela não descobre.
Docs: Memória e CLAUDE.md.
Memória entre sessões
Além do CLAUDE.md, o Claude Code tem uma memória automática por projeto. Cada memória é um arquivo pequeno com um fato só, e um índice (MEMORY.md) lista todos em uma linha cada. O índice é carregado em toda sessão; o arquivo inteiro só quando o assunto aparece.
Separo quatro tipos:
- Feedback: correções que dei. "Não faça deploy manual na Vercel, o push já faz." Sempre com o motivo, para a IA saber quando a regra se aplica.
- Projeto: fatos que não estão no código. "O
.envlocal desse app aponta para o banco de produção, rode scripts em dry-run primeiro." - Referência: onde achar as coisas.
- Usuário: como eu trabalho e o que eu prefiro.
O ganho é não repetir a mesma correção toda semana. Hoje tenho 20 memórias no monorepo, e cada uma nasceu de um erro que não quero ver de novo.
Ferramentas via MCP
O Model Context Protocol deixa a IA usar ferramentas externas por uma interface padrão. Os que mais uso:
- Meus próprios servidores: um para o Google Workspace (Sheets, Docs e Slides) e outro para o app que uso para controlar minhas finanças pessoais. Pedir "lança essa nota fiscal" ou "quanto gastei com mercado em outubro" virou conversa.
- Infraestrutura: Neon (Postgres), Vercel e Cloudflare.
- Observabilidade: Sentry para erros, PostHog para produto, Langfuse para chamadas de LLM.
- Trabalho: Linear, Slack, Gmail, Google Calendar, Google Drive e Granola (notas de reunião).
- Dispositivos: Argent, da Software Mansion, para a IA tocar, digitar e tirar screenshots no simulador iOS, no emulador Android e em apps Chromium.
Uma dica: deixe o MCP no escopo certo. Ferramentas que só fazem sentido num repositório ficam no .mcp.json desse repositório, não no global.
Docs: MCP no Claude Code.
Skills e plugins
Uma skill é um manual que a IA carrega quando a tarefa pede. É uma pasta com um SKILL.md que diz quando usar e o passo a passo. Alguns exemplos que uso:
- unslop e no-ai-slop para revisar texto. Este post segue as regras delas.
- seo-audit e web-perf para sites.
- Skills de Next.js, Cloudflare Workers e Argent para cada stack.
- Uma skill do próprio repositório para registrar horas de trabalho a partir dos commits. Era uma tarefa repetitiva com muitos detalhes, e agora é um comando.
Plugins juntam skills, comandos e servidores MCP num pacote. Tenho ativos os da Vercel, Expo, Cloudflare e Stripe. Para achar skills prontas, uso o skills.sh e o repositório anthropics/skills.
Permissões e auto mode
Deixo o Claude Code em auto mode: ele roda os comandos sem me pedir confirmação a cada passo, e um classificador bloqueia ações arriscadas. Tenho poucas regras de allow explícitas.
O bloqueio funciona. Quando fui instalar o RTK (próxima seção), o Claude tentou rodar o comando que altera as configurações do próprio Claude Code, e o auto mode barrou: a IA não pode mudar as próprias regras. Ele me passou o comando e eu rodei. É o comportamento que eu quero.
Docs: Modos de permissão e Permissões.
Hooks: o caso do RTK
Hooks são comandos que rodam em momentos fixos da sessão: antes de uma ferramenta, depois dela, no início da sessão. O mais novo no meu harness é o RTK.
O que é
O RTK é um programa em Rust que fica entre o terminal e a IA. Ele roda o comando de verdade, filtra a saída e entrega um resumo. Um git status vira "limpo, nada para commitar". Testes que passam viram PASS (101). A ideia é gastar menos tokens com ruído. Conheci pelo artigo do Rafael Pazini, que mediu 5,3 milhões de tokens economizados em 612 comandos (mais da metade vindo de uma única execução de testes do Gradle).
Como instalei com segurança
Um hook que reescreve todo comando que a IA roda tem acesso a tudo que ela tem. Antes de instalar, pedi ao Claude para revisar o código da versão exata que eu ia usar:
- Baixamos o código da v1.2.0 e conferimos que o checksum era o mesmo da fórmula do Homebrew.
- Lemos as partes que importam para segurança: o script de build, cada chamada de rede, a telemetria, o hook do Claude Code e onde ele grava arquivos.
- A telemetria só existe se a URL for definida na hora da compilação. O build do Homebrew não define, então ela nem existe no binário. O próprio
rtk telemetry statusconfirma. - O hook só aprova um comando sozinho quando uma regra
allowminha já aprovaria. Regras dedenyeaskcontinuam valendo. - O proxy de API e o envio de leituras grandes para outro modelo são opcionais. Recusei os dois.
Depois instalei com brew install rtk, fixei a versão com brew pin rtk e configurei o hook com rtk init -g.
O que ganhei e o que perdi
No primeiro dia, 39 comandos economizaram 39,5% dos tokens. Mas resumir é escolher o que cortar, então testei os comandos que mais uso, com e sem o RTK:
- Sem perda: leitura de arquivos, buscas pequenas, diffs pequenos, erros do
tsce os códigos de saída de todos os comandos. - Diffs grandes: um diff de 15 commits voltou com 362 das 9.896 linhas alteradas.
- Testes que falham no Vitest: some o bloco "Expected / Received", que é justamente o que mostra a diferença.
git log: mostra só 10 commits e corta as mensagens.- Buscas grandes: um
grepmostrou 205 de 2.020 linhas.
Em todos os casos o RTK avisa o corte e diz como recuperar a saída completa (rtk recall <id>), e rtk bypass <comando> roda sem filtro. O risco é a IA não perceber o aviso. Minha conclusão: vale para testes, lint e logs barulhentos. Para ler código e depurar, desligo o filtro desses comandos.
Outros hooks
Uso o Lefthook para um hook de git antes de cada push. Ele olha quais apps os commits alteram e roda só o lint, o typecheck e os testes desses apps. Não é um hook do Claude Code, mas segue a mesma ideia: uma verificação automática que não depende de alguém lembrar.
Docs: Hooks.
Verificação no app de verdade
Testes passando não garantem que a tela está certa. Por isso a IA também abre o app:
- Web: a extensão do Claude para o Chrome navega, clica e lê o console.
- Mobile: o Argent opera o simulador e o emulador, e lê a árvore de componentes do React Native.
A regra nas minhas instruções é simples: mudou algo visível, confira no app antes de dizer que terminou.
Como começar
Não precisa montar tudo de uma vez. A ordem que eu seguiria:
- Crie um
CLAUDE.mdcurto com o que a IA não descobre sozinha. - Toda vez que corrigir a IA na mesma coisa duas vezes, vire isso uma regra ou uma memória.
- Adicione um MCP para a ferramenta que você mais abre durante o dia.
- Transforme sua tarefa mais repetitiva numa skill.
- Só depois pense em hooks. Revise o código de qualquer hook de terceiros antes de instalar e fixe a versão.
Se quiser mais dicas pontuais, escrevi sobre ferramentas de IA para o dia a dia do dev.
Referências:
