O engenheiro de software do Google, Addy Osmani, publicou em 7 de junho um texto que define “Loop Engineering” como uma abordagem para projetar agentes de IA de prompt que substitui o método manual por sistemas automatizados, composta por cinco blocos: Automations, Worktrees, Skills, Plugins/Connectors e Sub-agents.
Definição e funções dos cinco blocos
De acordo com a estrutura de Addy Osmani:
Automations (automação): tarefas acionadas por agendamento, responsáveis por executar automaticamente “Discovery” e “Triage”. Osmani explica que Automations é o mecanismo central para fazer o loop ser realmente cíclico, e não uma “execução única”. O Codex app usa Automations por página e oferece o comando /goal (executa até uma condição ser atendida); o Claude Code realiza funções semelhantes por meio de tarefas agendadas, cron, /loop, /goal e GitHub Actions.
Worktrees (árvores de trabalho): usando o mecanismo git worktree para criar diretórios de trabalho independentes para agentes executarem em paralelo, evitando conflitos quando múltiplos agentes modificam o mesmo arquivo ao mesmo tempo. O Codex app tem worktree embutido para cada thread; o Claude Code oferece o mesmo isolamento por meio de git worktree e da flag --worktree.
Skills (habilidades): usando o formato SKILL.md para registrar o conhecimento do projeto, convenções e etapas de build em documentos externos, para que o agente não precise inferir novamente o contexto do projeto a cada execução. As duas ferramentas usam o mesmo formato de SKILL.md; Osmani diz que descrições precisas são melhores do que descrições vagas.
Plugins / Connectors (plugins e conectores): construídos com base no MCP (Model Context Protocol), para que o agente possa acessar sistemas externos como Issue Tracker, bancos de dados, endpoints de API e ferramentas de comunicação. Tanto o Codex app quanto o Claude Code suportam MCP; Osmani confirma que o mesmo connector normalmente pode ser usado diretamente em ambas as ferramentas.
Sub-agents (subagentes): separa o “agente de execução” e o “agente de verificação” em papéis distintos, com diferentes instruções e até diferentes modelos fazendo revisão um do outro, para evitar que o mesmo agente faça uma autoavaliação permissiva demais. O Codex app define em .codex/agents/ no formato TOML; o Claude Code define Task subagents e agent teams em .claude/agents/.
Memória externa (State): definição e função do sexto componente
Osmani define memória externa como “qualquer coisa que exista fora de uma conversa única, usada para registrar o que foi feito e qual é o próximo passo”, como arquivos Markdown ou um quadro no Linear. A razão de ser dessa necessidade é que grandes modelos de linguagem não mantêm memória entre execuções; portanto, o progresso precisa ser armazenado externamente, e não na janela de contexto do modelo.
As duas ferramentas suportam esse mecanismo: o Codex app conecta o Linear via Markdown ou Connector; o Claude Code conecta o Linear via AGENTS.md, arquivos de progresso ou via MCP.
Perguntas frequentes
Quais são as principais diferenças entre Loop Engineering e Prompt Engineering tradicional?
De acordo com a estrutura de Addy Osmani, no Prompt Engineering tradicional o engenheiro escreve prompts manualmente e interage com o agente em ciclos; já no Loop Engineering, o sistema é projetado para ser acionado automaticamente por Automations, com Worktrees isolando execuções em paralelo, Skills fornecendo conhecimento, Connectors conectando ferramentas e Sub-agents separando execução e validação, transformando o papel do engenheiro de “operar diretamente o agente” para “projetar o sistema que roda o agente”.
Quais blocos cada uma das ferramentas, Codex app e Claude Code, suporta atualmente?
Com base na análise comparativa de Osmani, até a publicação do artigo, as duas ferramentas já suportavam completamente os cinco blocos e o mecanismo de memória externa, com as principais diferenças sendo a nomenclatura e os caminhos específicos: a função de Automations tem correspondência, Worktrees são baseados em git worktree, Skills usam o formato SKILL.md, Plugins/Connectors são baseados em MCP e Sub-agents usam arquivos de configuração no diretório .agents/.
Como a “separação entre execução e validação” dos Sub-agents é implementada?
Segundo a explicação de Osmani, o design dos Sub-agents transforma o “agente que escreve código” e o “agente que revisa código” em dois papéis independentes, permitindo usar instruções diferentes e até modelos diferentes. O comando /goal do Claude Code aplica o mesmo princípio: um modelo novo avalia se a tarefa foi concluída, em vez de o modelo que executa a tarefa se autoavaliar. Osmani chama isso de aplicação de “quem faz vs quem verifica” ao próprio critério de parada.
