Como testar o Claude no seu trabalho real antes de mudar seu jeito de trabalhar

Todo mundo tem um veredito sobre o Claude, e nenhum deles usou a sua tarefa

Nem o seu código, nem o seu cliente, nem o seu padrão de qualidade

A thread que diz que "mudou tudo" e o comentário que diz que "não serve pra nada" estão falando de um trabalho que não é o seu, e é por isso que os dois conseguem estar certos ao mesmo tempo

Então a saída é chata e simples: testar você mesmo, em cima de trabalho real, com critério definido antes de ver a primeira resposta

É isso que este post entrega: um roteiro de avaliação em três tarefas que você já sabe fazer, o que registrar antes, o que comparar depois e como fechar um veredito por critério em vez de por impressão

Bora? 🙂

O que você precisa antes de começar o teste

Antes do roteiro, o básico da mesa posta

Acesso ao Claude Code. Ele exige assinatura paga: está incluído nos planos Pro, Max, Team e Enterprise, e não está disponível no plano Free

O plano Pro custa US$ 20 por mês nos Estados Unidos, com cobrança em moeda local onde houver suporte

A instalação. Em macOS, Linux e WSL, o script oficial resolve:

curl -fsSL https://claude.ai/install.sh | bash

Se o seu ambiente exige npm, tem o caminho alternativo:

npm install -g @anthropic-ai/claude-code

Tome cuidado com um detalhe aqui: a documentação orienta a NÃO usar sudo npm install -g

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

O entendimento dos limites. O uso por sessão reinicia a cada 5 horas, e existe também um limite semanal, com reset em horário fixo atribuído à sua conta

Isso importa mais do que parece num teste: se você empilhar as três tarefas numa tarde só, pode esbarrar no limite no meio da comparação e achar que a ferramenta "travou"

E o item mais importante da lista não é técnico

As três tarefas escolhidas e o seu resultado de referência para cada uma. Sem esse resultado de referência, você não tem com o que comparar, e aí volta tudo pro achismo que você estava tentando evitar

Roteiro de avaliação: 7 passos para testar o Claude na sua própria tarefa

1. Escolha três tarefas que você já sabe fazer

Escopo pequeno e definido, sem mexer no fluxo inteiro do seu trabalho

A lógica é a de qualquer teste honesto de ferramenta: você pega uma tarefa ou um fluxo, registra o estado atual, aplica a mudança por um período curto e mede uma coisa concreta no fim

Três tarefas dá variedade suficiente pra você não decidir em cima de uma sorte ou de um azar isolado

Se você está em dúvida sobre quais tarefas entregar pro assistente, dá uma olhada em quais tarefas vale a pena delegar antes de montar a sua lista

O erro comum deste passo: escolher a tarefa que você nunca fez, justamente a mais empolgante

Aí você não tem repertório pra julgar a saída, e qualquer coisa que compile parece genial

2. Registre o estado atual ANTES

Quanto tempo essa tarefa te toma hoje?

Qual foi o seu resultado da última vez que você fez?

O que conta como "aceitável" e o que te obrigaria a refazer?

Anota isso num arquivo qualquer, antes de abrir o terminal

O erro comum deste passo: só medir depois

Quando você mede só no fim, a sua memória já foi contaminada pelo resultado que acabou de ver, e o "nossa, eu levaria umas 2 horas nisso" vira um chute pra defender a impressão que você já formou

3. Defina os critérios por escrito, antes de ver qualquer saída

Qualidade, retrabalho, tempo e custo

E olha, esse último ponto é o que mais gente ignora: um modelo com desempenho melhor não é automaticamente a melhor escolha, porque custo e latência entram no critério

Uma avaliação séria considera eficiência, não só a beleza da resposta

Uma tabelinha antes do teste já resolve:

O erro comum deste passo: julgar por impressão depois do fato

Sem critério escrito, o que decide é o quanto a saída te surpreendeu, e surpresa não é métrica

4. Prepare a sessão

Abre o terminal na pasta do projeto e roda:

claude

Digitar / lista os comandos disponíveis, e /help também dá esse panorama

Pra cada tarefa nova, comece com contexto vazio usando /clear

E aqui vem uma pergunta que sempre aparece: "perdi a conversa anterior?"

Não! A conversa continua em disco e pode ser retomada depois pelo session ID, e o /resume existe justamente pra retomar uma conversa anterior

Antes de começar, use /model pra fixar o modelo do teste e deixar as três rodadas comparáveis

Se você quiser entender melhor por que a conversa longa atrapalha a leitura do resultado, vale ver quanto contexto o Claude Code aguenta antes de montar suas sessões

O erro comum deste passo: rodar as três tarefas na mesma conversa

A tarefa 3 herda tudo que você corrigiu na 1 e na 2, e a comparação vira uma bagunça que ninguém consegue ler depois

5. Comece cada uma das três tarefas em plan mode

O modo de planejamento faz o Claude propor as mudanças sem editar arquivo nenhum

Você entra nele com /plan ou pressionando Shift+Tab, que cicla entre os modos (o acceptEdits aprova edições automaticamente, o plan propõe sem editar)

O PORQUÊ disso vem antes do como: num teste, o que você quer avaliar primeiro é o raciocínio

Se o plano já sai torto, você economiza a rodada inteira e não precisa nem olhar o código

E se o plano sai certinho, aí sim você libera a edição sabendo o que esperar

E isso não é etapa única da tarefa 1, beleza? Vale igual pras três: contexto zerado com /clear, plan mode na largada, e só depois a edição liberada

Se você fizer plano só na primeira e soltar as outras duas direto na edição, as rodadas deixam de ser comparáveis entre si e o seu critério de retrabalho vira ruído

O erro comum deste passo: liberar edição automática logo de cara no teste

Os arquivos mudam, você perde a referência do que era seu, e no fim não sabe mais dizer se o resultado ficou bom ou se você foi arrastado até ele

6. Dê o mesmo briefing que você daria pra um humano

Esse é o passo que mais gente pula, e o que mais distorce o veredito

Você faz a tarefa com o projeto inteiro na cabeça: as convenções, o comando de build, aquela regra que ninguém escreveu mas todo mundo segue

O assistente entra sem nada disso

Pra corrigir esse desequilíbrio existe o CLAUDE.md, um markdown com comandos de build, convenções e regras fixas, que o Claude lê no começo de toda sessão

E tem comando pra criar:

/init

O /init lê a estrutura do projeto e escreve o CLAUDE.md com comandos de build, arquitetura e convenções

Escolhendo a opção pessoal, ele adiciona o CLAUDE.local.md ao .gitignore, o que é ótimo pra guardar as suas manias sem empurrar pro time

O erro comum deste passo: comparar a sua saída, feita com todo o contexto na cabeça, com a do assistente sem contexto nenhum

Isso não é teste, é armadilha

7. Acompanhe o consumo e feche o veredito

Durante e depois das rodadas, olha o gasto

Em Settings > Usage você vê a sessão atual (consumo e tempo restante) e quando o limite semanal reseta, nos planos Pro, Max, Team e Enterprise por assento

Se o seu uso é via chave de API, o /cost mostra o spend corrente da sessão

Em sessão longa, /compact ajuda a segurar o contexto, e o /memory deixa você abrir a pasta de auto memory pra ler, editar ou apagar as notas que o Claude grava entre sessões (é markdown puro, nada de mágica)

Se bater o limite no meio do teste, a mensagem é bem explícita, do tipo "You’ve hit your session limit · resets 3:45pm" ou "You’ve hit your weekly limit · resets Mon 12:00am"

O erro comum deste passo: atropelar a revisão humana

Mesmo quando a IA economiza tempo de verdade em tarefa administrativa, a revisão continua necessária, senão interpretação errada passa direto pro uso profissional

Como isso funciona na prática: o teste lado a lado que eu fiz

No vídeo abaixo eu rodo exatamente essa lógica de comparação, só que entre duas ferramentas: Antigravity e Claude Code

Antes de qualquer coisa eu fixei os critérios: projeto zerado nos dois lados, o modelo mais avançado disponível em cada ferramenta e o MESMO prompt enviado pras duas

Escrevi um prompt único, longo e específico (um app estilo Trello chamado FlowBoard) já definindo tecnologias, telas, funcionalidades do quadro e do modal, regras de estado, diretrizes de design e dados mocados

O escopo estava fechado no papel: quadro kanban com 4 colunas (a fazer, em progresso, revisão, concluído) e dados iniciais de 3 quadros, 5 cards por coluna e 4 membros do time

Deixei as duas em modo de planejamento pra largada ficar justa e, depois da etapa de plano, troquei o Claude Code pra edição automática justamente pra igualar o comportamento das duas na hora de codar

Os prompts das etapas seguintes eu preparei antes de gravar, e combinei comigo mesmo que, se aparecesse bug, eu criaria um prompt novo só pra corrigir, em vez de improvisar no meio do teste

Uma coisa que me chamou atenção logo no começo: o Claude Code fez perguntas antes de programar (qual pacote usar pro kanban, dark mode) e rodou pesquisa web sobre boas práticas, enquanto a outra decidiu sozinha e já saiu criando arquivo

Sobre os tempos, e é aqui que mora a lição pro seu teste

Na primeira tarefa eu gastei cerca de 5 minutos ainda na etapa inicial de planejamento, e assumi na hora que essa rodada é ruim pra medir tempo: o planejamento distorce a comparação

A partir da segunda tarefa os tempos ficam comparáveis: pedi um sistema de comentários dentro do modal do card (com edição, exclusão, contador e ordem por mais recentes), disparei o pedido quase no mesmo instante nos dois lados e, com as duas já codando, foram cerca de 3 minutos de desenvolvimento até o momento em que eu comentei, com diferença de conclusão de alguns segundos entre elas

Alguns segundos, olha só

Se eu decidisse no cronômetro, eu não teria decidido nada

O que decidiu foi abrir os dois resultados no navegador e conferir item por item contra o que eu tinha pedido: alternância dark/light, arrastar cards, adicionar tarefa, os três quadros, lista de membros, campo de busca

Um dos resultados veio com o dark mode quebrado e o outro funcionando, e isso sim foi ponto decisivo da rodada

Os dois tiveram desvio de escopo (um permitia adicionar coluna nova, o outro não), e tudo aquilo era corrigível com prompt

Usei a extensão do Claude Code em vez do terminal só pra deixar as duas telas visualmente parecidas na gravação, pelo terminal dá na mesma

Depois que começou a programar de fato, o Claude Code entregou mais rápido e ficou mais alinhado ao que o prompt pedia, então o resultado final me agradou mais

A outra largou na frente e não ficou muito atrás, é justo dizer

A lição que interessa pro SEU teste é essa: prompt idêntico e escopo fechado é o que torna a comparação legível, e diferença de segundos no relógio não decide nada sozinha

Quem decide é a qualidade da saída e o retrabalho que sobra pra você

No vídeo você vê o teste rodando lado a lado, com o mesmo prompt indo pras duas ferramentas ao mesmo tempo

Três tipos de tarefa que revelam mais no teste (e uma que engana)

1. A tarefa repetitiva que você já domina

Aquela que você faz no automático e cujo resultado bom você reconhece de olho, sem precisar abrir checklist

Essa é ouro porque o seu julgamento é rápido e confiável: em 30 segundos você sabe se ficou no padrão ou se ficou "quase"

Liga direto no critério de qualidade que você registrou lá no passo 3

2. A tarefa de escopo fechado e verificável

Tem critério objetivo de pronto: passa no teste, a tela faz o que foi pedido, o item do briefing está lá ou não está

Foi o que eu fiz no vídeo com o kanban de 4 colunas e os dados mocados: dá pra conferir item por item, sem discussão de gosto

Essa categoria alimenta o critério de retrabalho, porque cada item faltando é uma rodada de correção a mais

3. A tarefa em área do projeto onde o contexto pesa

Código legado, aquele módulo com regra estranha, a parte que só você entende

Essa aqui testa uma coisa específica: se as instruções persistentes do CLAUDE.md realmente mudam a saída

Rode uma vez sem as regras escritas e outra com elas, e compare

Se a diferença for grande, você acabou de descobrir que metade do trabalho de adoção é escrever o contexto direito, não trocar de ferramenta

E a que engana: a tarefa impressionante que você nunca fez

Sabe aquela ideia que você sempre quis ver de pé e nunca teve tempo?

É a pior tarefa possível pra decidir adoção

Ali você não mede qualidade, mede a sua própria surpresa

Como você não tem resultado de referência, qualquer coisa que rode parece absurda de boa, e você adota (ou rejeita) por emoção

Deixa essa pra depois do teste, como diversão, não como critério 😀

Veredito por critério, não por impressão: o próximo passo

No fim, a decisão sai da comparação registrada

Não do hype, não da thread, não do vídeo de ninguém (nem do meu, e eu deixei os critérios do teste na mesa justamente pra você poder discordar do resultado)

E qualidade melhor não basta sozinha: se custo e latência não fecham com o seu ritmo de trabalho, a resposta bonita não sobrevive à segunda semana

Vale lembrar também que a etapa controlada é só metade do serviço

A avaliação offline, comparando de forma controlada com o mesmo conjunto de tarefas, e a avaliação online, medindo o comportamento real depois de implantado, se complementam

Uma compara, a outra mede impacto

Então o próximo passo é pequeno e é pra hoje: escolhe a primeira das três tarefas, anota o seu tempo e o seu resultado ANTES de abrir o terminal, e roda só ela nesta semana

Uma tarefa, um critério escrito, um veredito seu

Depois disso a segunda e a terceira são fáceis…

até o próximo post! 🙂