Ein LLM unsere Pull Requests prüfen lassen (damit du es nicht tun musst)

We lieben Automatisierung. Wir nutzen sie, um unsere Infrastruktur zu betreiben, Workloads auf null zu skalieren und—zunehmend—um die Menge an menschlicher Aufmerksamkeit zu verringern, die nötig ist, um qualitativ hochwertigen Code auszuliefern. Ein Bereich, der sich bisher 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 CI wartete trotzdem noch auf einen Menschen.

Also stellten wir eine einfache Frage: Können wir ein großes Sprachmodell den Diff lesen lassen, Probleme finden 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 Menschen nicht ersetzen. Wir wollten einen ersten Durchgang, der:

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

Wenn eine Änderung in Ordnung ist, soll der Bot das einfach so sagen und sich aus dem Weg halten.

The tools in our stack

• GitHub Actions für CI-Orchestrierung.
• Cursor (unsere tägliche IDE).
• ChatGPT/Codex für Ideation und schnelle Offline-Reviews.
• @google/gemini-cli in 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

Hier ist die vollständige Action, die wir laufen lassen. Leg sie in .github/workflows/gemini-pr.yml ab:

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: >
          bitte überprüfe die änderungen in @pr.diff (dieser Pull Request) und schlage verbesserungen vor oder gib einblicke in mögliche probleme. 
          dokumentiere oder kommentiere bestehende änderungen nicht; wenn alles gut aussieht, sag es einfach.
          kannst du die änderungen und verbesserungen in niedrig, mittel und hoch priorität kategorisieren?
          Wann immer du ein Problem findest, gib bitte immer eine Datei- und Zeilennummer als Referenzinformation an. Wenn mehrere Dateien betroffen sind, gib bitte eine Liste von Dateien und Zeilennummern an.
          gib die Ausgabe im Markdown-Format aus und füge keinen weiteren Text hinzu.

What each part does

• 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 häufig Rust-Code enthalten; diese laufen anderswo in unserer Pipeline, aber die Toolchain hier einzurichten 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
  

  Das stellt sicher, dass das Modell nur die geprüften Änderungen sieht.

• Wir piped 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. Unseres hält die Dinge praktisch:

• Scope: Nur das prüfen, was sich geändert hat. Nicht das Repository neu dokumentieren.
• Signal: “Looks good” sagen, wenn nichts hinzuzufügen ist. Keine erzwungene Kreativität.
• Actionability: Immer Datei + Zeilennummern 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 passt und in der Zusammenfassung gut gerendert wird.

Wir haben etwas iteriert, um dorthin zu kommen. Die wirkungsvollsten Anpassungen waren: das Bestehen auf Datei-/Zeilenreferenzen und das Verbot von zusätzlichem Fließtext.

What the review looks like

Bei einem typischen PR sehen wir Abschnitte wie:

• High: Sicherheitsrelevante Änderungen, kaputtes Fehlerhandling, fehlende Eingabevalidierung, versehentlich veröffentlichte Geheimnisse oder entfernte Tests.
• Medium: Randfälle, Nebenläufigkeitsrisiken, fragwürdige Fehlermeldungen, nicht-idiomatisches Rust/Go/TS, das später Probleme machen könnte.
• Low: Benennungen, Kommentare, kleine Refactorings oder der Vorschlag eines kurzen Tests, um ein Verhalten abzusichern.

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

Gotchas and practical notes

• Secrets: Du brauchst GEMINI_API_KEY und GITHUB_TOKEN in 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 das verlangt.
• Diff source: 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 auf github.event.pull_request.base.sha an.
• Forks: Wenn ihr PRs aus Forks akzeptiert, überlegt, wie ihr mit Secrets umgeht. Ihr möchtet dies eventuell mit pull_request_target und sorgfältiger Härtung ausführen oder die Review hinter Labels sperren.
• Noise control: Wir fanden es nützlich, das Modell bei trivialen Änderungen einfach nur “looks good” sagen zu lassen. Das allein reduziert Reviewer-Müdigkeit.
• Costs and quotas: Modellaufrufe sind nicht kostenlos. Wir begrenzen die Größe des gesendeten Diffs und führen das nur bei pull_request (nicht bei jedem Push) aus.
• Privacy: 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/Deployments-Modell, das zu euren Compliance-Anforderungen passt.

Why this matters (beyond convenience)

Automatisierte Reviews machen Menschen selektiver 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 Contributors.
• Weniger Review-Zyklen wegen Nichtigkeiten.
• Eine sauberere Commit-Historie, weil Probleme früher gefasst werden.
• Mehr Zeit für nachhaltige Arbeit, die uns wirklich wichtig ist—wie Stromverbrauch eines Dienstes zu senken oder Netzwerkegress zu reduzieren.

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 fast jedem Modell oder CLI. Ein paar einfache Erweiterungen:

• Multi-model voting: Zwei Modelle mit demselben Prompt aufrufen und nur Erkenntnisse behalten, denen sie zustimmen.
• Language-aware passes: Wenn euer Repo mehrere Sprachen mischt, führe sprachspezifische Prompts aus (z. B. einen für Rust mit clippy-Hinweisen, einen für TypeScript).
• “Fail on High” gates: Nutze einen kleinen Parser, um einen “High”-Abschnitt zu erkennen und setze den Job auf failed, um Merges zu blockieren, bis die Probleme behoben sind.
• Inline review: Konvertiere Datei-/Zeilenreferenzen in GitHub-Review-Kommentare (die gh-CLI unterstützt das) für noch gezielteres Feedback.
• PR label control: Nur laufen lassen, wenn ein Maintainer ein ai-review-Label setzt, oder automatisch ein needs-attention-Label hinzufügen, wenn hochprioritäre Befunde auftauchen.

Results so far

• Kürzere Review-Zyklen bei einfachen Änderungen.
• Sauberere Diffs, weil Contributors niedrighängende Früchte vor dem menschlichen Review beheben.
• Besseres Onboarding: neue Teammitglieder bekommen konkretes Feedback, das dem entspricht, was Senior-Reviewer sagen würden.
• Kein Drama: hat der Bot nichts hinzuzufügen, bleibt er still.

Nichts davon ersetzt einen Menschen, der einen Merge approvt. Es ist ein leichter Filter, der sich bereits am ersten Tag bezahlt macht.