AI-Codereview-Gitlab: LLM-Reviews direkt im Merge Request

Welche Luecke der Webhook fuellt

Klassische Linter und SAST-Scanner finden Muster, die jemand vorher als Regel formuliert hat. Die Frage, ob eine Aenderung im Kontext dieses Repositories sinnvoll ist, beantworten sie nicht. Genau dort setzt dieses Projekt an: Es haengt sich als Webhook in den GitLab-Projektablauf und laesst ein Sprachmodell den Diff kommentieren. Die Zielgruppe sind kleine und mittlere Entwicklungsteams, die Merge Requests bereits ueber GitLab abwickeln und die Review-Rueckmeldung nicht in einem zweiten Werkzeug suchen wollen. Der Kommentar landet laut Beschreibung direkt als Note am Merge Request oder Commit, also dort, wo ohnehin diskutiert wird. Der Nutzen haengt damit an einer einzigen Bedingung: dass die Hinweise brauchbar genug sind, um nicht ignoriert zu werden. Ein Modell, das bei jedem Diff dieselben drei Allgemeinplaetze schreibt, erzeugt Rauschen statt Entlastung. Das README verspricht an dieser Stelle nicht mehr als einen zweiten Blick auf den Code.

Vom Push bis zur Note: der tatsaechliche Datenfluss

Die Architektur ist bewusst schmal. GitLab feuert bei Push- oder Merge-Request-Events eine HTTP-Anfrage an den Endpunkt /review/webhook auf Port 5001. Der Dienst nimmt die Nutzlast entgegen, holt den Diff und schickt ihn an den konfigurierten Anbieter. Zurueck kommt Text, der als Note am ausloesenden Objekt landet. Die Authentifizierung hat eine klare Rangfolge: Zuerst zieht das System GITLAB_ACCESS_TOKEN aus der .env-Datei, erst wenn dieser Wert fehlt, greift es auf das Secret Token zurueck, das der Webhook mitliefert. Das ist praktisch, weil ein einziger Token fuer alle angebundenen Projekte reicht, aber es heisst auch, dass ein versehentlich gesetztes Token im Container alle Projekt-Webhooks ueberschreibt. Ein zweiter Dienst laeuft getrennt auf Port 5002 und zeigt die Review-Historie als Dashboard. Die Trennung von API und Oberflaeche ist sinnvoll, weil ein Neustart des Dashboards die Webhook-Verarbeitung nicht unterbricht. Fuer die Kommunikation gilt eine harte Voraussetzung: Der GitLab-Server muss den Review-Host erreichen koennen. In abgeschotteten Netzen laeuft das nur, wenn GitLab ausgehende Verbindungen in dieses Segment aufbauen darf.

Inbetriebnahme in zwei Varianten

Der Docker-Weg beginnt mit git clone https://github.com/sunmh207/AI-Codereview-Gitlab.git, gefolgt von cp conf/.env.dist conf/.env. In der .env stehen die Schluessel, die den Betrieb bestimmen: LLM_PROVIDER auf deepseek, openai, zhipuai oder ollama, dazu DEEPSEEK_API_KEY beziehungsweise der passende Schluessel des anderen Anbieters, GITLAB_ACCESS_TOKEN und SUPPORTED_EXTENSIONS. Diese letzte Variable ist wichtiger, als sie aussieht: Dateitypen, die dort nicht auftauchen, werden gar nicht geprueft. Der dokumentierte Standardwert deckt .java, .py, .php, .yml, .vue, .go, .c, .cpp, .h, .js, .css, .md und .sql ab. Ein Team, das vor allem TypeScript oder Rust schreibt, muss die Liste erweitern, sonst laeuft der Dienst ohne Fehlermeldung ins Leere. Danach startet docker-compose up -d. Die Verifikation ist bewusst primitiv gehalten: Port 5001 zeigt die Zeile "The code review server is running.", Port 5002 das Log-Interface. Alternativ laeuft alles lokal mit Python 3.10 oder neuer, pip install -r requirements.txt, dann python api.py und streamlit run ui.py --server.port=5002 --server.address=0.0.0.0. Wer keinen Container betreiben will, nimmt diesen Weg, muss dann aber Prozessueberwachung selbst loesen.

Was der agentic Modus an Ressourcen bindet

Standardmaessig arbeitet das System im Modus diff_only und sieht nur den Diff. Mit REVIEW_STRATEGY=agentic bekommt das Modell Werkzeuge: read_file und eine Shell im Sandbox. Es darf im geklonten Repository selbst nachsehen, etwa Aufrufer einer geaenderten Funktion suchen. Gesteuert wird das ueber REPO_CACHE_DIR (Standard data/repo_cache/) und AGENT_MAX_ITERATIONS, standardmaessig 20. Die Kosten sind im README offengelegt und fallen deutlich aus: 10 MB bis 2 GB pro Projekt auf der Platte, mindestens 50 GB empfohlen, rund 500 MB Speicher pro Session, 5.000 bis 50.000 Tokens pro Review, das Drei- bis Zehnfache des Diff-Modus, und 30 Sekunden bis 5 Minuten Laufzeit. Fuer ein Team mit vielen kleinen Merge Requests ist das ein spuerbarer Unterschied im Kontingent. Der Schutzmechanismus ist mehrschichtig: Kommandos laufen gegen Whitelist und Blacklist, Pfade ausserhalb des Repositories werden abgewiesen, nach 30 Sekunden bricht die Ausfuehrung ab. Standardmaessig sind nur lesende Befehle wie ls, cat, grep, find oder git log erlaubt. Wer mehr braucht, aendert AGENT_SHELL_ALLOWLIST oder AGENT_SHELL_BLOCKLIST. Schlaegt irgendeine Stufe fehl, also Clone, Fetch, LLM-Aufruf oder Werkzeugaufruf, faellt das System auf diff_only zurueck. Das ist die vernuenftigste Designentscheidung im Projekt, denn sie garantiert, dass ein fehlgeschlagener Agentenlauf nicht in einem leeren Kommentar endet.

Wo das Modell an Grenzen stoesst

Die Qualitaet des Ergebnisses steht und faellt mit dem Diff. Enthaelt ein Merge Request nur eine umbenannte Variable, hat das Sprachmodell nichts zu bewerten und schreibt entweder nichts oder Plattitueen. Bei sehr grossen Diffs ist das Gegenteil das Problem: Der Kontext passt nicht vollstaendig hinein, und dann haengt es am Anbieter, ob gekuerzt oder abgelehnt wird. Das README adressiert diese Grenze nicht. Auch die vier Review-Stile sind kein Qualitaetsmerkmal. Die Modi professionell, sarkastisch, gentleman und humorvoll aendern den Ton, nicht die Tiefe der Analyse. Ein sarkastischer Kommentar unter einem korrekten Merge Request ist fuer das Team schlimmer als gar keiner. Der agentic Modus mildert das Kontextproblem, loest es aber nicht: Er sieht nur, was im Repository liegt. Liegt die relevante Information in einem verlinkten Ticket oder in der Infrastrukturkonfiguration eines anderen Repositories, bleibt sie unsichtbar. Und der Rueckfall auf diff_only ist ein Sicherheitsnetz, keine Garantie. Ein Team, das den Agenten unbemerkt ausfallen laesst, bekommt stillschweigend die schwaecherer Variante.

Der Vergleich mit einem gehosteten Review-Dienst

Der naheliegende Gegensatz sind kommerzielle Review-Bots, die als SaaS an den GitLab-Account gehaengt werden. Der Unterschied liegt nicht in der Funktion, sondern im Betriebsmodell. Ein gehosteter Dienst bekommt den Code ueber eine App-Installation und muss sich nicht um Token-Rotation, Container-Neustarts oder Plattenplatz kuemmern. Dieses Projekt dreht das um: Der Code verlaesst die eigene Infrastruktur nur in Richtung des gewaehlten Modellanbieters, und wer Ollama lokal betreibt, kann auch das vermeiden. Dafuer traegt das Team Betrieb und Ausfall selbst. Ein zweiter Unterschied ist die Anbieterbindung. Weil LLM_PROVIDER zwischen sechs Backends umschaltet, laesst sich der Anbieter wechseln, ohne die Integration anzufassen. Bei SaaS-Produkten ist der Wechsel meist ein Neuaufsetzen der Integration. Fuer Teams mit klaren Vorgaben zur Datenhaltung ist der Selbstbetrieb der Punkt, der zaehlt. Fuer Teams ohne Betriebskapazitaet ist er der Punkt, der das Projekt ausschliesst.

Pflegeaufwand und Lizenz

Das Repository steht unter Apache-2.0. Diese Lizenz erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben, und enthaelt eine ausdrueckliche Patentgewaehrung. Wer den Dienst intern weiterverkauft oder als eigene Plattform anbietet, sollte die Bedingungen selbst pruefen; eine rechtliche Einschaetzung ist hier nicht moeglich und auch nicht beabsichtigt. Zum Pflegeaufwand gibt die Materiallage wenig her. Die letzten Releases liegen bei v1.5.1 vom 29. Juni 2026, v1.4.3 vom 20. Mai 2026 und v1.4.2 vom 15. Maerz 2026, der letzte Push datiert auf den 23. Juli 2026. Aus diesen Zeitpunkten laesst sich ein Rhythmus ablesen, aber keine Aussage ueber Stabilitaet oder Antwortzeiten auf Issues. Wer das Projekt produktiv einsetzt, muss mit Upgrades rechnen: Die .env traegt anbieterspezifische Schluessel, und ein Anbieterwechsel bedeutet, Variablen und Modellnamen anzupassen. Im agentic Modus kommt der REPO_CACHE_DIR hinzu, der bei Schemaaenderungen geleert werden muss. Das README nennt keine Upgrade-Prozedur und keine Migrationshinweise. Das ist eine Luecke, kein Ausschlusskriterium, aber sie sollte vor dem Rollout eingeplant werden.

Redaktionelles Fazit

Sinnvoll ist das Projekt fuer Teams, die bereits GitLab selbst betreiben, einen API-Key fuer DeepSeek, ZhipuAI, OpenAI, Anthropic, Qwen oder Ollama besitzen und Reviews ohne zusaetzlichen SaaS-Vertrag im MR sehen wollen. Wer keine Server-Instanz betreiben darf oder einen Anbieter mit SLA und Audit-Trail braucht, sollte nicht darauf setzen, denn der Dienst laeuft in der eigenen Infrastruktur und die Verfuegbarkeit haengt am eigenen Host. Vor dem Rollout zu pruefen: ob die Zielpfade tatsaechlich in SUPPORTED_EXTENSIONS stehen, ob der GitLab-Host die Adresse http://{your-server-ip}:5001/review/webhook erreichen kann und ob der gewaehlte REVIEW_STRATEGY-Wert zum Token-Budget passt.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. sunmh207/AI-Codereview-Gitlab on GitHub