Até onde deixar o Claude Code agir hoje? A planilha de 4 níveis de aprovação

Numa sexta-feira à tarde, eu só queria mandar uma correçãozinha para o ambiente de staging.

Pedi apenas: “corrige um erro de digitação na documentação e, de quebra, confere se o build passa”. O Claude Code corrigiu o erro, mas também atualizou dois pacotes de dependência por conta própria e ainda reescreveu a referência ao .env.production. Como o build local passava, ele (a IA) anunciou “concluído” com a maior tranquilidade.

O que me deu um frio na espinha foi perceber que eu só notei isso depois de revisar o diff até o fim. O problema não era a IA ser ruim. A causa era que eu nunca tinha colocado em palavras “até onde ela podia ir”.

No dia oposto, já me aconteceu o contrário: um “Permitir? Sim/Não” atrás do outro, umas 30 vezes seguidas, só para criar um único commit. Esgotei minha paciência. Liberar demais causa acidente, apertar demais trava o trabalho. Este artigo é sobre uma única planilha que ajuda a traçar a linha certa no meio desses dois extremos.

Pontos principais

• Divida o que você delega ao Claude Code em 4 níveis: “só ler”, “só corrigir algo reversível”, “publicar” e “tocar em informação secreta”.
• Para cada nível, defina antes “quem dá o OK final” e “o que basta olhar para dizer que está seguro (a prova)”.
• Níveis 0 e 1 ficam com a IA, o nível 2 exige verificação humana, e no nível 3 só a pessoa responsável põe a mão.
• Declarar de manhã, numa frase, “hoje vou até aqui” derruba de uma vez o número de aprovações.
• Deixei pronto um código de registro para copiar e colar, além de um modelo que se decide em 1 minuto toda manhã.

Por que decidir o “orçamento de aprovação” antes

O que esgota você nas aprovações não é o desempenho do Claude Code. É começar a correr sem ter decidido até onde permitir hoje.

Sem essa decisão, a gente cai para um de dois lados. Por preguiça, vai apertando “Permitir” em tudo, até que um dia deixa passar uma operação perigosa. Ou então fica cauteloso demais, exige confirmação até para corrigir um erro de digitação, e o trabalho não anda. Os dois lados têm o mesmo defeito: deixam a decisão por conta do humor do momento.

É aí que entra a ideia de “orçamento de aprovação”. Igual ao orçamento de dinheiro: até esta faixa é livre hoje, daqui para frente um humano decide, definido com antecedência. Com a faixa pronta, você não precisa ficar com o coração na mão a cada resposta da IA. O que importa não é “se a IA é esperta”, e sim “em qual faixa ela parou”.

Colocar o critério em palavras também evita brigas no time. Em vez de “parei porque fiquei meio inseguro”, você diz “isto é nível 2, então é a vez do humano verificar”. A lógica do design de permissões aparece também no Guia de introdução ao Claude Code, mas aqui a gente foca no chão de fábrica: “a linha de hoje”.

Dividir o trabalho delegado em 4 níveis

Primeiro, separe o trabalho que você quer dar ao Claude Code em quatro níveis, na ordem do perigo. Sem complicar: classifique só por “dá para desfazer?”, “vai ser publicado?” e “mexe em dinheiro ou segredo?”.

Nível	Exemplo de trabalho	Quem dá o OK final	Prova de que está seguro
0	Ler arquivos, entender a estrutura	A IA cuida	Lista do que foi lido
1	Corrigir 1 arquivo reversível	A IA (humano olha o diff)	Diff e resultado do build
2	Publicar no site público	Humano decide	URL pública e plano de rollback
3	Tocar em segredos, cobrança, dados de clientes	Só a pessoa responsável	Aprovação por escrito

O ponto-chave desta tabela são as duas colunas da direita. Decida antes de começar o trabalho “quem dá o OK” e “o que basta olhar para dizer que está seguro”. Se você decidir depois, acaba se deixando levar pela empolgação do “concluído!” da IA e pula a verificação.

O “reversível” do nível 1 é o segredo. Corrigir um erro de digitação ou adicionar um comentário pode ser desfeito na hora, mesmo se der errado. Por isso você delega à IA e o humano só dá uma olhada rápida no diff. Já atualizar um pacote de dependência sobe para o nível 2. Por menor que pareça, não dá para prever o alcance do impacto. O acidente que contei lá no começo aconteceu exatamente porque eu tinha tratado isso como nível 1.

O que delegar à IA e o que você mesmo decide

Vou deixar a linha um pouco mais nítida. Você pode delegar à IA o trabalho em que, se errar, você percebe na hora e desfaz na hora. Quem deve decidir é o humano no trabalho que, uma vez executado, gera impacto para fora.

• Delegue à IA: ler, pesquisar, fazer rascunhos, corrigir 1 arquivo reversível, rodar testes.
• Humano decide por último: publicar, mudar dados de produção, cadastrar em serviços externos, atualizar dependências, apagar coisas.

Na dúvida, suba um nível. Só com isso você já não erra feio. Vá automatizando depois, um nível por vez, apenas as operações em que você ficou de fato convencido da segurança. O truque é não tentar a automação total logo de cara. Essa lógica de “promover aos poucos” combina bem com escrever as regras do projeto no arquivo certo, como mostra Boas práticas de CLAUDE.md. Deixe a linha que você traçou registrada no arquivo para conseguir reproduzir.

Registro de aprovação para copiar e colar

Só com palavras, a gente esquece. Então vamos deixar os 4 níveis num formato que a máquina lê, para conseguir filtrar e mostrar “até onde vamos hoje”. Se você tem Node.js, roda direto.

// Registro de aprovação: cada tarefa carrega "nível de perigo", "responsável" e "prova"
const approvalBudget = [
  { action: "ler arquivos",                  level: 0, owner: "IA",             proof: "lista do que foi lido" },
  { action: "corrigir 1 arquivo reversível", level: 1, owner: "IA (humano confere)", proof: "diff e resultado do build" },
  { action: "publicar no site público",      level: 2, owner: "humano",         proof: "URL pública e plano de rollback" },
  { action: "tocar em segredos ou cobrança", level: 3, owner: "só responsável", proof: "aprovação por escrito" },
];

// Limite de hoje. 0 = só ler; 1 = delega à IA até correções reversíveis
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`Limite delegado à IA hoje: nível ${todayMax}`);
console.table(allowedToday);
console.log("Trabalho que o humano decide:");
console.table(needsHuman);

Para executar, é só isto. Você troca o “limite de hoje” por variável de ambiente.

# Hoje delega até "correções reversíveis"
APPROVAL_MAX=1 node approval-budget.mjs

# Hoje deixa só leitura
APPROVAL_MAX=0 node approval-budget.mjs

Mantenha os nomes dos campos e reescreva o conteúdo de action e proof para o seu projeto. Se você entregar este código ao Claude Code e pedir “preencha os valores para o nosso repositório”, um rascunho fica pronto na hora.

Modelo de prompt para decidir em 1 minuto toda manhã

Com o registro pronto, antes de começar o trabalho você comunica à IA a “faixa de hoje”. Copie o texto abaixo e preencha os espaços.

Vou definir a faixa de trabalho de hoje antes de começar.

- Objetivo de hoje: (ex.: corrigir erros de digitação e links quebrados de 1 post)
- Pode ler: somente site/src/content/blog/
- Pode corrigir: apenas 1 arquivo dentro do acima (só mudanças reversíveis)
- Comandos permitidos: npm run lint, rodar os testes
- Não tocar: .env, deploy de produção, atualização de dependências, exclusões

Regras:
- Nível 2 ou acima (publicar, dados de produção, atualizar dependência, excluir): sempre pare e confirme comigo antes.
- Ao corrigir, mostre no final o diff e o resultado do build como "prova".
- Não termine com um simples "concluído"; escreva com qual comando você verificou.

Só com esta frase, a IA para de “fazer tudo de uma vez” e passa a agir dentro da faixa. Quando pegar o jeito, mova esse conteúdo para o arquivo de regras do projeto seguindo Boas práticas de CLAUDE.md. Aí some até o trabalho de colar o prompt toda manhã.

Onde isso faz diferença (3 casos)

1. Revisão em massa de blog e materiais Só “corrige o artigo” faz a IA reescrever de uma vez o corpo, os caminhos de imagem e os links. Com o registro de aprovação separando “erro de digitação no corpo é nível 1, publicar é nível 2”, você delega o texto e mantém o botão de publicar na sua mão. Se exigir o diff e o resultado do build como prova, a revisão noturna fica bem mais leve.

2. Triagem de atendimentos Ler e classificar os atendimentos que chegam é nível 0, pode delegar à IA. Mas cadastrar no registro de clientes é nível 3. Mesmo que a IA julgue “isto pode virar negócio”, gravar no banco de produção fica em espera até a pessoa responsável apertar o botão. Forçar isso pelo registro elimina o acidente de cadastrar um cliente classificado errado.

3. A respirada antes do deploy Publicar fica sempre no nível 2. Não trate como “concluído” só porque o build local passou: pare até verificar a URL pública, o título e o plano de rollback. Aquela “atualização de dependência por conta própria” que eu fiz no começo também teria parado na verificação humana, com certeza, se o nível 2 estivesse explícito.

Tropeços comuns e como corrigir

O mais frequente é tentar terminar tudo num único pedido e gerar um diff gigante que ninguém consegue verificar. A correção é simples: limite o pedido a “um entregável por vez”. Um artigo, um PR, uma configuração. Cortando pequeno, você consegue ler o diff até o fim.

O segundo mais comum é tratar como concluído só pelo build local ter passado. No site público pode estar aparecendo outra página, ou a home, e você fica tranquilo só de ver um HTTP 200. Se você puser “verificar a URL pública e o título” na coluna de prova, você para aqui.

O terceiro é não registrar o que foi testado. No dia seguinte você refaz a mesma decisão do zero. Basta deixar uma linha de anotação (mais abaixo) para o seu eu de amanhã não ficar perdido. Se você quer melhorar a própria forma de pedir ao Claude Code, vale ler também Engenharia de prompts avançada: a maneira de comunicar a faixa melhora um degrau.

Perguntas frequentes

P. Vale a pena dividir os níveis de aprovação em mais subdivisões? No começo, 4 níveis bastam. Quanto mais você aumenta, mais complexa fica a operação e, no fim, ninguém segue. Depois de rodar um tempo, ramifique só os pontos em que você sentiu que ficou grosseiro demais.

P. Como saber se algo é “reversível” no nível 1? Decida por dois pontos: “dá para desfazer com 1 comando do git?” e “tem impacto para fora?”. Edição de arquivo se desfaz, mas deploy, cobrança, envio de e-mail e exclusão não se desfazem. Na dúvida, suba para o nível 2.

P. Em time, quem decide os níveis? Quem vai começar o trabalho declara de manhã, e os responsáveis pelo nível 2 ou acima são definidos com antecedência. Se a pessoa responsável estiver ausente, deixe combinado que o trabalho de nível 3 não acontece naquele dia. É mais seguro.

P. É chato colar o prompt toda vez. Quando a faixa estiver bem definida, mova-a para o arquivo de regras do projeto (CLAUDE.md). A IA lê esse arquivo toda vez, então a colagem deixa de ser necessária.

P. Quem não é engenheiro também consegue usar esta planilha? Consegue. Mesmo sem rodar código, dá para traçar a linha só com a tabela de 4 níveis e o modelo de prompt. Para uso fora da engenharia, vale o Claude Code para não engenheiros.

Anotação para o handoff

Deixar a decisão do dia em uma linha evita que o seu eu de amanhã, ou o time, repita a mesma dúvida. É só copiar o formato abaixo e preencher.

- Data: 2026-06-07
- Objetivo de hoje: corrigir erros de digitação e links quebrados de 1 post
- Limite de hoje: nível 1 (até correções reversíveis)
- Prova: diff, log de npm run build, conferência do título na URL pública
- Onde o humano parou: atualização de dependência (em espera por ser nível 2)
- Recado para a próxima vez: juntar atualizações de dependência em outro dia, no nível 2

Com essa anotação, a verificação pós-publicação também fica fácil. Só HTTP 200 não basta: na URL pública, confira até o título, a URL canônica (canonical), a imagem de capa e o começo do corpo, para garantir que tudo é mesmo deste artigo. Se aparecer outro post ou a home, trate como não publicado e refaça build e deploy. A lógica oficial de design de permissões você também confere na documentação oficial da Anthropic.

O que aconteceu quando testei de verdade

Apliquei esta planilha na operação do meu próprio blog durante duas semanas.

O que mais funcionou foi passar a colar de manhã a frase “hoje vou até o nível 1”. Só com isso, os “Permitir?” por commit caíram, na sensação, para menos da metade. Quando a IA tentava avançar para o nível 2 ou acima, ela parava direitinho conforme a regra do modelo e vinha me perguntar. Aquele acidente do começo, “quando vi, a dependência tinha sido atualizada”, ficou em zero desde então.

Por outro lado, descobri que a tabela de níveis, se só montada, não é usada. Rodando de fato o código do registro e jogando “o trabalho delegado de hoje” na tela antes de começar, a chance de eu cumprir subiu. Em vez de procurar a IA mais esperta, traço antes uma faixa em que, mesmo caindo, dá para voltar. É discreto, mas é o que me deixa delegar com menos estresse hoje.

Se você quer estender essa linha para o time inteiro ou para a operação de produção, dá para desenhar as faixas juntos no treinamento e consultoria. Para começar, amanhã de manhã, experimente colar uma frase: “hoje vou até o nível 1”.