Zum Hauptinhalt springen
Da Code-Agenten immer verbreiteter werden, verlagert sich der Engpass vom Schreiben von Code auf das Review. Devin Review ist eine Full-Service-Code-Review-Plattform innerhalb der Devin-Webapp, die große, komplexe GitHub-PRs in intuitiv organisierte Diffs und präzise Erklärungen verwandelt.
Devin Review ist kostenlos und für PRs in normalen GitHub-Repositories verfügbar (nicht GitHub Enterprise). Öffentliche PRs erfordern kein Devin-Konto. Private PRs können mit einem Devin-Konto oder über die CLI angezeigt werden.

​
Funktionen

Intelligente Diff-Organisation

Gruppiert Änderungen logisch und fasst zusammengehörige Anpassungen zusammen, anstatt sie alphabetisch zu sortieren.

Erkennung von Kopieren und Verschieben

Erkennt, wenn Code kopiert oder verschoben wurde, und zeigt Änderungen übersichtlich an, statt vollständiger Löschungen und Einfügungen.

Bug-Erkennung

Prüft auf Bugs und kennzeichnet sie nach Vertrauensstufe. Schwere Bugs erfordern sofortige Aufmerksamkeit.

GitHub-Kompatibilität

Hinterlassen Sie Kommentare, genehmigen Sie PRs (Pull Requests), fordern Sie Änderungen an – alles in Devin Review, synchronisiert mit GitHub.

Chat mit Codebasis-Kontext

Stellen Sie Fragen zum PR und erhalten Sie Antworten mit relevantem Kontext aus dem Rest der Codebasis. Sie können Devin außerdem direkt aus jedem Kommentar, Bug oder Flag in der Diff-Ansicht heraus ansprechen.

​
Erste Schritte

  • Devin-Web-App — Rufen Sie app.devin.ai/review auf, um Ihre offenen PRs nach Kategorien gegliedert zu sehen (Ihnen zugewiesen, von Ihnen erstellt, Review angefordert). Wenn Devin PRs erstellt, sehen Sie einen orangefarbenen „Review“-Button im Chat.
  • URL-Kurzbefehl — Ersetzen Sie in jedem GitHub-PR-Link github.com durch devinreview.com in der URL. Melden Sie sich bei privaten PRs zuerst bei Devin an oder verwenden Sie die CLI.
  • CLI — Führen Sie npx devin-review {pr-url} in einem lokalen Klon aus. Siehe CLI unten für Details.

​
Auto-Review

Devin kann Pull Requests (PRs) automatisch überprüfen, ohne dass Sie ihn manuell auslösen müssen. Konfigurieren Sie Auto-Review unter Settings > Review oder über das Symbol für Einstellungen auf einer beliebigen PR-Review-Seite.

​
Wann wird Auto-Review ausgeführt?

Auto-Review wird ausgelöst, wenn:
  • ein Pull Request (PR) geöffnet wird (nicht als Entwurf)
  • neue Commits in einen PR gepusht werden
  • ein Entwurfs-PR als bereit für die Review markiert wird
  • ein registrierter Nutzer als Reviewer oder Verantwortlicher hinzugefügt wird
Entwurfs-PRs werden ignoriert, bis sie als bereit markiert sind.

​
Selbstanmeldung (alle Benutzer)

Jeder Benutzer mit verbundenem GitHub-Konto kann sich selbst für automatische Reviews anmelden – keine Admin-Berechtigungen erforderlich.
  1. Gehe zu Settings > Review
  2. Klicke auf „Add myself (@yourusername)“, um dich anzumelden
Sobald du angemeldet bist, wird Devin in jedem Repository automatisch jeden PR überprüfen, den du erstellst, bei dem du als Reviewer hinzugefügt wirst oder der dir zugewiesen wird. Du kannst dich auch direkt von einer PR-Review-Seite aus selbst anmelden, indem du auf das Einstellungs-Symbol klickst und „Me (@username)“ aktivierst.

​
Admin-Konfiguration

Admins haben zusätzliche Optionen unter Settings > Review:
  • Repositories — Fügen Sie Repositories hinzu, um ALLE PRs in diesem Repository automatisch prüfen zu lassen. Verwenden Sie das Dropdown-Menü, um in verbundenen Repositories zu suchen und diese auszuwählen.
  • Users — Anzeigen und Verwalten aller registrierten Benutzer in der gesamten Organisation. Fügen Sie beliebige GitHub-Benutzernamen zur Liste für automatische Reviews hinzu.
  • Insert link in PR description — Wenn diese Option aktiviert ist (Standard), fügt Devin einen Link zur Review in die PR-Beschreibung ein.
Enterprise-Konten: Die Einstellungen gelten für alle Organisationen im Enterprise-Account. Nur Benutzer in der primären Organisation mit Enterprise-Admin- Berechtigungen können diese Einstellungen verwalten. Benutzer in nicht primären Organisationen können sich nur selbst registrieren.
Automatische Reviews sind für öffentliche Repositories, die nicht mit Ihrer Organisation verbunden sind, nicht verfügbar.

​
Bug Catcher

Der Bug Catcher analysiert Ihren PR automatisch auf potenzielle Probleme und zeigt die Ergebnisse in der Analyse-Seitenleiste an. Die Ergebnisse sind in zwei Kategorien unterteilt: Bugs und Flags.

​
Bugs

Bugs sind behebbare Fehler, die im Code korrigiert werden sollten. Sie stellen Probleme dar, bei denen der Bug Catcher mit hoher Wahrscheinlichkeit davon ausgeht, dass es sich um tatsächliche Fehler handelt. Bugs werden mit zwei Schweregraden angezeigt:
  • Schwerwiegend — Probleme mit hoher Wahrscheinlichkeit, die sofortige Aufmerksamkeit erfordern
  • Nicht schwerwiegend — Probleme mit geringerer Schwere, die trotzdem überprüft werden sollten
Wenn Sie einen Bug sehen, sollten Sie ihn untersuchen und in Ihrem Code beheben.

​
Flags

Flags sind informative Codeanmerkungen, die möglicherweise Maßnahmen erfordern oder auch nicht. Es gibt zwei Arten:
  • Investigate — Flags, die eine genauere Untersuchung erfordern. Sie sollten den markierten Code selbst überprüfen und prüfen, ob es sich tatsächlich um einen Bug oder ein Problem handelt.
  • Informational — Der Bug Catcher hat entweder bestätigt, dass der Code korrekt ist, oder erklärt, wie etwas funktioniert. Diese helfen Ihnen, die Codeänderungen zu verstehen, ohne dass Maßnahmen erforderlich sind.

​
Findings beheben

Sie können Bugs und Flags als behoben markieren, sobald Sie sie behoben haben oder festgestellt haben, dass keine weitere Aktion erforderlich ist. Behobene Einträge werden in der Seitenleiste abgedunkelt dargestellt und in jedem Abschnitt an das Ende sortiert.

​
Review-Aktionen

​
Eine Review starten

Wenn du einen neuen Inline-Kommentar erstellst oder auf einen bestehenden Thread antwortest, kannst du das Kontrollkästchen Start a review aktivieren, um deine Kommentare zu einer ausstehenden Review zu bündeln, anstatt sie einzeln zu posten. Dies spiegelt den GitHub-Review-Workflow wider und ermöglicht dir, dein gesamtes Feedback zu sammeln, bevor du die Review einreichst. Sobald eine Review läuft, werden nachfolgende Kommentare automatisch dieser hinzugefügt und das Kontrollkästchen ausgeblendet.

​
Kommentare auflösen

Sie können Review-Threads auflösen, um anzuzeigen, dass sie bearbeitet wurden. Wenn alle Threads in einem von einem Bot erstellten Review aufgelöst sind, minimiert Devin dieses Review auf GitHub automatisch, um die PR-Diskussion übersichtlich zu halten. Wenn ein Thread später wieder als ungelöst markiert wird, wird das Review automatisch wieder eingeblendet. In der Diff-Ansicht können Sie einzelne Kommentar-Threads über das Caret-Symbol ein- oder ausklappen, um sich auf noch offenes Feedback zu konzentrieren.

​
Kennzeichnungen für Code Owner

Wenn ein Code Owner als Reviewer angefordert wurde, zeigt Devin Review ein Schildsymbol neben dem Namen in der Reviewer-Seitenleiste mit dem Tooltip „Requested as code owner“ an. So lässt sich leicht erkennen, welche angeforderten Reviewer die Code Ownership für die geänderten Dateien besitzen.

​
Auto-Fix

Devin Review kann automatisch Korrekturen für Fehler (Bugs) vorschlagen und anwenden, die es in Ihren PRs erkennt. Wenn Auto-Fix aktiviert ist, schlägt Devin Codeänderungen direkt zusammen mit den identifizierten Fehlern vor.

​
So aktivieren Sie Auto-Fix

Es gibt drei Möglichkeiten, Auto-Fix zu aktivieren:
  1. Über das Popover für PR-Review-Einstellungen — Klicken Sie auf einer beliebigen Devin Review-Seite auf das Einstellungssymbol (drei Punkte) und schalten Sie Enable Autofix ein. Dieser Schalter erscheint bei von Devin erstellten PRs.
  2. Über die eingebetteten PR-Review-Einstellungen — Öffnen Sie in der eingebetteten Devin Review-Ansicht innerhalb einer Devin-Sitzung das Einstellungs-Popover und schalten Sie Enable Autofix ein.
  3. Über die globalen Customization-Einstellungen — Gehen Sie zu Settings > Customization > Pull request settings > Autofix settings - bot comments und führen Sie dann einen der folgenden Schritte aus:
    • Setzen Sie den Modus auf Respond to specific bots only und fügen Sie devin-ai-integration[bot] zur Allowlist hinzu, oder
    • Setzen Sie den Modus auf Respond to all bot comments.
Wenn Devin Review Fehler findet und Auto-Fix aktiviert ist, generiert Devin Vorschläge für Korrekturen, die Sie direkt in der Diff-Ansicht prüfen und anwenden können.

​
Berechtigungen & Einschränkungen

  • Nur Administratoren der Organisation können diese Einstellung ändern.
  • Wenn der Bot-Kommentar-Modus auf Auf alle Bot-Kommentare antworten gesetzt ist, wird der Auto-Fix-Schalter zwar als aktiviert angezeigt, kann aber in den PR-Review-Einstellungen nicht geändert werden. Verwenden Sie die Anpassungseinstellungen, um den Bot-Kommentar-Modus zu ändern.
  • Die Zusammenfassungskommentare von Devin Review mit Keine Probleme gefunden werden immer ignoriert. Nur Kommentare mit tatsächlichen Befunden lösen Auto-Fix aus.
Wenn Feedback von Devin Review in Ihrem Repository derzeit ignoriert wird, sehen Sie eine Aufforderung im Sitzungsverlauf, es zu aktivieren.

​
CLI

Mit der Devin Review CLI können Sie Code-Reviews direkt in Ihrem Terminal durchführen. Das ist besonders nützlich für private Repositories oder wenn Sie einen schlanken lokalen Workflow bevorzugen.

​
Installation & Verwendung

Führen Sie die CLI in einem lokalen Klon des Repositories aus; eine Authentifizierung ist nicht erforderlich: 
cd path/to/repo
npx devin-review https://github.com/owner/repo/pull/123
Sie müssen diesen Befehl aus dem zu überprüfenden Repository heraus ausführen. Funktionsweise:
  1. Git-basierte Diff-Extraktion — Die CLI verwendet Ihren lokalen Git-Zugriff, um den PR-Branch abzurufen und das Diff zu berechnen. Das bedeutet, dass Sie Lesezugriff auf das Repository auf Ihrem Rechner benötigen.
  2. Isoliertes Worktree-Checkout — Die CLI erstellt einen git worktree in einem Cache-Verzeichnis, um den PR-Branch auszuchecken. Dadurch bleibt Ihr Arbeitsverzeichnis unverändert – kein Stashing, kein Branch-Wechsel. Der Worktree wird nach Abschluss des Reviews automatisch bereinigt.
  3. Diff wird an Devin-Server gesendet — Das berechnete Diff und die Dateiinhalte werden zur Analyse an die Devin-Server gesendet.

​
Datenschutz & Zugriffskontrolle

Die CLI verwendet einen Localhost-Server, um Ihre Review-Sitzung zu authentifizieren:
  • Standardmäßig nur lokaler Zugriff — Wenn Sie devin-review ausführen, startet es einen Localhost-Server auf Ihrem Rechner, der ein sicheres Token bereitstellt. Nur Prozesse auf Ihrem lokalen Rechner können auf dieses Token zugreifen, was bedeutet, dass nur Sie die Review-Seite anzeigen können, solange Sie nicht angemeldet sind.
  • Übertragung auf Ihr Devin-Konto — Wenn Sie sich bei einem Devin-Konto anmelden, das Zugriff auf die GitHub-Organisation hat, wird die Review-Sitzung auf Ihr Konto übertragen. Dadurch können Sie von anderen Geräten auf das Review zugreifen und es mit Teammitgliedern teilen.
Wenn Sie die CLI ausführen, kann devin-review lokal auf Ihrem Rechner Befehle ausführen, um zusätzlichen Kontext zum Auffinden von Bugs zu sammeln. Dies ermöglicht eine tiefere Analyse als ein reines Diff-Review. Der Bug Catcher kann nur einen begrenzten Satz an schreibgeschützten Operationen ausführen, die auf das Worktree-Verzeichnis beschränkt sind:
  • Dateilesen — Lesen von Dateiinhalten innerhalb des Repositorys
  • Suche — Mit grep nach Mustern suchen und mit Glob-Mustern nach Dateinamen suchen
  • Bash-Befehle — Nur schreibgeschützte Befehle wie ls, cat, pwd, file, head, tail, wc, find, tree, stat und du

​
Zuordnung von Commits und Kommentaren

  • Bugfunde, Flags und automatisierte Anmerkungen werden immer dem Devin-Bot zugeordnet.
  • Wenn ein Benutzer über Devin Review einen Kommentar oder ein Review schreibt, erscheint dies unter der GitHub-Identität des Benutzers.
  • Wenn ein Benutzer den Chat-Agenten bittet, eine Codeänderung vorzunehmen, wird der daraus resultierende Commit unter Devin-Bot erstellt.
  • GitHub Suggested Changes folgen dem Standardverhalten von GitHub: Jeder Reviewer (einschließlich Devin) kann eine vorgeschlagene Änderung in einem Review-Kommentar hinterlassen. Wenn ein Benutzer auf „Apply suggestion“ klickt, wird der Commit von diesem Benutzer erstellt, genau wie bei GitHub.
  • Devin wird niemals Commits oder Kommentare im Auftrag eines Benutzers erstellen, ohne dass der Benutzer die Aktion ausdrücklich initiiert.

​
AGENTS.md / Anweisungsdateien

Devin Review berücksichtigt Anweisungsdateien in Ihrem Repository. Wenn eine dieser Dateien vorhanden ist, werden sie beim Analysieren Ihres Pull Requests (PR) als Kontext verwendet:
  • REVIEW.md
  • AGENTS.md
  • CLAUDE.md
  • CONTRIBUTING.md
  • .cursorrules
  • .windsurfrules
  • .cursor/rules
  • *.rules
  • *.mdc
Diese Dateien können Coding-Standards, Projektkonventionen oder andere Richtlinien enthalten, die zu relevanterem Feedback beitragen.

​
Benutzerdefinierte Review-Regeln

Unter Review Rules in Settings > Review können Sie zusätzliche Dateien konfigurieren, die als Review-Kontext eingelesen werden sollen. So können Sie benutzerdefinierte Glob-Muster für Dateien über die oben aufgeführten Standardwerte hinaus hinzufügen. So fügen Sie eine benutzerdefinierte Regel hinzu:
  1. Gehen Sie zu Settings > Review
  2. Geben Sie unter Review Rules ein Glob-Muster für Dateien ein (z. B. docs/**/*.md)
  3. Klicken Sie auf Add
Benutzerdefinierte Regeln erscheinen in der Liste neben der Standardregel **/REVIEW.md. Sie können jede benutzerdefinierte Regel entfernen, indem Sie auf das Papierkorbsymbol daneben klicken. Dies ist hilfreich, wenn Ihr Projekt review-relevante Dokumentation an nicht standardmäßigen Speicherorten enthält, z. B. Architecture Decision Records (ADRs), Styleguides oder teamspezifische Konventionen, die in benutzerdefinierten Pfaden abgelegt sind.

​
REVIEW.md

REVIEW.md ist eine spezielle Anleitungsdatei für Devin Review. Platzieren Sie sie an einer beliebigen Stelle in Ihrem Repository, um zu steuern, wie Devin Pull Requests (PRs) in Ihrem Projekt überprüft. Devin erkennt REVIEW.md-Dateien automatisch auf jeder Verzeichnisebene (**/REVIEW.md), sodass Sie Review-Richtlinien bei Bedarf auf bestimmte Unterverzeichnisse beschränken können. Verwenden Sie REVIEW.md, um reviewspezifische Richtlinien wie die folgenden festzulegen:
  • Bereiche der Codebasis, die besonders sorgfältig geprüft werden müssen
  • Häufige Fallstricke oder Anti-Patterns, auf die geachtet werden soll
  • Projektspezifische Konventionen, die Reviewer durchsetzen sollen
  • Dateien oder Verzeichnisse, die während des Reviews gefahrlos ignoriert werden können
  • Sicherheits- oder Performance-Aspekte, die spezifisch für Ihr Projekt sind
Beispiel REVIEW.md: 
# Review-Richtlinien

## Kritische Bereiche
- Alle Änderungen an `src/auth/` müssen auf Sicherheitsauswirkungen überprüft werden.
- Datenbank-Migrationsdateien sollten auf Rückwärtskompatibilität geprüft werden.

## Konventionen
- API-Endpunkte müssen Eingabevalidierung und ordnungsgemäße Fehlerbehandlung enthalten.
- Alle öffentlichen Funktionen erfordern TypeScript-Rückgabetypen – verwenden Sie nicht `any`.
- React-Komponenten sollten funktionale Komponenten mit Hooks verwenden, keine Klassenkomponenten.

## Ignorieren
- Automatisch generierte Dateien in `src/generated/` benötigen keine Überprüfung.
- Lock-Dateien (package-lock.json, yarn.lock) können übersprungen werden, sofern sich die Abhängigkeiten nicht geändert haben.

## Performance
- Markieren Sie alle Datenbankabfragen innerhalb von Schleifen.
- Achten Sie auf N+1-Abfragemuster in API-Resolvern.