Letting an LLM Review Our Pull Requests (So You Don't Have To)

Wir lieben Automatisierung. Wir nutzen sie, um unsere Infrastruktur zu betreiben, Workloads auf null zu skalieren und—zunehmend—um die Menge an menschlicher Aufmerksamkeit zu reduzieren, die nötig ist, um qualitativ hochwertigen Code auszuliefern. Ein Bereich, der sich noch hartnäckig manuell anfühlte, waren die Pull-Request-Reviews. Zwischen Cursor als IDE, ChatGPT/Codex für Prototyping und gemini-cli für schnelle Checks waren unsere lokalen Workflows schnell—aber die CI wartete immer noch auf einen Menschen.

Also stellten wir eine einfache Frage: Könnten wir ein großes Sprachmodell den Diff lesen lassen, Probleme erkennen und direkt im PR kommentieren lassen?

Es stellte sich heraus: ja. Es brauchte nur ein paar Zeilen GitHub Actions-Kleber, um hilfreiche, strukturierte Reviews für jeden Pull Request zu bekommen.

The goal

Wir wollten keine Menschen ersetzen. Wir wollten einen ersten Durchgang, der:

• den tatsächlichen Diff eines PR liest (nicht das gesamte Repo),
• auf offensichtliche Fehler und riskante Änderungen hinweist,
• kleine Refactorings oder fehlende Tests vorschlägt,
• Befunde nach Priorität kategorisiert,
• und die Ergebnisse genau dorthin postet, wo wir ohnehin hinschauen: in die PR-Konversation und die Actions-Zusammenfassung.

Wenn eine Änderung in Ordnung ist, soll der Bot das einfach sagen und sich zurückziehen.

The tools in our stack

• GitHub Actions für die CI-Orchestrierung.
• Cursor (unsere tägliche IDE).
• ChatGPT/Codex für Ideenfindung und schnelle Offline-Reviews.
• @google/gemini-cli in der CI, um den automatisierten Review-Schritt auszuführen.
• Die GitHub CLI (gh), um im PR zu kommentieren.
• Eine kleine, aber wichtige Zutat: ein Prompt, das das Modell anleitet, nützliches, umsetzbares Feedback zu erzeugen.

The workflow, end to end

Here’s the full Action we’re running. Drop it into .github/workflows/gemini-pr.yml:

name: gemini-pr
on:
  workflow_dispatch:
  pull_request:
jobs:
  build:
    permissions: write-all
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
      with:
        submodules: 'true'
        fetch-depth: 0
    - uses: actions-rust-lang/setup-rust-toolchain@v1
      with:
        components: rustfmt, clippy
        cache: false
    - uses: actions/setup-node@v4
      with:
        node-version: 20
    - name: install gemini
      run: |
        npm install -g @google/gemini-cli
    - name: gemini
      run: |
        echo "merging into ${{ github.base_ref }}"
        git diff origin/${{ github.base_ref }} > pr.diff
        echo $PROMPT | gemini > review.md
        cat review.md >> $GITHUB_STEP_SUMMARY
        gh pr comment ${{ github.event.pull_request.number }} --body-file review.md
      env:
        GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}
        GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        PROMPT: >
          please review the changes of @pr.diff (this pull request) and suggest improvements or provide insights into potential issues. 
          do not document or comment on existing changes, if everything looks good, just say so.
          can you categorise the changes and improvesments into low, medium and high priority?
          Whenever you find an issue, please always provide an file and line number as reference information. if multiple files are affected, please provide a list of files and line numbers.
          provide the output in markdown format and do not include any other text.

Was jeder Teil macht

• Checkout mit fetch-depth: 0, damit wir zuverlässig gegen den Basis-Branch des PR diffen können.

• Rust-Toolchain installiert rustfmt und clippy, weil unsere Repos oft Rust-Code enthalten; diese laufen anderswo in unserer Pipeline, aber die Toolchain hier vorzubereiten vermeidet Überraschungen.

• Node wird für das gemini-cli benötigt.

• Wir installieren @google/gemini-cli global im Runner.

• Wir erstellen eine Diff-Datei:

  git diff origin/${{ github.base_ref }} > pr.diff
  

  So sieht das Modell nur die zur Überprüfung stehenden Änderungen.

• Wir leiten den Prompt in gemini (die CLI liest @pr.diff inline als Dateireferenz) und speichern die Markdown-Ausgabe des Modells in review.md.

• Wir hängen die Review an die Job-Zusammenfassung ($GITHUB_STEP_SUMMARY), damit sie in der Actions-UI sichtbar ist.

• Wir kommentieren im PR mit gh pr comment … --body-file review.md.

The prompt that makes it useful

LLM-Ausgaben sind nur so gut wie die Anweisungen. Unsere halten es praktisch:

• Umfang: Nur das prüfen, was sich geändert hat. Dokumentiere das Repository nicht neu.
• Signal: Sage “looks good”, wenn es nichts hinzuzufügen gibt. Keine erzwungene Kreativität.
• Umsetzbarkeit: Immer Datei + Zeilennummer angeben für Befunde.
• Prioritäten: Nach niedrig / mittel / hoch gruppieren, damit Reviewer schnell scannen können.
• Format: Nur Markdown, damit es sauber in PR-Kommentare eingefügt und in der Zusammenfassung gut gerendert wird.

Wir haben etwas iteriert, um hierher zu kommen. Die wirkungsvollsten Anpassungen waren: auf Datei-/Zeilenreferenzen zu bestehen und zusätzliche Prosa zu verbieten.

What the review looks like

In einem typischen PR sehen wir Abschnitte wie:

• Hoch: Sicherheitsrelevante Änderungen, fehlerhafte Fehlerbehandlung, fehlende Eingabevalidierung, versehentlich exponierte Secrets oder entfernte Tests.
• Mittel: Randfälle, Nebenläufigkeitsrisiken, fragwürdige Fehlermeldungen, nicht-idiomatischer Rust/Go/TS-Code, der später Probleme bereiten könnte.
• Niedrig: Benennungen, Kommentare, kleine Refactorings oder der Vorschlag für einen kurzen Test, um ein Verhalten abzusichern.

Wenn alles in Ordnung ist, bekommen wir einen Einzeiler: “Looks good.” Perfekt—genau das wollen wir.

Gotchas and practical notes

• Secrets: Du brauchst GEMINI_API_KEY und GITHUB_TOKEN in den Repo- oder Org-Secrets. Halte die Berechtigungen eng. Die Action setzt permissions: write-all, weil sie einen Kommentar postet; beschränke das, wenn eure Richtlinie es erfordert.
• Diff-Quelle: Bei komplexen Merges liefert git diff origin/${{ github.base_ref }} den richtigen Kontext. Wenn euer Workflow nur den Merge-Commit holt, stellt sicher, dass der Basis-Branch verfügbar ist, oder passt es an github.event.pull_request.base.sha an.
• Forks: Wenn ihr PRs von Forks akzeptiert, überprüft, wie ihr mit Secrets umgeht. Ihr könnt dies mit pull_request_target ausführen (mit sorgfältiger Härtung) oder die Review hinter Labels verstecken.
• Rauschkontrolle: Es hat sich als nützlich erwiesen, das Modell nichts anderes als “looks good” sagen zu lassen, wenn eine Änderung trivial ist. Das reduziert die Reviewer-Müdigkeit erheblich.
• Kosten und Kontingente: Modellaufrufe sind nicht kostenlos. Wir begrenzen die Größe des Diffs, das wir senden, und führen das nur bei pull_request aus (nicht bei jedem Push).
• Datenschutz: Ihr sendet euren Diff an einen externen Modellanbieter. Wenn euer Code sensibel ist oder Exportbeschränkungen unterliegt, bewertet das Risiko und wählt einen Anbieter/Deployment-Modus, der zu euren Compliance-Anforderungen passt.

Why this matters (beyond convenience)

Automatisierte Reviews machen Menschen wählerischer mit ihrer Aufmerksamkeit. Wir verbringen weniger Zeit mit “benenne diese Variable um” und mehr Zeit mit Architektur, Datenflüssen und Sicherheitsgrenzen. Das bedeutet:

• Schnellere Feedback-Schleifen für Beitragende.
• Weniger Review-Zyklen wegen Nichtigkeiten.
• Eine sauberere Commit-Historie, weil Probleme früher gefangen werden.
• Mehr Zeit für nachhaltige Arbeit, die uns wirklich wichtig ist—z. B. die Leistung eines Services zu optimieren oder Egress-Kosten zu senken.

Es ist außerdem überraschend gut in Sachen Konsistenz. Ein LLM vergisst nicht das vereinbarte Fehlerbehandlungs-Muster zwischen Services oder unsere bevorzugte Log-Struktur; es wendet diese Prüfungen bei jedem PR einheitlich an.

Variations you might try

Dieses Muster funktioniert mit nahezu jedem Modell oder CLI. Ein paar einfache Erweiterungen:

• Multi-Model Voting: Rufe zwei Modelle mit demselben Prompt auf und behalte nur Befunde, denen beide zustimmen.
• Sprachspezifische Durchläufe: Wenn euer Repo mehrere Sprachen mischt, führt sprachspezifische Prompts aus (z. B. einen für Rust mit clippy-Hinweisen, einen für TypeScript).
• “Fail on High”-Gates: Nutzt einen kleinen Parser, um einen “Hoch”-Abschnitt zu erkennen und setzt den Job auf failed, um Merges zu blockieren, bis das Problem behoben ist.
• Inline-Review: Konvertiert Datei-/Zeilenreferenzen in GitHub-Review-Kommentare (die gh CLI unterstützt das) für noch prägnanteres Feedback.
• PR-Label-Steuerung: Nur ausführen, wenn ein Maintainer ein ai-review-Label hinzufügt, oder automatisch ein needs-attention-Label setzen, wenn hochprioritäre Befunde auftauchen.

Results so far

• Kürzere Review-Zyklen bei unkomplizierten Änderungen.
• Sauberere Diffs, weil Beitragende niedrighängende Früchte selbst beheben, bevor ein Mensch hinschaut.
• Besseres Onboarding: neue Teammitglieder erhalten konkretes Feedback, das dem entspricht, was erfahrene Reviewer sagen würden.
• Kein Drama: hat der Bot nichts hinzuzufügen, bleibt er still.

Nichts davon ersetzt die menschliche Freigabe eines Merges. Es ist ein leichtgewichtiger Filter, der sich am ersten Tag auszahlt.