Lokales LLM codet, Cloud-LLM reviewt: Ein GitLab Review Bot in 100 Zeilen

Immer mehr Code schreibe ich nicht mehr selbst – ein LLM generiert ihn, bei mir lokal, schnell und günstig.

Genau da entsteht ein Engpass: Generierten Code kann ich beliebig hochskalieren, das menschliche Review nicht. Je mehr ein Modell produziert, desto weniger kommt der Mensch hinterher. Nur: wer reviewt das alles?

Ein Review kostet Zeit, der richtige Experte ist im Urlaub, und spätabends sitzt niemand mehr da.

Meine Idee: Ein zweites, fähigeres Modell übernimmt den ersten Blick. Nicht als Ersatz für Menschen, sondern als Prüfer, der nie müde wird.

Der Bot ist ein FastAPI-Service. Er lauscht auf GitLab Merge-Request-Events, checkt den Branch aus, sammelt den vollständigen Repo-Kontext und fragt ein Modell über einen lokalen LiteLLM-Proxy. Das Ergebnis postet er als MR-Kommentar (und Email) zurück. Der Kern des Bots passt tatsächlich in unter 100 Zeilen Python.

Das Besondere ist die Kombination aus fünf Entscheidungen.

Lokal statt Cloud. Der Bot spricht nicht direkt mit OpenAI, Anthropic oder Google, sondern mit einem selbst gehosteten LiteLLM-Proxy auf einem GX10 (Nvidia DGX Spark).

Der Proxy leitet zwar teilweise an OpenRouter weiter, aber die Kontrolle bleibt lokal: keine API-Keys im Client, keine externen Rate-Limits, zentrales Tracing.

Was an einen Cloud-Anbieter geht und was lokal bleibt, entscheide ich im Proxy. Die API-Keys folgen dem Schema <host>|<user>|<tool>, sodass sich jeder Request einem Menschen und einem Werkzeug zuordnen lässt. Jeder Review und jeder Token-Verbrauch landet als Trace in Langfuse. Das Setup des LiteLLM-Proxys habe ich in meinem Artikel zu Token Governance beschrieben.

Modelle sind austauschbar. Heute setze ich Kimi K2.7 ein, morgen kann es Qwen 3.6 35B-A3B sein. Beide laufen über denselben OpenAI-kompatiblen Endpoint.

Der Bot merkt den Wechsel nicht. Das unterscheidet den Ansatz fundamental von Copilot oder GitHub-Actions-Integrationen, die auf einen Anbieter festgelegt sind.

Kontext statt nur Diff. Der Bot liest nicht nur den Diff. Er klont das Repository mit --depth=1, checkt den MR-Branch aus und sammelt alle Dateien bis zu einer Obergrenze von 200.000 Zeichen.

Dieser Kontext macht den Unterschied: In einem echten MR erkannte das Modell, dass neuer Code nicht zu bestehenden Error-Handling-Patterns passte.

Deduplizierung funktioniert. Der Bot speichert den aktuellen Commit-SHA in einem unsichtbaren Kommentar im Review.

Bei einem neuen Push ändert sich der SHA, der Bot erkennt das automatisch und führt ein Re-Review durch.

Default Reviewer ohne manuelle Konfiguration. Der Bot fragt GitLab, in welchen Projekten er Mitglied ist, und pollt alle automatisch.

So läuft ein Review ab:

Ein Merge-Request öffnet sich, GitLab feuert einen Webhook an den Bot.
Der Bot prüft, ob er als Reviewer zugewiesen ist.
Er holt Kontext und Diff.
Das Modell – heute Kimi K2.7, morgen Qwen 3.6 35B-A3B – erhält beides und schreibt ein Review.
Das Ergebnis landet als Kommentar am Merge-Request.

Alle fünf Minuten pollt der Bot zusätzlich offene MRs. So deckt er auch den Fall ab, dass er erst nachträglich als Reviewer hinzugefügt wird. Der Code liegt in einem eigenen Repository: git-lab.de/consolving/gitlab-review-bot.

Der Weg bis zum ersten echten Review war nicht gerade. GitLab Test-Events senden keinen X-Gitlab-Token-Header, weshalb der Bot Requests ohne Header erlaubt, aber mit Header validiert. Die Authelia-Middleware blockte anfangs unauthentifizierte Webhooks, also entfernte ich Authelia für den Webhook-Router und verlagerte die Validierung in den Bot. Ein klassischer Fehler: Der Bot war konfiguriert als kimi-reviewer, der GitLab-Benutzer hieß aber gitlab-review-bot. Ein weiteres Mal waren Traefik-Routing-Labels falsch gesetzt. Und das GitLab-Token hatte keinen Zugriff auf das Projekt. Nach diesen Korrekturen lief es.

Technisch steht dahinter ein Stack, der sich in wenigen Stunden zusammenbauen lässt: FastAPI, python-gitlab, der OpenAI-Client für LiteLLM-Kompatibilität, Docker, Traefik und GitLab CI/CD.

Der Bot läuft auf einem öffentlich erreichbaren Host – GitLab muss seinen Webhook von außen erreichen.

Den LiteLLM-Proxy erreicht er über Tailscale: Der Proxy läuft auf dem GX10 und ist nur über das private Netzwerk angebunden. Dieses Muster nutzen auch weitere Services. Die Prometheus-Metriken des Bots – Token-Verbrauch pro Modell, Review-Dauer, Fehlerraten – liegen damit neben dem Langfuse-Tracing im eigenen Observability-Setup.

Prometheus-Dashboard des Review-Bots: Reviews, Token-Verbrauch, Dauer und Fehler über die letzten 30 Tage.

Das Dashboard der letzten 30 Tage zeigt: 295 Reviews, im Schnitt 1,37 Minuten pro Review, bei 18,1 Millionen Tokens. Die im Schnitt 34,2 Fehler stammen noch aus der Entwicklungsphase.

Der Ausblick ist klar: Inline-Kommentare statt einer Summary-Note, konfigurierbare Ignore-Listen für Repo-Dateien, Smart-Context, der nur relevante Dateien statt aller lädt, und ein Cache für identische Diffs. Aber die Grundversion funktioniert bereits.

KI-gestützte Reviews sind nicht nur für große Enterprise-Teams machbar. Mit der richtigen Infrastruktur ist es ein Wochenend-Projekt. Der entscheidende Unterschied zum simplen Diff-Review ist der Kontext. Der Bot sieht, wie neuer Code zu bestehenden Mustern passt oder nicht. Er vergisst keine Sicherheitsprüfung und ist nie im Urlaub. Ich persönlich sehe ihn als Vorprüfung, bevor ein Mensch überhaupt zuschaut.

Der größte Hebel entsteht, wenn sich die Rollen verteilen.

Ein lokales Modell schreibt Code schnell und günstig.

Ein fähigeres Cloud-Modell reviewt das Ergebnis.

Und weil Werkzeuge wie das CLI-basierte glab existieren, kann der lokale Agent das Review selbstständig abholen und weiterverarbeiten. Die Schleife schließt sich ohne menschlichen Zwischenschritt.

Eine Einschränkung bleibt: Der Bot kann Stil, Team-Konventionen und soziale Feinheiten nicht bewerten. Er findet Inkonsistenzen, schwaches Error Handling und offensichtliche Risiken.

Die finale Entscheidung trifft weiterhin ein Mensch. Das ist auch gut so.

Alle Links auf einen Blick: