Quando usar o Claude Code: como saber se a tarefa vale a pena delegar antes de mandar o pedido

Fala aí, beleza? Tarefa mal escolhida pro Claude Code não falha rápido, e é exatamente aí que ela machuca

O código volta, parece pronto, roda

Aí você abre, lê, acha um caso de borda estranho, pede ajuste, lê de novo, pede outro ajuste… e três rodadas depois percebe que teria feito na mão em quinze minutos 😅

O problema quase nunca é o modelo, é a ESCOLHA da tarefa

Existe um filtro de três perguntas que dá pra aplicar antes de digitar qualquer coisa: o escopo cabe numa frase? existe um check automatizável que diz se ficou pronto? você domina o assunto o bastante pra julgar o resultado?

E ele serve tanto pra dizer sim quanto pra dizer não, que é a parte que a galera pula

Bora ver o quadro?

Sinal verde x sinal vermelho: o quadro de decisão antes de mandar o pedido

Três dimensões, duas colunas, zero mistério

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

A documentação oficial de boas práticas é bem direta nos dois extremos: escopo claro com correção pequena vai direto, sem planejar, e se você conseguiria descrever o diff em uma frase dá pra pular o plano

Do outro lado, o planejamento compensa justamente quando há incerteza de abordagem, quando a mudança toca vários arquivos ou quando o código é desconhecido pra você

Repara numa coisa: a tabela NÃO é veredito final

Sinal vermelho não significa "não delega", significa "não delega ASSIM"

Cada vermelho tem uma ação correspondente, na MESMA ordem da tabela, e é isso que vem agora

O que fazer com a tarefa que não passa direto no filtro

Vermelho no escopo: incerteza, várias frentes ou código desconhecido pedem modo plano

O gatilho aqui é a primeira linha da tabela

O fluxo recomendado pela Anthropic pra tarefa não trivial é explorar, planejar e só então codar: explore, plan, code

No modo plano o Claude lê o código e explica como funciona, depois produz um plano dizendo quais arquivos mudam, qual o fluxo e o que pode quebrar

Só depois disso ele implementa, verificando contra esse plano

Pra entrar, tem dois caminhos: pressionar Shift+Tab até a barra de status mostrar ⏸ plan mode on, ou já iniciar a sessão assim:

claude --permission-mode plan

Nesse modo ele lê arquivos e responde perguntas SEM fazer alterações, o que é exatamente o que você quer quando ainda não sabe qual é a abordagem certa

Pra sair, você aprova o plano ou aperta Shift+Tab de novo, e a partir daí ele implementa

O ganho é óbvio quando você para pra pensar: revisar um plano de dez linhas custa muito menos que revisar um diff em sete arquivos 🙂

Vermelho no critério de pronto: escreve o check ANTES de mandar o pedido

Segunda linha da tabela, e é a que mais gente pula

A doc oficial aponta a verificação automatizável como a alavanca mais forte de qualidade

E check aqui não é nada sofisticado: é qualquer coisa que devolva um sinal que o Claude consiga ler

Suíte de testes, exit code de build, linter, script que compara a saída com um fixture, screenshot do navegador comparado ao design

Se nenhum desses existe pra essa tarefa, o resultado é previsível: "parece pronto" vira o único sinal e VOCÊ assume o loop de verificação na mão

Então a ação é inverter a ordem: primeiro nomeia o comando que diz se ficou pronto, depois escreve o pedido

E se não der pra nomear nenhum, quebra a tarefa até sobrar um pedaço que dê pra checar, beleza?

Vermelho no domínio do assunto: precisão na entrada é menos correção na saída

Terceira linha, e ela tem duas caras

Se você domina o assunto mas o pedido saiu genérico, o conserto é rápido: a doc em português relaciona as duas coisas de forma direta, quanto mais precisas as instruções (referenciar arquivos específicos, mencionar restrições, apontar padrões de exemplo), menos correções serão necessárias

Então antes de mandar, responde três coisas no próprio pedido: em QUAL arquivo, com QUAIS restrições, seguindo QUAL exemplo que já existe no projeto

Agora, se você não domina o bastante nem pra escrever o critério de aceite, precisão sozinha não salva: aí é modo plano primeiro, pra ler o código e entender antes de pedir mudança

Quando a tarefa é maior e isso não cabe num parágrafo, o caminho é escrever a spec antes de implementar, que é a versão formal da mesma ideia

Caso à parte: tarefa lateral que inundaria a conversa vai pra um subagente

Esse aqui não é linha da tabela, é um quarto gatilho que aparece DEPOIS que a tarefa já passou no filtro

A tarefa até é boa, o problema é que ela ia entupir a sessão principal de busca, log e arquivo

Cada subagente roda na própria janela de contexto, com system prompt, acesso a ferramentas e permissões próprios

É indicado justamente quando uma tarefa lateral inundaria a conversa principal com resultados de busca, logs ou arquivos, porque só o RESUMO volta pra conversa

O exemplo que a doc em português dá é bem concreto: pedir que um subagente faça a revisão de segurança do código do processador de pagamentos, mantendo o contexto dessa revisão separado da conversa principal

E tem um efeito colateral massa: um revisor rodando em contexto de subagente novo enxerga só o diff e os critérios que você deu, não o raciocínio que produziu a mudança

Ou seja, ele avalia o resultado por conta própria, sem estar contaminado pela própria justificativa de quem escreveu

Os sinais de que você vai gastar mais tempo revisando do que faria na mão

Agora a parte que ninguém gosta de ouvir: os sintomas de que a escolha saiu errada

Sintoma: a entrega parece plausível e quebra no caso de borda

A causa tem nome na doc oficial: trust-then-verify gap

É o padrão em que o Claude produz uma implementação plausível que não trata casos de borda

A correção indicada é sempre fornecer verificação (testes, scripts, screenshots) e simplesmente NÃO entregar o que não dá pra verificar

E tem um segundo movimento que economiza muito tempo: exigir evidência em vez de afirmação de sucesso

Pede pra ele mostrar a saída do teste, o comando que rodou e o retorno, ou um screenshot

Revisar evidência é mais rápido que refazer a verificação você mesmo, e é a diferença entre confiar e conferir

Sintoma: ele esquece a instrução que você deu no começo

Aqui a causa é mecânica, não é "burrice" do modelo

A janela de contexto guarda a conversa inteira, cada arquivo lido e cada saída de comando

Ela enche rápido, e o desempenho degrada conforme enche: com o contexto cheio o Claude pode esquecer instruções anteriores e errar mais

É por isso que a maioria das boas práticas existe, no fim das contas

Três ferramentas resolvem a maior parte disso:

• /clear reseta a conversa pra um contexto vazio, mantendo a memória do projeto; a conversa anterior continua salva em disco e pode ser retomada pelo ID da sessão
• /compact resume o histórico pra liberar espaço, e aceita um foco, tipo /compact focus on the API changes
• /rewind abre um menu com os prompts da sessão e deixa restaurar código e conversa, só a conversa, só o código, ou resumir a partir de / até aquele ponto

Regra prática: se o histórico ainda é útil, compacta com foco; se não é, limpa

Sintoma: a instrução do projeto é simplesmente ignorada

Causa provável: CLAUDE.md longo demais

A doc trata isso como problema explícito: se o arquivo é longo demais o Claude ignora metade, porque as regras importantes se perdem no ruído

A correção é podar sem dó, e converter em hook aquilo que já sai certo sem instrução nenhuma

Falando em hook, dá pra ir além do check estático: hooks do tipo agent sobem um subagente que lê arquivos e usa ferramentas antes de devolver a decisão, com timeout padrão de 60 segundos e até 50 turnos de uso de ferramenta

Tome cuidado com um detalhe: o Claude Code sobrepõe um Stop hook depois que ele bloqueia 8 vezes seguidas sem progresso

Ou seja, hook não é muro infinito, é sinal 😀

E fecho essa parte com o erro mais barato de evitar da lista toda: a kitchen sink session

É quando você começa uma tarefa, pergunta algo não relacionado e volta pra primeira, enchendo o contexto de informação irrelevante

A correção é ridícula de simples: /clear entre tarefas não relacionadas

O que o uso real mostra sobre quem escolhe bem a tarefa

Até aqui é critério, agora vamos pro dado, pra não virar achismo

A Anthropic fez uma análise com preservação de privacidade de aproximadamente 400.000 sessões interativas, de cerca de 235.000 pessoas, entre outubro de 2025 e abril de 2026

O que aparece sobre escolha de tarefa bate certinho com o filtro: as pessoas tendem a delegar tarefas facilmente verificáveis ou de baixo risco, e descrevem uma progressão de confiança, começando pelo simples e delegando trabalho mais complexo com o tempo

Agora o achado que muda a leitura da terceira linha da tabela: especialistas no domínio conseguem fazer o Claude entregar mais trabalho por instrução, e essa capacidade de dirigir vem mais do domínio do ASSUNTO do que da habilidade de escrever código

Se liga no que isso significa na prática: você não precisa ser o melhor programador da sala pra delegar bem, precisa entender o problema bem o suficiente pra dizer o que conta como pronto

O estudo ainda separa as decisões da sessão em dois grupos, e essa é literalmente a linha do filtro:

• planejamento: o que fazer, qual abordagem, o que conta como pronto
• execução: quais arquivos mudar, que código escrever, em que linguagem, quais comandos rodar

O filtro é você segurando o primeiro grupo e soltando o segundo

Pra dimensionar a escala em que isso já roda: mais de 80% do código integrado (merged) na base da Anthropic é autorado pelo Claude, número que era de um dígito baixo antes do lançamento do Claude Code em research preview, em fevereiro de 2025

E no segundo trimestre de 2026 o engenheiro típico de lá integrava 8 vezes mais código por dia do que em 2024, com o engenheiro dirigindo e revisando em vez de digitar

Outro movimento interessante do mesmo estudo: escrita e análise de dados praticamente dobraram, de cerca de 10% para cerca de 20% das sessões, entre outubro de 2025 e abril de 2026

O terreno não é só código, mas o critério de decisão continua o mesmo

O que aprendi na prática escolhendo o que mandar (e o que não mandar)

No vídeo abaixo eu mostro o fluxo inteiro na prática: abrir a ferramenta dentro da pasta do projeto, escrever o pedido em linguagem natural e deixar a IA analisar e executar

E o primeiro pedido foi proposital de baixo risco: perguntei o que existia naquele diretório (que estava vazio), só pra confirmar que estava tudo funcionando antes de pedir qualquer coisa maior

Parece bobo, mas é o filtro em ação: escopo minúsculo, resposta verificável em dois segundos, risco zero

Depois disso eu criei um projeto do zero com um pedido curto e direto: uma calculadora de IMC com HTML, CSS e JavaScript, pedindo também uma interface bonita

Quando testei, abri o projeto no navegador, inseri o peso e a calculadora funcionou sem problema

Repara por que essa tarefa é fácil de delegar: o critério de pronto era eu abrir no navegador e ver o número certo aparecer

Na sequência eu fiz um pedido de evolução em cima do projeto que já existia (um botão pra reiniciar a calculadora depois do cálculo, e dicas na tela), mostrando que o MESMO fluxo serve pra criar e pra incrementar

O terreno natural que eu apresento ali são as tarefas de dev do dia a dia: navegar pelo código e entender o projeto como um todo, criar e editar arquivos, executar comandos de terminal, fazer commits, criar e rodar testes e corrigir bugs

Dois hábitos que eu levo comigo e que economizam revisão:

• abrir o thinking depois da execução pra ver o raciocínio e como ele planejou cada funcionalidade
• usar o resumo final do que foi executado pra conferir o trabalho, em vez de reler tudo do zero

Teve tropeço também, claro: esbarrei em falta de permissão na instalação no Windows, com o binário indo parar na pasta local do usuário, e resolvi fechando o terminal e testando de novo

Já me ferrei uma vez por causa desse tipo de coisa, então vale registrar 😅

Outra coisa que eu comento no vídeo: no modo padrão ele pergunta antes de cada ação, tipo editar um arquivo, e isso deixa o desenvolvimento bem pausado

Minha recomendação continua a mesma: em projeto de equipe ou trabalhando pra uma empresa, fica sempre nos modos mais pausados pra entender o que está acontecendo antes de sair mudando tudo

Quem está sozinho fazendo vibe coding pode deixar no modo que faz tudo automático, beleza?

Os modos de permissão precisam ser estudados um a um pra você descobrir a qual se adapta melhor, e vale a leitura sobre permissões e sandbox no Claude Code antes de soltar a mão

Ah, e eu prefiro usar pela interface dentro do VS Code em vez do terminal puro: acho mais amigável e faz mais sentido pra maioria das pessoas

Um detalhe de organização que combina demais com o filtro: a recomendação oficial é nomear a sessão com /rename e tratar cada frente de trabalho como uma branch, com contexto persistente próprio, já que as conversas ficam salvas localmente

Uma frente, uma sessão, um critério de pronto

O vídeo é um tutorial completo pra iniciantes, do zero ao projeto, e ele complementa o filtro pelo lado prático: você vê o tamanho de pedido que passa liso e o momento em que o pedido cresce e começa a exigir mais conferência sua

Conclusão

O filtro cabe numa linha: escopo que você descreve em uma frase, critério de pronto que uma máquina consegue checar, e assunto que VOCÊ domina o suficiente pra julgar o resultado

Próximo passo concreto, e é pra fazer antes do próximo pedido: escreva o critério de pronto como um comando que dá pra rodar

Suíte de testes, exit code de build, linter, script comparando a saída com um fixture, screenshot comparado ao design, qualquer coisa que devolva sinal que o Claude consiga ler

Se você não conseguir escrever esse comando, a tarefa ainda não está pronta pra ser delegada, e o caminho é modo plano antes de código, não pedido maior

E quando o filtro já estiver afiado, o estágio seguinte aparece sozinho: times da Anthropic montam loops autônomos em que o Claude escreve o código, roda os testes e itera, partindo de um estado limpo no git, deixando rodar e revisando a solução antes dos ajustes finais

Olha a lógica se repetindo: git limpo é escopo fechado, testes são o critério de pronto, e a revisão final é você segurando o planejamento

Sempre a mesma régua, só que em outra escala 😀

até o próximo post!