O que os times da Anthropic fazem diferente no Claude Code
A Anthropic publicou como os times internos dela usam o Claude Code de verdade — e os maiores ganhos vieram de advogados, marketing e cientistas de dados, não dos engenheiros seniores. Esses são os cinco hábitos que valem copiar, com os números reais de cada um.
- #claude-code
- #workflows
- #anthropic
- #productivity
A Anthropic publicou um relato de como os próprios times usam o Claude Code, e o detalhe que quase todo mundo deixa passar é quem teve os maiores ganhos. Não foram os engenheiros seniores. O time jurídico prototipou uma ferramenta interna de triagem telefônica sem nenhum dev disponível. O time de marketing montou um fluxo com agentes que transforma um CSV em centenas de variações de anúncio em minutos — além de um plugin do Figma que reduziu horas de copiar e colar pra cerca de meio segundo por lote. E cientistas de dados de RL que não escrevem TypeScript hoje entregam dashboards inteiros em React pra visualizar a performance dos modelos.
Enquanto isso, os hábitos dos times de engenharia cabem todos num único princípio. Se você for copiar uma coisa só de quem construiu a ferramenta, copia essa: nunca termine um prompt sem dizer ao Claude como provar que o trabalho está correto.
1. Dê a ele uma verificação que ele mesmo consiga rodar
O Claude para quando o resultado parece pronto — e sem um sinal de passou/falhou, o teste é você. O guia oficial de boas práticas é organizado em volta de fechar esse ciclo: entregue ao Claude um comando de teste, um build, um linter ou um screenshot pra comparar, e exija a evidência (a saída dos testes, o resultado do comando), não uma promessa de que funcionou. O time de segurança da Anthropic credita essa mudança — junto com a adoção de desenvolvimento guiado por testes com o Claude — a resolver cerca de 3x mais rápido incidentes que antes consumiam de 10 a 15 minutos de varredura manual de logs. Pra execuções sem supervisão, um hook de Stop consegue impedir a sessão de encerrar até a verificação passar (o Claude só ignora o bloqueio depois de 8 seguidos).
2. Só planeje quando o diff precisa de um parágrafo
O modo de planejamento faz o Claude explorar o código e escrever um plano de implementação antes de mexer em qualquer coisa, e o atalho Ctrl+G abre esse plano no seu editor pra você apertar na mão. Mas a documentação é explícita sobre quando pular essa etapa: se dá pra descrever a mudança numa frase — renomear algo, adicionar um log — pede direto. Planejar compensa quando a mudança atravessa vários arquivos ou quando você não tem certeza da abordagem.
3. Trate o CLAUDE.md como código, não como diário
O teste de poda da documentação é cruel e útil: pra cada linha, pergunte se eu remover isso, o Claude passa a errar? Se a resposta for não, corta. Um CLAUDE.md inchado sai pela culatra — as regras importantes se afogam no ruído e o Claude começa a ignorá-las. Revise quando algo der errado, pode com frequência e versione no git pra que o time inteiro se beneficie.
4. Duas correções falhas, depois /clear
O contexto é a restrição de verdade: a performance cai conforme a janela enche. A regra da Anthropic é concreta de um jeito raro — se você já corrigiu o Claude duas vezes no mesmo problema na mesma sessão, pare de corrigir. O contexto já está contaminado de tentativas fracassadas. Rode /clear e recomece com um prompt mais afiado, incorporando o que você aprendeu. Os subagents seguem a mesma lógica: a pesquisa roda num contexto separado e volta só com o resumo, deixando a conversa principal limpa pra implementação.
5. Aponte a ferramenta pra problemas fora da sua stack
Esse é o padrão subestimado. O time de infraestrutura de dados da Anthropic depurou uma falha de agendamento de pods no Kubernetes durante um incidente colando screenshots dos dashboards — o Claude guiou o time pelo console do Google Cloud e entregou os comandos exatos pra criar um IP pool, economizando uns 20 minutos no meio da crise. O time de inferência escreve testes em Rust sem saber Rust, só descrevendo o comportamento esperado. O teto deixou de ser a sua linguagem mais forte; virou a precisão com que você especifica e verifica.
Por que isso importa pra sua carreira
Pra um dev ou EM brasileiro de olho em times internacionais, esse relato funciona como descrição de vaga. As empresas que contratam globalmente cada vez mais assumem que você já trabalha assim — e quem monta o ciclo de verificação, o CLAUDE.md enxuto e o fluxo de revisão pro time inteiro está fazendo um trabalho de liderança visível e promovível, independente do cargo no crachá.
Hoje: pegue a próxima tarefa que você mandaria pro Claude Code como "implementa X" e reescreva com uma cláusula de verificação — os casos de teste, o comando pra rodar e "itere até passar e me mostre a saída". Depois compare essa sessão com as suas de costume.
Fontes
Continue lendo
Mais guias parecidos com este.
Os comandos do Claude Code que você pula são todos o mesmo
São mais de 60 comandos embutidos. Quase todo mundo usa quatro. Organize os que faltam pelo que eles realmente fazem e aparece um padrão — quase todos existem pra administrar um único recurso, e é justamente ele que estraga suas sessões longas.
Suas regras expiram na compactação. Veja exatamente quais.
Quando uma sessão longa compacta, parte das suas instruções volta do disco e parte simplesmente não volta. A separação está documentada e quase ninguém conhece — é por isso que o Claude "esquece suas regras" depois de três horas.
Dynamic workflows no Claude Code: 100 agentes, uma resposta
O Claude Code agora escreve o próprio plano de orquestração e roda centenas de subagentes em paralelo. O paralelismo não é a parte interessante — a etapa de refutação é. Como ligar, quando compensa e a habilidade de especificação que isso cobra de você.