Il dibattito sull'opportunità o meno di sviluppare software completamente automatizzato dall'IA è finalmente esploso. La scintilla è stata
@yetone che mantiene magpie, criticato dai colleghi come un "servizio da fast food" e "troppo rischioso da usare".
Quasi tutti concordano sul fatto che lo sviluppo software automatizzato dall'IA sia la direzione verso cui stiamo andando. Ma come lo mette in pratica magpie? Ho clonato il repository di magpie, analizzato i 2.862 commit degli ultimi dieci giorni e usato OpenClaw come termine di paragone.
https://x.com/wquguru/status/2109458639501271530
1204 versioni in 19 giorni
magpie è un gateway LLM locale che collega agenti di programmazione come Claude Code, Codex e Gemini CLI a qualsiasi modello o abbonamento. Dal primo commit del 22 settembre a oggi, ha accumulato 9.474 stelle in soli 19 giorni. Dei 2.862 commit, l'account di yetone ne rappresenta l'85%, con 383 PR della community integrati (merged).
Il numero di tag (equivalenti alle versioni) ha raggiunto quota 1.204 in 19 giorni, con una media di oltre 60 versioni al giorno: un ritmo impossibile da sostenere manualmente per un essere umano. Per fare un confronto, OpenClaw ha registrato 1.423 commit nei suoi primi 19 giorni, il 99% dei quali inviati personalmente da Peter Steinberger, con circa 10 tag.
magpie ha il doppio dei commit, ma oltre cento volte più versioni.
L'unica cosa che volevo capire era questa: come fa esattamente l'IA a chiudere il cerchio in questo progetto?
Una tabella di routing e un quaderno degli errori
Il file CLAUDE.md di magpie fa riferimento solo a due documenti: AGENTS.md e LESSONS.md.
AGENTS.md è una tabella di routing. Non definisce regole proprie; si limita a indicare agli agenti quali documenti consultare prima di mettersi al lavoro: controllare docs/subsystems/ prima di modificare i sottosistemi, seguire docs/code-standards.md per scrivere o revisionare il codice e guardare docs/contributors.md per esaminare le PR della community.
La prima frase di LESSONS.md risponde alla domanda iniziale:
Il codice di magpie è scritto, revisionato, integrato e rilasciato dagli agenti. (Il codice di magpie è scritto, revisionato, integrato e rilasciato dagli agenti)
Scrittura, revisione, merge, rilascio: tutto gestito dagli agenti. Senza supervisione umana, perché non crolla tutto? La risposta è in questo file. Con le sue 479 righe, è essenzialmente un quaderno degli errori, compilato dall'agente ogni notte.
Ogni sera, l'agente passa in rassegna tutti i commit della giornata, concentrandosi su tre scenari:
- Quali fix sono stati rifatti da capo?
- Cosa non avrebbe dovuto essere integrato affatto?
- Quali verifiche sono state fatte troppo alla leggera?
Per ogni problema riscontrato, registra una regola, una motivazione e allega i numeri di commit e issue come prova. Ad esempio:
Riproduci l'esatto caso segnalato dal reporter, sulla superficie che utilizza, prima di dichiararlo risolto.
La 834 è tornata indietro 4 volte (v0.1.920 → .925 → .931 → .938). Ogni giro sistemava solo l'agente nello screenshot. Visto 1× (2026-10-05).
L'issue 834 è stata rilavorata quattro volte, e ogni volta veniva corretto solo l'agente mostrato nello screenshot. Da qui la regola: prima di dichiarare un bug risolto, riproduci il problema esattamente sull'interfaccia usata da chi lo ha segnalato.
Il dettaglio chiave è nell'ultima riga: Visto 1×. Se la stessa lezione emerge dalle revisioni in tre giorni diversi, viene spostata da LESSONS.md a code-standards.md, trasformandosi da esperienza vissuta a regola ferrea. Ogni successiva revisione delle PR deve verificarne il rispetto punto per punto.
Otto regole sono già state promosse in questo modo. Tra gli esempi: correggere insieme bug simili (segnalati una volta ciascuno il 5, 6 e 7 ottobre); i test che falliscono su main sono bug da risolvere immediatamente; dichiarare chiaramente cosa è stato testato e su quale commit prima del merge.
Naturalmente, il quaderno degli errori annota anche le cose fatte bene, contrassegnate come Done right, così gli agenti non leggono solo "non fare questo", ma anche "fai quest'altro invece".
Il quaderno degli errori è nato all'alba del 6 ottobre
Questo sistema era previsto fin dall'inizio? Controllando la cronologia dei commit di LESSONS.md, la prima versione è il commit 303819c5, creato alle 3:10 del mattino del 6 ottobre.
Il giorno prima, il 5 ottobre, magpie aveva rilasciato 168 versioni.
La prima versione di LESSONS.md documentava proprio quella giornata. Su 220 commit e circa 170 rilasci, una quarantina serviva a correggere versioni pubblicate quello stesso giorno o il precedente. Le pipeline CI venivano quasi sempre annullate dal push successivo. Un test che falliva solo su Linux è rimasto rosso dalla v0.1.877 alla v0.1.892 senza che nessuno se ne accorgesse.
294 tag in 51 ore non hanno lasciato completare nessuna esecuzione. (294 tag in 51 ore significavano che nessuna esecuzione CI riusciva a completarsi)
Così la prima versione ha introdotto una regola: Prima di creare un tag, la CI per quel commit deve terminare ed essere verde. Le esecuzioni annullate a causa di nuovi push non contano.
168 rilasci il primo giorno, 42 il secondo, 15 il terzo, per poi stabilizzarsi tra 15 e 26.
Nessuna riunione indetta, nessuna notifica inviata. Le revisioni notturne individuavano i problemi, aggiungevano una regola al quaderno degli errori e gli agenti operativi la leggevano, rallentando la frequenza dei rilasci.
Di conseguenza, le ventina di release giornaliere citate di recente come problematiche erano in realtà la velocità raggiunta dopo aver tirato il freno a mano.
I criteri di accettazione delle PR
Passiamo ora alle PR reali:
code-standards.md elenca sei criteri di accettazione. Tutti devono essere soddisfatti prima del merge o del rilascio. Tralasciando i controlli standard come la compilazione su tre piattaforme e i test in sandbox, tre sono piuttosto rari nei progetti tradizionali:
- Test di regressione: ripristina il vecchio codice; i nuovi test devono fallire in modo esplicito, indicando quale comportamento è sbagliato. Errori di compilazione o test saltati non valgono.
- Utilizzo reale: se modifichi l'integrazione di un vendor, verifica con account, configurazioni e risposte API reali. Le funzionalità non testate non possono essere usate come base per altro lavoro né dichiarate utilizzabili agli utenti.
- I controlli non eseguiti devono essere elencati:
Un controllo non eseguito viene elencato come non eseguito, mai omesso. (I controlli non effettuati devono essere elencati come non eseguiti, mai tralasciati)
Ho scelto a caso la #1339 per vedere il commento lasciato prima del merge:
Red check indica il test di regressione, Break check significa rompere intenzionalmente il codice per vedere se i test lo intercettano, e l'ultima riga riporta Not run, ovvero che non è stato testato su hardware reale.
Il comando di merge include --match-head-commit <reviewed sha>. Se qualcuno effettua un push durante la revisione, il merge fallisce, garantendo che non entri codice non revisionato.
L'umano nel ciclo (Human in the Loop)
Certo, gli esseri umani partecipano ancora ad alcune attività, almeno in questi ambiti:
- Decisioni di prodotto: "Non ribaltare decisioni prese consapevolmente." Dettagli come il comportamento dello scroll o i cursori dei pulsanti non possono essere modificati tramite PR.
- Presidi di sicurezza: se scattano i controlli di rischio, si attende l'approvazione del maintainer.
- Suggerimenti della community: 474 titoli di commit menzionano segnalatori da X o Discord, ad esempio JonahFu su X, Jeremy.Zhou su Discord.
In sintesi, gli umani gestiscono la rotta e presiedono i cancelli; scrittura, revisione, merge e rilascio sono affidati agli agenti.
yetone sta nascondendo qualcosa?
A questo punto qualcuno potrebbe chiedersi: yetone ci sta nascondendo qualcosa? Ero curioso anch'io, quindi ho scavato più a fondo.
Effettivamente, alcune cose non si trovano nel repository:
- Come vengono attivate le revisioni notturne non è documentato. Nessuno dei 4 workflow è pianificato.
- Ho estratto gli orari di 7 aggiornamenti di LESSONS.md: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Sono sparpagliati, sembrano meno job cron e più esecuzioni locali manuali o script personalizzati.
- Anche i prompt usati per le revisioni notturne mancano. Quale agente, quante sessioni parallele: nulla di documentato.
Strada facendo, ho trovato altri due dettagli interessanti:
Primo, il metodo si basa sui contributi della community. La documentazione dei sottosistemi e le revisioni dei cambiamenti semantici sono state introdotte tramite la PR #889 del membro della community Junjie Zhou. Le due tabelle all'inizio di code-standards.md sono esplicitamente attribuite nel commit 926bcaa3 a sei regole di revisione proposte da Junjie Zhou su Discord.
Secondo, le interazioni di yetone con gli agenti sono conservate nei commit. 52 titoli di commit contengono le citazioni originali di yetone tra parentesi:
1(il proprietario: Questo è troppo brutto)2(il proprietario: Perché questo è un selettore nativo invece del nostro ComboBox astratto?)3(il proprietario: Perché è tornato di nuovo? Non avevamo detto che doveva comparire solo al passaggio del mouse? Vederlo sempre è troppo brutto)4(proprietario: Durante il pr-preview, a volte non ci sono dati da testare. Puoi aiutarmi a creare dei dati finti?)
Si tratta per lo più di lamentele di una riga; il resto lo completa l'agente, arrivando spesso a centinaia di parole nel corpo del commit. La richiesta di dati finti è poi diventata il set di dati mock utilizzato per le registrazioni CI.
Gli umani indicano cosa non va; gli agenti lo trasformano in modifiche verificabili. Queste decine di titoli di commit spiegano la metodologia meglio di qualsiasi documento.
Se vuoi costruirne uno tuo
Chiunque può scrivere una tabella di routing. Il vero valore da copiare è il sistema del quaderno degli errori. Una voce di LESSONS si presenta così:
1**<Regola in una frase>**2- <Quale commit/issue ha causato il problema, quali sono state le conseguenze>3- <Commit di fix>4- Done right: <Esempio di come farlo correttamente>5- Seen N× (AAAA-MM-GG, AAAA-MM-GG).
Fai revisionare i commit giornalieri da un agente ogni notte, cercando esclusivamente rilavorazioni, merge errati e verifiche deboli. Se lo stesso problema compare in tre giorni diversi, spostalo negli standard di codice. Durante l'accettazione, elenca i test di regressione, l'utilizzo reale e le voci non verificate nei corpi dei commit e nei commenti alle PR.
Dopo aver analizzato l'intero repo, la cosa che mi ha colpito di più è stata la soglia del Seen 3×. Gli errori vengono messi per iscritto, gli agenti li leggono all'avvio e ripetere lo stesso sbaglio tre volte lo promuove a regola ferrea, incarnando perfettamente il detto "non c'è due senza tre" (o meglio, al terzo strike sei fuori).
Considerazioni finali...
Un anno fa, o anche solo sei mesi fa, le capacità dei modelli raramente raggiungevano un livello di automazione pronto per la produzione. Ma ora, soprattutto da quando è emerso Opus 5.5, possiamo vederlo con i nostri occhi: il futuro è già qui.
Questo mi ricorda Yoyo di @yuanhao, un Agente che si auto-itera da oltre 200 giorni: https://yoyo-gasp.yolog.dev/, merita sicuramente un'occhiata.
