A IDE Virou a Exceção: Como Passei a Construir Loops em Vez de Código
Há seis meses, abria minha IDE todos os dias. Hoje abro algumas vezes por semana, e quando abro, é porque algo realmente exige minha atenção: um bug gnarly de concorrência, uma decisão de design greenfield, uma revisão de segurança que não delego. O que mudou não foi a ferramenta. Foi o nível de abstração onde opero. Parei de escrever código e comecei a projetar loops. Os agentes escrevem e executam o código. Eu projeto o que os faz funcionar: o trigger, a topologia, o verificador, a regra de parada. Isso não é hype, é o que está rodando em produção agora mesmo, gerando os artigos deste site enquanto você lê.
A Virada: De Prompt Engineering para Loop Engineering
Durante anos, o trabalho de quem usava IA era escrever prompts melhores. Mais contexto, mais exemplos, melhor formatação. O gargalo era a palavra certa no lugar certo. Isso ainda importa, mas deixou de ser o trabalho principal.
Em junho de 2026, Addy Osmani nomeou o que muitos de nós já sentíamos: loop engineering. Boris Cherny foi ainda mais direto: meu trabalho agora é escrever os loops que dirigem o Claude. Não o prompt dentro do loop, o loop em si.
O que é um loop de agente, concretamente? É um ciclo com quatro elementos que você projeta explicitamente:
- Trigger: o que inicia o ciclo (um cron, um evento, uma chamada HTTP, outro agente)
- Topologia: quantos agentes, em que ordem, com que ferramentas
- Verificador: o que decide se a saída é boa o suficiente para avançar
- Stop-rule: o que decide que o loop terminou, por sucesso, por timeout, por orçamento
Quando o gargalo era o prompt, eu ficava no editor de texto. Quando o gargalo é o loop, fico no quadro branco e no YAML do EventBridge. A IDE virou a exceção, não o ambiente padrão.
Os Loops que Rodam em Produção Agora
/loop: dois modos que uso dependendo do contexto. Self-paced: o modelo escolhe a cadência, bom para tarefas exploratórias onde a profundidade importa mais que o tempo. Fixed-interval: o loop bate em intervalos fixos, bom para pipelines previsíveis onde SLA importa.A Fábrica de Loops de Agente
Cada loop que rodo segue esta topologia: um trigger externo dispara o ciclo, o agente raciocina/age/observa em sub-loops, um verificador decide se avança ou itera, e uma stop-rule (budget + timeout + human gate) decide quando parar.
- EventBridge · Scheduled Rule
- S3 / API GW · Event Trigger
- Lambda · Loop Orchestrator
- Bedrock · Reason / Plan
- AgentCore · Web Search / Tools
- Tool Output · Observe / Parse
- Verifier Lambda · Quality Gate
- Budget Guard · Token + Time Limit
- Human Gate · (async approval)
- S3 Cache · Chapter / Audio Ptr
- S3 / DynamoDB · Final Output
Meu Playbook: Como Coloco um Loop em Produção
- 1
1. Defina o trigger antes de qualquer prompt
O que inicia o loop? Um cron? Um evento de S3? Uma chamada humana? O trigger define o contrato de entrada. Sem trigger claro, o loop não tem fronteira.
- 2
2. Projete a topologia no quadro branco
Quantos agentes? Em sequência ou paralelo? Quais ferramentas cada um tem acesso? Eu desenho isso antes de escrever uma linha de YAML. A topologia errada custa caro para refatorar.
- 3
3. Escreva o verificador antes do agente
O verificador é o que decide se a saída é boa o suficiente. Escrevo primeiro porque ele força clareza sobre o critério de sucesso, algo que muitos loops pulam e depois pagam com loops infinitos ou saídas silenciosamente erradas.
- 4
4. Defina stop-rules explícitas: timeout, budget, tentativas
Todo loop tem três stop-rules: um timeout de tempo (o loop não pode durar mais que X), um budget de tokens/custo (não posso gastar mais que Y por execução), e um máximo de tentativas (retry-with-attempts, não retry-forever). Sem as três, o loop é um risco operacional.
- 5
5. Torne o estado externo e idempotente desde o início
Estado em memória é inimigo da resiliência. Uso S3 como ponteiro de estado, o que já foi gerado, o que falta. Um re-run não recomeça do zero; ele lê o ponteiro e continua. Isso é mais importante que qualquer otimização de prompt.
- 6
6. Adicione o human gate como stop-rule opcional, não como afterthought
Para loops que produzem saídas com consequências (publicação, envio, deploy), projeto um ponto de aprovação humana assíncrona. Não é burocracia, é a diferença entre um loop autônomo e um loop irresponsável.
Quando Ainda Abro a IDE: Credibilidade Acima de Tudo
Seria desonesto dizer que nunca abro a IDE. Abro. E quando abro, é porque o problema exige.
Debugging gnarly de concorrência: quando um loop de agentes está produzindo resultados não-determinísticos que não consigo reproduzir no log, preciso do debugger de verdade. Breakpoints, inspeção de estado, stack trace completo. O agente não me dá isso.
Design greenfield de alta consequência: quando estou projetando um novo sistema financeiro do zero, onde uma decisão de topologia errada custa meses, sento com a IDE, com os diagramas e com a documentação. Não delego esse raciocínio estrutural para um agente sem supervisão densa.
Revisão de segurança em código crítico: autenticação, autorização, criptografia, tratamento de segredos. Leio o código gerado pelo agente linha a linha. A IDE é o ambiente onde faço essa revisão com seriedade, com diff claro, com histórico, com anotações.
A IDE não desapareceu da minha bancada. Ela mudou de papel: de ambiente padrão para instrumento de precisão. Uso quando a tarefa exige precisão cirúrgica, não como reflexo, mas como escolha deliberada.
Parei de me perguntar 'como escrevo esse código?' e comecei a me perguntar 'qual loop produz esse resultado de forma confiável?' Essa mudança de pergunta mudou tudo.
Loops Que Deram Errado: Lições de Campo
- Loop sem stop-rule de tempo: um gerador de capítulos sem timeout ficou rodando por 47 minutos em um capítulo corrompido, consumindo tokens e bloqueando o pipeline inteiro. A regra de parada não é opcional.
- Verificador que sempre passa: um verifier que só checava se a saída era não-vazia deixou passar conteúdo alucinado por três execuções antes de eu perceber. Verificador sem critério real é pior que não ter verificador, dá falsa confiança.
- Estado em memória em Lambda: um loop que guardava progresso em variável de instância Lambda funcionou perfeitamente em desenvolvimento e perdeu todo o estado no primeiro cold start em produção. S3 como ponteiro de estado não é over-engineering, é o mínimo.
- Topologia de agente único para tarefa longa: tentei gerar um livro inteiro em uma única chamada de agente. Timeout, custo imprevisível e saída inconsistente. A solução foi o sub-loop por capítulo com cache. Granularidade de loop importa tanto quanto granularidade de função.
- Retry sem circuit breaker: um loop de retry sem limite de tentativas em uma ferramenta externa com rate limit virou um ataque DDoS acidental contra minha própria API. Retry-with-attempts + exponential backoff + abort não são paranoia, são engenharia básica.
Loop engineering não é o fim do software engineering, é uma camada acima dele. Os fundamentos ainda importam: idempotência, circuit breakers, observabilidade, segurança. O que mudou é onde você passa seu tempo de design. Se você ainda está otimizando prompts sem pensar no loop que os envolve, está resolvendo o problema errado. O gargalo se moveu. A pergunta agora é: você se moveu junto?
Veredicto: O Trabalho Mudou de Nível
Loop engineering é real, está em produção e está mudando o que significa ser um arquiteto de software. Não é sobre não usar a IDE, é sobre usá-la quando ela é o instrumento certo, não como reflexo. O meu trabalho hoje é projetar os sistemas que fazem os agentes funcionarem de forma confiável: triggers que disparam na hora certa, topologias que escalam, verificadores que realmente verificam, stop-rules que protegem o sistema de si mesmo. Os agentes escrevem o código. Eu projeto o que os faz funcionar. Essa divisão de trabalho, quando bem feita, é a coisa mais produtiva que já fiz em 16 anos de carreira.
Referências
Continue lendo
Deep dives de arquitetura, AWS, IA e mercado: direto no seu email. Grátis.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este artigo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.