Engenharia de loops: projetando workflows confiáveis em torno de agentes de programação com IA

Uma interação típica com um agente de programação com IA é sequencial: escrever um prompt, inspecionar a response, fornecer mais contexto e repetir. Isso funciona para tarefas específicas, mas o desenvolvedor continua responsável por conduzir cada etapa.

A engenharia de loops muda esse modelo de controle. Em vez de fornecer prompts manualmente ao agente durante toda a tarefa, você projeta um workflow capaz de selecionar o trabalho, executá-lo, verificar o resultado, registrar o progresso e decidir o que fazer em seguida.

A mudança importante não é simplesmente executar o mesmo prompt repetidamente. Um loop útil precisa de estrutura, limites e evidências de que o trabalho foi realmente concluído.

De prompts a sistemas de controle

Um prompt normalmente descreve a próxima ação. Um loop descreve um objetivo e o processo para alcançá-lo.

Por exemplo, pedir a um agente que corrija um teste com falha é um prompt. Já um loop poderia:

1. Ler os resultados mais recentes dos testes.
2. Selecionar uma falha.
3. Reproduzi-la localmente.
4. Investigar o código relevante.
5. Implementar uma alteração limitada.
6. Executar os testes afetados e as verificações estáticas.
7. Registrar o resultado.
8. Continuar, parar ou escalar com base nas evidências.

Isso se assemelha às automações existentes baseadas em tarefas agendadas, webhooks, filas e pipelines de CI. A diferença é que um agente pode tomar decisões adaptativas dentro do workflow, como decidir quais arquivos inspecionar ou qual comando de diagnóstico executar.

Essa flexibilidade é útil, mas também torna a verificação e os limites operacionais mais importantes.

Os componentes de um loop útil

Um loop prático de engenharia normalmente precisa de vários elementos.

Um gatilho inicia o workflow. Pode ser um agendamento, uma nova issue, um build com falha, um relatório de erro ou uma request manual.

Um objetivo mensurável define o que deve se tornar verdadeiro. “Melhorar o serviço de checkout” é amplo demais. “Fazer a suíte de correção do checkout passar sem alterar sua API pública” oferece ao loop um resultado que ele pode avaliar.

Ferramentas e contexto dão ao agente acesso ao repositório, aos testes, aos comandos de build, ao rastreador de issues, aos logs e às convenções do projeto. Sem essas informações, o agente precisa adivinhar como o sistema funciona.

Persistent state registra o trabalho concluído, as descobertas atuais, as tentativas que falharam e as tarefas restantes fora de uma única conversa com o modelo. Pode ser um arquivo Markdown, um quadro de issues, um registro de database ou outro armazenamento durável. O state persistido permite que uma execução posterior continue sem reconstruir todo o histórico a partir do contexto do chat.

A verificação confere o resultado de acordo com critérios explícitos. Verificações determinísticas, como compilação, testes, formatação, validação de schema e limites de desempenho, devem ser preferidas quando estiverem disponíveis. Um agente revisor separado pode acrescentar outra perspectiva, mas não deve substituir verificações objetivas.

Regras de parada e escalonamento impedem que o loop continue indefinidamente. Limites úteis incluem número máximo de tentativas, orçamentos de tokens ou custos, timeouts, escopos restritos de arquivos e condições que exigem aprovação humana.

A verificação é o verdadeiro trabalho de engenharia

A parte de execução de um loop geralmente é fácil de descrever: permitir que o agente inspecione o problema e faça uma alteração. A parte difícil é definir o que conta como sucesso.

Um agente informar que uma tarefa foi concluída não é evidência suficiente. O loop deve coletar resultados que outro processo ou outra pessoa possa inspecionar. Para uma alteração de código, isso poderia incluir:

• O diff exato produzido
• Resultados de testes e build
• Saída da análise estática
• Medições de desempenho
• Uma lista de suposições e questões não resolvidas
• Um link entre a alteração e a issue que lhe deu origem

Também é útil separar quem faz de quem verifica. Um agente pode implementar a alteração, enquanto outro a revisa em relação ao objetivo e às regras do projeto. Isso reduz a autoconfirmação, embora aumente a latência e o uso do modelo.

A revisão humana continua importante quando a correção depende da arquitetura, da intenção do produto, da segurança ou do contexto de negócios. Verificações automatizadas podem confirmar que os testes passam. Elas nem sempre conseguem determinar se a implementação é a alteração certa para o sistema.

Comece com workflows delimitados

A engenharia de loops é mais adequada para tarefas repetitivas com resultados observáveis do que para desenvolvimento vago e sem limites definidos.

Bons pontos de partida incluem fazer a triagem de falhas de CI, revisar atualizações de dependências, reproduzir erros registrados, verificar links da documentação ou investigar testes instáveis. Esses workflows já têm entradas, resultados esperados e ferramentas de validação estabelecidas.

A primeira versão deve permanecer restrita: processar um item por vez, trabalhar em uma branch isolada ou em um Git worktree, exigir que os testes passem, limitar o número de novas tentativas e criar um pull request para revisão em vez de fazer merge automaticamente.

O engenheiro continua responsável

Um loop pode reduzir a interação repetitiva com um agente de programação, mas não transfere a responsabilidade. Contexto insuficiente, critérios fracos de conclusão ou limites ausentes permitem que erros se repitam na velocidade da máquina, enquanto consomem mais tempo e tokens.

Portanto, a parte útil da engenharia de loops não é a geração de código sem supervisão. É o projeto explícito do sistema ao redor: como o trabalho entra, o que o agente pode alterar, como o progresso persiste entre execuções, como os resultados são verificados e quando um humano deve assumir o controle.

A qualidade dos prompts ainda importa dentro desse sistema. A tarefa mais ampla de engenharia é decidir como prompts, ferramentas, state, verificações e julgamento humano operam em conjunto como um único workflow controlado.

Referências

• Loop Engineering — addyosmani.com
• The Art Of Loop Engineering — langchain.com
• What Is Loop Engineering — newsletter.pragmaticengineer.com