O debate sobre se a construção de software totalmente automatizada por IA deveria existir finalmente explodiu. 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 natural. Mas como o magpie coloca isso em prática? Eu clonei o repositório do magpie, analisei os 2.862 commits dos últimos dez dias e usei o OpenClaw como base de comparação.
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 apenas 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 ser mantido manualmente por humanos. Em contrapartida, o OpenClaw teve 1.423 commits nos seus 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 escreve regras por conta própria; apenas diz aos agentes quais documentos consultar antes de executar uma tarefa: verificar docs/subsystems/ antes de modificar subsistemas, seguir docs/code-standards.md ao escrever/revisar código e olhar docs/contributors.md ao 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 funciona essencialmente como 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?
- O que nunca deveria ter sido mesclado?
- Quais verificações foram negligentes demais?
Para cada problema encontrado, ele registra uma regra, um motivo e anexa os números de commit e issue como evidência. Por exemplo:
Reproduza o caso exato relatado pelo usuário, na interface que ele usa, antes de considerar o problema resolvido.
A issue 834 voltou 4 vezes (v0.1.920 → .925 → .931 → .938). Cada rodada corrigia apenas o agente mostrado no print. Visto 1× (2026-10-05).
A issue 834 precisou ser refeita quatro vezes, e em cada tentativa corrigia apenas o agente exibido na captura de tela. Daí a regra: antes de dar algo como resolvido, 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, transformando experiência em regra rígida. 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 em cada dia: 5, 6 e 7 de outubro); testes falhando na main são bugs imediatos a serem corrigidos; e declarar claramente o que foi testado e em qual commit antes de fazer o merge.
É claro que o caderno de erros também registra acertos, marcados como Done right (Feito certo), para que os agentes leiam não apenas "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? Ao checar 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 dia anterior. O CI quase sempre era cancelado pelo push seguinte. Um teste que falhava apenas no Linux ficou vermelho da v0.1.877 até a v0.1.892 sem que ninguém percebesse.
294 tags em 51 horas não deixaram nenhuma execução terminar. (294 tags em 51 horas significavam que nenhuma execução de 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 os problemas, adicionaram uma regra ao caderno de erros, e os agentes em atividade leram essa regra, reduzindo a frequência de lançamentos.
Portanto, as pouco mais de vinte versões diárias apontadas recentemente como problemáticas eram, na verdade, a velocidade depois de pisar no freio.
Critérios de Aceitação de PRs
Agora, vamos analisar PRs reais:
O code-standards.md lista seis critérios de aceitação. Todos precisam ser aprovados antes do merge ou lançamento. Deixando de lado verificações padrão como compilação em três plataformas e testes em sandbox, três deles são raros em projetos comuns:
- Teste de Regressão: Volte o código antigo; os novos testes devem falhar explicitamente, apontando qual comportamento está errado. Erros de compilação ou testes ignorados não contam.
- Uso Real: Se estiver alterando uma integração de 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 deve ser listada como não executada, nunca omitida. (Checks não realizados devem ser listados como não executados, nunca omitidos)
Escolhi aleatoriamente o #1339 para ver o comentário deixado antes do merge:
Red check significa teste de regressão, Break check significa quebrar o código intencionalmente para ver se os testes pegam o erro, 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 na base.
Humano no Loop
É claro que humanos ainda participam de algumas tarefas, pelo menos nestas áreas:
- Decisões de produto: "Não reverta decisões deliberadas." Coisas como comportamento de rolagem ou cursores de botões não podem ser alteradas via PRs.
- Portões de Segurança: Se as verificações de risco forem acionadas, aguarde a aprovação do mantenedor.
- Sugestões da Comunidade: 474 títulos de commits mencionam relatores do X ou Discord, por exemplo, JonahFu no X, Jeremy.Zhou no Discord.
Em resumo, humanos gerenciam a direção e vigiam os portões; 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 mais a fundo.
De fato, algumas coisas não estão no repositório:
- Como as revisões noturnas são acionadas 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 com cron jobs e mais com 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 disso está 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 citações 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ó deveria aparecer no hover? Ficar aparecendo o tempo todo é muito feio)4(dono: Durante o pr-preview, às vezes não há dados para testar. Você pode ajudar a criar alguns 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 de 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).
Faça um agente revisar os commits diariamente todas as noites, procurando apenas retrabalho, 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×. Os erros são anotados, os agentes os leem ao iniciar, e repetir o mesmo erro três vezes o promove a uma regra rígida, materializando 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 uma 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 de @yuanhao, um Agente que vem se autoiterando há mais de 200 dias: https://yoyo-gasp.yolog.dev/, que também vale a pena conferir.
