israeldegasperi Gauntlet Loop
Aplicar um loop controlado de construir, avaliar, criticar e melhorar. Não confundir persistência com qualidade: exigir evidência observável e respeitar custo, prazo, risco e autorização.
1. Fazer o preflight
Antes de executar, fazer estas três perguntas obrigatórias, preservando a linguagem do usuário:
- O que você quer criar?
- Qual é o critério de qualidade?
- Qual é o custo máximo do projeto?
Perguntar em lotes curtos. Se o usuário já forneceu uma resposta, não perguntar novamente. Explicar custo na unidade aplicável: dinheiro, tempo, tokens, número de ciclos ou combinação deles. Se custo monetário não puder ser medido com precisão, declarar isso e usar limites controláveis de tempo e ciclos.
Sugerir somente as perguntas adicionais que mudem materialmente a execução:
- Para quem é o resultado e qual decisão, tarefa ou comportamento ele deve viabilizar?
- Qual referência real representa o padrão a superar ou igualar? Oferecer duas ou três referências concretas quando o usuário não tiver uma.
- Que evidência observável comprova qualidade: testes, métricas, fontes, screenshots, exemplos, conversão, clareza para um leitor ou aprovação humana?
- Quais requisitos são obrigatórios e o que está fora do escopo?
- Quais arquivos, dados, acessos e materiais estão disponíveis?
- Qual é o prazo ou tempo máximo de execução?
- Quais riscos, restrições legais, de marca, privacidade, segurança ou compatibilidade devem ser respeitados?
- O que não pode ser alterado?
- Quais marcos exigem aprovação humana antes de continuar?
- Qual é a condição de parada: vencer a referência, passar todos os testes, atingir uma métrica, esgotar orçamento ou melhora marginal insuficiente?
- Quem toma a decisão final quando critérios entram em conflito?
Quando qualidade estiver vaga, converter adjetivos em critérios verificáveis. Não aceitar apenas “profissional”, “premium”, “bom” ou “melhor”. Propor critérios e pedir confirmação. Separar critérios eliminatórios de critérios de preferência e, se houver conflito, registrar a prioridade.
Escolher o nível de profundidade
Depois das três perguntas obrigatórias, perguntar em qual nível o loop deve rodar. Se o usuário não escolher, assumir o Essencial.
Nível 1. Essencial. Objetivo, até três critérios eliminatórios, uma referência e no máximo dois ciclos. Sem contrato formal escrito, sem scorecard, sem separação de contexto. O construtor autoverifica conforme a seção 4.1 e entrega. Serve para a maior parte dos trabalhos.
Nível 2. Controlado. Contrato completo, scorecard por ciclo, ratchet e orçamento explícito. Crítica com contexto separado quando o ambiente permitir. Para entregáveis de alto impacto.
Nível 3. Organizacional. Tudo do nível 2, mais registro de emendas, pontos de aprovação nomeados, riscos e limitações declaradas. Para trabalho que precisa ser auditado por terceiros.
Motivo desta regra. Aplicar o nível 3 a um trabalho comum transforma o método em burocracia e faz o usuário abandonar antes do primeiro resultado. A profundidade deve acompanhar o custo do erro, não a ambição do processo.
2. Preparar o contrato do loop
Resumir antes da execução:
- objetivo e entregável;
- público e uso;
- referência ou baseline;
- critérios de aceitação e evidências;
- requisitos e limites;
- orçamento de dinheiro, tempo e ciclos;
- condição de parada;
- pontos de aprovação humana.
Não inventar uma referência. Se não houver referência real ou sinal confiável, avisar que o loop será exploratório e que a crítica terá menor poder de discriminação. Para projetos do zero, criar primeiro um baseline ou contrato de arquitetura e só depois iniciar o loop.
O contrato é permanente
Instruções dadas em uma rodada específica não substituem o contrato. Elas se somam a ele.
Ao receber uma instrução de correção, tratar todos os critérios anteriores como ainda vigentes. Antes de entregar, confirmar que nenhum requisito obrigatório, restrição ou item fora de escopo foi rompido para acomodar a nova instrução.
Quando a nova instrução conflitar com o contrato, não escolher sozinho. Apontar o conflito e pedir decisão humana.
Qualquer alteração de contrato durante o loop deve ser registrada com data, ciclo, motivo e efeito. Emendas que elevam a barreira são legítimas. Emendas que rebaixam ou removem critérios após o veredito invalidam o loop.
3. Decompor sem fragmentar demais
Dividir o resultado em partes independentemente melhoráveis. Definir para cada parte entradas, saída esperada, critérios locais, dependências e método de inspeção. Preservar coerência global. Evitar dividir trabalhos pequenos ou fortemente acoplados apenas para simular múltiplos agentes.
4. Construir e criticar com independência
Para cada parte:
- Produzir um candidato com um builder apropriado.
- Inspecionar o artefato real, não apenas a explicação do builder.
- Usar um crítico com contexto fresco quando o ambiente permitir. Não mostrar raciocínio, esforço ou justificativas do builder ao crítico.
- Comparar candidato e referência sem rótulos e em ordem aleatória quando uma comparação cega fizer sentido.
- Exigir um veredito binário: candidato vence ou perde. Pedir também a maior lacuna observável e a evidência que sustenta o veredito.
- Em caso de derrota, transformar a maior lacuna em uma instrução específica para a próxima construção.
Não permitir que o builder aprove o próprio trabalho. Quando agentes independentes não estiverem disponíveis, simular separação de contexto explicitamente e informar a limitação.
4.1 Autoverificar antes de entregar
Antes de apresentar qualquer candidato, percorrer a lista completa de critérios eliminatórios do contrato e produzir uma tabela com uma linha por critério, contendo veredito binário e a evidência observada.
Executar primeiro os critérios verificáveis por operação mecânica: contagem de palavras, contagem de elementos, busca literal por termos, presença de link, medição de posição. Esses não dependem de julgamento e custam quase nada.
Se qualquer critério eliminatório reprovar, não apresentar o candidato como pronto. Corrigir e reverificar, ou apresentar declarando explicitamente quais portões não foram vencidos e por quê.
Não é permitido relatar apenas as correções aplicadas nesta rodada. O relatório cobre a rubrica inteira, inclusive os critérios que não foram tocados.
Motivo desta regra. Relatar progresso sem verificar a rubrica completa produz a aparência de avanço com regressão silenciosa em critérios já atendidos.
5. Aplicar o ratchet
Manter a melhor versão validada como incumbent. Substituí-la apenas quando o novo candidato vencer uma comparação válida. Nunca degradar um critério já aprovado sem registrar e justificar o trade-off.
Invalidar avaliações baseadas em evidência defeituosa, como teste incompleto, screenshot quebrado ou fonte inadequada. Uma rodada inválida não substitui o incumbent.
Depois de mudanças locais, executar uma avaliação integrada de coerência, interfaces, consistência, acessibilidade, desempenho e regressões relevantes.
6. Controlar custo e parada
Antes de cada rodada, estimar se ela cabe no orçamento remanescente. Parar quando ocorrer o primeiro destes eventos:
- todos os critérios eliminatórios passam e o candidato vence a referência;
- o orçamento ou prazo se esgota;
- a melhoria marginal fica abaixo do limiar acordado;
- duas rodadas consecutivas repetem a mesma falha sem nova evidência;
- surge risco, bloqueio ou decisão que exige aprovação humana;
- o usuário pede para parar.
Não prometer loop ilimitado. Se o custo máximo não estiver definido, sugerir um teto inicial conservador e pedir confirmação antes de executar trabalho material.
7. Reportar o resultado
Entregar:
- artefato final ou link para ele;
- critérios atendidos e evidências;
- critérios não atendidos e impacto;
- versão preservada pelo ratchet;
- custo consumido nas unidades observáveis;
- número de ciclos válidos e inválidos;
- riscos residuais e decisão recomendada: aprovar, revisar ou interromper.
Distinguir fato observado, inferência do crítico e decisão humana. Não declarar vitória sem evidência.
Fontes metodológicas
Creditar o Gauntlet Loop a Matt Shumer. Usar como contexto complementar o artigo de Israel Degasperi: https://idegasperi.com/growth-receita/gauntlet-loop-ia-sem-criterio/