Em 18 de julho, Peter Steinberger publicou uma pergunta no X: “Ainda estamos discutindo loops, ou já migramos para grafos?”
Dois dias, 2,6 milhões de visualizações. Seis semanas antes, outra publicação sua — “desenhe loops que você possa entregar a agentes via prompt” — alcançou 8,4 milhões de visualizações e fez desenvolvedores no mundo todo perceberem que a era da engenharia de prompts estava se encerrando e que a engenharia de loops era a nova direção. Juntas, as duas publicações somaram mais de 11 milhões de visualizações e empurraram o debate mais quente da programação com IA para um ponto de inflexão. Desta vez, a própria pergunta contém a própria resposta.
A Ascensão dos Loops: Quando o Prompt virou Design
Olhando para trás ao longo do ano, o paradigma da programação com IA evoluiu mais rápido do que a maioria esperava. Em julho de 2025, o engenheiro Geoffrey Huntley propôs um método que chamou de “Ralph” — um loop Bash puro que fazia o Claude repetir uma tarefa até que o objetivo fosse atingido:
while :; do cat PROMPT.md | claude-code ; doneA essência do Ralph é contornar a janela de contexto. Os modelos mainstream da época tinham limite de 200K tokens — muito insuficiente para tarefas complexas. A solução era simples: dividir a execução do agente em unidades menores, iniciar cada uma com contexto novo e persistir o trabalho concluído no sistema de arquivos em forma compactada. Huntley construiu uma linguagem de programação inteira do zero dessa forma, provando a viabilidade — mas o método só se espalhou quando modelos mais fortes chegaram.
Os loops entraram no mainstream impulsionados pelos próprios desenvolvedores principais da Anthropic e da OpenAI. Boris Cherny, criador do Claude Code, disse sem rodeios em uma conferência de desenvolvedores: “Eu não dou mais prompt ao Claude. Eu executo loops que dão prompt ao Claude e decidem o que fazer em seguida. Meu trabalho é escrever loops.” O ex-engenheiro do Google Addy Osmani emendou com um ensaio batizando a prática: “Engenharia de loops é se retirar da posição de quem dá prompt ao agente e projetar um sistema que faz isso por você.”
Conceito, nome, infraestrutura — tudo chegou em sequência. De abril a maio de 2026, Codex, Claude Code e Hermes lançaram o comando /goal, transformando o loop escrito à mão em uma única instrução. A documentação do Codex resumiu: “Goal significa: continue trabalhando até que este resultado se mantenha.” Uma solicitação comum processa a instrução, reporta e espera. Com o Goal, um objetivo persistente é anexado à thread; após a execução, a condição de conclusão é verificada automaticamente, e o trabalho pendente continua. Exemplo: “Reduzir a latência p95 do benchmark de checkout para menos de 120ms mantendo a suíte de testes de corretude verde” — uma condição de término clara o suficiente para que o agente divida tarefas, crie sub-agentes e siga executando até terminar.
Os Grafos Chegam: Quando Desenhar Loops vira Desenhar Colaboração
A última publicação de Steinberger aponta mais adiante no caminho. Um ano atrás, engenharia de prompts era a habilidade central; de 2025 até o início de 2026, o centro de gravidade migrou para o design de loops; agora o próximo estágio já é visível — desenhar grafos de múltiplos loops, cada agente executando o seu, conectados por dependências.
“Loops têm muita tolerância à bagunça. Grafos te forçam a admitir o quanto do seu fluxo de trabalho nunca foi realmente modelado.” — Luis Catacora, na thread
Essa frase captura a diferença de paradigma: loops permitem adiar a arquitetura — deixar um único agente engolir tudo até engasgar; grafos exigem a estrutura desde o início — quem é responsável pelo quê, quais tarefas dependem de quais, o que acontece quando um ramo falha. Loops adiam decisões. Grafos as forçam cedo.
Dois Grafos: o Grafo de Organização e o Grafo de Trabalho
Shubham Saboo, gerente sênior de produtos de IA do Google — autor do repositório Awesome LLM Apps, com mais de 124 mil estrelas no GitHub — ofereceu a decomposição mais nítida:
“Um grafo de organização de longa duração define quem é responsável por qual domínio e retém contexto; um grafo de trabalho define o que precisa ser feito agora, e pode ser dividido, mesclado, reordenado ou desaparecer com base em evidências.”
Sistemas multiagente em produção, portanto, executam dois grafos simultaneamente. O grafo de organização — quem cuida do quê — é composto por agentes de longa duração, cada um com um domínio fixo, retendo o contexto, a expertise e as permissões de ferramentas desse domínio; relativamente estável, como um organograma de empresa. O grafo de trabalho — o que fazer agora e como o trabalho flui — muda a cada tarefa e nova evidência: dividindo, mesclando, reordenando ou cancelando. Lembra um plano de projeto gerado em tempo real. Eles operam em relógios diferentes: o grafo de organização é projetado e implantado com antecedência; o grafo de trabalho é gerado por tarefa e descartado quando ela termina.
A Escalada Contínua da Habilidade do Desenvolvedor
A chave para ler essa cadeia é uma clara migração de capacidade: Prompt → Loop → Grafo → grafos dinâmicos. Cada estágio afasta o desenvolvedor um passo de conversar pessoalmente com a IA e aproxima um passo de projetar como as IAs colaboram:
-
Engenharia de prompts: você escreve prompts e conversa diretamente com o modelo.
-
Engenharia de loops: você projeta um loop que dá prompt ao agente — você recuou para o nível de sistema.
-
Engenharia de grafos: você projeta a estrutura de colaboração de múltiplos agentes, cada um executando seu próprio loop, com o trabalho organizado por dependências.
-
Grafos dinâmicos (o futuro): o próprio grafo se torna programável — reescrevendo sua própria estrutura durante a execução.
O resumo de Preston Holmes crava: “Loops tornam o comportamento dos agentes programável. Grafos tornam as organizações de agentes programáveis.” A barreira competitiva está migrando de “quem usa IA melhor” para “quem projeta melhores sistemas de colaboração multiagente.”
Três Pontos de Entrada no Paradigma dos Grafos
1. Coloque o /goal para trabalhar. Se você ainda envia instruções ao Codex ou ao Claude Code uma a uma, mude o hábito hoje. Escreva um Goal claro e deixe o agente planejar, executar e se verificar. Isso não é preguiça — é adotar o novo paradigma.
2. Comece a separar “organização” de “trabalho”. Em cenários multiagente, faça duas perguntas primeiro: quais agentes devem ser de longa duração, e o que cada um possui? Quais agentes temporários a tarefa atual precisa, e como o trabalho flui entre eles? Desenhe esses dois grafos — mesmo que de forma rústica — e você já estará à frente de um loop gigante.
3. Acompanhe para onde as ferramentas vão. Prefira ferramentas que suportem instruções em nível de Goal, e monitore as plataformas que adicionam gerenciamento de topologia multiagente. A próxima guerra de ferramentas de programação com IA não será sobre quais templates de prompt são mais bonitos — será sobre qual arquitetura de colaboração entre agentes é mais elegante.
A publicação de Steinberger não declara a morte dos loops; ela marca sua maturidade. Quando um paradigma ganha nome, é debatido e gera volumes de metodologia e infraestrutura, ele já pavimentou o caminho para o próximo. De escrever bons prompts, a projetar loops, a construir grafos, o centro de capacidade continua subindo — desenvolvedores cada vez mais precisam não saber como conversar com um único agente, mas como projetar a colaboração entre eles. Isto não é uma iteração de técnica. É uma reformulação do que significa ser desenvolvedor.
