O engenheiro de software do Google Addy Osmani, num artigo publicado a 7 de Junho, define «Loop Engineering» como uma abordagem de design de agentes de Prompt AI que substitui o trabalho manual dos engenheiros por sistemas de automação, composta por cinco peças: Automations, Worktrees, Skills, Plugins/Connectors e Sub-agents.
Definições e funções das cinco peças
De acordo com o enquadramento de Addy Osmani:
Automations (automação): tarefas accionadas por agendamento, responsáveis por executar automaticamente «Discovery» e «Triage». Osmani explica que as Automations são o mecanismo central para tornar o loop num ciclo real, em vez de uma «execução única». A app Codex usa Automations por separadores e disponibiliza o comando /goal (executa até a condição ser satisfeita); o Claude Code obtém a mesma funcionalidade através de tarefas agendadas, cron, /loop, /goal e GitHub Actions.
Worktrees (árvores de trabalho): usando o mecanismo git worktree para criar directórios de trabalho independentes para agentes em execução em paralelo, evitando conflitos quando vários agentes modificam o mesmo ficheiro em simultâneo. A app Codex inclui worktree por cada thread; o Claude Code fornece o mesmo isolamento através de git worktree e da opção --worktree.
Skills (competências): escrevendo conhecimentos do projecto, convenções e passos de construção num ficheiro externo no formato SKILL.md, para que o agente não precise de voltar a inferir o contexto do projecto a cada execução. As duas ferramentas usam o mesmo formato SKILL.md; Osmani indica que uma descrição precisa é melhor do que descrições vagas.
Plugins / Connectors (plugins e conectores): construídos com base em MCP (Model Context Protocol), para que o agente possa aceder a sistemas externos como Issue Tracker, bases de dados, endpoints de API e ferramentas de comunicação. A app Codex e o Claude Code suportam MCP; Osmani confirma que o mesmo connector é, em geral, directamente reutilizável em ambas as ferramentas.
Sub-agents (subagentes): separar «agente de execução» e «agente de validação» em papéis independentes, com instruções diferentes e até modelos diferentes a fazerem uma revisão mútua, para evitar que o mesmo agente se autoavalie com demasiada permissividade. A app Codex define-os em .codex/agents/ em formato TOML; o Claude Code define Task subagents e agent teams em .claude/agents/.
Memória externa (State): definição e papel do sexto componente
Osmani define memória externa como «qualquer coisa que existe fora de uma única conversa e que é usada para registar o que foi feito e qual é o próximo passo», por exemplo ficheiros Markdown ou um board do Linear. A necessidade prende-se com o facto de que grandes modelos de linguagem não conservam memória entre execuções, pelo que o progresso tem de ser guardado fora, e não na janela de contexto do modelo.
As duas ferramentas suportam este mecanismo: a app Codex liga ao Linear via Markdown ou Connector; o Claude Code liga via AGENTS.md, ficheiros de progresso ou MCP.
Perguntas frequentes
Qual é a principal diferença entre Loop Engineering e tradicional Prompt Engineering?
De acordo com o enquadramento de Addy Osmani, no Prompt Engineering tradicional o engenheiro escreve manualmente prompts e interage com o agente de forma iterativa; no Loop Engineering, desenha-se um sistema completo em que as Automations são accionadas automaticamente, as Worktrees isolam execução paralela, as Skills fornecem conhecimento, os Connectors ligam ferramentas, e os Sub-agents separam a execução e a validação, passando o papel do engenheiro de «operar directamente o agente» para «desenhar um sistema que faz o agente funcionar».
Que peças é que a Codex app e a Claude Code suportam actualmente?
Com base na análise comparativa de Osmani, à data da publicação do seu artigo, as duas ferramentas já suportam integralmente as cinco peças e o mecanismo de memória externa; as principais diferenças são o nome e os caminhos específicos: as funcionalidades de Automations têm equivalentes, as Worktrees assentam em git worktree, as Skills usam o formato SKILL.md, Plugins/Connectors assentam em MCP e Sub-agents usam ficheiros de configuração no directório .agents/.
Como é que a «separação entre execução e validação» dos Sub-agents é implementada?
Segundo a explicação de Osmani, o desenho dos Sub-agents define «um agente que escreve código» e «um agente que revê código» como dois papéis independentes, permitindo usar instruções diferentes e até modelos diferentes. O comando /goal do Claude Code segue o mesmo princípio: um modelo totalmente novo decide se a tarefa está concluída, em vez de o modelo da tarefa de execução se autoavaliar; Osmani chama-lhe «o que faz vs quem verifica», aplicado ao próprio critério de paragem.
