Ein LLM unsere Pull Requests überprüfen lassen (damit Sie es nicht tun müssen)

Wir lieben Automation. Wir nutzen sie, um unsere Infrastruktur zu betreiben, Workloads auf Null zu skalieren und – zunehmend – um den menschlichen Aufwand zu verringern, der nötig ist, um qualitativ hochwertigen Code auszuliefern. Ein Bereich, der sich bisher noch hartnäckig manuell anfühlte, waren Pull-Request-Reviews. Zwischen Cursor als unserer IDE, ChatGPT/Codex für Prototyping und gemini-cli für schnelle Checks waren unsere lokalen Workflows schnell – aber 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 stellt sich heraus: ja. Es brauchte nur ein paar Zeilen GitHub Actions-Kleber, um bei jedem Pull Request hilfreiche, strukturierte Reviews zu erhalten.

The goal

Wir wollten Menschen nicht ersetzen. Wir wollten einen ersten Durchlauf, der:

• den tatsächlichen Diff eines PR liest (nicht das gesamte Repo),
• offensichtliche Fehler und riskante Änderungen hervorhebt,
• kleine Refactorings oder fehlende Tests vorschlägt,
• Ergebnisse nach Priorität kategorisiert,
• und die Resultate genau dort postet, wo wir ohnehin hinschauen: im PR-Gespräch und in der 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 zur Orchestrierung der CI.
• Cursor (unsere tägliche IDE).
• ChatGPT/Codex für Ideation und schnelle Offline-Reviews.
• @google/gemini-cli in der CI, um den automatisierten Review-Schritt durchzuführen.
• Die GitHub CLI (gh), um im PR zu kommentieren.
• Eine kleine, aber wichtige Zutat: ein Prompt, der das Modell steuert, nützliches und umsetzbares Feedback zu liefern.

The workflow, end to end

Hier ist die komplette Action, die wir ausführen. Einfach in .github/workflows/gemini-pr.yml einfügen:

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 Tools laufen auch woanders 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 erzeugen eine Diff-Datei:

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

  So sieht das Modell nur die zur Review stehenden Änderungen.

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

• Wir fügen die Review in die Job-Zusammenfassung ($GITHUB_STEP_SUMMARY) ein, sodass sie in der Actions-Oberfläche 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 sind pragmatisch:

• Scope: Nur das prüfen, was geändert wurde. Nicht das Repo erneut dokumentieren.
• Signal: Sag “looks good”, wenn es nichts hinzuzufügen gibt. Keine erzwungene Kreativität.
• Actionability: Immer Datei + Zeilennummer für Funde angeben.
• Priorities: 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 dargestellt wird.

Wir haben ein wenig iteriert, um dies zu erreichen. Die wirkungsvollsten Anpassungen waren: auf Datei-/Zeilenverweise zu bestehen und ausschweifenden Text zu verbieten.

What the review looks like

In einem typischen PR sehen wir Abschnitte wie:

• High: Sicherheitsrelevante Änderungen, fehlerhafte Fehlerbehandlung, fehlende Eingabevalidierung, versehentliche Geheimnisse oder entfernte Tests.
• Medium: Randfälle, Concurrency-Risiken, fragwürdige Fehlermeldungen, nicht idiomatisches Rust/Go/TS, das später Probleme bereiten könnte.
• Low: Benennung, Kommentare, kleine Refactorings oder Vorschläge für kurze Tests zur Verhaltenssicherung.

Wenn alles in Ordnung ist, erhalten wir eine Einzeiler: “Looks good.” Perfekt – genau das wollen wir.

Gotchas and practical notes

• Secrets: Sie benötigen GEMINI_API_KEY und GITHUB_TOKEN als Repo- oder Organisations-Geheimnisse. Halten Sie die Berechtigungen eng. Die Action setzt permissions: write-all, da sie Kommentare postet; schränken Sie dies ein, wenn Ihre Policies das erfordern.
• Diff-Quelle: Für komplexe Merges liefert git diff origin/${{ github.base_ref }} den richtigen Kontext. Wenn Ihr Workflow nur den Merge-Commit abholt, stellen Sie sicher, dass der Basis-Branch verfügbar ist oder passen Sie auf github.event.pull_request.base.sha an.
• Forks: Akzeptieren Sie PRs von Forks, prüfen Sie, wie Sie Secrets handhaben. Sie möchten das möglicherweise auf pull_request_target mit sorgfältiger Härtung ausführen oder die Review hinter Labels absichern.
• Lärmsteuerung: Wir fanden es nützlich, das Modell nichts anderes als “looks good” sagen zu lassen, wenn eine Änderung trivial ist. Das allein verringert die Reviewer-Müdigkeit deutlich.
• Kosten und Kontingente: Modellaufrufe sind nicht kostenlos. Wir begrenzen die Größe des gesendeten Diffs und führen das nur auf pull_request (nicht bei jedem Push) aus.
• Datenschutz: Sie senden Ihren Diff an einen externen Modellanbieter. Wenn Ihr Code sensibel ist oder Exportbeschränkungen unterliegt, bewerten Sie Risiken und wählen Sie einen Anbieter/Einsatzmodell, das Ihre Compliance-Anforderungen erfüllt.

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 bei Kleinigkeiten.
• Eine sauberere Commit-Historie durch frühzeitiges Erkennen von Problemen.
• Mehr Zeit für nachhaltige Arbeit, die uns wirklich wichtig ist – etwa um Stromverbrauch eines Services zu senken oder Netzwerk-Ausgangsdaten zu reduzieren.

Es ist auch überraschend gut in Sachen Konsistenz. Ein LLM vergisst nicht das vereinbarte Fehlerbehandlungsmuster zwischen Diensten 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. Einige einfache Erweiterungen:

• Multi-Model Voting: Zwei Modelle mit gleichem Prompt befragen und nur Übereinstimmungen als Funde behalten.
• Sprachspezifische Durchläufe: Wenn Ihr Repo mehrere Sprachen mischt, führen Sie sprachspezifische Prompts aus (z. B. eines für Rust mit Clippy-Hinweisen, eines für TypeScript).
• “Fail on High”-Gates: Mit einem kleinen Parser eine „High“-Sektion erkennen und den Job auf failed setzen, um Merges bis zur Behebung zu blockieren.
• Inline Review: Datei-/Zeilenverweise in GitHub-Review-Kommentare umwandeln (das gh CLI unterstützt das) für noch präziseres Feedback.
• PR-Label-Steuerung: Nur ausführen, wenn Maintainer ein ai-review-Label hinzufügen, oder automatisch needs-attention hinzufügen, wenn hochprioritäre Funde erscheinen.

Results so far

• Kürzere Review-Zyklen bei unkomplizierten Änderungen.
• Sauberere Diffs, weil Beitragende niedrig hängende Verbesserungen vor Review durch Menschen beheben.
• Besseres Onboarding: Neue Teammitglieder bekommen konkrete Tipps, die erfahrene Reviewer geben würden.
• Kein Drama: Wenn der Bot nichts hinzuzufügen hat, bleibt er still.

Das ersetzt keine menschliche Merge-Freigabe. Es ist ein leichter Filter, der sich am ersten Tag bezahlt macht.