Die Debatte darüber, ob vollständig KI-automatisierte Softwareentwicklung überhaupt existieren sollte, ist endlich entbrannt. Auslöser war
@yetone mit der Weiterentwicklung von magpie, was von anderen als „Fast-Food-Service" und „zu riskant für den Einsatz" kritisiert wurde.
Die meisten sind sich einig: KI-automatisierte Softwareentwicklung ist der Trend. Aber wie setzt magpie das in der Praxis um? Ich habe mir magpie heruntergeladen, die 2.862 Commits der letzten zehn Tage analysiert und zum Vergleich OpenClaw herangezogen.
https://x.com/wquguru/status/2109458639501271530
1204 Versionen in 19 Tagen
magpie ist ein lokales LLM-Gateway, das Coding-Agents wie Claude Code, Codex und Gemini CLI mit jedem beliebigen Modell oder Abo verbindet. Vom ersten Commit am 22. September bis heute hat es in 19 Tagen 9.474 Stars gesammelt. Von den 2.862 Commits gehen 85 % auf yetones Konto zurück, der 383 Community-PRs gemergt hat.
Die Anzahl der Tags (also der Versionen) erreichte in 19 Tagen 1.204 – im Schnitt über 60 Versionen pro Tag. Eine Frequenz, die kein Mensch manuell durchhalten könnte. Zum Vergleich: OpenClaw hatte in seinen ersten 19 Tagen 1.423 Commits, von denen 99 % von Peter Steinberger selbst stammten, bei etwa 10 Tags.
magpie hat also doppelt so viele Commits, aber über hundertmal mehr Versionen.
Was ich herausfinden wollte, war eine einzige Sache: Wie genau schließt die KI in diesem Projekt den Kreislauf?
Eine Routing-Tabelle und ein Fehlerheft
Die CLAUDE.md von magpie verweist nur auf zwei Dateien: AGENTS.md und LESSONS.md.
AGENTS.md ist eine Routing-Tabelle. Sie definiert keine eigenen Regeln, sondern sagt den Agents lediglich, welche Dokumente sie vor der Arbeit konsultieren sollen: Vor Änderungen an Subsystemen einen Blick in docs/subsystems/ werfen, beim Schreiben und Prüfen von Code docs/code-standards.md befolgen und für das Review von Community-PRs docs/contributors.md lesen.
Der erste Satz in LESSONS.md beantwortet bereits die Eingangsfrage:
Der Code von magpie wird von Agents geschrieben, geprüft, gemergt und veröffentlicht. (Der Code von magpie wird von Agents geschrieben, geprüft, gemergt und veröffentlicht)
Schreiben, prüfen, mergen, veröffentlichen – alles erledigen die Agents. Warum fliegt uns das ohne menschliche Aufsicht nicht um die Ohren? Die Antwort steckt in dieser Datei. Mit 479 Zeilen ist sie im Grunde ein Fehlerheft, das der Agent jede Nacht schreibt.
Jede Nacht geht der Agent alle Commits des Tages durch und konzentriert sich dabei auf drei Szenarien:
- Welche Fixes mussten nachgebessert werden?
- Was hätte gar nicht erst gemergt werden dürfen?
- Bei welchen Prüfungen wurde geschlampt?
Für jedes gefundene Problem notiert er eine Regel, eine Begründung und hängt Commit- sowie Issue-Nummern als Beleg an. Zum Beispiel:
Reproduziere exakt den Fall des Reporters, auf der Oberfläche, die er nutzt, bevor du etwas als behoben markierst.
834 kam viermal zurück (v0.1.920 → .925 → .931 → .938). Jede Runde hat nur den Agent im Screenshot repariert. Seen 1× (2026-10-05).
Issue 834 musste viermal nachgebessert werden, wobei jedes Mal nur der Agent aus dem Screenshot korrigiert wurde. Die Regel lautet also: Bevor du etwas als gelöst abhakst, reproduziere das Problem exakt auf der Benutzeroberfläche, die der Reporter verwendet.
Entscheidend ist die letzte Zeile: Seen 1×. Taucht dieselbe Erkenntnis an drei verschiedenen Tagen in den Reviews auf, wandert sie von LESSONS.md in die code-standards.md und wird von einer Erfahrungswerte zu einer festen Regel. Jedes weitere PR-Review muss dann Punkt für Punkt gegen diese Regeln geprüft werden.
Acht Regeln wurden auf diesem Weg bereits befördert. Beispiele: Ähnliche Bugs zusammen beheben (jeweils einmal am 5., 6. und 7. Oktober bemerkt); fehlschlagende Tests auf main sind sofort zu behebende Bugs; vor dem Mergen klar angeben, was und auf welchem Commit getestet wurde.
Natürlich hält das Fehlerheft auch Dinge fest, die gut liefen – markiert mit Done right. So lesen die Agents nicht nur „mach das nicht", sondern auch „mach es stattdessen so".
Das Fehlerheft wurde am frühen Morgen des 6. Oktober eingeführt
War dieses System von Anfang an so geplant? Ein Blick in die Commit-Historie von LESSONS.md zeigt: Die erste Version war Commit 303819c5, erstellt am 6. Oktober um 3:10 Uhr morgens.
Einen Tag zuvor, am 5. Oktober, hatte magpie 168 Versionen veröffentlicht.
Die erste Version von LESSONS.md hielt genau diesen Tag fest. Bei 220 Commits und rund 170 Releases waren etwa 40 davon Fixes für Versionen desselben oder des Vortags. CI wurde fast immer durch den nächsten Push abgebrochen. Ein Test, der nur unter Linux fehlschlug, blieb von v0.1.877 bis v0.1.892 rot, ohne dass es jemandem auffiel.
294 Tags in 51 Stunden ließen keinen einzigen Durchlauf abschließen. (294 Tags in 51 Stunden bedeuteten, dass kein einziger CI-Durchlauf abgeschlossen werden konnte)
Deshalb fügte die erste Version eine Regel hinzu: Vor dem Taggen muss die CI für diesen Commit durchgelaufen und grün sein. Abbrüche durch neue Pushes zählen nicht.
168 Releases am ersten Tag, 42 am zweiten, 15 am dritten, danach pendelte es sich zwischen 15 und 26 ein.
Es gab keine Meetings, keine Benachrichtigungen. Die nächtlichen Reviews fanden Probleme, fügten dem Fehlerheft eine Regel hinzu, die arbeitenden Agents lasen sie – und bremsten die Release-Frequenz ein.
Die gut zwanzig Releases pro Tag, die kürzlich als problematisch kritisiert wurden, waren also bereits das Tempo nach dem Tritt auf die Bremse.
Akzeptanzkriterien für PRs
Schauen wir uns nun echte PRs an:
Die code-standards.md listet sechs Akzeptanzkriterien auf. Alle müssen erfüllt sein, bevor gemergt oder released wird. Neben Standardprüfungen wie Kompilierung auf drei Plattformen und Sandbox-Tests fallen drei auf, die in typischen Projekten selten sind:
- Regressionstest: Den alten Code wieder einsetzen; die neuen Tests müssen explizit fehlschlagen und zeigen, welches Verhalten falsch ist. Kompilierungsfehler oder übersprungene Tests zählen nicht.
- Echte Nutzung: Wenn eine Vendor-Integration geändert wird, muss sie mit echten Accounts, Configs und API-Antworten geprüft werden. Ungetestete Features dürfen weder darauf aufgebaut noch Usern als nutzbar verkauft werden.
- Nicht ausgeführte Checks müssen aufgelistet werden:
Ein Check, der nicht ausgeführt wurde, wird als „nicht ausgeführt" gelistet, niemals weggelassen. (Nicht durchgeführte Checks müssen als „nicht ausgeführt" gelistet werden, niemals einfach weggelassen)
Ich habe mir zufällig #1339 herausgepickt, um den Kommentar vor dem Merge zu sehen:
Red check steht für den Regressionstest, Break check bedeutet, den Code absichtlich kaputtzumachen, um zu sehen, ob die Tests anschlagen, und die letzte Zeile besagt Not run – es wurde also nicht auf echter Hardware getestet.
Der Merge-Befehl enthält --match-head-commit <reviewed sha>. Wenn während des Reviews jemand pusht, schlägt der Merge fehl. So landet kein ungeprüfter Code im Repo.
Human in the Loop
Natürlich greifen Menschen noch an einigen Stellen ein, mindestens in diesen Bereichen:
- Produktentscheidungen: „Gewollte Entscheidungen nicht rückgängig machen." Dinge wie Scrollverhalten oder Button-Cursor dürfen per PR nicht geändert werden.
- Sicherheits-Schleusen: Wenn Risikoprüfungen anschlagen, muss auf die Freigabe durch den Maintainer gewartet werden.
- Community-Vorschläge: 474 Commit-Titel erwähnen Reporter von X oder Discord, z. B. JonahFu auf X, Jeremy.Zhou auf Discord.
Kurz gesagt: Menschen geben die Richtung vor und bewachen die Schleusen; Schreiben, Prüfen, Mergen und Veröffentlichen übernehmen die Agents.
Verheimlicht yetone etwas?
An diesem Punkt fragen sich manche vielleicht: Verheimlicht yetone etwas? Das hat mich auch interessiert, also habe ich tiefer gegraben.
Tatsächlich fehlen einige Dinge im Repo:
- Wie die nächtlichen Reviews ausgelöst werden, ist nicht dokumentiert. Keiner der 4 Workflows ist zeitgesteuert.
- Ich habe die Zeiten von 7 LESSONS.md-Updates extrahiert: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Sie sind weit gestreut, was weniger nach Cron-Jobs aussieht und eher nach manuellen lokalen Läufen oder eigenen Skripten.
- Auch die Prompts für die nächtlichen Reviews fehlen. Welcher Agent, wie viele parallele Sessions – nichts davon ist dokumentiert.
Nebenbei bin ich auf zwei weitere Punkte gestoßen:
Erstens fließen Community-Beiträge in die Methode ein. Die Dokumentation der Subsysteme und semantische Change-Reviews kamen über PR #889 des Community-Mitglieds Junjie Zhou ins Projekt. Die beiden Tabellen am Anfang der code-standards.md werden in Commit 926bcaa3 ausdrücklich auf sechs Review-Regeln zurückgeführt, die Junjie Zhou auf Discord vorgeschlagen hat.
Zweitens bleiben yetones Interaktionen mit den Agents in den Commits erhalten. 52 Commit-Titel enthalten yetones Originalzitate in Klammern:
1(der Owner: Das ist viel zu hässlich)2(der Owner: Warum ist das ein nativer Selector und nicht unsere abstrakte ComboBox?)3(der Owner: Warum taucht das schon wieder auf? Hatten wir nicht gesagt, es soll nur beim Hover erscheinen? Dauerhaft sichtbar ist viel zu hässlich)4(Owner: Beim pr-preview gibt es manchmal keine Daten zum Testen. Kannst du ein paar Fake-Daten erzeugen?)
Das sind meist einzeilige Beschwerden; den Rest füllt der Agent aus, was oft zu hunderten Wörtern im Commit-Body führt. Die Bitte um Fake-Daten wurde später zum Mock-Datensatz für die CI-Aufzeichnungen.
Menschen zeigen auf, was falsch läuft; Agents machen daraus überprüfbare Änderungen. Diese paar Dutzend Commit-Titel erklären die Methodik besser als jedes Dokument.
Wenn du dein eigenes bauen willst
Eine Routing-Tabelle kann jeder schreiben. Der eigentliche Wert zum Kopieren ist das Fehlerheft-System. Ein LESSONS-Eintrag sieht so aus:
1**<Regel in einem Satz>**2- <Welcher Commit/das Issue hat das Problem verursacht, was war die Folge>3- <Fix-Commit>4- Done right: <Beispiel für die korrekte Umsetzung>5- Seen N× (JJJJ-MM-TT, JJJJ-MM-TT).
Lass einen Agent jede Nacht die täglichen Commits prüfen, ausschließlich auf Nachbesserungen, schlechte Merges und schwache Verifizierungen. Taucht dasselbe Problem an drei verschiedenen Tagen auf, verschiebe es in die Code-Standards. Liste bei der Abnahme Regressionstests, echte Nutzung und nicht ausgeführte Punkte in Commit-Bodys und PR-Kommentaren auf.
Nachdem ich das gesamte Repo durchgegangen bin, hat mich die Seen 3×-Schwelle am meisten beeindruckt. Fehler werden aufgeschrieben, Agents lesen sie beim Start, und wer denselben Fehler dreimal macht, befördert ihn zur festen Regel – eine perfekte Umsetzung des Sprichworts „aller guten Dinge sind drei" (oder in diesem Fall eher: drei Strikes und du bist raus).
Abschließende Gedanken ...
Noch vor einem Jahr, ja sogar vor einem halben Jahr, reichten die Fähigkeiten der Modelle selten für Automatisierung auf Produktionsniveau. Aber jetzt, besonders seit Opus 5.5 auf der Bildfläche erschien, sehen wir: Die Zukunft ist da.
Das erinnert mich an Yoyo von @yuanhao, ein Agent, der sich seit über 200 Tagen selbst iteriert: https://yoyo-gasp.yolog.dev/ – ebenfalls einen Blick wert.
