O debate sobre se a construção de software totalmente automatizada por IA deveria existir finalmente estourou. O estopim foi
@yetone mantendo o magpie, que colegas criticaram como "serviço de fast-food" e "arriscado demais para usar".
A maioria das pessoas concorda que a construção de software automatizada por IA é o caminho. Mas como o magpie coloca isso em prática? Eu clonei o magpie, analisei os 2.862 commits dos últimos dez dias e usei o OpenClaw para comparar.
https://x.com/wquguru/status/2109458639501271530
1204 Versões em 19 Dias
O magpie é um gateway local de LLM que conecta agentes de programação como Claude Code, Codex e Gemini CLI a qualquer modelo ou assinatura. Do primeiro commit, em 22 de setembro, até hoje, ele acumulou 9.474 estrelas em 19 dias. Dos 2.862 commits, a conta do yetone responde por 85%, mesclando 383 PRs da comunidade.
O número de tags (equivalente a versões) chegou a 1.204 em 19 dias, uma média de mais de 60 versões por dia — um ritmo impossível de manter manualmente por humanos. Em comparação, o OpenClaw teve 1.423 commits nos primeiros 19 dias, 99% enviados pelo próprio Peter Steinberger, com cerca de 10 tags.
O magpie tem o dobro de commits, mas mais de cem vezes o número de versões.
O que eu queria descobrir era uma coisa só: como exatamente a IA fecha o ciclo neste projeto?
Uma Tabela de Roteamento e um Caderno de Erros
O CLAUDE.md do magpie referencia apenas dois arquivos: AGENTS.md e LESSONS.md.
O AGENTS.md é uma tabela de roteamento. Ele não cria regras por conta própria; apenas diz aos agentes quais documentos consultar antes de trabalhar: verifique docs/subsystems/ antes de modificar subsistemas, siga docs/code-standards.md para escrever/revisar código e consulte docs/contributors.md para revisar PRs da comunidade.
A primeira frase do LESSONS.md responde à pergunta inicial:
O código do magpie é escrito, revisado, mesclado e lançado por agentes. (O código do magpie é escrito, revisado, mesclado e lançado por agentes)
Escrever, revisar, mesclar, lançar — tudo feito por agentes. Sem supervisão humana, por que o sistema não desmorona? A resposta está nesse arquivo. Com 479 linhas, ele é essencialmente um caderno de erros, preenchido pelo agente todas as noites.
Toda noite, o agente revisa todos os commits do dia, focando em três cenários:
- Quais correções precisaram ser refeitas?
- Quais não deveriam ter sido mescladas de jeito nenhum?
- Quais verificações foram feitas nas coxas?
Para cada problema encontrado, ele registra uma regra, um motivo e anexa os números do commit e da issue como evidência. Por exemplo:
Reproduza o caso exato relatado pelo usuário, na interface que ele usa, antes de considerar algo corrigido.
A issue 834 voltou 4 vezes (v0.1.920 → .925 → .931 → .938). Cada rodada corrigiu apenas o agente mostrado no print. Visto 1× (2026-10-05).
A issue 834 precisou ser retrabalhada quatro vezes, e cada vez corrigia apenas o agente que aparecia no print. Daí a regra: antes de dar algo como corrigido, reproduza o problema exatamente na interface que o usuário está usando.
O segredo está na última linha: Visto 1×. Se a mesma lição aparecer nas revisões de três dias diferentes, ela sai do LESSONS.md e vai para o code-standards.md, virando uma regra rígida baseada em experiência. Toda revisão de PR subsequente precisa checar essas regras item por item.
Oito regras já foram promovidas dessa forma. Exemplos incluem corrigir bugs semelhantes juntos (flagrados uma vez cada nos dias 5, 6 e 7 de outubro); testes falhando na main são bugs para resolver imediatamente; e declarar claramente o que foi testado e em qual commit antes de fazer o merge.
Claro, o caderno de erros também registra o que foi bem feito, marcado como Done right (Feito certo), para que os agentes leiam não só "não faça isso", mas também "faça assim".
O Caderno de Erros Foi Introduzido na Madrugada de 6 de Outubro
Esse sistema foi planejado desde o início? Olhando o histórico de commits do LESSONS.md, a primeira versão foi o commit 303819c5, criado às 3h10 da manhã de 6 de outubro.
Um dia antes, em 5 de outubro, o magpie lançou 168 versões.
A primeira versão do LESSONS.md registrou aquele dia. Com 220 commits e cerca de 170 lançamentos, aproximadamente 40 eram versões corrigindo algo lançado no mesmo dia ou no anterior. O CI quase sempre era cancelado pelo próximo push. Um teste que falhava só no Linux ficou vermelho da v0.1.877 até a v0.1.892 sem ninguém notar.
294 tags em 51 horas não deixaram nenhuma execução terminar. (294 tags em 51 horas significavam que nenhuma execução do CI conseguia ser concluída)
Por isso, a primeira versão adicionou uma regra: Antes de criar uma tag, o CI daquele commit precisa terminar e estar verde. Execuções canceladas por novos pushes não contam.
168 lançamentos no primeiro dia, 42 no segundo, 15 no terceiro, e depois estabilizando entre 15 e 26.
Nenhuma reunião foi feita, nenhum alerta enviado. As revisões noturnas encontraram problemas, adicionaram uma regra ao caderno de erros, os agentes em atividade leram e reduziram a frequência de lançamentos.
Ou seja, aquelas vinte e poucas versões por dia apontadas recentemente como problemáticas eram, na verdade, a velocidade depois de pisar no freio.
Critérios de Aceitação de PRs
Agora, vamos olhar para PRs reais:
O code-standards.md lista seis critérios de aceitação. Todos precisam passar antes de mesclar ou lançar. Deixando de lado verificações padrão como compilação em três plataformas e testes em sandbox, três são raros em projetos comuns:
- Teste de Regressão: Coloque o código antigo de volta; os novos testes devem falhar de forma explícita, apontando qual comportamento está errado. Erros de compilação ou testes ignorados não contam.
- Uso Real: Se estiver mudando uma integração com fornecedor, valide com contas, configurações e respostas de API reais. Funcionalidades não testadas não podem servir de base para outras nem ser anunciadas aos usuários como prontas.
- Verificações Não Executadas Devem Ser Listadas:
Uma verificação que não foi executada é listada como não executada, nunca omitida. (Checks não realizados devem ser listados como não executados, nunca omitidos)
Peguei a #1339 aleatoriamente para ver o comentário deixado antes do merge:
Red check significa teste de regressão, Break check significa quebrar o código de propósito para ver se os testes pegam, e a última linha diz Not run — ou seja, não foi testado em hardware real.
O comando de merge inclui --match-head-commit <reviewed sha>. Se alguém fizer um push durante a revisão, o merge falha, garantindo que código não revisado não entre.
Humano no Loop
É claro que humanos ainda participam de algumas tarefas, pelo menos nestas áreas:
- Decisões de produto: "Não reverta decisões intencionais." Coisas como comportamento de rolagem ou cursores de botões não podem ser alteradas via PRs.
- Barreiras de Segurança: Se as verificações de risco forem acionadas, espere a aprovação do mantenedor.
- Sugestões da Comunidade: 474 títulos de commits mencionam quem reportou no X ou Discord, por exemplo, JonahFu no X, Jeremy.Zhou no Discord.
Resumindo: humanos definem o rumo e vigiam as barreiras; escrever, revisar, mesclar e lançar fica por conta dos agentes.
O yetone Está Escondendo Algo?
Chegando aqui, alguns podem perguntar: será que o yetone está escondendo alguma coisa? Eu também fiquei curioso e fui investigar.
De fato, algumas coisas não estão no repositório:
- Como as revisões noturnas são disparadas não está documentado. Nenhum dos 4 workflows é agendado.
- Extraí os horários de 7 atualizações do LESSONS.md: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Estão espalhados, parecendo menos jobs cron e mais execuções manuais locais ou scripts personalizados.
- Os prompts usados nas revisões noturnas também não estão lá. Qual agente, quantas sessões paralelas — nada documentado.
No meio do caminho, encontrei dois pontos adicionais:
Primeiro, o método envolve contribuições da comunidade. A documentação de subsistemas e as revisões de mudanças semânticas foram introduzidas pelo PR #889 do membro da comunidade Junjie Zhou. As duas tabelas no início do code-standards.md têm crédito explícito no commit 926bcaa3 a seis regras de revisão propostas por Junjie Zhou no Discord.
Segundo, as interações do yetone com os agentes ficam preservadas nos commits. 52 títulos de commits contêm falas originais do yetone entre parênteses:
1(o dono: Isso está feio demais)2(o dono: Por que isso é um seletor nativo em vez do nosso ComboBox abstrato?)3(o dono: Por que isso voltou de novo? Não tínhamos combinado que só devia aparecer no hover? Ficar aparecendo o tempo todo é muito feio)4(dono: Durante o pr-preview, às vezes não tem dados para testar. Você pode ajudar a criar uns dados falsos?)
Na maioria, são reclamações de uma linha; o resto é preenchido pelo agente, muitas vezes resultando em centenas de palavras no corpo do commit. O pedido por dados falsos acabou virando o conjunto de dados mock usado nas gravações do CI.
Humanos apontam o que está errado; agentes transformam isso em mudanças verificáveis. Essas dezenas de títulos de commits explicam a metodologia melhor do que qualquer documento.
Se Você Quiser Construir o Seu
Qualquer um consegue escrever uma tabela de roteamento. O verdadeiro valor a ser copiado é o sistema do caderno de erros. Uma entrada no LESSONS se parece com isto:
1**<Regra em uma frase>**2- <Qual commit/issue causou o problema, qual foi a consequência>3- <Commit de correção>4- Done right: <Exemplo de como fazer corretamente>5- Seen N× (AAAA-MM-DD, AAAA-MM-DD).
Coloque um agente para revisar os commits diários toda noite, procurando apenas retrabalhos, merges ruins e verificações fracas. Se o mesmo problema aparecer em três dias diferentes, mova-o para os padrões de código. Durante a aceitação, liste testes de regressão, uso real e itens não executados nos corpos dos commits e comentários dos PRs.
Depois de revisar o repositório inteiro, o que mais me impressionou foi o limite do Seen 3× (Visto 3×). Os erros são anotados, os agentes leem ao iniciar, e repetir o mesmo erro três vezes o promove a uma regra rígida, encarnando perfeitamente o ditado de que "a terceira vez é a definitiva" (ou melhor, o terceiro strike).
Considerações Finais...
Há um ano, ou mesmo há seis meses, as capacidades dos modelos raramente alcançavam automação em nível de produção. Mas agora, especialmente desde o surgimento do Opus 5.5, podemos ver: o futuro já chegou.
Isso me lembra o Yoyo do @yuanhao, um Agente que vem iterando a si mesmo há mais de 200 dias: https://yoyo-gasp.yolog.dev/, que também vale a pena conferir.
