Wie wir KI-Code prüfen, bevor er live geht

Bei uns schreiben KI-Agenten den Code, für Kundenprojekte ebenso wie für unsere eigenen Werkzeuge. Ein zweiter Agent liest jede Zeile, bevor eine Änderung übernommen wird, und live geht sie erst, wenn ein Mensch genau diese Version freigegeben hat. Hier ist der Weg, den eine Änderung bei uns nimmt, und wie wir den Prüfer selbst prüfen.

Jede Aufgabe beginnt mit einem schriftlichen Auftrag

Eine Änderung beginnt bei uns als Aufgabe mit einem kurzen Auftrag: was zu tun ist, warum, und woran man erkennt, dass sie fertig ist. Der Agent, der sie umsetzt, arbeitet in einer eigenen Kopie des Codes, nie direkt am gemeinsamen Stand. So können mehrere Agenten gleichzeitig arbeiten, ohne sich gegenseitig zu überschreiben.

Bevor jemand die Änderung prüft, lässt der Agent die Prüfungen des Projekts laufen: Formatierung, Typprüfung und die betroffenen Tests. Die Typprüfung kontrolliert, ob jeder Wert im Code die erwartete Form hat. Ein weiteres Werkzeug sucht Code, den die Änderung unbenutzt zurücklässt; solange es welchen findet, kommt die Änderung nicht weiter. Warum Tests und Typen bei KI-Code die Grundlage sind, steht im Leitfaden Software mit KI entwickeln, ohne die Kontrolle zu verlieren.

Ein unabhängiger Agent prüft

Dann liest ein zweiter Agent die fertige Änderung. Er läuft in einer frischen Sitzung und darf nichts ändern. Normalerweise kommt er vom jeweils anderen Anbieter: Hat Claude von Anthropic die Änderung geschrieben, prüft Codex von OpenAI, und umgekehrt. Ist der andere Anbieter nicht erreichbar, prüft ein frischer Agent desselben Anbieters, und der Prüfbericht vermerkt diesen Ersatz. Der Prüfer sieht den Auftrag und die Änderung, aber nicht das Gespräch, in dem sie entstanden ist. Warum ein Autor die eigene Arbeit schlecht prüft, beschreibt das Vier-Augen-Prinzip für KI-Agenten.

Der Prüfer meldet nur zwei Arten von Befunden. Ein Fehler braucht eine genaue Stelle im Code und einen konkreten Auslöser, also welche Eingabe zu welchem falschen Ergebnis führt. Solange ein Fehler offen ist, wird die Änderung nicht übernommen. Eine Entscheidung ist eine Abwägung, die ein Mensch treffen muss, etwa ob ein Sonderfall bewusst nicht abgedeckt wird. Sie hält die Änderung nicht auf und erscheint später auf der Übersicht, mit der ein Mensch die Version freigibt. Stil und Namensgebung meldet der Prüfer nicht; dafür gibt es eine eigene Durchsicht alle zwei Wochen.

Zwei Regeln machen die Prüfung strenger. Berührt eine Änderung die Anmeldung, Berechtigungen, Zahlungen, das Speichern von Daten oder eine Umstellung der Datenbank, gilt ein fehlender Test für das sichtbare Verhalten selbst als Fehler. Und bevor der Prüfer eine Änderung für fehlerfrei erklärt, muss er auch den Code lesen, der die geänderten Teile aufruft, und die zugehörigen Tests.

Zwei Prüfrunden, dann wird umgeplant

Wenn ein Agent schreibt und ein anderer prüft, braucht die Prüfung eine Grenze. Ein Mensch übergeht eine Kleinigkeit in Sekunden. Ein Agent behebt sie, legt eine neue Fassung vor und löst damit die nächste Prüfrunde aus. Ohne Grenze können Autor und Prüfer so beliebig lange hin und her arbeiten.

Deshalb bekommt jede Änderung eine vollständige Prüfung und höchstens eine Nachprüfung, die nur die Korrekturen seit der ersten Prüfung liest. Findet auch die Nachprüfung einen Fehler, wird die Änderung verkleinert und der fehlerfreie Teil neu geprüft. Oder sie bleibt liegen, bis ein Mensch über den Ansatz entschieden hat. Wir gehen davon aus, dass ein Fehler, der zwei Korrekturen übersteht, eher am Ansatz liegt als an der einzelnen Zeile.

Übernommen wird, was mit dem aktuellen Stand funktioniert

Eine geprüfte Änderung kommt in eine Warteschlange. Dort wird sie mit dem neuesten gemeinsamen Stand zusammengeführt, und die Prüfungen laufen auf genau diesem Ergebnis noch einmal. Zwei Änderungen können einzeln fehlerfrei sein und zusammen etwas beschädigen. Deshalb laufen die Prüfungen auf der Kombination, bevor sich der gemeinsame Stand ändert.

Live geht nur eine freigegebene Version

Der gemeinsame Stand ist noch nicht die laufende Anwendung. Vor der Übernahme wartet bei uns keine Änderung auf einen Menschen. Dafür geht nichts live, bevor ein Mensch genau diese Version freigegeben hat. Auf der Übersicht zur Freigabe stehen die übernommenen Änderungen, die Entscheidungen aus den Prüfungen und bei sichtbaren Änderungen ein kurzes Video, das die neue Funktion am Computer und am Telefon zeigt.

So liest die Maschine jede Zeile, und ein Mensch bleibt für das verantwortlich, was live geht. Warum sich die Prüftiefe nach dem Risiko richten sollte, steht in Wie viel Review braucht KI-Code?

Wie wir den Prüfer prüfen

Unser Ablauf hat eine Lücke: Wir wissen noch nicht genau, wie gut unser Prüfer ist. Deshalb haben wir am 20. Oktober 2026 drei Dinge eingeführt.

• Wir halten fest, wie jeder Befund ausgegangen ist: behoben, widerlegt oder offen. Daraus lässt sich ablesen, wie oft der Prüfer falschen Alarm gibt.
• Fehler, die trotz Prüfung durchgekommen sind, werden zur Testsammlung für den Prüfer. Vorher kontrollierten unsere Tests des Code-Prüfers vor allem, ob seine Antwort die verlangte Form hat. Ändern wir den Prüfer oder sein Modell, lassen wir ihn erneut gegen diese Sammlung laufen.
• Der Prüfer benennt die Art jedes Fehlers und listet alle Stellen, an denen er vorkommt. Korrigiert der Autor nur die eine genannte Zeile, während derselbe Fehler an zwei anderen Stellen steckt, scheitert die Nachprüfung, und die Änderung muss verkleinert oder zurückgestellt werden.

Der zweite Punkt wiegt für uns am schwersten. Solange wir nicht wissen, was der Prüfer übersieht, wissen wir nicht, ob eine Prüfung ohne Befund eine gute Änderung bedeutet oder einen schwachen Prüfer.

Mehr Prüfung ist nicht automatisch mehr Qualität. Vom 11. bis 13. Oktober 2026 haben unsere Agenten tagelang an Werkzeugen gearbeitet, die unsere Prüfungen absichern sollten, während fertige Änderungen auf ihre Übernahme warteten. Seitdem ist Tempo bei uns ein ausdrückliches Ziel. Deshalb messen wir zuerst, was unser Prüfer übersieht, und entscheiden erst danach, ob mehr Prüfaufwand gerechtfertigt ist.

Was Sie Ihren Dienstleister fragen können

Wenn KI-Agenten Software für Sie schreiben, können Sie die Qualitätssicherung mit wenigen Fragen einschätzen. Wie viele Prüfrunden bekommt eine Änderung höchstens, und was geschieht danach? Woher weiß Ihr Dienstleister, welche Fehler sein Prüfer übersieht? Und wer gibt welche genaue Version frei, bevor sie bei Ihnen live geht? Auf die zweite Frage haben wir selbst noch keine vollständige Antwort; die Testsammlung aus echten Fehlern soll sie liefern.

In der Stufe Entwicklung bauen wir Software, die danach Ihnen gehört, und jede Änderung daran nimmt den hier beschriebenen Weg. Entwicklung besprechen