Rode o método dentro da sua IA.

Antes de pedir qualquer tela, fluxo ou feature pra um agente. Se o pedido cabe numa frase, ele ainda não é uma especificação.

Dê ao seu agente o brief bruto e peça que ele NÃO construa nada ainda. O trabalho aqui é outro: transformar intenção em especificação. Uma especificação executável tem cinco partes, nesta ordem: 1. Intenção: o problema do usuário em uma frase, com o resultado esperado. Não é a solução, é o porquê. 2. Contexto: quem usa, em que situação, com que restrição real (dispositivo, acessibilidade, idioma, estado de erro). 3. Decisões já tomadas: o que NÃO está em aberto (design system, tom de voz, padrões do produto). Tudo que você não fixar aqui o agente decide por você. 4. Critérios de aceite: como você vai verificar que ficou pronto. Cada critério precisa ser checável (um teste, um screenshot, um número), não uma opinião. 5. Fora de escopo: o que este pedido explicitamente não cobre. É a parte que mais evita retrabalho. Peça ao agente que devolva a especificação preenchida e aponte os buracos: toda pergunta que ele faria antes de construir. Responda os buracos, atualize a especificação e só então autorize a construção. Teste de qualidade: entregue a mesma especificação duas vezes, em conversas separadas. Se os dois resultados divergem no que importa, a especificação está subespecificada onde divergiu.

Uma especificação de cinco partes, com os buracos respondidos, pronta pra virar ordem de construção.

Uma vez por produto, e revisitado quando uma decisão nova vira regra. Se você já se pegou colando as mesmas instruções pela terceira vez, está atrasado.

Peça ao agente que monte com você o dossiê de contexto do produto: um documento único que qualquer agente lê antes de qualquer tarefa (no Claude Code ele se chama CLAUDE.md; a ideia vale pra qualquer ferramenta). Construa em seis blocos: 1. O produto em três frases: o que é, pra quem, o que nunca deve ser. 2. Stack e estrutura: tecnologias, onde vive cada coisa, comandos de rodar e testar. 3. Design system: tokens, componentes canônicos, o que é proibido hardcodar. 4. Voz e conteúdo: idioma, tom, palavras banidas, como se escreve erro e vazio. 5. Regras duras: acessibilidade mínima, privacidade, o que exige aprovação humana. 6. Armadilhas conhecidas: os erros que agentes já cometeram neste produto e não podem repetir. O bloco 6 é o que separa dossiê vivo de documentação morta: toda vez que um agente errar feio, a lição entra ali, com uma linha de contexto. Regra de tamanho: se o dossiê passa de duas telas, ele vira ruído e o agente começa a ignorar. Corte o que não muda decisão.

Um dossiê de contexto de até duas telas que qualquer agente lê antes de trabalhar, com a seção de armadilhas viva.

Quando você começa a delegar tarefas inteiras (não só perguntas) pra um agente, e sempre que der autonomia nova.

Autonomia sem limite declarado termina de um jeito só: o agente decidindo algo que era seu. Antes de delegar, escreva com o próprio agente o contrato de papéis, em três listas: 1. Decide sozinho: o reversível e barato. Renomear, refatorar sem mudar comportamento, ajustar espaçamento dentro do design system, corrigir erro óbvio. 2. Propõe e espera: o que muda comportamento, aparência pública ou estrutura. O agente traz opção com prós e contras, você bate o martelo. 3. Nunca faz: publicar, apagar o que não criou, mexer em dado de usuário, gastar dinheiro, falar em seu nome. Depois, defina o formato do relatório: ao terminar, o agente diz o que fez, o que verificou (com evidência: teste, screenshot, diff) e o que ficou pendente. Trabalho sem evidência volta pra fila. Revisite o contrato quando o agente errar: o erro quase sempre mostra uma tarefa que estava na lista errada.

Um contrato de três listas (decide, propõe, nunca) e um formato de relatório com evidência obrigatória.

Durante qualquer construção com agente que vá pra produção ou pro seu portfólio. Protótipo descartável pode pular; produto real, nunca.

O risco da construção com agente não é o código errado, é o código que parece certo. Este loop troca velocidade bruta por velocidade com chão: 1. Fatie: peça a construção em fatias que você consegue revisar em uma sentada. Fatia que não cabe na sua atenção é fatia grande demais. 2. Antes de aceitar cada fatia, peça ao agente: "explica o que esse trecho faz, por que dessa forma, e o que quebraria se ele não existisse". Se a explicação não te convence, você não entendeu ou o código não se sustenta. Nos dois casos, não aceita. 3. Pergunte o que o trecho assume: dependências, estados que não trata, o que acontece com entrada inesperada. 4. Guarde uma frase sua (não do agente) por fatia: o que ela faz, no seu vocabulário. É o seu teste de compreensão e vira material do seu case depois. 5. Só então integre e peça a próxima fatia. O critério é honesto e desconfortável: se alguém te perguntar amanhã "por que isso está assim?", você responde sem abrir o chat?

O produto construído em fatias revisadas, mais um registro seu, frase a frase, do que cada parte faz.

Antes de declarar qualquer entrega pronta. Principalmente quando ela veio rápido e parece impecável.

Agente revisando o próprio trabalho com a mesma persona que o criou é teatro. A revisão precisa ser adversarial: instrua o agente a REPROVAR a entrega, não a confirmá-la. Rode três ataques, um de cada vez: 1. Correção: "encontre três formas de esta implementação estar errada. Pra cada uma, mostre a entrada ou o estado que quebra." Proibido responder que está tudo certo; se não achar, procure de novo com outra lente. 2. Acessibilidade: "audite contra WCAG 2.1 AA: navegação por teclado, foco visível, contraste, rótulos, leitores de tela. Liste cada violação com o elemento exato." 3. Borda: "o que acontece com vazio, com lista de mil itens, sem conexão, no meio de um envio, com texto quatro vezes maior?" Pra cada achado: reproduza antes de corrigir. Achado que não se reproduz é ruído; corrigir ruído introduz erro novo. Feche com a pergunta que o agente não pode responder por você: o que aqui você aceitou sem verificar?

Uma lista de achados reproduzidos e corrigidos, com evidência, e a lista honesta do que ficou aceito sem verificação.

Na primeira publicação de qualquer produto e em toda mudança que toca dado, formulário ou dinheiro.

Publicar é o momento em que o erro para de ser seu e passa a ser do usuário. Antes de apertar o botão, percorra com o agente: 1. Segredos: nenhuma chave no código ou no histórico. Tudo em variável de ambiente, e o agente lista quais o ambiente de produção precisa. 2. Formulários e entradas: o que acontece com envio malicioso, repetido, vazio? Onde cai o dado? Quem é avisado? 3. Estado de falha: derrube de propósito a dependência externa (API, email, banco) e veja o que o usuário vê. Falha silenciosa é a pior tela do seu produto. 4. Reversão: você sabe voltar pra versão anterior em um comando? Se não sabe, ainda não está pronto pra ir. 5. Prova de vida: depois de publicar, execute o fluxo principal de verdade, no ambiente real, como usuário. Deploy verde não é produto funcionando. Guarde o resultado do item 5 (screenshot, registro): é a primeira evidência do seu case.

Um produto no ar com fluxo principal verificado no ambiente real, segredos fora do código e caminho de volta conhecido.

Logo depois da primeira publicação, e a cada ciclo. Sem este método, o ciclo anterior foi um lançamento, não um aprendizado.

A pergunta não é "o que dá pra medir?", é "que decisão essa medida muda?". Com o agente: 1. Escreva a pergunta do ciclo: a única coisa que você precisa saber pra decidir o próximo passo (as pessoas chegam? completam? voltam?). 2. Instrumente o mínimo que responde essa pergunta. Um evento bem escolhido vale mais que quarenta métricas num painel que ninguém abre. 3. Defina antes o que cada resultado significa: "se X passar de tanto, faço A; se não, faço B". Decidir o significado depois de ver o número é ler borra de café. 4. Colete o qualitativo junto: uma resposta em texto livre de usuário real vale um gráfico inteiro nesta fase. 5. Feche o ciclo: o que você aprendeu vira a intenção da próxima especificação executável (método 1). É isso que faz as sete etapas serem um ciclo, não uma checklist. Regra de honestidade: número sem fonte e sem denominador não entra em case, post ou conversa com stakeholder. Nunca.

Uma pergunta de ciclo respondida com evidência, e a próxima especificação já nascida do que você mediu.