Pare de Escrever Prompts Manualmente. Como Transformar Agentes de IA em uma Linha de Montagem Autônoma
O chefe do desenvolvimento do Claude Code na Anthropic, Boris Cherni, uma vez admitiu que não escreve mais prompts manualmente. Em vez disso, ele executa loops automáticos que formam tarefas para o Claude, o iniciam e verificam o resultado por conta própria. Escrever um prompt uma vez não é um problema. Mas se você alimenta as mesmas instruções para um assistente de IA todos os dias—seja verificando CI ou organizando bugs—você está fazendo trabalho rotineiro.
O desenvolvedor Kobus Greyling publicou um projeto chamado loop-engineering no GitHub, que propõe mudar a abordagem. Pare de ser um operador de chat e se torne um designer de sistemas autônomos. O projeto conquistou mais de 10.000 estrelas, e há genuinamente algo para se pensar aqui.
De Sessões Únicas a Loops Fechados
O principal problema com interações típicas com agentes de codificação como Claude Code, Grok, ou Cursor está no contexto. Você abre um diálogo, explica a estrutura do projeto, dá uma tarefa e espera o resultado. A sessão fecha—o contexto se perde. No dia seguinte, tudo começa de novo.
O conceito de Loop Engineering propõe fechar o processo em um loop infinito. O agente é executado em um cronograma, lê o estado do repositório de um arquivo especial, faz o trabalho em um branch isolado, executa testes e atualiza os status.
flowchart LR
A[Schedule / Automation] --> B[Triage Skill]
B --> C[Read + Write STATE / Memory]
C --> D[Isolated Worktree]
D --> E[Implementer Sub-agent]
E --> F[Verifier Sub-agent]
F --> G[MCP / Git / Tickets]
Você não precisa escrever frameworks Python complexos para isso. A arquitetura do loop é construída a partir de vários elementos compreensíveis:
- Execução agendada via cron, GitHub Actions, ou systemd.
- Estado do projeto em um arquivo Markdown regular
STATE.mdque fica na raiz do repositório e sobrevive a qualquer reinicialização do agente. - Branches de worktree Git isolados para que as mudanças do agente não quebrem a cópia de trabalho atual.
- Separação de agentes em executor e verificador (Maker / Checker). Um escreve código, o segundo executa testes e verifica linters.
O Que Está Dentro do Repositório
O projeto consiste em um conjunto de utilitários CLI publicados no npm e um catálogo de cenários prontos. Todas as ferramentas são combinadas em um único pacote, então nada precisa ser clonado.
Você pode fazer deploy de um template para um projeto existente com um comando:
npx @cobusgreyling/loop init . --pattern daily-triage --tool grok
Após a inicialização, a ferramenta cria arquivos de skills, estrutura de armazenamento de estado e produz o índice de prontidão do projeto—o Loop Ready score.
Para verificar a saúde do sistema resultante, use o doctor:
npx @cobusgreyling/loop doctor .
Este comando encontra problemas de configuração e produz três passos principais para melhoria. Por exemplo, ele sugerirá adicionar limites de orçamento de tokens ou configurar caminhos proibidos para edição.
O toolkit também inclui utilitários loop-cost para estimar custos de tokens, loop-sync para encontrar discrepâncias entre a descrição do loop e o arquivo de estado, e loop-worktree para criar branches separados com segurança para cada tentativa de correção.
Sete Templates Prontos
O repositório contém templates para tarefas comuns de desenvolvimento.
Cada padrão é descrito com uma análise de custos de tokens e um modo de implementação recomendado:
- Daily Triage. Uma vez por dia, escaneia o repositório, coleta issues e atualiza
STATE.md. - PR Babysitter. Monitora pull requests abertos, verifica status de testes e deixa dicas para autores.
- CI Sweeper. Intercepta builds de CI que falharam e tenta corrigir testes falhos em um branch separado.
- Dependency Sweeper. Atualiza bibliotecas dependentes e verifica que o projeto compila.
- Changelog Drafter. Coleta um rascunho de changelog antes de um novo release.
- Post-Merge Cleanup. Remove branches desatualizados e arquivos temporários após um merge.
- Issue Triage. Revisa novas submissões no tracker e sugere labels ou respostas iniciais.
O autor recomenda implementar loops incrementalmente. Primeiro, execute o agente em modo somente leitura (L1), onde ele apenas gera relatórios. Quando você estiver confiante na precisão de suas conclusões, pode passar para o modo de confirmação (L2), e só então entregar rotinas menores para autonomia total (L3).
O Lado Feio da Autonomia
Kobus Greyling divide honestamente os riscos de agentes autônomos. Se você lançar um loop com sub-agentes sem restrições, sua conta de API de LLM será surpreendentemente desagradável. Requisições repetidas em um loop infinito podem queimar centenas de dólares em poucas horas.
O segundo risco é chamado de dívida de compreensão. Se o agente escreve patches sozinho, executa testes sozinho e faz merge do código no main sozinho, a equipe rapidamente perde o controle sobre a arquitetura. O projeto se transforma em uma caixa preta.
Além disso, toda verificação continua sendo sua responsabilidade. O agente não tem senso comum e tentará fechar um teste por qualquer meio necessário, mesmo que isso signifique deletar o próprio teste.
Quem Deve Experimentar
O repositório será útil para equipes que já usam ativamente ferramentas de IA de linha de comando como Claude Code ou Grok e estão procurando uma forma de integrá-las sistematicamente no CI/CD.
Comece pequeno. Instale loop init, escolha um cenário daily-triage, e deixe o agente passar uma semana apenas escrevendo relatórios diários para STATE.md. Esta é uma forma segura de entender quão bem o conceito se encaixa no seu projeto sem arriscar a estabilidade da sua base de código.
Projetos relacionados