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 colocou essa conversa dentro do contexto mais amplo de "Construindo Produtos do 0 ao 1", fornecendo um panorama mais completo.

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: Engenharia de Loop é 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 habilitamos agentes de IA a trabalhar 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 o executa

Duração do ciclo

O que ele produz para a camada externa

Loop de codificação do agente

o próprio agente

segundos - minutos

uma versão que funciona

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 loop fica no topo e adiciona três verbos que o harness não tem. Ele roda em um temporizador, gera ajudantes e se alimenta - a saída de hoje se torna a entrada de amanhã. Esse último é o que o 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 em cima do harness

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

Um loop é, por design, uma máquina que torna o "número de turnos" 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 um turno:

"Loop" é mal interpretado como "girar no lugar". Não é, cada turno 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 este turno no próximo.

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 este turno 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 sub-agente como revisor, testando e analisando skills

Persistência

escrever o estado fora da conversa

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

Agendamento

deixar o loop rodar turno após turno

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 de 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 explícita de "Parar" que especifique o que o loop NÃO pode fazer.

Aqui está o ponto de partida - 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 o 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, "ler 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 mesclará para você.

Especifique 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 noturno de saúde do site. 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 tipo mais comum de "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 o Judge dentro da skill e deixe-o escolher o trabalho de hoje por conta própria.

Antes de prosseguir, responda a estas três perguntas:

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 do 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 em seguida - disparar 5 agentes de uma vez, ir rápido. Esse passo exato é como você cultiva 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 nativo: um repositório, múltiplos diretórios de trabalho independentes, cada um vinculado ao 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# ler state/triage.md, uma worktree por descoberta
2# altere: MAX_PARALLEL para o que sua máquina / conta pode suportar
3MAX_PARALLEL=3
4
5# altere: análise para corresponder às colunas do seu triage.md real
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  # a linha chave: isolamento físico por agente
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # altere: goal é a condição de parada que o avaliador da Lição 3 lerá
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   # deixe todos os agentes paralelos terminarem
22
23# regra de fechamento: agentes nunca fazem auto-merge — worktrees aguardam
24# a porta humana na Lição 5
25echo "Todas as worktrees prontas para revisão:"
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 processa 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 copiar: 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 rigorosa 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 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 perguntas:

**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 loop, 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 ele acabou de escrever, e ele quase sempre se elogiará - mesmo quando um humano pode ver rapidamente que é medíocre.

Isso não é o modelo sendo burro: avaliar seu próprio trabalho é estruturalmente quebrado. Quando o código é finalizado, o contexto do agente está repleto da cadeia de autojustificativa de por que ele escreveu as coisas dessa maneira. 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 turno, "isso é bom o suficiente?" é respondido pelo agente que acabou de escrever. Cada turno concorda consigo mesmo. 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 tornar um gerador 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: PAPEL + PRESSUPONHA + VERIFIQUE + USE + VEREDITO.

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  (altere 3 coisas)
2PAPEL: Revisor de código adversarial.
3PRESSUPONHA: este código está QUEBRADO até que se prove o contrário.
4NÃO elogie. Encontre o que falha.
5
6# altere: ordene VERIFIQUE pelos modos de falha reais do seu projeto,
7# verificações executáveis primeiro
8VERIFIQUE, em ordem:
9  1. Funciona?  (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# altere: qual MCP depende do que você está testando —
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
20VEREDITO: PASSE somente se cada verificação for válida.
21         Caso contrário, REJEITE + liste cada motivo.

1# condição de parada — julgada por um modelo pequeno novo, NÃO pelo gerador
2# altere: troque pela condição verificável real da sua descoberta
3/goal all tests in test/auth pass and the lint step is clean
4
5# cuidado: /goal e /loop NÃO são a mesma coisa
6#   /loop = reexecutar em intervalo (sem julgamento de parada — perigoso)
7#   /goal = executar até que um modelo novo julgue a condição verdadeira

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 é PRESSUPONHA 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 "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: uma REJEIÇÃO sem motivos listados não é uma rejeição - o gerador não tem ideia do que corrigir.

E o teste decisivo: seu avaliador já rejeitou algo nos últimos 5+ turnos? Um loop que nunca disse "não" em centenas de turnos é 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 turno se auto-aprova, 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 perguntas:

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" para 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 PASSAM, uma REJEITA. Pergunta: onde esses três vereditos 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 na REJEIÇÃO não corrigida de ontem, talvez atribua outro agente para corrigi-la novamente, talvez a perca completamente, talvez caia no mesmo buraco.

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

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ê NESTE turno -> limpa a cada atualização.

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

Um loop faz a ponte 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 o escreve, as worktrees da Lição 2 o leem.
2. Conecte um conector (MCP): um veredito PASSAR abre automaticamente um PR, um veredito REJEITAR atualiza automaticamente o ticket.
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 ser commitado 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 externo
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 parou ontem em vez de começar de novo? Esta você descobre executando, não raciocinando sobre ela.

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. No próximo turno, 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 perguntas:

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 corretamente - 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"examinar issues do GitHub às 3h e abrir 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 alguns turnos 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 workflow com a regra: PRs nunca fazem merge automático, qualquer coisa incerta vai para ./inbox/.

1# .github/workflows/triage.yml  (mude 3 coisas)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # mude: 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 · mude
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 · mude
22          MAX_RETRIES: '3'          # ← limite de tentativas · mude
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. merge continua sendo humano.
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triagem" \
33            --body-file ./state/triage.md
34          # não há `gh pr merge` aqui — de propósito
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 você pode. Solde todas as portas, e no dia em que precisar entrar, você perdeu a chave.

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

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

1CAPACIDADE           Claude Code          Codex
2agendamento          /loop · worker       Guia Automações
3execução-condicional /goal                reexecução automação + juiz
4isolamento paralelo  --worktree           worktree em segundo plano
5sub-agentes          .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 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 é 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 terá te transformado no cuidador de uma máquina que você não consegue ler? Qual é seu plano para evitar o segundo?

As 4 dívidas e permanecer o engenheiro

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

Enquanto um loop roda, quatro coisas se acumulam silenciosamente - e sua característica compartilhada é 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 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 eles já têm.

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 cuidador de uma máquina que eles não conseguem ler.

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

Loops tornam a geração quase gratuita, o que permanece escasso é o julgamento: qual plano está certo, em qual linha parar, qual coisa roda 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 compreensão.

Traga preguiça - ele amplifica preguiça.

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

Fique ligado!

Boa sorte :)