Stripe Minions: über 1.300 PRs pro Woche von Agenten
Die Coding-Agenten Stripe Minions liefern jetzt über 1.300 gemergte Pull Requests pro Woche, teilte Stripe am 19. Februar 2026 in einem Engineering-Beitrag mit, zuvor waren es 1.000. Jede Änderung prüft ein Mensch, enthält aber keinen von Menschen geschriebenen Code. Für Engineering-Teams zeigt der Fall unbeaufsichtigte Agenten, die den steten Strom kleiner Upgrades und Fixes übernehmen, während Ingenieure bei jedem Merge das letzte Wort behalten.
Warum Stripe Agenten wollte, die ohne Aufsicht arbeiten
Stripes Problem war Größe in einer Codebasis, in der Fehler teuer sind. Der Code, an dem die Agenten arbeiten, trägt ein jährliches Zahlungsvolumen von mehr als 1 Billion Dollar und hängt von Finanzinstituten, regulatorischen Rahmen und Compliance-Pflichten ab, berichtet InfoQ.
Interaktive Werkzeuge wie Cursor und Claude Code standen Stripe-Ingenieuren schon zur Verfügung, aber sie arbeiten als Begleiter, bei dem ein Ingenieur jeden Schritt beobachtet. Stripe wollte ein anderes Werkzeug: eines, das eine einzelne Anweisung nimmt und einen fertigen Pull Request zurückgibt, ohne dass jemand den Lauf beaufsichtigt.
Was Stripe gebaut hat: die Minions-Agenten
Minions sind Stripes hauseigene, unbeaufsichtigte Coding-Agenten. Ende 2024 hat Stripe den Coding-Agenten goose von Block geforkt und für die eigene LLM-Infrastruktur angepasst, dann die Entwicklung auf die Bedürfnisse unbeaufsichtigter Läufe ausgerichtet.
„Das Einzigartigste an Minions ist das Fehlen eines beaufsichtigenden Menschen." Stripe über seine Coding-Agenten Minions
Eine Aufgabe kann aus einem Slack-Thread, einem Fehlerbericht oder einer Funktionsanfrage starten. Der Minion schreibt Code, Tests und Dokumentation, und der Lauf endet mit einem Pull Request, den ein Ingenieur vor dem Merge prüft.
Wie Minions im Alltag laufen
Jeder Minion läuft auf einer Devbox, derselben Cloud-Entwicklungsumgebung, die Stripe-Ingenieure nutzen: eine AWS-EC2-Instanz mit Stripes Quellcode. Stripe hält einen vorgewärmten Pool von Devboxes bereit, sodass innerhalb von 10 Sekunden eine neue bereit ist, mit geklonten Repositories und aufgebauten Caches. Weil jede Devbox isoliert ist, bleibt ein Fehler in einer Box, deshalb kann der Agent mit vollen Rechten laufen und Bestätigungsabfragen überspringen.
Die Arbeit folgt einem Blueprint, einem im Code definierten Ablauf. Manche Schritte sind Agentenschleifen mit Entscheidungsspielraum, etwa „Aufgabe umsetzen" oder „CI-Fehler beheben". Andere sind fester Code, der nie ein Modell aufruft, etwa „Konfigurierte Linter ausführen" oder „Änderungen pushen". Stripe sagt, vorhersehbare Schritte im Code festzulegen spare im großen Maßstab Token und CI-Kosten und lasse dem Agenten weniger Raum für Fehler.
Um die Codebasis zu lernen, lesen Minions Regeldateien, die auf bestimmte Ordner und Dateimuster begrenzt sind, im selben Format, das Cursor nutzt, sodass Menschen und Agenten dieselben Hinweise teilen. Erzeugte Änderungen durchlaufen dann CI/CD-Pipelines, automatisierte Tests und statische Analyse vor der menschlichen Prüfung.
Was die Ergebnisse von Stripe Minions zeigen
Das gemessene Ergebnis ist die Menge. In einem Beitrag vom 19. Februar 2026 schrieb Stripes Alistair Gray, dass über 1.300 Stripe-Pull-Requests pro Woche vollständig von Minions erzeugt gemergt werden, nach 1.000 im ersten Teil der Serie. Jeder wird von einem Menschen geprüft, keiner enthält von Menschen geschriebenen Code.
Engineering Manager Cameron Bernhardt schrieb, die Agenten erzeugten Änderungen zunehmend von Anfang bis Ende. Stripe-Ingenieure sagen, Minions seien bei klar umrissenen Aufgaben am besten, etwa Konfigurationsänderungen, Abhängigkeits-Upgrades und kleinen Refactorings. Zahlen zu eingesparter Zeit, Prüfaufwand oder Fehlerquoten hat Stripe nicht veröffentlicht.
Was autonome Coding-Agenten für Engineering-Teams ändern
Für ein Unternehmen übernehmen Minions den steten Strom kleiner, klar umrissener Änderungen, die sich in einer großen Codebasis anhäufen: Upgrades, Einstellungen und Aufräumarbeiten, für die niemand einen Nachmittag opfern will. Verlagert man diese Arbeit auf Agenten, bleibt Zeit für Entwurf und Prüfung, und für jeden Merge bleibt ein Mensch verantwortlich.
Stripes Fall zeigt auch, wohin die Investition fließt. Das Modell ist nur ein Teil. Die Gewinne kommen aus Infrastruktur, die früher für Menschen gebaut wurde: schnelle, isolierte Entwicklungsumgebungen, gute Tests und gemeinsame Regeldateien. Teams bei Stripe haben außerdem eigene Blueprints für Migrationen über die ganze Codebasis gebaut, die eine einfache skriptgesteuerte Codeänderung nicht bewältigt hätte.
Fragen und Antworten
Wie viele Pull Requests erzeugen Stripes Minions?
Über 1.300 gemergte Pull Requests pro Woche werden vollständig von Minions erzeugt, zuvor waren es 1.000, laut Stripes Engineering-Blog.
Prüfen Menschen den KI-generierten Code von Stripe?
Ja. Jeder Pull Request eines Minions wird vor dem Merge von einem Ingenieur geprüft, obwohl der Code selbst keine von Menschen geschriebenen Zeilen enthält.
Bei welchen Aufgaben sind Stripes Coding-Agenten am besten?
Bei klar umrissenen Aufgaben wie Konfigurationsänderungen, Abhängigkeits-Upgrades und kleinen Refactorings, sagen Stripe-Ingenieure.
Die Sicht von MOZGII
Wie wir es bauen würden
Stripes Fall zeigt, dass ein unbeaufsichtigter Coding-Agent vor allem ein Infrastrukturprojekt ist. Das Modell schreibt den Code, aber die isolierte Entwicklungsmaschine, die Testsuite und die gemeinsamen Regeldateien entscheiden, ob dieser Code sicher gemergt werden kann. Ein Unternehmen ohne diese Teile bekäme mehr Pull Requests und zugleich mehr Risiko.
Wenn wir das bauen würden, wählten wir zuerst eine enge, langweilige Aufgabe wie Abhängigkeits-Upgrades und hielten fest, wie eine korrekte Änderung aussieht. Jeder Agentenlauf fände in einer Wegwerfumgebung ohne Zugriff auf Produktion oder persönliche Zugangsdaten statt. Die festen Schritte, etwa Linting und Pushen, wären einfacher Code, und das Modell übernähme nur die Teile, die Urteilskraft brauchen. Jeder Pull Request würde den Ingenieur nennen, der ihn geprüft hat.
Scheitern würde es bei der Prüfung. Wenn Agenten Hunderte Änderungen pro Woche erzeugen, fangen Prüfer an zu überfliegen, und eine kleine falsche Änderung im Zahlungscode kann durchgehen, weil sie der vorherigen gleicht. Regeldateien veralten auch, wenn sich die Codebasis bewegt. Die eine Kennzahl, die wir beobachten würden, ist der Anteil der Agenten-Pull-Requests, die später zurückgenommen oder nachgebessert werden, im Vergleich zu menschlichen.
Als Nächstes würden wir eine Prüfwarteschlange bauen, die Agentenänderungen nach Risiko sortiert, damit kleine Konfigurationsänderungen eine schnelle Prüfung bekommen und Änderungen nahe an Geldbewegungen einen zweiten Prüfer.
Quellen
Woher die Fakten dieser Meldung stammen.