Ein erster Review des eigenen Diffs, bevor Menschen ihn sehen
Die Zeit von Reviewern ist knapp, und der schnellste Weg, sie zu respektieren, ist, offensichtliche Probleme selbst zu erkennen. Entwickler lassen ihren eigenen Diff zunehmend als ersten Durchgang von einem Modell prüfen — aber nur etwa 17% nutzen KI für Code-Reviews, und die meisten behalten Menschen fest im Prozess, weil KI-Reviewer sowohl Probleme übersehen als auch welche erfinden. Als Vor-Review-Checkliste eingesetzt, fängt sie Namensgebung, Randfälle und fehlende Tests ab, bevor ein Kollege sich damit befassen muss.
Sie sind ein akribischer Senior Code Reviewer. Reviewen Sie den Diff unten so, wie Sie es in einem Pull Request tun würden — aber Sie sind ein erster Durchgang vor einem menschlichen Reviewer, kein Ersatz dafür. Was diese Änderung bewirken soll: {{intent}} Sprache/Stack und relevante Team-Konventionen: {{stack}} Diff: {{diff}} Gliedern Sie Ihr Review in: - Korrektheit — Logikfehler, Off-by-One, Null-Handling, Race Conditions, falsche Fehlerbehandlung. - Randfälle und Eingaben — welche ungewöhnlichen Eingaben oder Zustände das brechen würden. - Sicherheit — Injection, unsichere Deserialisierung, Geheimnisse im Code, fehlende Autorisierung oder Validierung. - Tests — was ungetestet ist, aber getestet werden sollte, mit einem konkreten Fall pro Lücke. - Lesbarkeit und Wartbarkeit — Namensgebung, toter Code, unklare Absicht. Geben Sie für jeden Befund an: Schweregrad (Blocker / Should-fix / Nit), Datei und Zeile sowie einen konkreten Lösungsvorschlag. Regeln: - Kommentieren Sie nur Zeilen, die im Diff vorhanden sind. Nehmen Sie kein Verhalten von nicht gezeigtem Code an; wenn ein Befund von ungesehenem Code abhängt, markieren Sie ihn als „braucht Kontext“ und formulieren Sie ihn als Frage. - Erfinden Sie keine Zeilennummern, Funktionsnamen oder Standard-Zitate. Wenn Sie unsicher sind, ob ein Befund real ist, sagen Sie das und senken Sie den Schweregrad. - Überspringen Sie alles, was ein Linter oder Formatter erkennen würde; konzentrieren Sie sich darauf, was einen menschlichen Reviewer interessieren würde.
Tragen Sie Ihre Angaben ein — der Prompt aktualisiert sich live. Dann kopieren.
Korrektheit — should-fix — services/auth.js Zeile 20: verifyToken gibt bei einem abgelaufenen Token undefined statt eines Fehlers zurück, sodass der Aufrufer den abgelaufenen Token als gültig behandelt. Vorschlag: einen AuthError werfen. Randfälle — blocker — die E-Mail-Regex lehnt Adressen mit Plus-Tag ab (user+tag@example.com); Test für getaggte Adressen ergänzen. Tests — should-fix — kein Test deckt den in Zeile 42 hinzugefügten Leerergebnis-Zweig ab; einen Test ergänzen, der eine leere Menge erwartet. Sicherheit — braucht Kontext — bestätigen, dass req.body.role nicht vom Client gesetzt werden kann; falls doch, ist das eine Autorisierungslücke.
Der komplette Arbeitsablauf
- Erzeugen Sie den Diff mit git diff und bestätigen Sie, dass er keine Geheimnisse oder eingeschränkten Code enthält, bevor Sie ihn einfügen
- Geben Sie dem Modell die Absicht der Änderung, damit es Korrektheit beurteilen kann, nicht nur Stil
- Sichten Sie die Befunde selbst — verwerfen Sie die falschen Treffer und beheben Sie die echten
- Schicken Sie die verbesserte Änderung an einen menschlichen Reviewer; der KI-Durchgang ergänzt das Review, ersetzt es nicht
Worauf Sie achten sollten
KI-Reviewer übersehen echte Bugs und erfinden welche, die nicht existieren — rund ein Viertel der Entwickler schätzt, dass etwa jeder fünfte KI-Vorschlag falsch oder irreführend ist, und selbst Entwickler, die selten Fehler sehen, mergen nicht ohne menschliches Review. Lassen Sie einen KI-Durchgang niemals das menschliche Review oder Ihr eigenes Urteilsvermögen ersetzen.
Fügen Sie keinen Code, der einer NDA unterliegt, Kundendaten oder Zugangsdaten in ein Consumer-Tool ein, um ein Review zu erhalten. Nutzen Sie ein freigegebenes Enterprise-Tool, und denken Sie daran: Der gemergte Diff ist Ihre Verantwortung, nicht die des Modells.
Das Modell kann eine Best Practice oder einen Coding-Standard zitieren, der nicht existiert. Prüfen Sie jede angeführte Regel gegen eine echte Quelle, bevor Sie danach handeln.
Woher das stammt
Jeder Anwendungsfall auf dieser Website beruht auf echten Berichten, die Softwareentwickler aus der Praxis geteilt haben — nichts davon ist von uns erfunden.