Risikoklassen am Pull Request
Aus den berührten Pfaden, nicht aus der Beschreibung. Falsche Klassen sind sichtbar und werden korrigiert; die Mehrheit des Volumens verlässt die Warteschlange.
Dreimal so viel Code.Dieselben zwei Reviewer.
Risikoklassen am Pull Request, Eigenschaften
statt Stichproben, Herkunft jeder Änderung.
Das Modell, live
Nicht jede Änderung ist gleich.
Nicht jede Änderung ist gleich.
Das System sortiert zuerst.
Die meisten Änderungen können keinen echten Schaden anrichten. Wenige können es. Sortieren ist billig; alles gleich zu behandeln kostet die Reviewer, die Sie nicht haben. So sieht der Moment aus, in dem eine Änderung ankommt.
Ein Pull Request, 480 Zeilen aus dem Assistenten. Was jetzt passiert, entscheidet die Klasse.
Die Klasse kommt aus den berührten Pfaden, nicht aus der Selbstauskunft des Autors. Unklassifiziert wird nicht gemergt.
Klasse A: benannter Mensch prüft, vor dem Merge
Klasse B: Eigenschafts-Tests plus Diff-Zusammenfassung
Klasse C: Gates laufen, Menschen nicht
Zahlungspfad angefasst, 480 Zeilen, Großteil aus dem Assistenten. Wer muss das sehen?
REVIEW-GATE
Risikoklasse A erkannt: api/zahlung/ berührt
Pflicht-Review zugewiesen: N. Weber, vor dem Start benannt
Eigenschafts-Tests: 14 von 14 halten, inkl. Idempotenz
Herkunft vermerkt: assistiert, Modell und Prompt-Hash im Log
REGELWERK · risk-map.yaml · ZEILE 42 · STAND HEUTE
Eigenschaften statt Stichproben
Property-Tests sagen, was immer gelten muss. Generierter Code wird gegen die Regel geprüft, nicht gegen drei Fälle, die jemandem eingefallen sind.
Herkunft jeder Änderung
Geschrieben, assistiert oder generiert steht im Protokoll. Nicht zur Kontrolle, sondern damit Sie in sechs Monaten einem Auditor antworten können.
Die letzte Review-Instanz
Manches fängt kein Gate. Progressive Auslieferung plus Alarm auf den Eigenschaften macht daraus einen Fünf-Minuten-Rollback statt eines Montags-Vorfalls.
Engineering-Check starten →
30 Minuten mit dem Team
Fünf Fragen, dann sehen Sie, wo Ihr Review-Modell reißt. Vertiefung: Quality Gates · Risikoklassen · PR-Größe und Fehlerrate
Prüfpunkte
Wer prüft den Code, den die KI schreibt?
Die Antwort ist keine Person, sondern eine Ordnung: ein kleiner Teil der Änderungen braucht einen benannten Menschen vor dem Merge, der große Rest Gates, die niemand überstimmen kann. Diese sechs Punkte entscheiden darüber.
Risikokarte und Klassenzuordnung
Gibt es eine gepflegte Karte, die Pfade auf Risikoklassen abbildet? Wir prüfen, ob die Klasse aus den berührten Dateien entsteht oder aus dem Pull-Request-Text, und was unklassifiziert passiert.
Pflicht-Review an der richtigen Stelle
Wer muss zustimmen, bevor eine Änderung der höchsten Klasse gemergt wird? Wir sehen uns an, auf welchen Wegen diese Pflicht umgangen werden kann.
Eigenschaften statt Beispielfälle
Beispieltests prüfen, was jemandem eingefallen ist. Eigenschaftstests prüfen die Regel: Idempotenz, Erhaltung von Summen, Rundungsverhalten. Wir stellen fest, wo sie fehlen.
Abhängigkeiten und Lizenzen
Generierter Code bringt Bibliotheken mit, die niemand ausgesucht hat. Wir prüfen, ob neue Abhängigkeiten einen Freigabeweg haben und ob eine Stückliste der Auslieferung entsteht.
Zugangsdaten und Datenwege
Assistenten schreiben Zugangsdaten in Beispiele, und Beispiele landen im Repository. Wir prüfen die Gates gegen Geheimnisse im Code und welche Firmendaten den Assistenten erreichen.
Herkunft und Rückweg
Steht an jeder Änderung, ob sie geschrieben, assistiert oder generiert wurde? Und wenn ein Gate etwas durchlässt: wie schnell lässt sich das zurücknehmen, und wer darf es?
Ablauf
Vier Schritte, terminiert, ohne die Roadmap anzuhalten.
Die Review läuft neben der Entwicklung, an Ihren echten Pull Requests der letzten Wochen. Die Dauerangaben beschreiben unseren Aufwand; Ihr Team ist im Erstgespräch und im Abschluss gebunden.
Schritt 1
Erstgespräch 30 Minuten
Sie sprechen mit einem Solution Architect, nicht mit dem Vertrieb. Wir klären, wie Ihr Weg von der Änderung zur Produktion heute aussieht und ob eine Review der richtige Schritt ist.
Schritt 2
Bestandsaufnahme drei Arbeitstage
Wir lesen Repository-Struktur, Pipeline-Konfiguration, Branch- und Freigaberegeln sowie die Pull Requests eines zusammenhängenden Zeitraums. Daraus entsteht die erste Risikokarte.
Schritt 3
Stichprobe an echten Änderungen fünf Arbeitstage
Wir ziehen Änderungen aus allen Klassen und gehen sie durch: Was hätte ein Gate fangen müssen, was hat es gefangen, was lief durch. Jeder Befund hängt an einer Pull-Request-Nummer.
Schritt 4
Befund und Reihenfolge ein halber Tag
Mit Ihren Leads: die Lückenliste, sortiert nach möglichem Schaden und Aufwand, dazu die eine Gate-Änderung, die sich in derselben Woche umsetzen lässt. Was danach gebaut wird, entscheiden Sie.
Diagnose
Woran Sie erkennen, dass die Review-Kapazität der Engpass ist.
Der Engpass meldet sich selten als Ausfall, sondern als Gewohnheit, über die niemand mehr spricht. Wenn Sie drei dieser Sätze kennen, liegt die Grenze in der Prüfung.
- Pull Requests warten länger auf Zustimmung, als ihre Entwicklung gedauert hat.
- Freigaben kommen mit einem Daumen nach oben und ohne einen Kommentar am Code.
- Große Änderungen gehen schneller durch als kleine, weil niemand sie zeilenweise liest.
- Unter fast jeder Freigabe stehen dieselben zwei Namen, und beide haben die Rufbereitschaft.
- Auf die Frage, welcher Teil des letzten Release aus einem Assistenten kam, folgt eine Schätzung.
- Die Vorfälle der letzten Monate betreffen Bereiche, in denen die Testsuite grün war.
Grenzen
Was eine AI Engineering Review nicht leistet.
Damit Sie den Aufwand einordnen, bevor Sie ihn intern verteidigen: Diese vier Dinge sind nicht Teil der Review.
Kein Sicherheitsaudit und keine Zertifizierung
Wir prüfen, ob Ihre Gates greifen, nicht ob Ihr Produkt einer Norm entspricht. Ein Testat oder eine Penetrationsprüfung ist ein zweites, eigenes Mandat.
Keine Zusicherung, dass nichts mehr durchrutscht
Ein Gate fängt, was als Eigenschaft formuliert wurde. Deshalb steht die progressive Auslieferung mit Alarm als letzte Instanz im Modell.
Kein Urteil über einzelne Entwickler
Das Herkunftsprotokoll dient der Nachweisführung gegenüber Dritten. Wer es zur Leistungsmessung umwidmet, bekommt schlechtere Daten.
Keine Kennzahl, die wir Ihnen hier versprechen
Zu Review-Durchsatz und Fehlerrate liegen uns keine eigenen gemessenen Werte vor, deshalb steht hier keine Prozentzahl, sondern ein Befund an Ihren eigenen Änderungen.
Häufige Fragen
Was CTOs an dieser Stelle zuerst fragen.
Wer prüft den Code, den die KI schreibt?
Bei der höchsten Risikoklasse ein benannter Mensch, vor dem Merge, ohne Umgehungsweg. Bei allem anderen prüfen Gates in der Pipeline. Entscheidend ist, dass die Klasse aus den berührten Pfaden entsteht, nicht aus der Beschreibung des Autors.
Brauchen wir dafür neue Werkzeuge?
In aller Regel nicht. Risikoklassen, Pflicht-Reviews und Gates lassen sich in GitHub, GitLab und Azure DevOps mit vorhandenen Mitteln abbilden. Die Arbeit steckt in der Risikokarte, nicht im Einkauf.
Bremst das nicht die Beschleunigung aus, für die wir die Assistenten eingeführt haben?
Der umgekehrte Fall ist wahrscheinlicher. Heute laufen alle Änderungen durch dieselbe Warteschlange, auch die ungefährlichen. Sortieren nimmt den größten Teil heraus und legt die Aufmerksamkeit der Reviewer dorthin, wo sie gebraucht wird.
Wie weisen wir einem Auditor KI-geschriebenen Code nach?
Über ein Protokoll an der Änderung: Herkunft, Modell, Prompt-Hash, zugewiesene Risikoklasse und die gelaufenen Gates. Der Nachweis muss im Moment der Änderung entstehen; nachträglich gesammelte Screenshots belegen die Zuordnung nicht.
Für wen ist eine AI Engineering Review nichts?
Für Teams, die Assistenten noch nicht im Alltag einsetzen: dort gibt es nichts zu sortieren. Und für Organisationen, die vor allem ein Dokument mit Stempel brauchen.