Valudio lässt die erste Prüfung jedes Pull Requests in Azure DevOps vom KI-Werkzeug CodeRabbit übernehmen. Für einen sauber abgegrenzten Pull Request rechnet unser Tech Lead heute mit rund 15 Minuten Prüfzeit, vorher waren es alle Runden zusammen über eine Stunde. Die Einrichtung dauerte drei Arbeitstage, der Test danach zwei Wochen. Die meiste Zeit ging in das Rechtemodell von Azure.
Im Gespräch mit Dennis Quitaquís Tamay, Tech Lead bei Valudio. Die Fragen stellte Leda Felix.
„Einen Pull Request kann man nicht gut planen. Er ist komplett asynchron: In dem Moment, in dem ein Entwickler etwas fertig hat oder unser Feedback eingearbeitet hat, muss es fast sofort geprüft werden. Sonst wird es zum Engpass, bevor QA überhaupt mit dem Testen anfangen kann.“
Dennis Quitaquís Tamay, Tech Lead, Valudio
Ein Pull Request ist Code, den ein Entwickler zur Prüfung durch einen Kollegen einreicht. Er kommt, wenn die Arbeit fertig ist, nicht wenn der Prüfer Zeit hat. Bei uns arbeiteten damals drei Frontend- und zwei Backend-Entwickler in hohem Tempo, und die meisten Backend-Pull-Requests landeten zur ersten Prüfung bei Dennis.
Woher der Engpass beim Code-Review kam
Jeder Pull Request lief durch zwei Prüfphasen: zuerst, ob der Code sauber ist und unseren Standards entspricht, dann, ob das Gebaute das ist, was die User Story verlangt. Je nach Qualität der ersten Fassung brauchte das null, eine oder mehrere Runden aus Rückmeldung, Korrektur und erneuter Prüfung.
SonarCloud und Snyk liefen daneben, decken aber ein anderes Feld ab: Risiken und Sicherheitslücken, nicht Design und Logik. Die erste Prüfung blieb Handarbeit, und die Qualitätssicherung wartete darauf.
Der Umweg über den KI-Chat
Bevor ein Werkzeug im Spiel war, kopierte das Team Codeänderungen von Hand in einen allgemeinen KI-Chat, um sie gegenlesen zu lassen. Die Antworten waren brauchbar. Der Ablauf blieb aber derselbe, mit einem manuellen Schritt mehr, und die erste Prüfung lag weiterhin bei Dennis. Warum viele KI-Vorhaben an genau dieser Stelle stehen bleiben, beschreiben wir in „Warum KI-Arbeitsgruppen nichts liefern“.
Drei Kriterien für die Werkzeugsuche
Die Prüfung sollte automatisch starten, sobald ein Pull Request geöffnet wird. Sie sollte nativ in Azure DevOps laufen, dem Rückgrat unserer Microsoft-Umgebung. Und sie sollte mit .NET, Node, TypeScript und React umgehen können.
Dennis hat die Suche mit dem Team übernommen. Neben CodeRabbit haben sie CodeAnt AI und Aikido angeschaut:
| Werkzeug | Warum es passte oder nicht | Entscheidung |
|---|---|---|
| CodeRabbit | Native Integration in Azure DevOps, startet automatisch beim Öffnen eines Pull Requests. Ergänzt SonarCloud und Snyk, statt sie zu doppeln. | Eingeführt |
| CodeAnt AI | Integration nach unserem Eindruck auf Jira und GitLab ausgerichtet; wir arbeiten in Azure DevOps. In unserer Umgebung nicht getestet. | Nicht weiterverfolgt |
| Aikido | Überschneidet sich mit den Sicherheits-Scans, die wir mit SonarCloud und Snyk schon haben. Kein Grund zum Wechsel. | Nicht weiterverfolgt |
CodeRabbit war der erste Treffer bei der Suche nach einem KI-Werkzeug für Pull Requests in Azure. Dass es dabei blieb, lag am zweiwöchigen kostenlosen Test mit echten Pull Requests aus unseren Projekten.
„Die Integration ist vor allem auf Microsoft ausgerichtet. Jeder Schritt im Setup war uns vertraut, wir konnten alles selbst machen. Es gab keinen einzigen Schritt, den wir nicht kannten.“
Drei Tage Einrichtung, zwei Wochen Test
„Die ganze Integration hat, würde ich sagen, nicht mehr als drei zusammenhängende Tage gedauert: erst das passende Setup finden, dann testen, dann konfigurieren und in Betrieb nehmen.“
Die drei Tage waren die Einrichtung: einen Tag den passenden Weg der Anbindung finden, einen Tag prüfen, ob sie läuft, einen Tag konfigurieren und in Betrieb nehmen. Danach lief CodeRabbit zwei Wochen im kostenlosen Test auf echten Pull Requests, bevor wir über ein Budget gesprochen haben.
Die meiste Zeit der Einrichtung ging in das Rechtemodell von Azure. Wir betreuen viele Kundenprojekte in Azure DevOps, und das Team musste zuerst herausfinden, welcher Benutzer mit welcher Subscription Zugriff auf die zu prüfenden Projekte hat. Danach bekam CodeRabbit Leserechte auf den Code und kommentiert seither jeden neuen Pull Request.
Was sich für das Team geändert hat
CodeRabbit übernimmt heute die erste Prüfung: Es markiert Qualitätsprobleme, schlägt andere Variablennamen vor oder empfiehlt, eine Methode aufzuteilen. Der Entwickler entscheidet, was er davon übernimmt.
„Jetzt gehen wir direkt zum Verständnis des Codes, direkt zur Architektur, direkt zu den Anforderungen aus der User Story. Wir schauen weniger aufs Detail und mehr auf das Design, das der Entwickler für seine Umsetzung gewählt hat.“
Für einen sauber abgegrenzten Pull Request rechnet Dennis heute mit rund 15 Minuten statt über einer Stunde. Beide Zahlen sind seine Schätzung aus dem Alltag, keine Messung, und je nach Grösse und Komplexität des Pull Requests mehr oder weniger. Komplexe Fälle bekommen weiterhin ein Gespräch, in dem es um Logik und versteckte Fehler geht. Vor der Qualitätssicherung stapelt sich seither nichts mehr.
Woran sich das Team gewöhnen musste, war die Menge der Kommentare.
„Die Vorschläge der KI sind reine Empfehlungen, nicht verpflichtend, und das ist uns wichtig. Wir können uns entscheiden, ihnen nicht zu folgen. Am Anfang kann es einen etwas erschlagen, wenn zehn Kommentare zu einer einzigen Datei auftauchen, die man geändert hat. Aber es sind zehn Kommentare, die man nicht umsetzen muss. Man liest sie, ordnet sie ein und entscheidet dann.“
Was wir daraus mitnehmen
Der Engpass war ein einzelner Schritt, und das Werkzeug passte in die Umgebung, die wir schon betreiben. Entschieden haben wir nach zwei Wochen mit echten Pull Requests. So gehen wir auch bei KI-Vorhaben mit Kunden vor; hier waren wir unser eigener Kunde. Wo KI in unserem Alltag nicht hilft, steht in „Die Schattenseiten von KI im Entwicklungsalltag“. Welche Abläufe wir für Kunden digitalisieren, zeigen unsere Projekte.
Häufige Fragen
Funktioniert KI-Code-Review mit Azure DevOps?
Ja. CodeRabbit bindet sich nativ an Azure DevOps an und startet, sobald ein Entwickler einen Pull Request öffnet. Bei Valudio brauchte es dafür Leserechte auf den Code. Den grössten Aufwand machte die Frage, welcher Benutzer mit welcher Subscription Zugriff auf die zu prüfenden Kundenprojekte hat.
Ersetzt ein KI-Code-Review die menschliche Prüfung?
Nein. Bei Valudio übernimmt die KI die erste Prüfung: Qualitätsprobleme, Benennungen, zu lange Methoden. Die Abnahme bleibt beim Tech Lead oder einer Kollegin und richtet sich auf Architektur und die Frage, ob das Gebaute der User Story entspricht.
Wie lange dauert die Einführung eines KI-Code-Review-Werkzeugs?
Bei Valudio drei zusammenhängende Arbeitstage für die Einrichtung, danach zwei Wochen kostenloser Test mit echten Pull Requests vor der Budgetentscheidung. Das Werkzeug selbst war schnell eingerichtet; die Zeit ging in das Rechtemodell von Azure.
Können Entwickler die Vorschläge der KI ignorieren?
Ja. Die Vorschläge von CodeRabbit sind Empfehlungen. Der Entwickler liest sie, ordnet sie ein und entscheidet, was er übernimmt. Zehn Kommentare zu einer Datei sind am Anfang viel, aber es sind zehn Kommentare, die man nicht umsetzen muss.
Sprechen wir über Ihren Engpass
Wenn Ihr Team einen ähnlichen Engpass hat, sprechen wir gern darüber. Erstgespräch, 30 Minuten. Wir sagen Ihnen ehrlich, ob Vorhaben und Budget zusammenpassen, und wie eine Discovery- und Konzeptphase bei Ihnen aussehen würde. Antwort innerhalb von 24 Stunden. Termin vereinbaren.
