Engenharia de Loop - Do Prompting ao Loop

Decidi dedicar este artigo a como criar seu próprio agente programável que fará o trabalho para você, para que você não precise ligar o computador todas as manhãs e dar comandos repetidamente.

Ele vai acordar sozinho, encontrar tarefas sozinho, identificar problemas sozinho e salvar e apresentar os resultados na sua mesa para você revisar.

Prefácio

A ideia do Loop não surgiu do nada - durante uma única semana em junho de 2026, três especialistas do setor expressaram quase simultaneamente o mesmo pensamento: era hora de começar a desenvolver esse nível.

Uma semana depois, Andrew Ng contextualizou essa conversa dentro do quadro mais amplo de "Construindo Produtos do 0 ao 1", fornecendo uma visão mais abrangente.

Este artigo começa com essa história e, em seguida, guia você na construção de um loop mínimo, mas completo, do zero: 5 movimentos, 6 partes, uma porta que diz "não" e uma porta humana - tudo rodando na sua própria máquina e reutilizável em qualquer projeto de software.

Fonte: HuaShu Orange Book, Loop Engineering: Pare de Me Perguntar o Que É (v260615, junho de 2026)

A semana em que 3 pessoas acenderam o pavio

Junho de 2026: três pessoas, sem nenhuma coordenação entre si, disseram quase a mesma coisa com dias de diferença.

Peter Steinberger, criador do OpenClaw, postou duas frases no X que atingiram 8,9 milhões de visualizações:

https://x.com/steipete/status/2063697162748260627

Foi aí que a discussão realmente começou. Não foi um manifesto ou um longo ensaio, apenas duas linhas que nomearam algo que as pessoas já estavam fazendo silenciosamente.

Boris Cherny: Eu não dou mais prompts para o Claude, eu tenho loops que estão rodando. São eles que estão dando prompts para o Claude e descobrindo o que fazer.

Addy Osmani: A engenharia de loops é substituir a si mesmo como a pessoa que dá o prompt para o agente. Você projeta o sistema que faz isso.

A prática veio antes do nome por meses, todo mundo já estava escrevendo loops, ninguém tinha dado um nome ainda.

Então, loops são agora uma parte fundamental de como permitimos que agentes de IA trabalhem iterativamente a longo prazo para criar software.

Andrew Ng organizou os três loops do mais interno para o mais externo com base em suas escalas de tempo: o loop mais interno é o mais rápido, e o loop mais externo é o mais lento. Além disso, a entrada do loop mais externo vem da saída do loop mais interno:

Loop

Quem executa

Duração do ciclo

O que produz para a camada externa

Loop de codificação do agente

o próprio agente

segundos - minutos

uma versão que executa

Loop de feedback do desenvolvedor

humano + agente

dezenas de minutos - horas

uma visão e especificação de produto mais claras

Loop de feedback externo

usuários + equipe

horas - semanas

dados reais que evoluem a visão

Andrew Ng nos deu o mapa por tempo: três loops rodando em velocidades diferentes. Addy Osmani desenhou um segundo mapa por abstração: prompt -> contexto -> harness -> loop.

A engenharia de loops fica no topo e adiciona três verbos que o harness não tem. Ela roda em um temporizador, gera ajudantes e se alimenta - a saída de hoje se torna a entrada de amanhã. Esse último é o que a torna um loop, não a mesma tarefa executada N vezes.

A intuição mais importante: o mesmo bug custa um valor diferente em cada camada:

Camada

Com o que se importa

Pergunta central

Eng. de prompt

escrever um prompt

o que dizer ao modelo

Eng. de contexto

o que está carregado na janela

o que puxar, resumir, limpar

Eng. de harness

armar uma única execução

quais ferramentas, quais ações, o que conta como concluído

Eng. de loop

agendamento sobre o harness

como fazê-lo rodar sozinho, rodada após rodada

Um loop é, por design, uma máquina que torna o "número de rodadas" grande. Cada decisão daqui em diante - avaliador, porta humana, limite de tokens, arquivo de estado - existe para encurtar a distância entre "o erro acontece" e "alguém o vê".

O que acontece dentro de uma rodada:

"Loop" é mal interpretado como "girar no lugar". Não é, cada rodada tem 5 movimentos concretos. Corte qualquer um e o loop ou não roda - ou roda sem ir a lugar nenhum.

1. Verificação é o movimento que diz "não."
2. Agendamento é o movimento que alimenta esta rodada na próxima.

Essa é exatamente a parte que o torna um loop.

Mapeado para o projeto que vamos construir: um loop de triagem matinal para uma pequena equipe:

Ação

O que faz

No LOOP DE TRIAGEM

Descoberta

descobrir o que esta rodada deve fazer

uma skill lê CI / issues / commits recentes

Transferência

despachar a tarefa e isolá-la

cada descoberta ganha sua própria worktree

Verificação

trocar para outro agente dizer não

um segundo subagente como revisor, testando e verificando skills

Persistência

escrever o estado fora da conversa

PR + ticket Linear + ./state/triage.md

Agendamento

deixar rodar rodada após rodada

Gatilho cron do GitHub Actions às 06:00

Cada uma das 5 lições abaixo desenvolve exatamente um movimento.

Cinco lições = um Loop completo.

E começamos com o primeiro: Descoberta, porque se o Loop não consegue decidir o que vale a pena fazer hoje, nada depois disso importa.

Lição 1 Descoberta: escreva uma SKILL.md de triagem matinal

Skills, não uma parede de prompt.

Imagine, é segunda-feira, 6h da manhã. Seu laptop está fechado e o GitHub Action acorda e dispara claude --skill morning-triage: o que ele lê, o que ele julga como acionável, onde ele escreve os resultados - tudo isso vive dentro do SKILL.md que você está prestes a escrever.

A frase-chave de Osmani: a automação deve acionar uma skill - conhecimento do projeto escrito e atualizável, não uma parede de prompt colada em um cron job. O prompt colado simplesmente apodrece lá, porque ninguém nunca volta para atualizar algo enterrado dentro de um agendamento.

Sua tarefa para esta lição: escreva uma skill em .claude/skills/morning-triage/SKILL.md que leia três fontes (CI / issues / commits) por conta própria, decida o que vale a pena fazer por conta própria, escreva os resultados em ./state/triage.md - e tenha uma seção Stop explícita que detalhe o que o loop NÃO pode fazer.

Aqui está o modelo - mude três coisas e é seu:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: invoked by daily automation
5---
6
7## Read   (entradas de descoberta — troque pelas fontes que SEU repositório realmente tem)
8- Execuções de CI que falharam desde a última execução      # gh run list --status failure
9- issues abertas nas últimas 24h               # gh issue list --search "created:>=…"
10- commits mesclados desde ontem              # git log --since=yesterday
11- o ./state/triage.md anterior              # a transferência "ontem → hoje"
12
13## Judge  (o teto — deixe o loop escolher, não entregue uma lista)
14Para cada candidato, decida:
15- é acionável AGORA, ou é ruído?
16- bloqueia um lançamento? → prioridade = P0
17- já está sendo rastreado? → pule
18Mantenha apenas o que vale uma worktree HOJE.
19
20## Write  (persistência — registre em markdown, não no chat)
21Acrescente a ./state/triage.md:
22| descoberta | fonte | prioridade | status |
23Faça commit do arquivo para que amanhã possa lê-lo.
24
25## Handoff  (preparação para a Lição 2)
26Para cada descoberta mantida, emita uma linha de tarefa:
27  worktree=fix/<slug>
28  goal=<condição-de-parada>
29
30## Stop   (a ÚNICA seção não padronizada — pense bem aqui)
31Nunca mesclar. Nunca deletar.
32Qualquer coisa sobre a qual você não esteja confiante → ./inbox/ para um humano.
33NÃO é um PR.

Três seções fazem o trabalho pesado aqui:

Read: esta é a entrada da Descoberta - liste fontes concretas, até o comando real. Lembre-se, "leia o contexto" não é uma fonte, mas gh run list --status failure é uma fonte.

Judge: este é o teto de todo o seu loop. O loop decide "acionável vs ruído" por si só - ele não recebe uma lista sua, porque se você ainda está entregando uma lista todas as manhãs, você automatizou o fazer, mas não o escolher. E escolher geralmente é a etapa mais cara. Não importa o quão boas sejam suas fontes, se esta seção pegar lixo, os outros quatro movimentos estão girando em trabalho inútil.

Stop: a única parte deste arquivo que não é padronizada. O loop fará tudo o que a skill diz, e apenas o que a skill diz. Se você não escrever "nunca mesclar" - um dia ele vai mesclar para você.

Detalhe as linhas vermelhas: nunca mesclar, nunca deletar, nunca fazer push para main, qualquer coisa incerta vai para ./inbox/ para um humano, não para um PR.

Mais uma coisa que vale a pena saber: esta mesma estrutura de skill funciona além da triagem matinal: troque a seção Read por "logs de acesso de ontem + novas issues + versão atual do deploy" e ela se torna um loop de saúde do site noturno. Adicione uma linha ao Judge - "isso é uma regressão de ontem?" - e ela ganha comparação entre dias.

A doença que esta lição previne - Loop Cego:

O mais comum "parece um loop, mas não é.": o loop roda, mas você ainda está atribuindo o trabalho todas as manhãs ("ei, olhe para esses três bugs"). Isso é automação da execução, não automação da descoberta.

Sintoma: o loop nunca te surpreende, porque só faz o que você já sabia que precisava ser feito.

Correção: coloque Judge dentro da skill e deixe-a escolher o trabalho de hoje por si só.

Antes de prosseguir, responda a estas três:

1/ Quantas linhas sua seção Stop tem?

Se for apenas "nunca mesclar" - adicione mais uma: o que mais este loop nunca deve fazer por você? (nunca fechar issues / nunca fazer push para main / nunca pegar mais de 3 descobertas de uma vez...)

2/ Reescreva a primeira linha de Read em um comando que realmente rode em SEU projeto

**3/ Se esta skill ficar inalterada por um ano - o que acontece?

**Agora compare: o que acontece com uma parede de prompt colada em um cron job por um ano?

Lição 2 Transferência: distribua o trabalho e isole-o

A skill da Lição 1 acabou de rodar. ./state/triage.md agora contém 5 descobertas acionáveis. O pensamento mais natural - dispare 5 agentes de uma vez, vá rápido. Esse passo exato é como você cria um Loop Emaranhado: vários agentes editando os mesmos arquivos no mesmo diretório, e o dia da mesclagem se transforma em arqueologia.

O antídoto é uma linha: cada descoberta ganha sua própria worktree.

git worktree é um mecanismo git embutido: um repositório, múltiplos diretórios de trabalho independentes, cada um verificado em seu próprio branch. git worktree add ../fix-auth fix/auth abre um workspace totalmente isolado em ../fix-auth. Builds, edições, testes - nada toca em ninguém. Uma worktree por descoberta = agentes fisicamente separados.

Sua tarefa para esta lição: escreva um script que leia cada descoberta de ./state/triage.md, abra uma worktree isolada por descoberta (nomeada fix/<slug>), envie um agente para redigir uma correção dentro dela - e defina um limite paralelo para que não gere infinitamente.

1# read state/triage.md, one worktree per finding
2# change: MAX_PARALLEL to what your machine / bill can handle
3MAX_PARALLEL=3
4
5# change: parsing to match your actual triage.md columns
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # the key line: physical isolation per agent
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # change: goal is the stop condition Lesson 3's evaluator will read
16  claude --worktree ../wt-$slug \
17    --goal "tests in tests/$slug pass and lint is clean" \
18    "draft a fix for: $finding" &
19done
20
21wait   # let all parallel agents finish
22
23# closing rule: agents never auto-merge — worktrees wait
24# for the human gate in Lesson 5
25echo "All worktrees ready for review:"
26git worktree list

As regras que importam aqui: nunca trabalhe em main.

Main é a pista de pouso para revisão humana - não a mesa dos agentes. Todos os agentes vivem em worktrees fix/*.

Limite o paralelismo: a geração ilimitada é a porta de entrada para um estouro de tokens (a Lição 5 volta a isso). Escolha MAX_PARALLEL com base em uma pergunta honesta: não "quantos minha máquina pode rodar", mas "quantos PRs eu posso realmente revisar".

Mesclagem é uma decisão humana: a Stripe roda mais de 1.000 PRs por semana através de loops como este, e humanos ainda revisam cada um. O humano não saiu do processo - eles mudaram de mesa: de escrever código para revisar código.

E um detalhe do caso da Stripe que vale a pena roubar: eles usaram, contra-intuitivamente, um modelo menor com portas determinísticas estritas em vez do maior modelo disponível.

A lição: uma porta de verificação apertada supera o poder bruto do modelo para trabalho em loop.

A doença que esta lição previne - Loop Emaranhado:

Um loop de agente único parece perfeitamente saudável. O problema só aparece no dia em que você vai para o paralelo - cinco agentes rodam, cinco diffs colidem no mesmo arquivo, a mesclagem é um caos.

Correção: cada tarefa ganha sua própria worktree, nunca compartilhe um diretório de trabalho entre agentes.

Antes de prosseguir, responda a estas três:

**1/ Qual número você definiu para MAX_PARALLEL e por quê?

**(dinheiro? máquina? ou "quantos PRs posso honestamente revisar"?)

**2/ Se uma worktree falhar - o agente sair sem tocar em nada

**o que o arquivo de estado de amanhã deve registrar sobre isso?

**3/ A Stripe usou um modelo menor + portas determinísticas estritas

**Em vez do maior modelo, o que essa escolha significa para SEU loop?

Lição 3 Verificação: instale uma porta que diz "não" (a lição mais pesada)

Este é o movimento mais difícil na engenharia de loops, e merece mais esforço do que qualquer outra lição.

O engenheiro da Anthropic, Prithvi Rajasekaran, trabalhando em aplicações de agentes de longa duração, notou algo: peça a um agente para avaliar o código que acabou de escrever, e ele quase sempre se elogiará - mesmo quando um humano pode ver à primeira vista que é medíocre.

Isso não é o modelo sendo burro: avaliar seu próprio trabalho é estruturalmente quebrado. Quando o código é concluído, o contexto do agente está repleto da cadeia de autojustificativa de por que ele escreveu as coisas dessa forma. Olhando para sua própria saída, ele não vê o resultado - ele vê o argumento para o resultado.

Coloque isso dentro de um loop e amplifica-se em um desastre: a cada rodada, "isso é bom o suficiente?" é respondido pelo agente que acabou de escrever. Cada rodada concorda consigo mesma. Quanto mais tempo roda, mais se afasta da qualidade real. Esse é o Loop da Concordância - e é a doença mais cara da lista.

A correção de Rajasekaran, em suas próprias palavras:

"Ajustar um avaliador independente para ser cético é muito mais tratável do que fazer um gerador ser crítico de seu próprio trabalho."

Isso é um problema estrutural, não um problema de redação. Você não pode pedir a um autor para sair da própria cabeça, mas você pode trazer um agente diferente, com instruções completamente diferentes, olhando para o código do zero - sem nenhuma cadeia de autojustificativa anexada.

A analogia vem das GANs: uma rede constrói, outra ataca: criador e verificador. A mesma velha regra bancária: a pessoa que transfere o dinheiro e a pessoa que o aprova devem ser pessoas diferentes.

Sua tarefa para esta lição - escreva duas coisas:

1) Um prompt de sistema avaliador em .claude/agents/reviewer.md com cinco seções: ROLE + ASSUME + CHECK + USE + VERDICT.

2) Um comando /goal declarando a condição de parada deste loop - julgada por um modelo novo separado, não pelo gerador.

1# .claude/agents/reviewer.md  (mude 3 coisas)
2ROLE: Revisor de código adversarial.
3ASSUME: este código está QUEBRADO até prova em contrário.
4NÃO elogie. Encontre o que falha.
5
6# change: order CHECK by your project's real failure modes,
7# runnable checks first
8CHECK, em ordem:
9  1. Roda? (execute, não leia)
10  2. Testes: execute-os, cole a saída real.
11  3. Casos de borda que o autor pulou.
12  4. O comportamento corresponde ao ticket?
13
14# change: which MCP depends on what you're testing —
15# frontend → Playwright, API → curl/httpie
16USE Playwright MCP: abra a página, clique,
17faça captura de tela, inspecione o DOM.
18Julgue o comportamento, não a intenção.
19
20VERDICT: PASS apenas se cada verificação for válida.
21         Caso contrário, REJECT + liste cada motivo.

1# stop condition — judged by a fresh small model, NOT the generator
2# change: swap for the real verifiable condition of your finding
3/goal all tests in test/auth pass and the lint step is clean
4
5# careful: /goal and /loop are NOT the same thing
6#   /loop = rerun on interval (no stop judgment — dangerous)
7#   /goal = run until a fresh model judges the condition true

Dois agentes, idealmente dois modelos: "mesmo modelo, prompt diferente" muitas vezes preserva os mesmos pontos cegos. Troque o modelo também, se puder.

Ceticismo padrão: a linha de base do avaliador é ASSUMIR QUEBRADO - a confiança deve ser conquistada passando nas verificações, não concedida por padrão.

Julgue o comportamento, não a intenção: "este JSX parece bom" e "eu cliquei no botão, a página navegou, aqui está a captura de tela" são dois universos diferentes. O avaliador deve agir - executar os testes, clicar na página, não ler o código e sentir.

Rejeite com motivos: um REJECT sem motivos listados não é uma rejeição - o gerador não tem ideia do que corrigir.

E o teste decisivo: seu avaliador realmente rejeitou algo nas últimas 5+ rodadas? Um loop que nunca disse "não" em centenas de rodadas é estatisticamente impossível em qualquer carga de trabalho real. Portanto, prova que o avaliador não está funcionando.

A doença que esta lição previne - Loop da Concordância:

O loop roda, o agente escreve código, o mesmo agente diz "parece bom." Cada rodada se autoaprova, empilhando erros aparentemente plausíveis em velocidade de máquina. Correção: esta lição inteira: separação estrutural + ceticismo padrão + julgamento por ação + uma condição de parada de terceiros.

Antes de prosseguir, responda a estas três:

1/ Seu avaliador é o mesmo modelo com um prompt diferente, ou um modelo diferente? por quê?

2/ Traduza "julgue o comportamento, não a intenção" em uma

frase concreta do seu projeto: "meu avaliador não lê código, ele

executa _____, e só PASSA quando vê _____"

3/ Qual a probabilidade de um modelo novo "mais ou menos" aprovar falsamente sua condição /goal?

se seu modo de falha mais assustador for X - adicione uma verificação para X na condição de parada agora mesmo

Lição 4 Persistência: faça o trabalho de hoje sobreviver até amanhã

A Lição 3 terminou. Seu avaliador julgou três descobertas - duas PASS, uma REJECT. Pergunta: onde esses três veredictos vivem agora?

Se a resposta for "na janela de contexto" - então amanhã às 6h, o loop acorda com um contexto limpo e não se lembra de nada. Ele faz uma nova triagem do zero, tropeça no REJECT não corrigido de ontem, talvez atribua outro agente para corrigi-lo novamente, talvez o perca completamente, talvez caia no mesmo buraco.

Esse é o Loop Amnésico - todos os dias começam do mesmo lugar.

O antídoto em uma linha: a memória é o estado escrito em disco, não o contexto. Um arquivo markdown, um quadro Linear, um banco de dados - uma vez escrito, não importa o quão completamente o agente esqueça.

Esses dois são constantemente confundidos, então fixe a diferença:

CONTEXTO = a janela que o agente vê NESTA rodada -> limpa a cada atualização.

MEMÓRIA = o estado que vive entre rodadas e dias -> escrito em disco (markdown / BD / quadro).

Um loop faz a ponte entre hoje -> amanhã através da MEMÓRIA apenas.

Sua tarefa para esta lição:

1. Crie ./state/triage.md com pelo menos 4 colunas (descoberta / fonte / prioridade / status) - a skill da Lição 1 escreve, as worktrees da Lição 2 leem.
2. Conecte um conector (MCP): um veredicto PASS abre um PR automaticamente, um REJECT atualiza o ticket automaticamente.
3. Verifique se o loop de amanhã pode realmente ler o estado de hoje.

1# ./state/triage.md  (a memória do loop — altere conforme necessário)
2
3| descoberta       | fonte         | prioridade | status     |
4|------------------|---------------|------------|------------|
5| teste auth instável | CI #4821     | P0         | corrigindo |
6| desreferência nula  | issue 92     | P1         | PR aberto  |
7| dependência obsoleta| commit a3f9c | P2         | inbox      |
8
9# estenda as colunas conforme necessário: ultima_vez, contagem_tentativas, atribuido_a
10# este arquivo DEVE ter commit no repositório —
11# caso contrário, o executor em nuvem de amanhã não pode vê-lo

1// .mcp/connectors.json — conecte o loop ao mundo exterior
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← DEVE ser false. porta humana = Lição 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Blocked", "reason": "${verdict.reasons}" }
15  }
16}

Por que cada coluna importa: sem fonte -> você não pode auditar de onde veio uma descoberta. sem prioridade -> você não pode ordenar o trabalho. sem status -> amanhã não pode pegar o bastão.

E a verificação para esta lição é a única que você não pode falsificar: espere até amanhã. Acorde, verifique - a inbox ainda está lá? As descobertas inacabadas ainda mantêm seu status? A execução das 6h pegou de onde ontem parou em vez de começar de novo? Isso você descobre executando, não raciocinando sobre.

Uma disciplina silenciosa que vem com a persistência - leia uma amostra, sempre.

Uma vez que a persistência funciona, uma armadilha se abre: o loop envia PRs em velocidade, você se sente produtivo - e seu mapa mental da base de código silenciosamente fica desatualizado. A regra: não leia tudo (isso derrota o propósito do loop), mas leia um PR de amostra por dia e force-se a explicar o que o loop mudou e por quê.

No momento em que você não consegue explicar - seu mapa ficou para trás. Corrigir isso em uma manhã calma custa dez minutos. Corrigir isso durante um incidente de produção custa muito mais.

A doença que esta lição previne - Loop Amnésico:

O loop encontra um bom trabalho, faz, depois esquece que fez - porque o resultado só viveu em um contexto limpo. Na próxima rodada, ele redescobre o mesmo trabalho, ou pior - refaz e sobrescreve a primeira tentativa.

Sintoma: nenhum progresso acumulado, todos os dias começam do mesmo lugar. Correção: arquivo de estado em disco.

Antes de prosseguir, responda a estas três:

1/ Traduza "memória ≠ contexto" em uma frase concreta

do seu próprio projeto: "meu _____ é memória, meu _____ é contexto"

2/ O loop de amanhã acorda - qual COLUNA do state.md ele

**lê primeiro para decidir seu primeiro movimento? você nomeou essa coluna corretamente, ou apenas enterrou uma mina terrestre para ele?

3/ Disciplina: a que horas do dia você lerá seu

**PR de amostra? defina o lembrete de calendário agora - este é um contrato consigo mesmo.

Lição 5 Agendamento: torne-o real, torne-o seguro, mantenha uma porta aberta

As Lições 1-4 estão instaladas, mas o loop ainda para no momento em que você para de apertar o botão. O movimento final é um verbo: pendure-o em um gatilho.

Mas a parte mais perigosa desta lição não é errar o cron. É acertar o cron certo - porque então o loop realmente roda sozinho, e um bug pode fazê-lo girar a noite toda, ajudantes gerando ajudantes, até você acordar com uma conta que não reconhece.

Então, esta lição na verdade faz três coisas: pendure o gatilho, defina os limites, mantenha uma porta humana.

Primeiro - escolha seu agendador:

1Nuvem (GH Actions)   Desktop agendado   /loop (no CC)
2onde roda          nuvem                sua máquina        sua máquina
3máquina ligada?    não necessário       necessário         necessário
4sessão aberta?     não necessário       não necessário     necessário
5intervalo mínimo   1 hora               1 minuto           1 minuto
6vê arquivos locais? não                 sim                sim

A pergunta decisiva: este trabalho pode sair do seu laptop?

1"verificar meu servidor dev local a cada minuto"
2   → deve ser local + /loop (o intervalo de 1 hora da nuvem não consegue alcançá-lo)
3
4"escaneie issues do GitHub às 3h e abra PRs"
5   → deve ser nuvem (seu laptop está fechado — o loop não pode
6     ficar esperando por ele)

E o autoengano mais sorrateiro de toda a prática: tratar um temporizador local como "rodando enquanto você dorme." Não é. É "rodando algumas rodadas extras enquanto ainda estou por perto."

Sua tarefa para esta lição:

1. Escreva .github/workflows/triage.yml com um gatilho cron que acione a habilidade morning-triage.
2. Defina três limites: orçamento por execução, orçamento diário e número máximo de tentativas.
3. Finalize o fluxo de trabalho com a regra: PRs nunca fazem merge automático, qualquer coisa incerta vai para ./inbox/.

1# .github/workflows/triage.yml  (altere 3 coisas)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # altere: 06:00 do seu fuso horário em UTC
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← limite por execução · altere
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: triagem matinal
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← limite diário · altere
22          MAX_RETRIES: '3'          # ← limite de tentativas · altere
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: abrir PRs (NUNCA fazer merge automático)
29        run: |
30          # PRs abrem automaticamente. O merge permanece humano.
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # não há `gh pr merge` aqui — propositalmente
35
36      - name: encaminhar incertezas para a caixa de entrada
37        run: |
38          ls ./inbox/ && echo "itens aguardando revisão humana"

As três regras que o mantêm vivo no sexto mês:

Limite antes de enviar: três níveis - tempo limite por execução, orçamento diário, número máximo de tentativas - definidos antes da primeira execução autônoma, não depois da primeira conta assustadora. Um limite de tokens não é sobre economizar dinheiro. É um disjuntor que transforma risco aberto em risco limitado. Um loop sem limites terceirizou sua autoridade de gastos para seus próprios bugs.

Para escala: a Uber limitou os engenheiros a US$ 1.500 por pessoa por ferramenta por mês depois de queimar seu orçamento de IA em quatro meses. Seu limite por loop é a versão granular dessa lição.

Mantenha uma porta aberta: PRs não fazem merge automático. Itens incertos vão para a caixa de entrada. Você lê uma amostra por dia. A porta não está lá porque um humano sempre vai passar por ela, está lá porque a porta existir mantém você em uma posição onde pode. Solde todas as portas, e no dia em que precisar entrar, você perdeu a chave.

Verifique se ele realmente acorda. Execute-o por pelo menos 3 rodadas (execuções de teste contam). A falha mais comum: deslumbrante no dia da demonstração, morto na quinta-feira. "a última execução foi no dia em que foi demonstrado" é a assinatura diagnóstica de um Loop Manual.

Funciona da mesma forma fora do Claude Code - as capacidades não são vinculadas a um fornecedor, apenas renomeadas:

1CAPACIDADE            Claude Code          Codex
2agendamento           /loop · worker       Guia Automações
3execução até condição /goal                reexecução de automação + juiz
4isolamento paralelo   --worktree           worktree em segundo plano
5subagentes            .claude/agents/      .codex/agents/
6conexão externa       MCP + plugins        Conector MCP
7habilidade explícita  SKILL.md             $skill-name
8execução offline      Cloud Routines       nuvem (planejado)

A pergunta nunca foi "qual fornecedor". É "todas as seis capacidades estão instaladas."

A doença que esta lição previne - Loop Manual:

Quatro movimentos lindamente construídos, sem cron. Não é um loop - é um script que você executou uma vez e esqueceu.

Correção: pendure qualquer gatilho que não dependa de você se lembrar.

Antes de enviar, responda a estas três:

1/ Quais são os números exatos dos seus três limites?

Se um bug rodar a noite toda - qual limite quebra a queda primeiro? Se nenhum deles quebrasse... O que isso te diz?

2/ Como é a sua porta humana?

(Revisão de PR / caixa de entrada / amostra diária / reconciliação semanal?) Escreva = assine o contrato consigo mesmo

3/ A pergunta final: Daqui a seis meses, este loop terá te tornado mais forte (compreensão, julgamento, sensibilidade para o sistema) - ou te transformado no zelador de uma máquina que você não consegue ler? Qual é o seu plano para evitar o segundo?

As 4 dívidas e permanecendo o engenheiro

Seu loop está construído: ele acorda, encontra trabalho, critica a si mesmo, lembra e agenda seu próprio amanhã.

Enquanto um loop roda, quatro coisas se acumulam silenciosamente - e sua característica comum é que nenhuma delas dispara um alarme.

1DÍVIDA DE VERIFICAÇÃO     saída não rejeitada se acumulando
2DETERIORAÇÃO DE COMPREENSÃO  a base de código cresce, seu mapa mental não
3RENDIÇÃO COGNITIVA        "Não estou a fim de examinar mais"
4EXPLOSÃO DE TOKENS        um bug roda a noite toda → você vê como uma conta

Eles se alimentam mutuamente: saída não verificada corrói sua compreensão -> compreensão corroída convida à rendição -> rendição deixa o loop rodar mais e gastar mais -> o que produz mais saída não verificada.

Audite seu novo loop contra todos os quatro antes de sua primeira execução solo:

• Meu avaliador realmente rejeita - não é decoração.
• Eu leio um PR de amostra por dia e posso explicar o que mudou.
• Mantive o hábito de dizer "isso está errado".
• Meus limites foram definidos ANTES da primeira execução, não depois da primeira conta.

E aqui está a parte que decide tudo:

O mesmo loop, construído por duas pessoas, pode terminar em lugares opostos. Um o usa para se mover mais rápido enquanto ainda lê o código e mantém a direção - o loop amplifica o julgamento que ele já tem.

O outro usa exatamente o mesmo loop especificamente para nunca mais entender nada - seis meses depois, o primeiro está mais afiado, e o segundo é um zelador de uma máquina que ele não consegue ler.

Addy Osmani: "construa o loop, mas construa-o como alguém que pretende permanecer o engenheiro - não apenas a pessoa que aperta o play."

Loops tornam a geração quase gratuita, o que permanece escasso é o julgamento: qual plano está certo, em qual linha parar, qual coisa funciona mas está errada na raiz. O loop não desvaloriza o julgamento - ele remove tudo que não é julgamento, e deixa apenas isso.

Um loop é um multiplicador fiel:

Traga compreensão - ele amplifica a compreensão.

Traga preguiça - ele amplifica a preguiça.

Decida o que você quer amplificado - antes de construí-lo.

Fique ligado!

Boa sorte :)