Gauntlet Loop
O método por trás do Claude of Duty, generalizado para qualquer trabalho que um agente possa inspecionar. Um único prompt produziu aproximadamente 55.000 linhas de um jogo de tiro no estilo AAA jogável, com zero intervenção humana. O modelo não foi o diferencial. O loop foi.
Ciclo central:
Dividir → construir → julgar contra um padrão externo → repetir.
Método de Matt Shumer. Veja references/origin.md.
Contrato de execução
Você executa este protocolo. O usuário não.
Quando esta habilidade for acionada, não entregue um prompt, um plano para aprovação ou uma descrição do que seria um Gauntlet Loop. Defina o padrão, decomponha o objetivo, gere construtores e críticos, execute as rodadas e entregue o artefato finalizado.
O usuário deu um objetivo uma vez. Tudo depois disso é com você.
- Não faça perguntas esclarecedoras. Cada incerteza é uma decisão sua, que você registra no resumo final.
- Escolha o padrão você mesmo. Declare-o em uma frase e prossiga. Nunca pergunte qual referência usar.
- Roteie os modelos você mesmo. Escolha o modelo e o esforço de raciocínio para cada agente gerado a partir do que o harness oferece. Nunca pergunte ao usuário qual modelo usar e nunca deixe tudo na configuração padrão da sessão.
- Não relate nada durante a execução. O progresso vai para o arquivo de progresso ao vivo, não para a conversa.
- Interrompa apenas por uma credencial bloqueada, um recurso pago ausente ou uma instrução que causaria dano.
Se o usuário solicitar explicitamente ser consultado em pontos de verificação, atenda a isso. Na ausência desse sinal, execute até a conclusão.
Quando se aplica
Três condições:
- A solicitação é criar ou melhorar algo, não responder a uma pergunta.
- A saída pode ser inspecionada objetivamente: renderizada, executada, aberta, medida, testada, lida.
- Mais de uma rodada é acessível.
Ignore para consultas, correções de uma linha e explicações. Custa computação real e só compensa quando a qualidade importa mais que a velocidade.
Roteiro
1. Detecte o harness
Leia references/harness-setup.md e escolha a fiação antes de fazer qualquer outra coisa. Ela determina se os críticos vêm de subagentes paralelos, sessões separadas ou passagens com isolamento rígido. Nunca anuncie esta etapa, apenas adapte-se.
Enquanto estiver lá, enumere os modelos e as configurações de esforço de raciocínio que este harness expõe. Você não pode rotear o que não listou.
2. Defina o orçamento e a tabela de roteamento
O loop multiplica as chamadas. Se não for roteado, cada uma delas herda o modelo e o esforço da sessão, e uma expansão de edições mecânicas é executada em um modelo de fronteira com raciocínio máximo, sem ganho algum.
Leia references/model-routing.md e decida, de uma vez, antes de construir:
- Os níveis. Mapeie os modelos disponíveis para T0 (um comando, sem modelo), T1 (pequeno e rápido), T2 (médio), T3 (fronteira com alto esforço).
- A tabela. Qual função recebe qual nível: líder e toda chamada de julgamento em T3, construção padrão em T2, edições mecânicas e contabilidade em T1, qualquer coisa que um comando possa verificar em T0.
- O orçamento. Respeite o orçamento do usuário, se ele forneceu um; caso contrário, defina um e reserve aproximadamente um quarto dele para os críticos.
Duas regras substituem qualquer economia. O julgamento nunca é roteado para o nível mais barato, porque um crítico fraco aprova cedo e anula o método. E uma peça que é sobre gosto ou novidade começa no nível mais alto, porque um construtor barato perdendo quatro rodadas custa mais do que um caro vencendo em uma.
Registre a tabela no arquivo de progresso. Não a anuncie e não peça ao usuário que a aprove.
3. Defina o padrão
O padrão decide se a execução funciona ou não. Padrões que não servem: "tornar incrível", "qualidade de produção", "seguir as melhores práticas". Um padrão é um artefato ou medição externa real com o qual a saída pode ser comparada e perder.
Escolha um usando references/quality-bars.md, que cobre trabalho visual, front-end, UI de produto, back-end, mobile, escrita, sistemas de design, pesquisa, dados e marketing.
Regras:
- Inspecionável dentro da execução. Uma captura de tela salva no espaço de trabalho, uma URL que você pode abrir, um conjunto de testes que executa, um arquivo que você pode ler. Não é um padrão lembrado do treinamento.
- Não precisa ser alcançável. Claude of Duty nunca superou Call of Duty. O padrão existe para impedir que a execução se contente com "bom para IA".
- Atingido na primeira rodada significa que era muito baixo. Aumente-o e continue.
Obtenha ou gere os artefatos do padrão agora, antes de qualquer construção, e armazene-os no espaço de trabalho para que todo crítico possa alcançá-los.
4. Pegue o objetivo, não a implementação
Não prescreva sua própria arquitetura antecipadamente e não aceite uma decomposição inventada antes de olhar para o artefato. Reafirme o destino e deixe a forma emergir.
Se o usuário fixou uma stack ou uma arquitetura, essa é uma restrição real. Respeite-a e deixe todo o resto em aberto.
5. Divida o trabalho
Divida o objetivo nas menores partes que podem ser melhoradas e julgadas separadamente e decida quais executar em paralelo.
Granularidade é a alavancagem. "Melhorar o site" é intratável. "Fazer esta seção de preços superar a seção de preços de referência" é um problema que você pode atacar até vencer. O mesmo vale para "fazer p95 superar 120ms sob esta carga" e "fazer este parágrafo ser pelo menos tão claro quanto este parágrafo de referência".
6. Construa e julgue, nunca no mesmo contexto
Para cada peça, um construtor e um crítico separados. Sempre contextos diferentes, nunca o mesmo agente.
O construtor viu cada decisão e se lembra por que as tomou, o que o torna excelente em explicar por que o resultado é razoável. Razoável não é o alvo.
Instrua-os usando assets/delegation-templates.md. O crítico recebe o objetivo, o padrão, as restrições e o artefato real. Ele nunca recebe a transcrição do construtor, a explicação do construtor ou qual lado é o nosso.
Roteie cada geração conforme a cria, usando a tabela da etapa 2. Faça as três perguntas antes de cada construtor: o sucesso é verificável por um comando (nenhum modelo, execute-o), o estado alvo já está totalmente especificado (menor modelo, esforço mínimo) ou fechar a lacuna requer decidir como é o bom (fronteira). Críticos julgando gosto são sempre de fronteira; críticos verificando um número executam o comando primeiro e só precisam de um modelo pequeno para relatá-lo.
Procedimento completo em references/critic-protocol.md. Essenciais: comparação cega A/B, inspecione a coisa real, veredito binário, nomeie a única maior lacuna, envie de volta.
7. Continue repetindo
Nunca defina um número de rodadas. Qualquer rodada final acordada se torna um teto.
Pare quando uma destas condições for verdadeira e registre qual delas:
- O usuário declara que está pronto a partir do arquivo de progresso.
- Os ganhos por rodada pararam de importar para o objetivo.
- O orçamento de computação acabou, medido contra o orçamento definido na etapa 2.
Aumente o nível de uma peça apenas com evidências: duas derrotas consecutivas na mesma lacuna aumentam seu esforço; uma terceira aumenta seu modelo. Uma peça que começa a vencer desce de nível pelo resto da execução. Com 80% do orçamento gasto, pare de adicionar rodadas a peças que já estão vencendo e coloque o restante na peça mais distante do padrão.
Se a mesma lacuna sobreviver a três rodadas consecutivas, pare essa peça e redecida no nível de liderança. É estrutural, ou o padrão está errado para aquela peça, ou construtor e crítico estão medindo coisas diferentes. Gastar mais nela nesse ponto é a maneira mais comum de queimar um orçamento em nada.
8. Mantenha um arquivo de progresso ao vivo
Mantenha uma página HTML simples ou arquivo markdown no espaço de trabalho, atualizado conforme o trabalho chega: capturas de tela, rascunhos, resultados de teste, vereditos rodada a rodada, lacunas abertas. Não especifique demais o formato e informe ao usuário onde ele está na sua primeira linha de saída.
Isso existe para que o usuário possa assistir sem interromper. A interrupção custa uma janela de contexto e quebra o loop.
9. Passagem de suavização entre ondas
Quando muitos agentes editam partes separadas de um artefato, as partes ficam individualmente boas e coletivamente incoerentes.
No final de cada onda principal, gere um agente novo para inspecionar o resultado completo, resolver conflitos e fazer com que pareça uma coisa só. Ele não redesenha nada.
Útil, não essencial. O essencial permanece: dividir, construir, julgar, repetir.
Fechando a execução
Entregue o artefato, depois um breve resumo contendo:
- O padrão usado e por quê.
- Até onde o trabalho chegou contra ele.
- A última lacuna não fechada, que é o ponto de entrega para quem pegar o trabalho em seguida.
- Suposições feitas no lugar de perguntas não feitas.
- Qual condição de parada encerrou a execução.
- O que custou: rodadas executadas, aproximadamente onde o orçamento foi e qualquer peça que consumiu uma grande parte sem se mover.
Nenhum elogio pelo trabalho. Os vereditos do crítico já disseram tudo o que importa.
Anti-padrões
| Sintoma | Correção |
|---|---|
| Entregar ao usuário um prompt para ele mesmo executar | Execute o protocolo, esse é o ponto principal |
| "Isso está ótimo!" do construtor | Gere um crítico com contexto limpo, sem histórico |
| Crítico lendo um relatório em vez do artefato | Force a inspeção da saída real |
| Padrão subjetivo ("classe mundial", "nível Apple") | Substitua por um artefato concreto que você possa abrir |
| Decomposição fixada antes de ver o artefato | Deixe a forma emergir do trabalho |
| "Faça 3 iterações" | Loop aberto com uma condição de parada explícita |
| Perguntar qual referência usar | Escolha uma, justifique em uma frase, prossiga |
| Atualizações de status na conversa | Arquivo de progresso ao vivo |
| Partes boas, todo incoerente | Passagem de suavização no final da onda |
| Padrão atingido na primeira rodada | O padrão era muito baixo, aumente-o |
| Mesma lacuna sobrevivendo três rodadas | Escalone, é estrutural |
| Cada agente herdando o modelo e esforço da sessão | Roteie cada geração: fronteira para julgamento, pequeno para trabalho mecânico |
| Modelo de fronteira com esforço máximo renomeando uma variável | T1 com esforço mínimo, ou um comando sem modelo algum |
| Crítico barato, para economizar uma rodada | Regra zero. Um crítico fraco aprova cedo e anula o método |
| Construtor barato em uma peça que é sobre gosto | Quatro rodadas perdidas custam mais do que uma vitória cara |
| Aumentar o nível porque uma peça parece difícil | Escalone com base em vereditos repetidos, não em palpites |
| Orçamento do crítico gasto em rodadas extras de construção | A reserva não é um poço. O julgamento fica com ele |