Le débat sur la légitimité d'une construction logicielle entièrement automatisée par l'IA a enfin éclaté. L'élément déclencheur :
@yetone qui maintient magpie, un projet que ses pairs ont qualifié de « service de fast-food » et jugé « trop risqué à utiliser ».
La plupart des gens s'accordent à dire que la construction logicielle automatisée par l'IA est la tendance de fond. Mais concrètement, comment magpie met-il cela en pratique ? J'ai cloné le dépôt magpie, analysé les 2 862 commits des dix derniers jours, et utilisé OpenClaw comme point de comparaison.
https://x.com/wquguru/status/2109458639501271530
1204 versions en 19 jours
magpie est une passerelle LLM locale qui connecte des agents de code comme Claude Code, Codex et Gemini CLI à n'importe quel modèle ou abonnement. Du premier commit le 22 septembre à aujourd'hui, il a accumulé 9 474 stars en 19 jours. Sur les 2 862 commits, le compte de yetone en représente 85 %, avec la fusion de 383 PR issues de la communauté.
Le nombre de tags (l'équivalent des versions) a atteint 1 204 en 19 jours, soit une moyenne de plus de 60 versions par jour — une cadence qu'un humain ne pourrait tout simplement pas tenir manuellement. À titre de comparaison, OpenClaw a enregistré 1 423 commits lors de ses 19 premiers jours, dont 99 % soumis par Peter Steinberger lui-même, pour environ 10 tags.
magpie compte deux fois plus de commits, mais plus de cent fois plus de versions.
Ce que je voulais comprendre tenait en une seule question : comment exactement l'IA boucle-t-elle la boucle sur ce projet ?
Une table de routage et un carnet d'erreurs
Le fichier CLAUDE.md de magpie ne référence que deux fichiers : AGENTS.md et LESSONS.md.
AGENTS.md est une table de routage. Il ne définit pas de règles lui-même ; il indique simplement aux agents quels documents consulter avant de se mettre au travail : vérifier docs/subsystems/ avant de modifier des sous-systèmes, suivre docs/code-standards.md pour écrire ou relire du code, et consulter docs/contributors.md pour examiner les PR de la communauté.
La première phrase de LESSONS.md répond directement à notre question initiale :
Le code de magpie est écrit, relu, fusionné et publié par des agents. (Le code de magpie est écrit, relu, fusionné et publié par des agents)
Écriture, relecture, fusion, publication : tout est géré par des agents. Sans supervision humaine, pourquoi le système ne s'effondre-t-il pas ? La réponse se trouve dans ce fichier. Avec ses 479 lignes, il s'agit essentiellement d'un carnet d'erreurs, rédigé chaque nuit par l'agent.
Toutes les nuits, l'agent passe en revue l'ensemble des commits de la journée, en se concentrant sur trois scénarios :
- Quels correctifs ont dû être repris ?
- Qu'est-ce qui n'aurait jamais dû être fusionné ?
- Quelles vérifications ont été bâclées ?
Pour chaque problème détecté, il consigne une règle, une justification, et joint les numéros de commit et d'issue comme preuves. Par exemple :
Reproduis exactement le cas signalé par l'utilisateur, sur l'interface qu'il utilise réellement, avant de déclarer le bug corrigé.
L'issue 834 est revenue 4 fois (v0.1.920 → .925 → .931 → .938). À chaque passage, seul l'agent visible sur la capture d'écran était corrigé. Vu 1× (2026-10-05).
L'issue 834 a nécessité quatre reprises, chacune ne corrigeant que l'agent montré sur la capture d'écran. D'où la règle : avant de crier victoire, reproduisez le problème à l'identique sur l'interface utilisée par la personne qui l'a signalé.
Le détail crucial se trouve à la dernière ligne : Vu 1×. Si la même leçon apparaît lors des revues de trois journées différentes, elle migre de LESSONS.md vers code-standards.md, passant du statut d'expérience vécue à celui de règle absolue. Chaque revue de PR ultérieure doit ensuite vérifier ces règles point par point.
Huit règles ont déjà été promues de cette manière. Parmi elles : regrouper les corrections de bugs similaires (constaté une fois les 5, 6 et 7 octobre) ; un test qui échoue sur main est un bug à corriger immédiatement ; et préciser clairement ce qui a été testé et sur quel commit avant toute fusion.
Bien sûr, le carnet d'erreurs note aussi ce qui a bien fonctionné, avec la mention Done right, afin que les agents ne lisent pas seulement « ne fais pas ça », mais aussi « fais plutôt ceci ».
Le carnet d'erreurs a été introduit tôt le matin du 6 octobre
Ce système avait-il été pensé dès le départ ? En consultant l'historique des commits de LESSONS.md, on découvre que la première version (commit 303819c5) a été créée le 6 octobre à 3 h 10 du matin.
La veille, le 5 octobre, magpie avait publié 168 versions.
Cette première version de LESSONS.md fait le bilan de cette journée-là. Sur 220 commits et environ 170 publications, une quarantaine consistaient à corriger des versions sorties le jour même ou la veille. Le CI était presque systématiquement annulé par le push suivant. Un test qui n'échouait que sous Linux est resté au rouge de la v0.1.877 à la v0.1.892 sans que personne ne le remarque.
294 tags en 51 heures n'ont laissé aucune exécution aller à son terme. (294 tags en 51 heures signifiaient qu'aucune exécution CI ne pouvait aboutir)
La première version a donc ajouté une règle : Avant de poser un tag, le CI de ce commit doit être terminé et au vert. Les exécutions annulées suite à de nouveaux pushes ne comptent pas.
168 publications le premier jour, 42 le deuxième, 15 le troisième, puis une stabilisation entre 15 et 26.
Aucune réunion n'a été organisée, aucune notification envoyée. Les revues nocturnes ont identifié les problèmes, ajouté une règle au carnet d'erreurs, et les agents au travail l'ont lue, ralentissant ainsi la fréquence des publications.
Par conséquent, la vingtaine de publications quotidiennes récemment pointées du doigt comme problématiques représentaient en réalité la vitesse... après avoir appuyé sur le frein.
Les critères d'acceptation des PR
Passons maintenant aux PR réelles :
code-standards.md liste six critères d'acceptation. Tous doivent être validés avant toute fusion ou publication. Outre les vérifications classiques comme la compilation sur trois plateformes et les tests en bac à sable, trois d'entre eux sont rares dans les projets habituels :
- Test de non-régression : remettre l'ancien code en place ; les nouveaux tests doivent explicitement échouer en indiquant quel comportement est incorrect. Les erreurs de compilation ou les tests ignorés ne comptent pas.
- Usage réel : si vous modifiez une intégration fournisseur, vérifiez-la avec de vrais comptes, configurations et réponses API. Une fonctionnalité non testée ne peut ni servir de base à d'autres développements, ni être présentée comme utilisable aux utilisateurs.
- Les vérifications non effectuées doivent être listées :
Une vérification non effectuée est listée comme telle, jamais omise. (Les vérifications non réalisées doivent être listées comme non effectuées, jamais passées sous silence)
J'ai tiré au sort la PR #1339 pour voir le commentaire laissé avant la fusion :
Red check désigne le test de non-régression, Break check signifie casser volontairement le code pour voir si les tests le détectent, et la dernière ligne indique Not run — autrement dit, aucun test sur matériel réel n'a été effectué.
La commande de fusion inclut --match-head-commit <reviewed sha>. Si quelqu'un pousse du code pendant la revue, la fusion échoue, garantissant qu'aucun code non relu ne passe entre les mailles du filet.
L'humain dans la boucle
Bien sûr, les humains participent encore à certaines tâches, au moins dans ces domaines :
- Décisions produit : « Ne revenez pas sur les décisions délibérées. » Des éléments comme le comportement du défilement ou le curseur des boutons ne peuvent pas être modifiés via des PR.
- Barrières de sécurité : si les contrôles de risque se déclenchent, il faut attendre l'approbation du mainteneur.
- Suggestions de la communauté : 474 titres de commits mentionnent des personnes ayant fait des retours sur X ou Discord, par exemple JonahFu sur X, Jeremy.Zhou sur Discord.
En résumé, les humains définissent le cap et gardent les portes ; l'écriture, la relecture, la fusion et la publication sont confiées aux agents.
yetone nous cache-t-il quelque chose ?
À ce stade, certains pourraient se demander : yetone nous cache-t-il quelque chose ? Ma curiosité a été piquée, alors j'ai creusé.
Effectivement, plusieurs éléments ne figurent pas dans le dépôt :
- La façon dont les revues nocturnes sont déclenchées n'est pas documentée. Aucun des 4 workflows n'est planifié.
- J'ai extrait les horaires de 7 mises à jour de LESSONS.md : 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Ils sont éparpillés, ce qui ressemble moins à des tâches cron qu'à des exécutions locales manuelles ou à des scripts personnalisés.
- Les prompts utilisés pour les revues nocturnes sont également absents. Quel agent, combien de sessions parallèles : rien n'est documenté.
Au passage, j'ai relevé deux autres points :
Premièrement, la méthode s'appuie sur les contributions de la communauté. La documentation des sous-systèmes et les revues de changements sémantiques ont été introduites via la PR #889 du membre de la communauté Junjie Zhou. Les deux tableaux au début de code-standards.md sont explicitement attribués, dans le commit 926bcaa3, à six règles de revue proposées par Junjie Zhou sur Discord.
Deuxièmement, les interactions de yetone avec les agents sont conservées dans les commits. 52 titres de commits contiennent les citations originales de yetone entre parenthèses :
1(le propriétaire : C'est beaucoup trop moche)2(le propriétaire : Pourquoi est-ce un sélecteur natif plutôt que notre ComboBox abstrait ?)3(le propriétaire : Pourquoi est-ce revenu ? On n'avait pas dit que ça ne devait apparaître qu'au survol ? L'affichage permanent est vraiment trop moche)4(propriétaire : Pendant le pr-preview, il n'y a parfois pas de données à tester. Tu peux m'aider à créer de fausses données ?)
Il s'agit le plus souvent de reproches en une ligne ; l'agent se charge du reste, ce qui donne fréquemment des centaines de mots dans le corps du commit. La demande de fausses données est d'ailleurs devenue le jeu de données mock utilisé pour les enregistrements CI.
Les humains pointent ce qui cloche ; les agents le transforment en modifications vérifiables. Ces quelques dizaines de titres de commits expliquent mieux la méthodologie que n'importe quelle documentation.
Si vous voulez construire le vôtre
N'importe qui peut écrire une table de routage. La véritable valeur à copier, c'est le système du carnet d'erreurs. Une entrée LESSONS ressemble à ceci :
1**<Règle en une phrase>**2- <Quel commit/issue a causé le problème, quelle en a été la conséquence>3- <Commit de correction>4- Done right : <Exemple de bonne pratique>5- Vu N× (AAAA-MM-JJ, AAAA-MM-JJ).
Demandez à un agent de revoir chaque nuit les commits de la journée, en cherchant uniquement les reprises, les mauvaises fusions et les vérifications insuffisantes. Si le même problème apparaît sur trois journées différentes, faites-le migrer vers les standards de code. Lors de l'acceptation, listez les tests de non-régression, les usages réels et les éléments non vérifiés dans les corps de commit et les commentaires de PR.
Après avoir passé tout le dépôt au peigne fin, ce qui m'a le plus marqué, c'est ce seuil de « Vu 3× ». Les erreurs sont consignées, les agents les lisent au démarrage, et répéter trois fois la même faute la transforme en règle absolue. C'est l'illustration parfaite du dicton « jamais deux sans trois » (ou plutôt, ici, trois strikes et t'es out).
En conclusion...
Il y a un an, ou même il y a six mois, les capacités des modèles atteignaient rarement le niveau requis pour une automatisation en production. Mais aujourd'hui, surtout depuis l'arrivée d'Opus 5.5, le constat est clair : le futur est déjà là.
Cela me rappelle Yoyo de @yuanhao, un Agent qui s'auto-itère depuis plus de 200 jours : https://yoyo-gasp.yolog.dev/, un projet qui mérite aussi le détour.
