Como trabalhar com IA e crescer de forma cumulativa, como juros compostos

• Guia prático que organiza de forma sistemática cinco princípios para colaborar com IA: fornecer contexto, configurar preferências, automatizar validação, ampliar delegação e criar loops de feedback
• Todos os resultados do trabalho (código, documentos, análises, decisões) se acumulam como contexto para a sessão seguinte, e as correções passam a refletir nas configurações, reduzindo erros futuros em uma estrutura de crescimento composto
• Apresenta métodos concretos para gerenciar o comportamento e o fluxo de trabalho do modelo como se fosse código, usando CLAUDE.md, arquivos de skill, guias etc.
• Inclui estratégias de delegação para ampliar a capacidade de execução com sessões paralelas, validação cruzada entre modelos e controle remoto
• Esses princípios formam um framework geral aplicável não só à IA, mas também à colaboração entre equipes humanas

---

Construindo contexto como infraestrutura

• Se todo o código ficar em ~/src e o trabalho de conhecimento em ~/vault (projects/, notes/, kb/ etc.), o modelo consegue buscar contexto com grep ou glob com mais facilidade
• É possível conectar o contexto da organização (Slack, Drive, Mail etc.) ao modelo via MCP (Model Context Protocol)
  • Manter um INDEX.md por projeto e registrar em cada item a URL, o responsável e uma descrição do conteúdo como comentários
  • Uma simples lista de URLs obriga o modelo a abrir todos os links, então adicionar comentários ajuda a evitar desperdício de contexto
• Como o modelo começa cada nova sessão em branco, é preciso escrever um CLAUDE.md por projeto como se fosse um documento de onboarding para novos membros
  • Incluir glossário de siglas, codinomes do projeto, distinção entre homônimos etc.
  • Definir a ordem de leitura como INDEX.md → TODOS.md → notas do tema específico
• Operar com duas camadas de memória separadas
  • ~/vault: armazena informações factuais (facts), como status do projeto, entregáveis e conhecimento de domínio
  • ~/.claude (CLAUDE.md, skills/, guides/): armazena configuração (configuration), como preferências, workflow e estilo pessoal

Codificando preferências como configuração

• Uso de ~/.claude/CLAUDE.md

  • Funciona como um contrato de comportamento que o Claude lê no início de toda sessão
  • Inclui regras de comportamento como falar de forma direta, contestar quando não concordar, ser honesto quando houver incerteza, investigar a causa raiz ao falhar antes de tentar de novo e não reformatar nada fora do escopo do trabalho
  • Também é possível configurar uma seção de teaching para explicar em 1 ou 2 frases termos centrais de um novo sistema ou domínio

• Separação de escopo por diretório

  • Global (~/.claude/CLAUDE.md): configurações válidas em qualquer lugar, como comportamento, objetivos de longo prazo e preferências de aprendizado
  • Raiz do repositório: regras específicas do repositório, como linting, naming e convenções de PR
  • Diretório do projeto: contexto específico do projeto, como estrutura de diretórios e conhecimento de domínio
  • O Claude Code, quando iniciado em um subdiretório, sobe pela árvore carregando cada CLAUDE.md

• Estratégia de separação quando o CLAUDE.md fica longo

  • Um CLAUDE.md extenso vira um imposto de contexto, já que precisa ser carregado inteiro a cada sessão
  • Em vez de @import, o CLAUDE.md pode indicar apenas o caminho dos arquivos de guia no formato “ler quando relevante”, implementando lazy loading
  • Ex.: ao escrever documentos, ~/.claude/guides/writing.md; em tarefas de avaliação, ~/.claude/guides/evals.md

• Tarefas repetidas pelo menos uma vez por semana devem virar skills

  • Skills são arquivos de workflow em Markdown com nome, gatilho e procedimento
  • /polish: revisar o diff do artefato, rodar eval se houver métricas, conferir no Chrome se houver renderização no navegador, caso contrário executar o código e verificar saída/erros → iterar e redigir um rascunho de PR
  • /write: entrevista de outline → criar subagente de pesquisa → redigir rascunho → receber feedback de um crítico adversarial → iterar
  • /daily: ler calendário, Slack, PRs e log do dia anterior para escrever as prioridades de hoje
  • SKILL.md deve focar em workflow e roteamento; conhecimento como templates e scripts fica em arquivos separados para ser carregado só quando necessário

• Como fazer bootstrap de skills

  • Execute a tarefa uma vez de forma interativa e depois peça ao modelo para transformá-la em skill
  • Rode a skill em tarefas iguais ou parecidas, e faça as correções da saída na mesma sessão
  • Peça ao modelo para atualizar a skill com base nas correções e no feedback
  • Também é possível fornecer exemplos da saída desejada para que ele extraia padrões, como estrutura de código, estrutura de documento e tom

• Melhorando skills com transcrições

  • É normal que a primeira versão fique overfit à sessão original
  • Em vez de editar o SKILL.md manualmente, faça as correções durante a sessão para que pares de before-and-after se acumulem na transcrição
  • Quando a saída estiver satisfatória, peça ao modelo para incorporar o feedback na skill → após algumas rodadas, a skill converge

• Nem todo trabalho precisa desse contexto

  • Para brainstorming, exploração e rascunhos, use o modo simples (CLAUDE_CODE_SIMPLE=1 claude)
  • O CLAUDE.md continua sendo carregado, mas o harness de agentes (hooks, skills, loop de ferramentas) fica desativado → isso permite pensar de forma mais próxima do modelo em si

Validação para autonomia

• Fazer a validação acontecer mais cedo

  • Estruture a validação em uma escada: embaixo ficam as verificações baratas e determinísticas; em cima, as mais caras e que exigem julgamento
  • Na camada mais baixa: um hook pós-edição que roda ruff format e ruff check --fix nos arquivos alterados pelo modelo → determinístico e sem custo de tokens
  • Nas camadas superiores: testes, evals e revisão por LLM, entre outros

• Estruture o sistema para que o modelo valide o próprio trabalho

  • Se o sistema produz métricas, o modelo pode rodar os evals diretamente para otimizar
  • Se a saída é renderização no navegador, inspecione com Claude in Chrome
  • Ao construir uma imagem Docker, leia os erros, ajuste o Dockerfile e faça o build novamente
  • Ao montar um dashboard, verifique no Chrome a renderização de tooltips, sobreposição de rótulos e se os números batem com a narrativa

• Em tarefas longas, um modelo vigia o outro

  • Sessões longas acumulam erros e podem gerar drift
  • Solução: iniciar uma segunda sessão com contexto limpo para comparar a especificação original com os turnos mais recentes da primeira sessão
  • Configuração com dois painéis no tmux: um para o desenvolvimento principal e outro para o pair programmer
  • Adicione instruções iniciais e prompts posteriores em um arquivo compartilhado, e o pair programmer faz verificações periódicas
  • Execution drift: se o modelo está executando a tarefa corretamente — ignorando erros, reportando métricas erradas, saindo da especificação etc. → checagem tática frequente
  • Direction drift: se o modelo está fazendo a tarefa certa — entendendo mal a intenção original e construindo a coisa errada → problema estratégico a ser verificado ocasionalmente

Escalar por meio de delegação

• Delegar unidades de trabalho cada vez maiores

  • O estilo de pair programming com tarefas curtas e feedback rápido é adequado para iteração veloz, análise exploratória e prototipagem
  • Para modelos mais potentes, é melhor explicar de antemão a intenção, as restrições e os critérios de sucesso, e delegar para que executem de ponta a ponta
  • O que não pode ser validado não pode ser delegado; por isso, é necessário definir antes os critérios de sucesso e as métricas
  • Exemplo: “criar contêineres isolados por eval suite e rodar smoke tests → executar tudo → registrar métricas e transcrições → validar acurácia com subagentes → repetir n vezes para calcular intervalos de confiança → gerar relatório e enviar o resultado no Slack”

• Operar sessões paralelas e identificar gargalos

  • Ao delegar tarefas maiores, é possível rodar 3 a 6 sessões em paralelo
  • O gargalo deixa de ser a execução do trabalho e passa a ser escrever especificações claras e revisar rapidamente as saídas — os passos intermediários tendem a desaparecer
  • Quando sessões paralelas compartilham o mesmo repositório, use git worktrees para que cada uma tenha seu próprio checkout independente

• Garantir observabilidade das sessões

  • stop hook: tocar um som ao final da sessão (no macOS, reproduzir Glass.aiff com afplay)
  • Títulos de janela do tmux: usar emoji de status (⏳ em andamento, 🟢 concluído) e um rótulo curto gerado pelo Haiku para identificar cada painel
  • Barra de status do Claude Code: mostra uso de contexto e modo atual

• Possibilidade de check-in mesmo longe do computador

  • Com o recurso /remote-control do Claude Code, é possível verificar o estado de execução na aba de código do app Claude enquanto estiver em deslocamento, e fornecer contexto adicional ou novas instruções a sessões travadas
  • Isso evita que uma sessão fique ociosa por horas, mas deve ser usado só em casos urgentes

Fechando o loop de feedback

• Trabalhar em público para manter o contexto rico

  • Trabalhar em documentos, repositórios e canais compartilhados permite que todos os membros da equipe, incluindo o modelo, usem o contexto
  • Um teste simples: “um novo membro da equipe conseguiria reproduzir o trabalho da última semana usando apenas o contexto compartilhado?” — se não, então parte importante do contexto está só na sua cabeça
  • Oriente no CLAUDE.md que, ao concluir trabalho relevante, seja publicada automaticamente no canal de worklog uma breve atualização com links para os artefatos

• Minerar transcrições para atualizar configurações

  • Fazer o modelo ler transcrições de sessões passadas ajuda a encontrar lacunas
  • Ao analisar cerca de 2.500 turnos anteriores de usuário, uma parte significativa continha expressões como “can you also…”, “did you check…”, “still wrong”
  • Isso sugere tarefas que o modelo deveria ter feito por conta própria ou etapas de validação ausentes/com defeito
  • Faça as correções dentro da sessão para usar a transcrição como dados de entrada para a próxima atualização do CLAUDE.md ou das skills

• Refatoração e limpeza periódicas

  • À medida que a configuração cresce, diferentes regras podem se sobrepor ou entrar em conflito
  • Se o modelo ignora uma regra, pode ser por contradição com outra; por isso, vale refatorar para que cada regra ou preferência exista em um único lugar (instruções importantes ainda podem ser repetidas no CLAUDE.md principal)
  • Consolidar settings.json espalhados por diretórios em ~/.claude para organizar tudo em um ponto central

Conclusão

• As configurações específicas podem mudar conforme os modelos evoluem, mas os princípios de fornecer bom contexto, codificar preferências, validar com baixo custo, delegar mais e fechar o loop de feedback continuam válidos
• No fim, esse processo é treinar um colaborador, um feedback por vez, e ele também se aplica da mesma forma à colaboração com equipes humanas
• Esses princípios valem não só para ferramentas pessoais, mas também para projetar agent harnesses, definir normas de equipe e construir infraestrutura organizacional

[xguru]

A trajetória dessa pessoa é interessante: de alguém formado em psicologia para estudar pelo curso de ciência de dados da Coursera
entrou no começo da Lazada, que era a Amazon do Sudeste Asiático, e foi promovido até VP.
A Lazada foi adquirida pela Alibaba.
Depois disso, foi para a Amazon como cientista-chefe de recomendação/LLM.
Atualmente, faz parte da equipe técnica da Anthropic