Claude Code Mastery10 / 12

Workflows de time

Como times de engenharia estão de fato integrando o Claude Code hoje. A pasta .claude/ compartilhada, os rituais de review e os antipadrões que vejo se repetindo no campo.

Publicado em 14 de mai. de 20265 min de leituraHaythem Rehouma · Claude Mastery

Um dev solo com Claude Code é uma história de produtividade. Um time com Claude Code é uma pergunta de operating model.

A maior parte das vitórias (e a maior parte dos fracassos) que vejo no nível de time não tem nada a ver com o modelo. Tem a ver com vocabulário compartilhado, restrições compartilhadas e rituais de review compartilhados.

Aqui vai o que funciona, o que não funciona e os padrões que eu roubaria.

A pasta `.claude/` compartilhada é o destravamento

Faça commit de .claude/ no repo. Tudo.

CLAUDE.md — contexto do projeto, convenções, lista "nunca modificar".
.claude/settings.json — allowlist / denylist de ferramentas.
.claude/agents/*.md — sua tropa de sub-agents.
.claude/commands/*.md — seus slash commands.

Todo mundo no time recebe o mesmo operating model no git pull. O onboarding sai de "deixa eu te mostrar meus prompts" para "lê .claude/, você vai pegar".

Propriedade dos agentes — escolha um mantenedor

Cada sub-agent precisa ter um owner no time. Não porque agents sejam complexos (é um arquivo .md), mas porque agents derivam.

Um code-reviewer escrito para um time de 5 engenheiros no mês 1 vai estar errado no mês 6. Alguém precisa:

Ler o feedback de review que o agent traz à tona.
Notar quando ele perde uma classe de bug.
Atualizar o system prompt.

Trate sub-agents como infraestrutura. Owned, versionados, revisados em PRs.

Rituais de PR que mudam com o Claude Code

Três rituais que vi funcionar:

1. PRs escritas por IA declaram isso

Adicione um label ou uma seção no template do PR:

## Assistida por IA

- Implementer: sim / não
- Autor dos testes: humano / IA
- Code reviewer (pré-PR): n/a / agent `code-reviewer`

Isso não é burocracia. É sinal. Quando algo quebra, você quer saber que classe de autoria investigar.

2. Review em dois níveis

Para PRs > 200 linhas ou que tocam caminhos críticos:

Nível 1: agent code-reviewer (pré-push).
Nível 2: reviewer humano (pós-push).

Para todo o resto, a passada do agent + o review do diff pelo autor já basta. Pare de fingir que você lê cada linha de cada PR de menos de 50 linhas.

3. Review de código "diff-first"

Os reviewers param de abrir arquivos. Leem o diff no gh pr diff e confiam na suíte de testes. Soa imprudente até você perceber que esse é o comportamento certo há anos — os humanos só eram ruins nisso.

A review-as-agent do Claude Code torna o modelo diff-first honesto: um agent separado já checou o óbvio antes de um humano tocar.

O que NÃO funciona

Uma lista curta de padrões que parecem vitórias mas não são:

Uma licença Claude Code, compartilhada pelo time. Mata a personalização, mata as trilhas de auditoria, cria um pesadelo de permissões. Licenças por usuário, ponto.
"Demos de sprint IA" onde os managers escolhem a dedo as melhores PRs. Viés do sobrevivente. Acompanhe métricas agregadas, não highlight reels.
Banir Claude Code de serviços "críticos". O oposto do movimento certo. Serviços críticos precisam dos sub-agents mais disciplinados e das allowlists mais apertadas, mas são os que mais se beneficiam do workflow.
Forçar todo mundo a usar os mesmos prompts. Incentive .claude/commands/ compartilhados; resista a impor estilo pessoal. As pessoas promptam diferente e tudo bem.

O que muda para gerentes de engenharia

Três coisas mudam de verdade:

1. A velocidade fica mais legível

Você consegue puxar estatísticas de ~/.claude/sessions/ (ou seu equivalente no log shipping). Tempo médio por feature, número médio de rodadas de agent até o verde, fração de PRs que passam no review de primeira.

Esses dados são bons. Use-os para diagnóstico ("o time está sofrendo com a feature X"), não para avaliações de desempenho ("você usou menos o agent").

2. O onboarding se molda à codebase

Um recém-contratado vira produtivo mais rápido — não porque é mais esperto, mas porque .claude/CLAUDE.md e os sub-agents pré-carregam todo o conhecimento tribal da codebase.

Eu já onboardei engenheiros em 2 dias que levariam 2 semanas pré-Claude-Code. A codebase agora é auto-documentada sob instrução.

3. O tempo dos seniors se realoca

Engenheiros sêniores param de digitar o boilerplate. Revisam mais diffs, escrevem mais CLAUDE.md, projetam mais ADRs. O agent cuida da digitação; o senior cuida da arquitetura.

É uma mudança real. Alguns sêniores adoram. Outros sentem falta da digitação. Os dois são legítimos. Só reconheça que a mudança está acontecendo.

O erro de time mais comum

Deixar o Claude Code entrar na codebase sem um .claude/ compartilhado primeiro.

Cada engenheiro acaba com seus próprios settings, seu próprio CLAUDE.md, sua própria tropa. A saída do time fica inconsistente porque, bem, ela é.

Gaste dois dias escrevendo o .claude/ compartilhado. Passe pelo time. Faça commit. Aí libere o Claude Code.

Um plano de rollout de 30 dias que funciona

Semana 1: 2-3 engenheiros sêniores usam Claude Code em tickets opt-in. Escrevem a primeira versão do .claude/.
Semana 2: abra para o resto do time. Bana em migrações de prod e PRs de infra. Stand-up diário de 15 min "o que funcionou / o que não" dedicado ao workflow do agent.
Semana 3: sub-agents codificados. Rituais de review adotados. Métricas no lugar.
Semana 4: tire o ban de prod para engenheiros que entregaram 3+ PRs assistidas por IA. Mantenha o ban de infra por enquanto.

No mês 2, Claude Code é só "como a gente trabalha". Ninguém fala mais dele especificamente. Esse é o objetivo.

Próximo artigo: Padrões avançados — hooks, servidores MCP, ferramentas custom e system prompts. As coisas que você constrói depois que cresceu além dos defaults.