Mapa da trilha
Conteúdo detalhado
🪜 A escada de decisão
Antes de construir qualquer loop, passe a tarefa por uma escada de duas perguntas. A maioria não sobe — e está tudo bem.
Antes de construir, passe a tarefa por duas perguntas; só construa loop se for SIM nos dois degraus.
Economiza horas de engenharia em tarefas que um prompt simples já resolvia.
Escada de decisão; SIM/SIM; one-shot.
Se a tarefa é um passo previsível, só prompte; one-shot é mais rápido e barato.
Loop existe para terceirizar repetição, não para enfeitar uma tarefa única.
Repete × único; muitos passos desconhecidos.
A IA consegue verificar que terminou (rodar testes, contar palavras)? Se não, faça você.
Sem essa checagem o loop não converge — para cedo demais ou nunca para.
Checagem automática; conserte o objetivo primeiro.
Nate Herk: "a maioria das tarefas não precisa de loop"; quando faz, é pela verificação.
Te livra de construir arquitetura gigante onde um terminal + um bom prompt bastava.
Loop é custo; comece pequeno.
Firecrawl: loops rendem mais em tarefas repetitivas, revisáveis e de alto valor — não em tudo.
Te dá o grid ✓/✗ para separar bom de mau candidato a loop.
Revisável; os três critérios juntos.
Conserto de teste → loop; reescrever 1 e-mail → só prompt; pesquisa ampla → depende de checar.
Treina o reflexo de aplicar a escada antes de sair construindo.
Critério objetivo × subjetivo.
🧩 As 3 formas de loop
Decidiu que vale? São só três formas — mudam quantos agentes entram e quem confere o trabalho de quem.
Um agente percorre reason→act→observe e repete; o "modelo + ferramentas" da Trilha 1.
É a mais fácil de construir e depurar e cobre a maior parte do trabalho. Comece aqui.
Think→Act→See; menos peças, menos bugs.
Um agente faz, um segundo (IA fresca) dá nota; quem cria não carimba o próprio trabalho.
É o beat "observe/check" com agente dedicado; suba para cá quando a qualidade importa.
Maker; checker; conserta até passar.
Um líder divide o objetivo e entrega pedaços a sub-agentes que rodam em paralelo.
Serve quando o job é grande demais para um fluxo sequencial.
Sub-agente; fan-out; paralelismo.
É qualquer uma das três formas deixada sem supervisão — não uma forma nova.
É a configuração que mais precisa de um STOP forte (teto de voltas, gate humano).
Autônomo; condição de parada; supervisão.
Comece no Solo; suba para Maker→Checker pela qualidade; para Manager→Helpers pelo tamanho.
Complexidade extra é custo — só suba quando um agente realmente não dá conta.
Escalada gradual; custo por forma.
Solo: conserto de teste; Maker→Checker: thumbnail + scorer; Manager→Helpers: auditar 45 fontes.
Fixa cada forma num caso real + um prompt colável de maker→checker.
Scorer dedicado; copy-run.
🏁 Definir e checar "pronto"
Um loop é tão bom quanto a sua linha de chegada. Trave o "pronto" e escolha entre os 4 tipos de check.
Antes de rodar, responda o que "pronto" significa (uma máquina lê) + como vai checar.
Essas duas respostas SÃO a checagem "pronto?" do loop — o motor da parada.
Linha de chegada; os 4 tipos de check.
Uma máquina responde sim/não: testes passam, app roda, build compila.
É o check mais fácil e confiável — comece por ele sempre que der.
Verde/vermelho; checagem binária.
Quando o resultado precisa ser VISTO para ser julgado: UI, thumbnail, layout.
A maioria dos agentes consegue olhar imagens / tirar screenshot e julgar o pixel.
Screenshot; ver o pixel, não o código.
Precisa de gosto, mas dá para escrever uma rubrica; um 2º agente pontua por ela.
A armadilha "até você ficar satisfeito" é subjetiva demais — objetive ("até a métrica = Y").
Rubrica; objetivar o gosto.
Irreversível ou puro gosto que nenhuma rubrica captura: o loop pausa, você aprova, e continua.
É o check certo para passos arriscados — as portas de mão única.
Gate humano; one-way door.
Quanto mais objetivo o "pronto", melhor o loop: ele ganha um número para perseguir.
Exemplo real (Nate): Abbey Road em CSS, parando em score ≥ 9 OU após 8 passes (cap duro).
Métrica; cap de iterações; screenshot + reavaliar.