Loop Engineering

O que é

Loop Engineering é a disciplina de projetar, construir e operar ciclos autônomos de agentes de IA que descobrem, executam, verificam, corrigem e param sem intervenção humana contínua. Evolução do prompt engineering: o prompt é commodity, o loop — gatilho, sensor, critério de retry, condição de parada — é o diferencial.

Um agente isolado é uma ferramenta pontual (pergunta → resposta → fim). Um loop é um sistema que vive: GATILHO → EXECUTAR → VERIFICAR → DECIDIR (repete ou para).

Os 8 princípios (P1–P8)

Princípio	Resumo
P1 — Objetivo verificável	"Pronto" é um fato observável (código/query), não uma opinião.
P2 — Limites explícitos	Sucesso, parada e hand-off definidos antes de rodar.
P3 — Sensor por estágio	Cada estágio tem um sensor binário (passou/falhou, com número).
P4 — Reversibilidade/iteração	Idempotente; forward-fix só nos itens que falharam; retry ≤3.
P5 — Checker independente	Quem verifica não é quem executou — pega o erro que age sobre si mesmo.
P6 — Memória entre runs	Journal de cada run; evita retrabalho; auditoria obrigatória em ação irreversível.
P7 — Bound no recurso caro	Teto sobre o que dói se exagerar (tokens, escrita irreversível, reputação de domínio).
P8 — Gates no ponto de não-retorno	Aprovação humana antes de qualquer ação sem Ctrl+Z.

Tipos de loop

• Single-Agent Loop — um agente faz tudo (descobre, executa, verifica).
• Fleet Loop — dois+ agentes especializados passam o bastão (hand-off explícito).
• Open Loop com Checkpoints — reage a estado externo que muda independentemente.
• Scout Loop — roda em background, observa, reporta/age (ex.: ci-scout, backlog-scout).

Como isso vive na Menos Juros — 2 loops aplicados

• Loop de issues — gatilho: ci-scout/comitê, ou humano criando issue direto sem projeto. Comitê de agentes + Engenharia Regenerativa, já roda em produção. Ver engenharia-regenerativa.
• Loop de novos projetos — gatilho: to-project (quem cria o projeto no Linear). Iniciativa grande, planejamento com o humano junto. Ainda em construção (documentado abaixo).

Loop de novos projetos — o to-project

⚠️ Em construção — majoritariamente manual/interativo, sendo montado peça por peça.

É o irmão do loop de issues: onde aquele cobre "achado/ideia → issue analisada em Deep Search", este cobre "iniciativa grande → issue pronta em To build" — planejamento feito com o humano junto. A partir de To build, os dois loops convergem no mesmo back-half: to-build (fan-out) → review → PR → pr-guardian.

O pipeline de skills

co-create / co-create-with-docs → to-prd → visual-plan → to-issues → to-build (dispara test-writer) → review → PR

• co-create/co-create-with-docs — co-criam/lapidam a ideia (incl. UX/UI), entrevista implacável; não produzem artefato de trabalho, só clareza.
• to-prd — sintetiza a conversa num PRD (exige issue-âncora, publica como documento no Linear); ao terminar, sempre chama o visual-plan.
• to-issues — fatia o PRD em issues verticais independentes (exige issue-pai).
• to-build — orquestrador de implementação: fan-out front/back paralelo, dispara o agente test-writer em paralelo (nunca em sequência), reporta andamento no Linear subtask a subtask (In Plan → In Progress → In Test/Review → Done; pai → To Check ao abrir o PR). Slice de UI segue o design system do código.
• review — portão de qualidade final: dois subagentes paralelos, Standards (padrão do repo) e Spec (entrega o que a issue pedia).
• to-project — orquestra co-create → to-prd (→ visual-plan) → to-issues e cria um projeto no Linear com as issues dentro; issues nascem direto em To build (não passam por Deep Search — a revisão foi o humano, ao vivo). Atalho: ticket já pequeno pula o to-project inteiro.

Ferramentas de apoio (não são etapas)

graphify (ver codebase-grafo), codebase, o design system do código (ver impeccable), linear, handoff, visual-plan, mem0, improve-codebase-architecture, domain-modeling, ddd, codebase-design — todas dão suporte em qualquer ponto do ciclo, sem serem etapas obrigatórias.

As duas lanes — engenharia × design (gate de UI)

Atravessando os dois loops, um segundo eixo: nem toda feature tem tela.

• Lane de engenharia (sempre roda): co-create → to-prd → to-issues → to-build → PR → pr-guardian → merge → prod-guardian.
• Lane de design (só se tem tela): ancora no DESIGN.md → rascunho opcional (Claude Design) → impeccable critique/audit → mantém o DESIGN.md. Ver impeccable.

Regras: (1) gate checado em cada junção, default = pular design; (2) dois sinais independentes — no planejamento é declarativo (o PRD tem seção UX/UI?), no guardian é observável (o diff toca apps/*/client/**?); (3) cada lane tem dono, artefato e disparo próprios. Feature sem UI = zero imposto de design.

Workflow (hoje) → Loop (em construção)

O fluxo de dev roda hoje como workflow (um humano dispara e conduz nos pontos-chave), não como loop (auto-disparado, que se realimenta sozinho). Falta: um driver autônomo que pegue qualquer issue de To build sozinho; frontend-builder/backend-builder como agentes dedicados; um design-scout que feche o lado de design; e decidir quais gates automatizar conforme a confiança sobe. Promove-se por confiança, não por volume — os gates humanos (merge, negar cliente, enviar em massa) só saem quando justifica, e o que não tem Ctrl+Z sai por último.

Relacionado

engenharia-regenerativa · comite-de-agentes · skills · impeccable · codebase-grafo · visao-geral