Design e Revisão de Loops

Premissa. Um LLM é um sistema feed-forward: prompt de entrada → tokens de saída, sem um "direcionamento para o objetivo" embutido entre as interações. Para fazê-lo se comportar como um sistema orientado a objetivos, você o envolve em um loop de feedback. Esta habilidade ajuda você a escrever esse loop corretamente e a revisá-lo para que ele não saia do controle.

Quando usar / não usar

Use quando:

• Você quer entregar uma tarefa repetitiva a um agente que roda várias vezes (escrever→testar, testar→corrigir, corrigir→verificar…).
• Você já tem um loop e se preocupa que ele fique girando, trapaceando ou executando uma resposta errada até o fim.

Não use para:

• Uma tarefa única → faça-a diretamente; não crie um loop para isso.
• Um simples timer / enquete → use /loop; não é necessário design.
• Como conectar a arquitetura do loop (pipelines → DAGs, recuperação de longo prazo) → essa é a camada de mecanismo; veja autonomous-loops / continuous-agent-loop. Esta habilidade cobre apenas "o objetivo está certo e ele vai sair do controle" — ela não reexplica o mecanismo.

Premissa da linha vermelha: dois níveis de feedback

Um termostato pode dar feedback sobre "o quão longe de 26°C", mas quando você está com febre e quer 28°C, ele não pode julgar se 26 é o alvo certo — ele apenas se esforça para atingir 26. "O que definir hoje" é sempre uma decisão humana. Entregar o julgamento / aprovação / o último interruptor para a máquina = remover o feedback de alto nível = ela corre, rápida e intensamente, em direção a um objetivo que ninguém questionou → resultado incorreto.

Ação 1 — Escrever um loop (5 passos)

Passo 0 · Subtraia primeiro: você realmente precisa construir isso? (Portão de 4 condições, qualquer falha = veto)

① a tarefa se repete semanalmente ou mais　② a verificação pode ser automatizada　③ o orçamento de tokens pode suportar　④ o agente tem ferramentas que realmente executam e veem o resultado

Falhou em qualquer um → não construa um loop; faça manualmente ou de outra forma.

O que impede a maioria das pessoas não é "posso escrever um loop", mas sim "meu repositório merece um". Um repositório que merece um loop tem uma linha de base de reconciliação (amostra de ouro / total upstream) + testes + um guarda de lint. Um repositório que não merece um loop apenas terá seus erros amplificados por um.

Passo 1 · Defina um objetivo decidível pela máquina (a parte difícil — o loop vive ou morre aqui)

Todo o loop depende do comparador "já terminou?". O comparador só pode funcionar se sua condição de saída puder ser julgada como sim/não por uma máquina.

• Ruim: Vago ("faça ser bom", "escreva de forma mais afiada") → o comparador não pode julgar → ou ele nunca passa (preso tentando novamente) ou ele adivinha (passa/bloqueia aleatoriamente).
• Bom: Decidível ("todos os 96 testes unitários verdes E uma lista de alterações é produzida", "campos do módulo-02 preenchidos, pytest passa, lógica de negócios intocada") → uma verificação resolve; o loop converge limpo.

Framework de objetivo de cinco pontos:

1. Critério de conclusão é verificável pela máquina.
2. Condições de limite definidas junto com o critério de conclusão ("o que ele NÃO deve fazer") — anti-Goodhart; limites ausentes = licença para trapacear.
3. Tem um fallback em caso de falha — limite de tentativas N + escalonamento para um humano quando excedido.
4. O objetivo é em camadas.
5. Prefira reconciliação sobre asserção para o critério de conclusão — ancore em um fato externo (amostra de ouro / total upstream / conciliação financeira / números do back-office da plataforma) antes de suas próprias asserções. "Todos os testes passam" pode ser manipulado (afrouxar asserções, mocks falsos, engolir exceções); "diferença vs a referência < 0.01" não pode.

Autoverificação: leia o objetivo para alguém que não conhece o domínio — essa pessoa pode executar um comando e dizer se está pronto? Se não, não é decidível o suficiente. Volte.

Passo 2 · Escolha o tipo de loop

…