Career Development

Loop Engineering - for thought in chain(prompts)

28 de junho de 2026  ·  #prompts #ia #AI Agents #vibe-coding #loop
Loop Engineering - for thought in chain(prompts)

Vamos iniciar um novo ciclo? Vem fazer um brainstorm seguido de writing-plans, daí no fim me diz se você aceita implementar essa ideia.

A habilidade que parecia ser a mais cobiçada do futuro, escrever prompts, está sendo substituída por escrever loops.

Passei boa parte do começo de 2026 aprimorando minha "arte de escrever prompts". Tinha meus templates, minhas frases mágicas, minha ordem certa de colocar contexto. Quando a IA fazia besteira, eu reescrevia o prompt e me sentia um maestro. Demorei pra perceber que eu era só um operário apertando um botão mais rápido que os outros. O botão continuava sendo apertado por mim, uma vez de cada vez.

Semana passada trombei com um post do Addy Osmani (sim, aquele do Google Chrome, o cara que escreveu metade do que você sabe sobre performance web) chamado Loop Engineering. Ele colocou um deathlock na minha cabeça com uma frase:

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

Em bom português: Você desenha o sistema que faz o prompt. Peguei o argumento do Addy, mergulhei em três frentes de pesquisa (a origem do conceito, as ferramentas que já existem, e a parte prática de como amarrar isso no GitHub) e o que volto com esse texto é uma versão comentada da ideia, com alguns exemplos de caminhos que você pode seguir.

Se você ainda abre o Claude Code ou o Codex e fica lá, conversando turno a turno, lendo cada resposta e digitando a próxima: esse texto é pra você. Porque essa parte está acabando.

A frase que dois caras importantes disseram quase igual

O que me convenceu que isso não é hype de LinkedIn foi ver duas pessoas que constroem essas ferramentas dizerem a mesma coisa, com palavras quase idênticas.

Peter Steinberger, que viveu de construir ferramenta de dev a vida inteira, disse: "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

E Boris Cherny, que é o head do Claude Code dentro da Anthropic (ou seja, a pessoa que literalmente desenha a ferramenta), foi ainda mais direto: "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

Quando o cara que faz a ferramenta diz que parou de usar a ferramenta do jeito que ela foi vendida, vale a pena prestar atenção.

O que é um loop, sem a mística

Tira a palavra bonita e olha o que tem embaixo. Um loop é um objetivo recursivo: você define um propósito e deixa a IA iterar até completar. Observa, age, verifica, repete. É um while com cérebro.

E aqui mora o paradoxo mais engraçado dessa história. A forma mais pura de loop de agente que existe foi batizada com o nome do personagem mais burro dos Simpsons.

Geoffrey Huntley popularizou o que ele chama de Ralph, uma homenagem ao Ralph Wiggum. Na sua forma mais crua, Ralph é isto, e nada além disto:

# A coisa toda. Sério, é isso.
while :; do cat PROMPT.md | claude-code ; done

Lê o arquivo de prompt, joga no agente, deixa ele trabalhar, e quando termina... lê de novo, joga de novo, pra sempre. O Huntley resume a alma da técnica com uma frase:

"That's the beauty of Ralph — the technique is deterministically bad in an undeterministic world."

A beleza do Ralph é ser deterministicamente ruim num mundo não-determinístico. Ele erra de um jeito previsível. E coisa previsível você conserta com prompt. O Huntley usou exatamente isso pra construir uma linguagem de programação inteira, nova, que nem estava no dataset de treino do modelo. Num hackathon do Y Combinator, alguém pôs um agente num while loop e shipou 6 repositórios numa noite.

Quando li o Ralph pela primeira vez meu instinto foi rir e fechar a aba. "Isso é gambiarra, não é engenharia." Aí parei. O for que você escreveu hoje de manhã também é, no fundo, uma gambiarra deterministicamente burra: ele não pensa, só repete. O que faz ele ser útil é a condição de parada e o que tem dentro. O Ralph é igual. A pergunta não é "isso é sério?". A pergunta é "o que eu coloco dentro do loop e quando ele para?".

As cinco peças (e a memória que segura tudo)

O Addy decompõe um loop maduro em cinco primitivas, e o detalhe lindo é que elas pararam de ser script de bash que você mantém sozinho pra sempre. Hoje vêm de fábrica dentro do Codex e do Claude Code:

  1. Automations: o batimento cardíaco. Tarefas que disparam num cron e fazem descoberta e triagem sozinhas. É o que transforma "uma vez que rodei" em "loop de verdade".
  2. Worktrees: pra dois agentes em paralelo não escreverem no mesmo arquivo e virar um briga de merge. Cada um no seu git worktree, na sua branch, sem se tocar.
  3. Skills: receitas em markdown (SKILL.md) que gravam o conhecimento do projeto. Sem elas, o agente re-deduz seu projeto inteiro do zero toda sessão, igual peixinho dourado.
  4. Plugins e connectors (MCP): plugam o agente nas ferramentas que você já usa de verdade: o issue tracker, o banco, o staging, o Slack.
  5. Sub-agents: um tem a ideia, outro confere. Separa quem escreve de quem avalia.

E a sexta coisa, que não é primitiva mas segura todas: a memória. Um arquivo markdown, um board no Linear, qualquer coisa que viva fora da conversa e guarde o que foi feito e o que falta. Parece simples demais pra importar. Mas o Addy crava a frase: o agente esquece, o repositório não. O modelo zera o contexto entre as rodadas, então a memória tem que estar no disco, não na cabeça dele.

O pulo do gato: in the loop, on the loop

Aqui é onde a coisa sai do "deixa rodar e reza" e vira engenharia. E quem desenhou esse mapa com mais clareza foi o Kief Morris, num artigo publicado no site do Martin Fowler chamado Humans and Agents in Software Engineering Loops. Se você for ler uma fonte só dessa lista, leia essa.

Ele separa dois laços. O why loop (o porquê) itera sobre a ideia e o software que entrega valor, e esse é nosso, humano, porque somos nós que queremos a coisa. E o how loop (o como) itera sobre os artefatos do meio: código, testes, ferramenta, infra. O how loop é o que dá pra entregar pro agente.

A partir daí ele desenha três posturas, e a diferença entre elas é tudo:

Humano fora do loop. Você só cuida do porquê e larga o como inteiro pro agente. É o vibe coding clássico. Funciona pra protótipo, desanda em produção.

Humano dentro do loop (in the loop). Você é o porteiro do laço mais interno, inspecionando cada linha que o agente gera. Parece responsável, mas você vira o gargalo: o agente gera código mais rápido do que qualquer humano revisa. É por isso que metade dos estudos de produtividade com IA dá empate. A galera gasta revisando o que economizou gerando. Eu mesmo caí nessa e medi meu próprio caso aqui no blog.

Humano em cima do loop (on the loop). Essa é a virada de chave. Em vez de inspecionar o que o agente produz, você melhora a máquina que produz. Quando não gostou do resultado, você não corrige o artefato, você corrige o harness (a ferramenta que orquestra o agente) que gerou aquele artefato, pra ele parar de gerar errado. O Kief amarra isso direto na ideia de Harness Engineering, que é prima do loop engineering. Já falei dele naquele post sobre harnesses serem os novos web frameworks.

A frase que fecha: a diferença entre estar in e estar on o loop aparece no que você faz quando não gosta do resultado. Dentro do loop, você conserta o artefato. Em cima do loop, você conserta o que produziu o artefato.

O nível final: o flywheel

E tem um terceiro andar, que o Kief chama de agentic flywheel (o volante de inércia agêntico, aquela roda pesada que, depois de girar, mantém o movimento sozinha). É quando você direciona o agente pra melhorar o próprio harness, em vez de fazer isso na mão. Você dá pra ele os sinais que medem o quão bem o loop está indo (os testes, as métricas do pipeline, os dados de produção) e pede que ele recomende melhorias no próprio processo que o governa.

Começa interativo: o agente sugere, você aprova. Depois ele vai botando as recomendações no backlog com uma nota de risco e benefício. E num ponto, as de baixo risco se auto-aprovam. O que você tem aí é um harness que gera recomendações pra melhorar a si mesmo. O Kief é honesto: lá na frente isso vai se parecer de novo com vibe coding, humano fora do loop. Mas a diferença é que agora a máquina por baixo é robusta, porque você passou esse tempo todo afiando ela em vez de só consumir o resultado.

E o que segura o agente honesto? O quality gate.

Chega na parte que eu mais queria escrever, porque é a que faz toda a diferença entre um brinquedo e uma ferramenta de produção.

Se o agente roda em loop sozinho, quem decide que ele terminou? Se a resposta for "ele mesmo", você tem um problema. É a velha história da raposa cuidando do galinheiro. Um agente perguntado "você terminou?" vai responder "sim" com uma confiança que daria inveja a qualquer júnior.

A sacada do loop engineering bem feito é tirar essa decisão das mãos do agente. O Addy descreve dois comandos que ilustram isso: o /loop, que só re-roda numa cadência, e o /goal, que roda até uma condição verificável ser verdade, e depois de cada turno um modelo separado confere se acabou. O agente que escreveu o código não é o que dá a nota. Você diz algo como "todos os testes em test/auth passam e o lint está limpo" e vai dormir.

É exatamente o mesmo princípio do shift left (deslocar pra esquerda, ou seja, testar mais cedo no processo em vez de no fim) que a gente aprendeu na marra: em vez de jogar o código pra um QA testar lá no final, o agente verifica a qualidade do próprio trabalho enquanto trabalha. Só que com um verificador que ele não controla. Esse é o coração de tudo.

No mundo do GitHub, esse verificador tem nome: quality gate (portão de qualidade, em bom português: uma checagem automática que só deixa o código passar se atender a critérios objetivos). E a arquitetura do loop fica assim:

Issue (a spec)
   │
   ▼
Agente lê a issue + o repo
   │
   ▼
Cria branch, commita, abre Pull Request
   │
   ▼
CI roda os QUALITY GATES  ◀──────────┐
   │                                  │
   ├── tudo verde ──▶ merge           │
   │                                  │
   └── falhou ──▶ agente lê o log ────┘
                  do check e corrige

A peça que transforma isso em engenharia: a fonte da verdade sobre "está pronto?" não é o agente — é o status check do GitHub (o resultado verde ou vermelho que o CI, a integração contínua que roda seus testes a cada push, carimba no PR), que ele não controla. A issue é a especificação. O resultado do check é o sensor. A branch protection (proteção de branch, as regras que travam o merge até os checks passarem) é o trinco que impede o atuador de mentir pra si mesmo.

Montando o gate na prática

Primeiro, você fecha a porta. Branch protection na main exigindo que os checks passem antes de qualquer merge:

# Exige checks verdes + 1 review + dono do código, sem bypass nem pra admin
gh api --method PUT /repos/OWNER/REPO/branches/main/protection \
  -F "required_status_checks[strict]=true" \
  -F "required_status_checks[checks][][context]=test" \
  -F "required_status_checks[checks][][context]=lint" \
  -F "required_status_checks[checks][][context]=coverage" \
  -F "enforce_admins=true" \
  -F "required_pull_request_reviews[required_approving_review_count]=1" \
  -F "required_pull_request_reviews[require_code_owner_reviews]=true"
# strict=true: a branch precisa estar atualizada com a base antes de mesclar.
# cada "context" é o nome exato do job no seu workflow — tem que bater certinho.

Aí você escolhe os gates que servem de critério de parada do loop. A regra de ouro: o gate tem que ser binário, determinístico e barato de avaliar. E você ordena do mais barato pro mais caro, porque falhar cedo economiza token (o loop nem chega no teste lento se não compilou):

go build ./...          # compilou? Se não, nada mais importa.
gofmt -l . && go vet ./...   # formatação e armadilhas óbvias
golangci-lint run       # o lixo que o agente deixa pra trás
go test ./...           # o coração: comportamento verificável
go test -coverprofile   # coverage com piso mínimo
gosec ./... && govulncheck ./...  # segurança: secret, injeção, CVE

Repara no coverage com piso. Essa não é firula. Num loop autônomo, o atalho que o agente cedo ou tarde descobre pra "fazer os testes passarem" é apagar ou pular o teste que incomoda. O coverage gate com um piso fecha esse buraco. É o que o pessoal chama de reward hacking (hackear a recompensa). O agente otimiza a métrica, não o objetivo. Igual aquele estagiário que descobre que "fechar o ticket" conta como meta e começa a fechar ticket sem resolver.

O passo que fecha o ciclo: ler a falha

Quando o gate fica vermelho, o agente precisa ler o que quebrou, e só o que quebrou, não o log inteiro:

gh pr checks <PR>                    # o que está vermelho?
gh run view <run-id> --log-failed    # SÓ os steps que falharam → alimenta o agente
gh run rerun <run-id> --failed       # re-roda só o que falhou, depois do conserto

O --log-failed é o pulo do gato aqui. Ele entrega pro agente o stack trace exato do que falhou, sem enterrá-lo em dez mil linhas de log verde. Menos contexto, menos token, correção mais certeira.

Quem já faz isso de verdade

Não é teoria de Substack. Tem ferramenta de gente grande implementando exatamente esse ciclo:

  • O GitHub Copilot coding agent é o exemplo canônico: você atribui uma issue a ele, ele cria branch, abre PR em draft, roda no Actions e itera nos próprios checks de CI até passar. E respeita branch protection: ele não pode aprovar o próprio PR.
  • O OpenHands (open source) dispara o agente quando você põe o label fix-me numa issue. Ele resolve, abre PR, e re-itera quando você comenta no review.
  • O SWE-agent de Princeton pega uma issue do GitHub e tenta resolver sozinho, foi ele que praticamente inventou o benchmark de "agente resolve issue real".
  • O Aider roda testes e lint e se auto-corrige em loop no seu terminal.
  • A Claude Code GitHub Action deixa você marcar @claude numa issue ou PR e o agente trabalha dentro do CI.

Pega o seu caso: você não precisa de nenhum produto desses pra começar. Um cron que pega issues com um label específico, manda pro seu agente favorito, e um workflow de Actions com seus testes como required check, e você já tem um loop engineering rodando. O resto é lapidar.

Quando dar um passo atrás

Essa tese não é bala de prata, e quem te vende ela como bala de prata está vendendo curso.

Não bote em loop o que não tem gate. Se seu projeto não tem teste, lint nem CI, loop engineering não vai te salvar, vai só gerar lixo mais rápido. O loop é tão bom quanto o gate que o segura. Sem teste, o agente está "voando às cegas e dizendo que pousou".

Cuidado com o teto humano. O Kief chama isso de orchestration tax, a taxa de orquestração. As worktrees tiram a colisão mecânica, mas a sua banda de revisão ainda é o limite. Não adianta rodar dez agentes em paralelo se você só consegue revisar três PRs por dia. Você continua sendo o gargalo, só que num andar mais alto.

Os perigos são reais. Loop infinito que queima token sem nunca ficar verde (resolve com cap de iterações e um circuit breaker que escala pra humano via label needs-human). Teste flaky que faz o agente "consertar" código que estava certo (põe o flaky de molho antes de meter no loop). E o custo: cada iteração roda o CI inteiro mais a chamada do modelo. Falha-cedo, cache de dependência e paths-filter pra rodar só o que mudou não são luxo, são sobrevivência financeira.

E o maior de todos: não deixe o agente editar o próprio gate. Proteja com CODEOWNERS (o arquivo que define qual pessoa ou time é dona obrigatória de cada parte do código) os arquivos de teste e a config do CI. Se o agente pode mexer no workflow que o julga, ele vai descobrir que baixar a régua é mais fácil que pular mais alto. Coloque o *_test.go e o .github/workflows/ atrás de um dono humano.

Fechando

A habilidade que importa mudou de lugar de novo, e mais rápido do que da última vez. Por dois anos a pergunta foi "como eu escrevo um prompt melhor?". A pergunta agora é "como eu desenho o laço que escreve o prompt por mim, e como eu garanto que ele não está se enganando?".

O Ralph do Geoffrey Huntley mostra que a mecânica é boba: é um while. O Addy Osmani mostra as peças que vão dentro. E o Kief Morris, no artigo do Martin Fowler, mostra onde você, humano, deve ficar: nem dentro micro-gerenciando, nem fora rezando, mas em cima, construindo e afiando a máquina. O quality gate é o que mantém a coisa honesta. A issue é o pedido, o check verde é a prova, e você é o engenheiro que projetou os dois.

Recomendo de coração ler os três originais. Os links estão logo abaixo, e cada um foi mais fundo num pedaço do que eu consegui cobrir aqui. O que eu fiz foi traduzir a ideia central, juntar as três pontas e jogar minha experiência por cima.

E você? Já deixou um agente rodando em loop num projeto seu? Qual foi seu critério de parada? Você confiou no agente pra dizer "terminei", ou amarrou num gate de verdade? E o mais importante: ele já tentou te enganar baixando a régua? Me conta nos comentários, esse causo eu quero ouvir.

Fontes