3'025 Pull Requests in zehn Monaten: ein KI-gestützter Delivery-Prozess von innen

Eine Plattform für Bildungsanbieter begann in einem KI-App-Builder und ist heute ein mandantenfähiges SaaS mit Web-App, nativen iOS- und Android-Apps, 160 Serverless-Funktionen und 1'048 automatisierten Testdateien. In zehn Monaten wurden 3'025 Pull Requests gemergt, die meisten von Coding-Agenten geschrieben und jeder einzelne über dieselben sieben Stufen geprüft, getestet und ausgeliefert. Eine zweite Plattform, für einen Gastgewerbe-Betrieb, kam auf dieselbe Weise in sechs Monaten auf 2'133. So sieht dieser Prozess im Alltag aus, dort sitzen die zwei harten Tore, und das würde ich zuerst einrichten, wenn ich morgen neu anfinge.

Dominik Heinrich

8. November 202611 Min. Lesezeit

1. Das Setup: ein Lead Engineer, mehrere Agenten, ein Prozess

Ich war Architekt und Lead Engineer von Anfang bis Ende. Programmiert haben grösstenteils Agenten, Claude Code und Codex, parallel an Tickets, jeder in seinem eigenen Branch. Das funktioniert nur, wenn die Agenten allein keinen Schaden anrichten können, also kam der Prozess vor dem Tempo: React auf Vercel, Supabase Postgres mit Row-Level-Security auf jeder Tabelle, Edge Functions und geplante Jobs, native Apps, deren Design-Tokens aus dem Web-CSS erzeugt werden, und eine Release-Pipeline, die jede Änderung gleich behandelt, egal wer sie geschrieben hat.

3'025 gemergte Pull Requests in zehn Monaten sind rund 300 pro Monat. Die Zahl selbst ist nicht der Punkt; entscheidend ist, dass jeder klein genug zum Prüfen war, umkehrbar, und über Staging lief, bevor er in Produktion ging. Der Leitfaden, den ich zu diesem Prozess geschrieben habe, beschreibt die sieben Stufen in kompakter Form. So sehen sie in der Praxis aus.

2. Leitplanken vor dem ersten Prompt

Jedes Repository hat eine kurze Instruktionsdatei, die die Agenten zu Beginn jeder Session lesen: die Architektur in wenigen Zeilen, die Konventionen, wie man die Tests ausführt, und eine Liste, was ein Agent darf und was nicht. Die harten Regeln sind wenige und absolut. Authentifizierung, Zahlungen, Datenlöschung und Secrets brauchen immer eine menschliche Freigabe. Agenten fassen nie Produktionsdaten oder echte Kundenkonten an; sie bekommen Testkonten auf Staging und sonst nichts.

Die Instruktionsdatei ist keine Dokumentation um ihrer selbst willen. Sie ist der billigste Weg, denselben Fehler kein zweites Mal zu machen. Ohne sie beginnt jede Session bei null, und ein Agent wiederholt fröhlich ein Migrationsmuster, das letzte Woche Staging zerlegt hat. Mit ihr ist die Lektion einmal aufgeschrieben, und jede künftige Session beginnt damit.

markdown

# AGENTS.md (excerpt)
## Never without a human approval
- auth, payments, data deletion, secrets, production config
## Never
- push to main, touch production data or real customer accounts
## Always
- one ticket = one PR; migrations idempotent, dry-run before merge
- run unit tests + type check before asking for review
## Lessons (append, never delete)
- <date>: <what went wrong> -> <the rule that prevents it>

KI-gestützte Auslieferung in sieben Stufen: Leitplanken (Instruktionsdatei, harte Regeln), kleine Pull Requests (ein Ticket, ein PR), Staging (gleicher Build wie Produktion), Prüfen (Tests und KI-Browser-Check, Tor: Tests grün), Impact-Check (Risiko und Weg zurück, Tor: ein Mensch gibt frei), Ausliefern und Beobachten (Smoke-Tests, Monitoring, ein Issue pro Fehler) und Lernen (Lektionen zurück in die Instruktionsdateien), mit einer Schleife von der letzten zur ersten Stufe. — Sieben Stufen, zwei harte Tore. Agenten schreiben den Code; Menschen geben frei, was in Produktion geht; jede Lektion fliesst zurück in die Leitplanken.

3. Kleine, umkehrbare Änderungen, zuerst Staging

Ein Ticket, ein Pull Request, mit Branch-Protection auf main, damit niemand, Mensch oder Agent, direkt pusht. Ein Pull Request, der tausend Zeilen über zehn Features ändert, lässt sich nicht sauber prüfen, egal wie gut die Reviewerin ist, also werden Agenten um die kleinste Änderung gebeten, die das Ticket schliesst. Datenbankmigrationen sind idempotent und laufen probeweise gegen die Zieldatenbank, bevor etwas gemergt wird.

Jede Änderung erreicht eine Staging-Umgebung mit demselben Build und derselben Konfiguration wie die Produktion, bevor sie in die Nähe von Kunden kommt. Beim Release werden nur die Funktionen ausgeliefert, die sich wirklich geändert haben, so bleibt jedes Release klein und jeder Rollback offensichtlich. Das ist der unspektakuläre Teil, und genau von hier kommt das meiste Tempo: Wenn jeder Schritt klein und umkehrbar ist, muss niemand Angst vor dem Mergen haben.

4. Prüfen wie ein Nutzer, nicht wie ein Compiler

Grüne Typen und grüne Unit-Tests sind nötig und nicht genug. Die Plattform hat 1'048 automatisierte Testdateien, und Typprüfung und Linting laufen gegen Baselines, die nur besser werden dürfen, damit die Agenten nichts heimlich verschlechtern. Hier sitzt das erste harte Tor: Nichts wird gemergt, solange die Tests nicht grün sind.

Dazu wird ein Ablauf so geprüft, wie ihn ein Nutzer erlebt. Dafür habe ich einen KI-Browser-Tester gebaut: Man beschreibt den Ablauf in normaler Sprache, etwa 'eine Trainerin legt eine Session an, ein Lernender unterschreibt per QR-Code, die Trainerin sieht die Unterschrift ohne Neuladen', und ein Agent steuert einen echten Chrome hindurch und liefert ein Bestanden oder Nicht bestanden mit Konsolenfehlern, fehlgeschlagenen Requests und einem Fix-Prompt. Ein solcher Test ist in neun Schritten eingerichtet statt in rund zweihundert, und Abläufe mit mehreren Rollen wie dieser sind genau dort, wo klassische Tests dünn sind.

5. Impact-Check, dann sagt ein Mensch Ja

Bevor ein Release in Produktion geht, beantwortet eine kurze Tabelle vier Fragen: Was ändert sich, wer ist betroffen, wie hoch ist das Risiko und wie kommt man zurück? Agenten entwerfen sie aus den Pull Requests; ich lese sie. Das ist das zweite harte Tor: Ein Mensch gibt jeden Produktions-Merge frei. Das dauert Minuten, weil die Änderungen klein und die Tabelle kurz ist, und es fängt die Fälle ab, in denen eine technisch korrekte Änderung am Freitagnachmittag oder in der Audit-Woche eines Kunden das Falsche ist.

Es geht nicht um Misstrauen gegenüber den Agenten. Es geht darum, dass Release-Entscheidungen Kontext brauchen, der nicht im Code steht: ein Kunde kurz vor dem Onboarding, ein Support-Rückstand, eine geplante Migration. Dieser Kontext liegt bei Menschen, also auch die Entscheidung.

markdown

## Release <date> — impact check (template, example rows)
| change                         | who is affected        | risk   | way back                 |
|--------------------------------|------------------------|--------|--------------------------|
| attendance flow change         | trainers, learners     | low    | revert PR, redeploy fn   |
| new invoice field              | admins of all tenants  | medium | migration is additive    |
| CRM scoring update             | sales users            | low    | feature flag off         |
Approved by: ____  (no production merge without a name here)

6. Ausliefern, beobachten und Fehler Tickets eröffnen lassen

Nach jedem Deploy laufen Smoke-Tests gegen die lebenswichtigen Routen des Live-Systems, etwa Login und Checkout. Bricht einer, wird der Deploy rot und die Änderung zurückgerollt. Das Monitoring beobachtet Ergebnisse statt CPU: Wurde die Anwesenheit erfasst, ist die Rechnung rausgegangen? Jeder Fehler eröffnet automatisch genau ein Issue, und das Issue schliesst sich selbst, wenn der Check wieder grün ist, so zeigt der Backlog echte Probleme und kein Alarmrauschen.

Darunter liegt das Netz, das niemand sieht: verschlüsselte Backups siebenmal am Tag, Dateien auf einen zweiten Anbieter gespiegelt und eine nächtliche Wiederherstellung in ein separates Zwillingsprojekt, die beweist, dass die Backups funktionieren. Wenn Agenten in diesem Tempo Code schreiben, macht erst die Möglichkeit, alles rückgängig zu machen, Daten eingeschlossen, dieses Tempo vertretbar.

7. Den Kreis schliessen und das Richtige messen

Jeder Vorfall, jeder Review-Kommentar, der sich wiederholt, jede Migration, die auf Staging scheiterte, endet mit einer Frage: Welche Zeile in der Instruktionsdatei hätte das verhindert? Diese Zeile wird ergänzt. Kundenantworten entwirft ein Agent, gesendet werden sie von einem Menschen. Über Monate macht genau das aus einem schnellen Team ein sicheres: Die Regeln wachsen mit dem Produkt.

Messen Sie die Durchlaufzeit vom Ticket bis zur Produktion, die Change-Failure-Rate, gemergte Pull Requests pro Woche und von Nutzern gefundene Fehler, also Delivery-Kennzahlen wie in der DORA-Forschung. Messen Sie keine Codezeilen; die liefern Agenten gratis. Wenn Sie anfangen wollen, beginnen Sie mit Leitplanken und Staging, nicht mit mehr Agenten. Der Readiness-Check unten zeigt, wo eine Codebasis steht, bevor Sie Tempo hinzufügen.

Fazit
Agenten können den Grossteil des Codes schreiben. Der Prozess entscheidet, ob das ein Risiko oder ein Vorteil ist: kleine, umkehrbare Änderungen, zwei harte Tore in menschlicher Hand und jede Lektion zurück in die Regeln geschrieben.

Echte Projekte dazu

Vom KI-Prototyp zum produktiven SaaS

Selbst ausprobieren

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden