Como ler: as quatro primeiras etapas (módulo 6.1) são preparação — nenhuma linha de código de produção é escrita nelas. As quatro seguintes (módulo 6.2, em ciano) são execução e verificação. Se a preparação for boa, a execução é rápida; se você pular a preparação, vai reconhecer todos os problemas descritos na trilha 4.
🧰 Antes de começar
O que você precisa
- • Um repositório seu, pequeno, com testes que rodam.
- • Um agente de código (Claude Code, Codex, Cursor — tanto faz).
- • Uma branch nova. Nada disto acontece na branch principal.
- • 2 a 3 horas sem interrupção — ou duas sessões de 90 minutos.
Como escolher a tarefa
- • Pequena: cabe em 3 a 5 arquivos.
- • Verificável: dá para provar com teste que ficou pronta.
- • Real: algo que estava mesmo na sua lista.
- • Reversível: nada de migração de banco ou mudança de contrato público.
Mapa da trilha
Conteúdo detalhado
🧱 Exercício: spec, harness e loop
Etapas 1 a 4 do projeto final: escolher o problema, escrever a especificação completa, configurar o harness com limites e desenhar o loop de execução — tudo antes da primeira linha de código.
A seleção de uma funcionalidade, bug ou módulo legado do seu próprio repositório para servir de caso do exercício.
Escolher errado é o jeito mais comum de o exercício falhar: tarefa grande demais impede fechar o ciclo e você não vê o método funcionando.
3 a 5 arquivos · verificável por teste · reversível · algo que já estava na sua lista.
A aplicação do módulo 1.2 no seu caso: problema, objetivo, escopo, fora do escopo, entradas, saídas, contratos, erros, restrições, critérios, testes e definição de pronto.
É aqui que o exercício se paga: você vai descobrir, ainda no papel, decisões que teria delegado sem perceber.
Critério verificável · escopo negativo explícito · toda suposição vira pergunta respondida antes de codar.
Definir ferramentas, contexto, permissões e limites: o AGENTS.md do módulo 2.1, a branch/worktree isolada e o comando de teste rápido.
Sem isso, você vai passar o exercício inteiro repetindo restrições no chat — e algumas vão escapar.
Permissão implícita é total · isolamento torna o erro barato · comando de teste documentado.
O ciclo de execução, teste e correção com objetivo verificável, limite de tentativas, condição de parada por falta de progresso e ponto de aprovação humana.
O loop escrito antes é o que impede a sessão de virar "tenta de novo" até o cansaço.
Objetivo = comando · máximo de tentativas · mesma falha 2x → parar · testes intocáveis.
Um arquivo simples onde você anota tempo gasto, tentativas, custo, o que o agente supôs e onde você precisou intervir.
Sem registro, o exercício vira impressão. Com registro, ele vira o argumento que você leva para o time.
Medir a própria prática · intervenção humana é dado · comparação antes/depois.
A checagem final antes de liberar o agente: spec com critérios verificáveis, PERGUNTAS respondidas, AGENTS.md no lugar, branch isolada, comando de teste funcionando e limites definidos.
Cada item que faltar aqui vira uma correção cara no módulo 6.2 — ou um resultado que passa nos testes e está errado.
Preparação boa = execução rápida · nada de código ainda · pronto significa pronto.
🏁 Exercício: execução, gates, revisão e entrega
Etapas 5 a 8: executar a menor mudança possível, aplicar build, lint, testes e segurança, rodar a revisão independente e preparar o pull request com evidências.
Rodar o loop definido na etapa 4, exigindo o plano antes da implementação e a menor mudança que satisfaça os critérios.
Aprovar o plano custa dois minutos e evita refazer uma hora de implementação na direção errada.
Plano aprovado antes · menor mudança · saída real dos testes colada, nunca resumida.
Rodar a bateria completa do módulo 3.3 sobre a mudança e registrar o resultado de cada portão.
É onde você descobre quais gates o seu repositório ainda não tem — e essa lista é um produto valioso do exercício.
Gate ausente também é resultado · nenhum segredo, nenhuma dependência nova sem aprovação · evidência anexada.
Abrir uma sessão limpa e revisar a mudança com o prompt do módulo 3.2, recebendo apenas especificação e diff.
É a etapa que mais surpreende quem faz o exercício: o revisor encontra coisas que o implementador defendia com confiança.
Independência de contexto · achados com severidade · você decide o que vira mudança.
Montar o pull request com spec, diff, saída real dos testes, resultado dos gates, achados da revisão e o que ficou fora do escopo.
Um PR com evidência é revisado em minutos; um PR sem evidência é revisado no boca a boca — ou aprovado sem leitura.
Evidência anexada > narrativa · o que ficou fora também se declara · aprovação humana registrada.
A revisão do próprio processo: onde você precisou intervir, quais suposições o agente fez, quais gates faltaram e quanto custou.
Cada intervenção sua é candidata a virar rule, gate ou item do AGENTS.md — é assim que o sistema melhora sozinho na próxima tarefa.
Intervenção → regra · gate ausente → backlog · aprendizado registrado, não lembrado.
A reunião dos artefatos produzidos: modelo de spec, AGENTS.md, modelo de loop, rules, skills, checklist de gates, fluxo de review, playbooks e checklist de governança.
Esse kit é o que transforma um workshop de dois dias em mudança permanente de prática — porque ele volta para o repositório com você.
Artefato versionado > anotação · comece pelo que você já usou no exercício · compartilhe com o time.