# A IDE Virou a Exceção: Como Passei a Construir Loops em Vez de Código Depois de 16 anos construindo sistemas financeiros na AWS, percebi que meu trabalho mudou: não projeto mais código linha a linha, projeto loops — triggers, topologias, verificadores e stop-rules. A IDE ainda existe na minha bancada, mas cada vez menos. Este post é o registro honesto dessa transição. - URL: https://fernando.moretes.com/blog/ide-virou-excecao-loop-engineering-nos-meus-agentes - Markdown: https://fernando.moretes.com/blog/ide-virou-excecao-loop-engineering-nos-meus-agentes/article.md?lang=pt - Published: 2026-06-29T21:51:42.967Z - Category: IA & Agentes - Tags: loop-engineering, ai-agents, aws-bedrock, eventbridge, prompt-engineering, serverless, agentic-ai, developer-productivity - Reading time: 5 min - Source: [Loop Engineering (architecture study)](https://fernando.moretes.com/studies/loop-engineering-agentes-de-ia) --- 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 - **Geração diária de artigos bilíngues**: EventBridge dispara uma Lambda que chama Bedrock AgentCore Web Search para grounding. Se a busca falha, o agente cai automaticamente para grounding por texto-fonte — o artigo sai de qualquer forma. O loop tem verifier de qualidade e abort por timeout. - **Livros e estudos capítulo a capítulo**: nenhuma chamada única carrega o livro inteiro. Cada capítulo é um sub-loop com cache próprio. Se o processo reinicia, os capítulos já gerados são pulados. Retry-with-attempts + circuit breaker garantem que um capítulo problemático não derruba o livro inteiro. - **Cron de áudio às 02:00 — idempotente por design**: o loop de geração de voz roda com preferência por GPU; se não há GPU disponível, cai para Mac. O estado é um ponteiro no S3 — não há estado em memória. Um re-run retoma de onde parou. Idempotência não é feature, é arquitetura. - **Keepalive loop engenheirado ao vivo**: um render longo dentro de uma janela curta de execução. Projetei um heartbeat que mantém o processo vivo — uma lição pequena mas real sobre triggers e stop-rules: sem a regra de parada certa, o keepalive vira loop infinito. - **O padrão `/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. ### ⏰ Triggers — Event Sources - EventBridge Scheduled Rule (messaging) - S3 / API GW Event Trigger (messaging) ### 🤖 AWS Bedrock — Agent Loop - Lambda Loop Orchestrator (compute) - Bedrock Reason / Plan (ai) - AgentCore Web Search / Tools (ai) - Tool Output Observe / Parse (compute) ### ✅ Control — Verifier + Stop-Rules - Verifier Lambda Quality Gate (security) - Budget Guard Token + Time Limit (security) - Human Gate (async approval) (user) ### 💾 State + Output — Storage - S3 Cache Chapter / Audio Ptr (storage) - S3 / DynamoDB Final Output (storage) ### Fluxos - cron -> orchestrator: dispara - event -> orchestrator: dispara - orchestrator -> reason: inicia ciclo - reason -> act: usa ferramentas - act -> observe: retorna resultado - observe -> reason: itera (sub-loop) - observe -> verifier: saída candidata - verifier -> orchestrator: falhou → retry - verifier -> budget: passou → checar budget - budget -> human: gate opcional - budget -> output: done → persiste - orchestrator -> cache: lê/escreve estado ## 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. > — Fernando F. Azevedo ## 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. > **Minha Leitura Honesta Desse Momento:** 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. **Rating:** paradigm shift — in production ## Referências - [Addy Osmani — Loop Engineering (June 2026)](https://addyosmani.com/blog/loop-engineering/) - [Boris Cherny — Writing the Loops that Drive Claude](https://boris.sh/loops) - [AWS Bedrock AgentCore — Web Search Tool](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-tools-web-search.html) - [Amazon EventBridge Scheduler](https://docs.aws.amazon.com/scheduler/latest/UserGuide/what-is-scheduler.html) - [AWS Lambda — Retry behavior and error handling](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) - [Building agentic AI applications — AWS Blog](https://aws.amazon.com/blogs/machine-learning/building-agentic-ai-applications-with-amazon-bedrock/) - [Idempotency in serverless architectures — AWS Blog](https://aws.amazon.com/blogs/compute/handling-lambda-functions-idempotency-with-aws-lambda-powertools/) - [AWS Lambda Powertools — Idempotency utility](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)