Mainlane besteht aus einem Entwickler und einem Team von KI-Agenten. Das wirft eine berechtigte Frage auf: Wer prüft den Code, den eine KI geschrieben hat? Unsere Antwort: eine zweite KI, die ihn nicht geschrieben hat – und danach ein Mensch, der entscheidet, ob er live geht.
Der Ablauf
- Eine Claude-Sitzung übernimmt eine Aufgabe und öffnet einen Pull Request.
- Ein separater Reviewer startet in einer frischen Sitzung. Er hat nie gesehen, wie der Code entstanden ist, und liest den Diff deshalb so, wie es ein Kollege tun würde – ohne die Annahmen des Autors.
- Der Reviewer hält seine Befunde in drei Stufen fest: 🔴 muss behoben werden, 🟡 sollte behoben werden, 🟢 wäre schön.
- Die Autoren-Sitzung behebt sie, antwortet Punkt für Punkt und schließt mit einem Abschnitt „Verifizierung“: welche Befehle sie ausgeführt hat und was diese ausgegeben haben.
- Der Reviewer prüft den neuen Stand. Der Ablauf wiederholt sich, bis es überhaupt keine Befunde mehr gibt – nicht einmal 🟢.
Zwei Regeln sorgen dafür, dass das ehrlich bleibt. Einem Befund kann man nur mit einer Messung widersprechen – einer Zahl, einer Befehlsausgabe, einer Mutation, die ein Test nicht erkennt –, nicht mit „passt schon“. Und nach fünf Runden hält der Ablauf an und fragt einen Menschen, damit er sich nie endlos im Kreis dreht.
Der menschliche Teil
Kein Agent merged. Wenn das Review sauber ist und die CI genau für den Commit grün ist, den der Reviewer gesehen hat, schreibt die Sitzung „bereit zum Mergen“ und wartet. Gemergt wird erst, wenn ein Mensch es freigibt – und nur genau dieser Commit.
Was dabei auffällt
Ein paar echte Beispiele aus dem Repository dieser Website:
- Im Pull Request, der Lighthouse-Prüfungen in die CI aufgenommen hat, bemerkte der Reviewer, dass eine CSS-Build-Einstellung auf den falschen Ordner zeigte – Layout-Styles verschwanden dadurch unbemerkt von der Website. Weder Lighthouse noch der Barrierefreiheits-Checker hatten das gemeldet. Außerdem fiel ihm ein fixiertes Sprachbanner auf, das für Tastaturnutzer das fokussierte Element verdecken konnte.
- Bei der Prüfung der Wiederherstellung von Datenbank-Backups verglich der tägliche Test die wiederhergestellten Daten mit sich selbst statt mit dem Export – fehlende Zeilen wären so nie aufgefallen. Dasselbe Review fand eine Fehlermeldung, die die E-Mail-Adresse eines Interessenten in die Logs schreiben konnte.
- Bei der Einführung der Content Security Policy hätten Meldungen von Browsererweiterungen verhindert, dass das Ziel „eine Woche ohne Verstöße“ jemals erreicht wird, und externe Bilder in Blogbeiträgen wären kaputtgegangen, sobald die Policy durchgesetzt wird.
Nichts davon war exotisch. Es waren genau die Dinge, die man an einem Freitagabend müde übersieht.
In Zahlen
Stand Ende Oktober 2026 läuft der Ablauf in acht Repositorys, mit 385 gemergten Pull Requests und 1.069 Reviews. Der größte Teil der Kosten entfällt auf die eigentliche Arbeit: In der letzten Oktoberwoche gingen etwa drei Viertel der Tokens in die Umsetzung und weniger als ein Zehntel ins Review.
Grenzen
Der Reviewer ist dieselbe Art von Modell wie der Autor und kann daher dieselben blinden Flecken haben. Er ersetzt kein menschliches Review wichtiger Änderungen, und Text in einem Pull Request wird als Daten behandelt, nie als Anweisung. Was er ersetzt, ist der Schritt, den die meisten Einzelentwickler auslassen: ein zweites Paar Augen auf jeder einzelnen Änderung.