Quando parar de insistir com o Claude Code e escrever o código na mão?

Fala aí, beleza? Terceira tentativa no mesmo bug, o Claude Code já trocou de abordagem duas vezes, e o erro voltou com outra cara

E aí bate aquela sensação chatinha: a próxima mensagem resolve

Só que na maioria das vezes a próxima mensagem não resolve, ela só empurra o problema pra frente e engorda a conversa

O ponto aqui não é o Claude Code ser ruim, longe disso. O problema é que ninguém define um critério de parada antes de abrir a sessão, então a decisão de continuar fica na mão da esperança 🙂

Neste post eu te entrego sinais objetivos de que a conversa virou custo, e principalmente o que fazer com o trabalho que já foi feito na sessão antes de você assumir o teclado

Por que a sua sensação de velocidade não serve como critério

Em julho de 2025 a METR publicou um estudo randomizado com devs open source experientes: 16 desenvolvedores, 246 tarefas

O resultado foi contraintuitivo: o tempo de conclusão foi 19% MAIOR quando a IA era permitida (intervalo de confiança de +2% a +39%)

E o detalhe que dói: os próprios participantes estimaram depois que a IA tinha deixado eles 20% mais rápidos

Ou seja, percepção e relógio apontaram pra lados opostos

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Agora, sendo honesto com o cenário atual: a METR atualizou esse quadro em 2026, e o número de 19% mais lento não descreve mais o estado da medição

Na rodada seguinte (57 desenvolvedores, 143 repositórios, mais de 800 tarefas), a medição foi refeita separando dois grupos: o subconjunto de devs que já tinha participado do estudo original e os recém-recrutados

A própria METR considera provável que os devs estejam mais acelerados em 2026 do que na estimativa de 2025, mas classifica os próprios dados como evidência fraca por causa de um efeito de seleção: entre 30% e 50% dos desenvolvedores relataram escolher não submeter algumas tarefas justamente por não quererem fazê-las sem IA

Então o que sobrevive às duas rodadas não é o número, é a lição

A sua percepção de velocidade não é instrumento de medição. Você não sente o tempo que perde insistindo, você sente o movimento da conversa

Se o critério vai depender do seu feeling no meio do fluxo, ele já falhou. O critério precisa ser externo e definido antes

Os sinais objetivos de que a conversa virou custo

Aqui entram os sinais que você consegue observar na tela, sem precisar adivinhar nada

Sinal 1: tentativas sem avanço (a mesma classe de erro volta)

Sintoma: você já aplicou duas ou três correções DIFERENTES e o erro volta na mesma classe. Muda a mensagem, muda a linha, mas o tipo de falha é o mesmo

Causa provável: não é falta de capacidade do modelo, é falta de informação. Existe algo que só você sabe (uma regra de negócio, um comportamento do ambiente, um detalhe da tela que você tem na cabeça) e que nunca entrou na conversa

O que fazer: assuma o trecho na mão. Se duas abordagens distintas falharam pelo mesmo motivo, a terceira tende a falhar igual

Como prevenir: antes de pedir, escreva o que o modelo não tem como saber. Isso vale muito pra interface, onde a informação costuma morar só na sua cabeça: eu já mostrei como descrever uma tela no prompt quando não existe design pronto

Sinal 2: escopo que só cresce

Sintoma: cada resposta toca mais arquivos que a anterior. Começou num componente, agora tá mexendo em config, util e rota

Causa provável: o pedido era grande demais, e o modelo tá tentando resolver por volume em vez de precisão

O que fazer: reverta os arquivos com Restore code no menu de rewind e reabra o pedido MENOR, num único arquivo

Como prevenir: peça uma coisa por vez. Pedido pequeno erra pequeno, e erro pequeno é fácil de jogar fora

Sinal 3: o trecho que você escreveria em minutos

Sintoma: você tá na segunda rodada explicando uma função que você digitaria em poucos minutos

Causa provável: o custo de explicar já passou o custo de digitar. Simples assim

O que fazer: escreva você. Não tem prêmio por fazer tudo via prompt haha

Como prevenir: esse é o mesmo raciocínio que eu uso pra tarefas de terminal. Pedir pro Claude subir o projeto faz o pedido passar pelo modelo, que precisa interpretar o contexto e voltar, quando o que roda de fato é um npm run dev que você digita em segundos

npm run dev

No vídeo eu rodo esse tipo de comando direto no terminal, sem passar pela LLM, e mostro que dá pra deixar rodando em background sem travar o uso do terminal

Não é preguiça premiada: terceirizar o que tu faz sozinho cobra caro em consumo

Sinal 4: contexto estourando no meio da tarefa

Sintoma: a sessão fica cada vez mais lenta de raciocínio, o modelo começa a esquecer decisões que vocês já tinham tomado ali mesmo

Causa provável: o histórico virou peso. Tem muita coisa irrelevante viajando junto em toda mensagem

O que fazer: rode /context pra ver o consumo por categoria, com sugestões de otimização e quais arquivos CLAUDE.md e de memória estão carregados. É um panorama ao vivo de quem tá ocupando espaço

Se o histórico pesa mais do que ajuda, o /compact pede ao modelo um resumo da conversa e substitui o histórico por esse resumo (o Claude Code também compacta automaticamente ao se aproximar do limite do contexto, funcionando da mesma forma)

Como prevenir: /clear entre tarefas, que é a recomendação da documentação oficial pra não reenviar contexto anterior irrelevante ao modelo

O que eu faço antes de desistir da sessão

Antes de fechar o assunto e ir escrever na mão, tem UM ajuste que muda o jogo em muitos casos, e é o mais ignorado de todos

Colar o erro inteiro é o jeito mais rápido de inflar a conversa sem aumentar a chance de acerto

No vídeo eu mostro justamente o hábito errado primeiro: pego o erro completo do repositório aberto e colo tudo no Claude pedindo correção, com a maior parte das linhas sem nenhuma utilidade pro diagnóstico

O log que eu uso na demonstração tinha por volta de 250 linhas, e na minha estimativa umas 200 dali eram desnecessárias (estimativa minha, não medição)

O que eu faço na prática é o contrário: abro o console, localizo o erro eu mesmo e colo só a primeira linha, o arquivo que estourou, no máximo com as linhas logo abaixo se elas trouxerem informação extra

No meu uso, o que vai pro Claude são no máximo 5 a 10 linhas do erro

Essa primeira linha já é suficiente na maioria dos casos pro modelo entender o problema, sem o trace inteiro de como ele chegou ali

E aqui tá o ponto de decisão que fecha o post: se você já recortou o erro pra 5 a 10 linhas e o modelo AINDA não avança, o gargalo não é contexto

É entendimento do problema

E entendimento do problema é o que você resolve digitando, não conversando 🙂

No vídeo acima eu mostro na tela esses hábitos de consumo, incluindo o recorte do erro e por que eu não deixo o esforço de raciocínio sempre no máximo (reservo o mais alto pra início de projeto, planejamento e módulo novo, e uso um nível intermediário no dia a dia depois que o projeto já existe)

O que fazer com o trabalho já feito na sessão

Decidiu parar? Beleza, agora não joga fora o que já foi feito

Essa é a parte onde a galera se ferra: fecha a sessão na raiva e perde o caminho de volta

1. Abra o menu de rewind com /rewind ou pressionando Esc duas vezes com o campo de prompt VAZIO. O menu lista os prompts enviados na sessão, porque o Claude Code cria um checkpoint a cada prompt que inicia um turno. Erro comum deste passo: apertar Esc duas vezes com texto digitado, aí o duplo Esc só limpa o texto e o menu nem aparece
2. Escolha a ação certa entre Restore code and conversation (reverte os dois), Restore conversation (volta a conversa mantendo o código atual), Restore code (reverte arquivos mantendo a conversa), Summarize from here e Summarize up to here. Pra quem vai codar na mão, o mais útil costuma ser Restore code, que limpa a bagunça nos arquivos e te deixa com a conversa ali pra consulta do que já foi discutido. E se o código tá bom mas a conversa azedou, Restore conversation mantém o que foi escrito em disco. Erro comum deste passo: pedir Restore code and conversation quando você só queria desfazer os arquivos, e perder o raciocínio da sessão junto
3. Saiba o que o checkpoint NÃO cobre. Só são rastreadas as mudanças feitas via Write, Edit e NotebookEdit. Arquivo alterado por comando Bash não é capturado, e ações em sistemas remotos (bancos de dados, APIs, deploys) não podem ser revertidas por checkpoint. Erro comum deste passo: tratar rewind como undo universal e descobrir tarde que a migration que rodou continua lá
4. Não conte com a sessão antiga. São guardados os snapshots de arquivo dos 100 checkpoints mais recentes por sessão, e uma varredura de retenção apaga esses snapshots por padrão cerca de 30 dias depois de a sessão salvar o último. Sem snapshot, o rewind falha com o erro No files were restored. Erro comum deste passo: deixar a decisão de recuperar pra semana que vem
5. Rode /clear antes da próxima tarefa, pra não reenviar contexto anterior irrelevante ao modelo. Você vai codar na mão o trecho travado, então a tarefa seguinte não precisa carregar o histórico do que deu errado. Erro comum deste passo: seguir pra tarefa nova na mesma conversa e levar a bagagem inteira do problema antigo

/rewind
/context
/compact
/clear

Quando ainda vale insistir (e quando começar já na mão)

Tem cenário em que insistir é o certo, viu? Nem tudo que demora é desperdício

A orientação oficial sobre plan mode é um bom termômetro aqui: ele compensa quando existe incerteza sobre a abordagem, quando a mudança mexe em vários arquivos ou quando você não conhece o código

E é overhead em correções pequenas e claras

Pra acionar, é Shift+Tab ou prefixar o prompt com /plan. As edições ficam bloqueadas até o plano ser aprovado, e a barra de status mostra ⏸ plan mode on. Shift+Tab de novo e você sai do modo sem aprovar nada

A leitura prática é essa: correção pequena e clara, em código que você domina, é candidata natural a escrever na mão desde o começo

Não precisa nem abrir a rodada de conversa

E se essa dúvida ainda mora com você em tarefa maior, eu destrinchei em outro post se o Claude Code vale a pena comparado com fazer tudo você mesmo

Conclusão

Parar de insistir com o Claude Code é decisão técnica, não derrota

O estudo da METR mostrou o que a segunda rodada dela não desmentiu: sensação de velocidade e velocidade real não são a mesma coisa, então o critério tem que vir de fora da sua cabeça

Os sinais são observáveis: mesma classe de erro voltando, escopo crescendo a cada resposta, trecho que você digitaria em minutos, contexto estourando no meio da tarefa

O próximo passo é simples e você faz hoje: defina um limite pessoal de tentativas ANTES de abrir a sessão

E na próxima vez que travar, use /rewind pra escolher o que salvar, depois /clear antes de começar a tarefa seguinte

Depois disso, abre o editor e escreve aquelas 15 linhas na mão, sem culpa 😀

até o próximo post!