Mentalidade de Experimentação

Problema: Você usa os mesmos padrões de prompting em cada sessão. Não faz ideia se são os melhores, ou se estão a custar-te horas em silêncio.

Ganho Rápido: Faz este experimento agora mesmo e observa como o estilo do prompt muda o output do Claude:

Prompt A: "Fix the bug in auth.ts"
Prompt B: "Let's work through auth.ts together. What might be wrong?"
Prompt C: "Review auth.ts like a senior engineer. List every issue you find."

Compara os três resultados. A versão colaborativa normalmente produz análise mais profunda e encontra casos extremos que a versão direta não vê. É o ciclo de experimentação em ação.

Experimento 1: Impacto do Estilo de Prompt

A mesma tarefa produz outputs diferentes consoante a forma como a enquadras. Experimenta estes três estilos numa tarefa de debugging:

Style 1 (Command): "Fix the bug in login.ts"
Style 2 (Teaching): "Walk me through login.ts and help me find what's wrong"
Style 3 (Review): "Act as a code reviewer. Analyze login.ts for bugs, security issues, and edge cases."

O que vais descobrir: O Estilo 3 (modo de revisão) tende a encontrar mais problemas porque enquadra o trabalho como análise em vez de execução de correção rápida.

Aqui está o padrão no mundo real. Corre os três estilos contra um handler de login com um bug óbvio de null-check mais uma falha de temporização subtil no rate limiter. O Estilo 1 (comando) corrige o null check e para. O Estilo 2 (ensino) corrige o null check e explica porque é que importa, mas ainda assim perde a questão de temporização. O Estilo 3 (revisão) encontra o null check, a vulnerabilidade de temporização, e sinaliza mensagens de erro que expõem estado interno ao cliente.

O padrão mantém-se em vários tipos de tarefas, mas o tamanho da diferença varia. Para código sensível à segurança, o modo de revisão encontra notavelmente mais. Para bugs de UI simples, a diferença diminui e o estilo de comando é suficiente. Para refatorações, o modo de ensino muitas vezes produz os resultados mais limpos porque força o Claude a explicar cada mudança enquanto a faz.

Regista qual estilo ganha para cada tipo de tarefa nos teus projetos. Após algumas sessões, terás a tua própria tabela de referência: trabalho de segurança usa modo de revisão, correções simples usam modo de comando, refatorações usam modo de ensino.

Experimento 2: Impacto do Contexto de Ficheiros

A qualidade do código do Claude muda com base nos ficheiros que lhe forneces como contexto. Testa tu mesmo:

Experiment A: "Refactor errors.ts to use a cleaner pattern"
Experiment B: "Refactor errors.ts. Reference utils/errors.ts and AuthController.ts for the existing pattern."

A segunda versão produz refatorações que se encaixam nos teus padrões existentes. Sem contexto, o Claude inventa padrões que podem entrar em conflito com o teu codebase.

Experimenta isto num projeto real com uma hierarquia de erros personalizada. No experimento A, o Claude escreve um try/catch genérico com chamadas new Error(). Código limpo, mas ignora as classes AppError, ValidationError e NotFoundError já no repo. O ficheiro refatorado nem vai compilar junto com o resto do código sem erros de tipo.

No experimento B, o Claude encontra as classes de erro em utils/errors.ts, lê como o AuthController.ts já as usa, e produz uma refatoração que corresponde ao padrão existente. A mesma tarefa, o mesmo modelo, a mesma sessão. A única diferença foram três referências extra de ficheiros.

A lição real vai mais fundo do que "dá ao Claude mais ficheiros." Existe um ponto ótimo. Incluir 2-4 ficheiros estreitamente relacionados melhora a qualidade do output de forma consistente. Depois de 6-7 ficheiros, os retornos diminuem porque o Claude espalha atenção por demasiados padrões. Começa com o ficheiro de definição de tipos e um ficheiro que já implementa o padrão que queres.

Experimento 3: Modo de Planeamento vs Execução Direta

O modo de planeamento (Shift+Tab duas vezes) muda a forma como o Claude aborda os problemas. Corre esta comparação:

Direct: "Add user permissions to the admin dashboard"
Planning: [Shift+Tab twice] "Add user permissions to the admin dashboard"

No modo de planeamento, o Claude lê o teu codebase e apresenta opções antes de tocar num único ficheiro. Você revisa a abordagem, deteta problemas cedo, e escolhe o caminho a seguir.

A diferença surge rapidamente em funcionalidades multi-ficheiro. Corre este experimento num sistema de permissões que abrange o middleware de autenticação, as rotas do dashboard, e os componentes de frontend. A execução direta mergulha diretamente no middleware e começa a programar. Faz suposições sobre a estrutura de roles que entram em conflito com o modelo de utilizador existente, e metade das alterações têm que ser revertidas.

O modo de planeamento, ao contrário, apresenta três opções de arquitetura antes de escrever qualquer código. Uma opção usa o enum de roles existente. Outra sugere uma tabela de permissões para granularidade mais fina. A terceira propõe um híbrido. Escolhe a opção um, e a implementação alinha-se com o codebase desde o primeiro ficheiro tocado.

Onde fica o limiar: Funcionalidades complexas que tocam 3+ ficheiros quase sempre beneficiam do modo de planeamento. Correções simples (ficheiro único, alteração óbvia) não. O ponto de equilíbrio fica à volta de 2 ficheiros. Com 2 ficheiros, o modo de planeamento adiciona cerca de 30 segundos de overhead mas poupa backtracking. Abaixo disso, é cerimónia pela cerimónia.

Experimento 4: Configurações do CLAUDE.md

O teu ficheiro CLAUDE.md molda o comportamento do Claude diretamente. Testa diferentes configurações:

Configuration A: (empty CLAUDE.md)
Configuration B:
  - Always ask before making changes outside the current feature directory
  - Use conventional commits
  - Prefer small, focused changes over large refactors

Corre a mesma tarefa com cada uma e compara:

Quantas perguntas de esclarecimento faz o Claude?
Segue os padrões do teu projeto?
Os commits estão corretamente delimitados?

Com a Configuração A, o Claude trata cada diretório como território aberto. Pede para adicionar uma funcionalidade de dashboard e ele modifica o schema da base de dados, atualiza as rotas da API, e muda a configuração de deployment de uma vez. Sem perguntas. Um commit gigante.

Com a Configuração B, o mesmo pedido desencadeia uma pergunta de esclarecimento: "The dashboard feature needs a new API endpoint. Should I create it in src/api/ or modify the existing routes.ts?" O trabalho resultante chega como três commits focados, cada um tocando apenas os ficheiros dessa camada.

O teu CLAUDE.md não é documentação. É um sistema operativo. As instruções que colocas lá moldam cada decisão que o Claude toma. Corre diferentes instruções contra a mesma tarefa e observa como o output muda. Pequenas alterações no CLAUDE.md produzem mudanças surpreendentemente grandes no comportamento. Consulta o guia do diretório de regras para um controlo mais granular do comportamento do Claude por tipo de ficheiro.

Experimento 5: Pressão da Janela de Contexto

Este é silenciosamente importante. A qualidade do output do Claude cai sob pressão de contexto de formas que não se anunciam. Corre este teste:

Começa uma sessão nova e pede ao Claude para construir uma funcionalidade moderadamente complexa (algo que toque 3-4 ficheiros). Nota a qualidade. Depois, numa sessão existente que está a correr há algum tempo com contexto acumulado, pede a mesma funcionalidade exata.

A sessão nova normalmente produz código mais limpo com melhor tratamento de erros. A sessão carregada corta caminho: nomes de variáveis mais curtos, menos verificações de casos extremos, às vezes saltando testes. Não é que o Claude se esqueça de como escrever bom código. É que o modelo espalha atenção por todo o contexto acumulado, deixando menos espaço para a tarefa atual.

A conclusão prática: usa /compact de forma agressiva antes de tarefas complexas. Corre /compact antes de qualquer funcionalidade que toque mais de dois ficheiros, e a diferença de qualidade é fácil de ver. Alguns developers preferem /clear para um recomeço totalmente limpo, mas perdes o historial de conversa. O comando /compact faz o meio-termo ao resumir o contexto anterior sem o descartar.

Cria o Teu Próprio Registo de Experimentos

Cria um ficheiro de rastreamento simples para capturar o que aprendes:

# Claude Code Experiments

## Prompt Style
- Review mode: best for security and auth code
- Command mode: best for quick UI fixes
- Teaching mode: best for refactors

## Planning Mode
- Use for 3+ files
- Skip for single-file changes

Este registo torna-se o teu guia de otimização pessoal. Depois de um mês, terás um conjunto de dados do que realmente funciona no teu codebase com os teus padrões. Isso vale mais do que qualquer conselho genérico, porque a abordagem certa muda por projeto, por linguagem, e pelo tipo de trabalho que estás a fazer.

Ser específico é o ponto. "O modo de revisão é melhor" não é útil. "O modo de revisão encontra 2-3x mais problemas de segurança em código de autenticação" é algo em que ages em cada sessão.

Próximos Experimentos a Tentar

Pronto para testar mais? Experimenta estes:

Gestão de contexto: O que acontece com 60% vs 90% de utilização de contexto?
Auto-planeamento: O planeamento automatizado bate a comutação manual de modo?
Seleção de modelo: Como é que diferentes modelos lidam com a mesma tarefa complexa?
Pensamento profundo: O pensamento estendido produz melhores decisões de arquitetura?

Para de adivinhar. Corre o experimento. Regista o resultado. Itera.

Cada sessão é uma oportunidade para encontrar algo que te torna mais rápido. Os developers que experimentam sistematicamente ultrapassam os que ficam com o seu primeiro instinto. Cada solução alternativa é um padrão à espera de ser nomeado. Cada padrão nomeado é uma habilidade que o Claude pode reutilizar.

É isto que a "mentalidade de evolução de sistema" significa na prática. É uma das 5 melhores práticas do Claude Code que separa os top developers de todos os outros.