🔁 Repetir não é melhorar: o que falta num loop fraco
🧠 Imagine assim: ir pra academia todo santo dia sem anotar carga, repetições ou medida nenhuma não é treino — é só presença. Sem um critério salvo de uma vez pra outra, você não sabe se progrediu ou só girou em círculo.
Um loop de melhoria de verdade não é "olhar de novo de tempos em tempos" — é um ciclo com foco (uma área pequena por vez), critério salvo de um ciclo pro outro, teste que confirma se a mudança funcionou e um registro do que foi aprendido. Tire qualquer uma dessas quatro peças e o que sobra é repetição, não melhoria.
✗ Loop fraco (evite)
"Revise meu app todo dia." Parece disciplina, mas não diz o que revisar, contra qual critério, o que fazer se achar algo, nem onde guardar o que foi descoberto. Sem essas respostas, o agente repete a mesma varredura genérica todo dia — ou pior, usa um critério diferente a cada vez porque nenhum foi salvo.
Legenda: à esquerda, "revisar" só gira em torno de si mesmo, sem critério nem registro; à direita, escolher → testar → registrar termina numa memória que também alimenta o próximo ciclo.
✓ O que o loop forte garante
- ✓Escolhe uma área pequena por ciclo, não "o app inteiro".
- ✓Usa um critério salvo de um ciclo pro outro — não reinventa a régua toda vez.
- ✓Só aplica a mudança se for segura e reversível.
- ✓Roda um teste de verdade antes de aceitar "melhorou".
- ✓Pede a um verificador que tente achar erro.
- ✓Registra a lição em algo que sobrevive ao fim do ciclo.
✗ O que o loop fraco tem
- ✗"Revise de vez em quando" sem dizer o quê.
- ✗Nenhum critério salvo — cada ciclo reinventa o que é "bom".
- ✗Aplica mudança sem checar se é reversível.
- ✗Aceita "parece melhor" sem teste nenhum.
- ✗Só a opinião de quem fez a mudança, sem segunda checagem.
- ✗Nenhum registro — a próxima sessão começa do zero.
Em 1 frase: loop de verdade tem foco, critério, teste e registro — sem os quatro, é só repetição com aparência de disciplina.
🛠️ O loop de 7 passos — prompt copy-run
🧠 Imagine assim: é o checklist de boxe de uma equipe de F1 — cada parada segue os mesmos passos, na mesma ordem, e termina com uma nota do que ajustar na próxima. Ninguém improvisa a sequência a cada parada.
A dica 11 do guia dá a receita concreta pra transformar "revisar de vez em quando" num ciclo real: 7 passos fixos, sempre na mesma ordem, que fecham voltando pra memória do projeto (dica 12, tópico 4 abaixo).
Objetivo: dar ao agente um roteiro fixo de verificação contínua — que lê o critério salvo antes de agir e grava a lição aprendida depois, em vez de reavaliar tudo do zero a cada ciclo.
A cada ciclo: 1. escolha uma área pequena do sistema; 2. analise com base nos critérios já salvos em memória; 3. proponha uma melhoria; 4. implemente somente se for segura e reversível; 5. rode teste; 6. peça ao verificador para tentar encontrar erro; 7. registre a lição aprendida.
Como verificar: rode um ciclo completo do início ao fim e confirme, ao final, que existe (a) um registro de critério que foi de fato consultado no passo 2 e (b) uma linha nova gravada no passo 7. Se o passo 7 não deixou rastro em lugar nenhum, o ciclo seguinte vai começar do zero — o loop não fechou de verdade.
Legenda: os 7 passos giram em círculo, sempre na mesma ordem; as setas ciano tracejadas mostram o elo com a memória — "analisar" lê o critério salvo, "registrar" grava a lição aprendida, fechando o ciclo pro próximo giro.
Cruzamento com a trilha 1 · fonte oficial
"Establish a method for checking your own work at an interval of [X] as you build. Run this every [X interval], verifying your work with subagents against the specification."
Os passos 5 e 6 desse loop (rodar teste + pedir ao verificador pra achar erro) ecoam exatamente essa técnica do módulo 1.4 da trilha 1, que tem respaldo oficial na doc da Anthropic. Lá o foco é como delegar essa checagem tecnicamente (subagent de contexto fresco); aqui é o ritmo prático de quando disparar essa checagem dentro de um ciclo de melhoria contínua.
→ Aprofundar no módulo 1.4 — Deixe agir + prove que terminouEm 1 frase: 7 passos fixos, sempre na mesma ordem — o critério entra no passo 2, a lição sai gravada no passo 7.
🗂️ O problema de depender só do histórico do chat
🧠 Imagine assim: uma empresa onde todo conhecimento importante mora só na cabeça de uma pessoa, ou só num chat que ninguém salva. No dia em que essa pessoa sai — ou o chat reseta — a empresa perde tudo que aprendeu, mesmo tendo passado meses aprendendo.
Em trabalhos longos e contínuos — um produto que evolui por meses, uma marca com campanhas rodando toda semana — o histórico de uma única conversa não é memória confiável. Sessão nova, contexto que estourou, chat que foi limpo: qualquer um desses apaga decisões e lições que custaram tempo real pra chegar.
Semana 1 — decisão tomada
Você e o agente decidem, numa conversa longa, que a campanha X funciona melhor com tom informal.
Semana 3 — sessão nova
Contexto novo, chat diferente. O agente não tem mais acesso àquela decisão — ela morava só no histórico da conversa antiga.
Semana 3 — erro repetido
O agente sugere de novo um tom formal pra mesma campanha, porque não sabe que isso já foi testado e descartado.
Resultado
Tempo perdido reaprendendo algo que já tinha resposta — e ninguém percebe até comparar com o que foi decidido semanas atrás.
⚠️ O custo composto
Cada decisão que só existe no chat é uma decisão que vai precisar ser retomada do zero na próxima sessão longa. Isso não escala: quanto mais o projeto dura, mais caro fica reconstruir contexto toda vez que a memória não sobrevive ao fim da conversa.
Em 1 frase: histórico de chat é frágil por natureza — memória de projeto de verdade precisa viver fora da conversa.
📋 O que colocar na memória externa
🧠 Imagine assim: é o manual de bordo de um projeto — não guarda cada conversa que já rolou, guarda só o que qualquer pessoa nova (ou agente novo) precisaria saber pra não repetir os mesmos erros e decisões.
A dica 12 do guia lista o que uma memória externa de trabalho contínuo deve conter — não é histórico bruto, é o destilado do que muda a próxima decisão. Cada item abaixo é algo que dá pra conferir se já está (ou não) registrado no seu projeto hoje.
Público-alvo
Quem o projeto atende, e o que essa pessoa já sabe/quer.
Tom de comunicação
Como o projeto fala, formal ou informal, e por quê.
Ofertas
O que está sendo vendido/oferecido no momento.
Campanhas que funcionaram
O que já foi testado e deu resultado — e o que não deu.
Regras técnicas
Restrições, padrões e integrações que não podem ser quebradas.
Decisões estratégicas
O que já foi decidido e não precisa ser reaberto toda vez.
Erros recorrentes
O que já falhou mais de uma vez e como evitar de novo.
Processos de trabalho
Como as coisas são feitas aqui, passo a passo.
Prompts validados
O que já funcionou bem e pode ser reaproveitado.
Padrões de qualidade
O que separa "aceitável" de "pronto de verdade" neste projeto.
Em 1 frase: memória externa boa não guarda a conversa inteira — guarda só o que muda a próxima decisão.
🔗 O loop que lê e escreve na memória a cada ciclo
🧠 Imagine assim: um profissional experiente não reaprende o trabalho toda segunda-feira — ele consulta as próprias anotações antes de decidir, e anota de novo o que aprendeu antes de ir embora. É exatamente isso que junta as duas dicas.
Sozinho, o loop de 7 passos (dica 11) já é melhor que "revisar de vez em quando". Mas ele só vira sistema de trabalho de verdade quando os passos 2 e 7 apontam pra um lugar real: o passo 2 lê a memória externa (dica 12) antes de analisar, e o passo 7 escreve nela depois de aprender algo. Sem esse elo, o loop reinicia o critério a cada ciclo — exatamente o problema do tópico 3.
🔗 Onde o loop encosta na memória
- •Passo 2 — analise com base nos critérios já salvos: 📖 lê público-alvo, regras técnicas, padrões de qualidade e decisões já tomadas.
- •Passo 6 — peça ao verificador para tentar encontrar erro: 📖 lê os erros recorrentes já registrados, pra não repetir a mesma falha de novo.
- •Passo 7 — registre a lição aprendida: ✍️ grava uma entrada nova (decisão/lição, por que importa, onde aplicar, o que evitar, data).
Exemplo combinado — revisando o onboarding de um produto
- Escolhe a área pequena: só a tela de boas-vindas do onboarding.
- 📖 lê em memória: tom de comunicação + padrão de qualidade já validado pra essa tela.
- Propõe: trocar um parágrafo longo por 3 bullets, seguindo o tom salvo.
- Implementa — é reversível (basta desfazer o commit).
- Roda o teste: 5 usuários reais completam o onboarding, mede tempo até o primeiro clique.
- Verificador (outro agente/pessoa) tenta achar problema — confere se algum bullet cortou informação que mudava a decisão do usuário.
- ✍️ grava em memória: "bullets curtos reduziram o tempo até o primeiro clique em 20% — aplicar no resto do onboarding. Data: hoje."
Em 1 frase: o loop sem memória reinicia toda vez; o loop que lê e escreve na memória acumula — cada ciclo começa mais esperto que o anterior.
⚠️ Erros comuns nessas 2 dicas — checklist rápido
🧠 Imagine assim: uma agenda que ninguém atualiza é pior do que não ter agenda nenhuma — porque todo mundo confia nela achando que está certa. Memória externa desatualizada tem o mesmo risco: parece fonte de verdade, mas mente.
✓ Fazer
- ✓Manter a memória curta e destilada — só o que muda a próxima decisão.
- ✓Atualizar a nota existente em vez de duplicar informação nova.
- ✓Definir sempre uma área pequena por ciclo do loop.
- ✓Confirmar teste real antes de aceitar "melhorou".
- ✓Deixar o verificador ser alguém/algo separado de quem implementou.
- ✓Revisar a memória de tempos em tempos pra tirar o que ficou obsoleto.
✗ Evitar
- ✗Deixar a memória virar um histórico de chat colado num arquivo (lixo, não memória).
- ✗Duplicar a mesma decisão em três arquivos diferentes que divergem com o tempo.
- ✗Rodar o loop numa área grande demais pra caber num ciclo só.
- ✗Aplicar mudança "porque parece melhor", sem rodar teste.
- ✗Deixar o mesmo agente que implementou validar o próprio trabalho.
- ✗Nunca revisitar a memória — ela também envelhece.
Em 1 frase: loop sem memória é surdo; memória sem loop é morta — as duas dicas só funcionam completas juntas.
🧾 Resumo do Módulo
Próximo módulo:
2.7 — Bônus: o prompt mestre.