Mache die KI zu einem anspruchsvollen Reviewer für Lesbarkeit, Bugs und Sicherheit, und schärfe dein Urteil, indem du deine Entscheidungen gegen ihre Anmerkungen verteidigst.
Diese Lektion in Kodokon öffnenDas Code-Review im Team ist einer der am besten belegten Wachstumsbeschleuniger im Feld - und einer der am schwersten zugänglichen, wenn du allein arbeitest. Die KI bietet einen Reviewer rund um die Uhr, unter einer Bedingung: Du musst ihn konfigurieren. Standardmäßig ist ein Modell gefällig: Es lobt deine Mühe, nennt zwei Kleinigkeiten und schließt mit „insgesamt gute Arbeit“. Das ist kein Review, das ist ein Schulterklopfen. Der spiegelbildliche Fehler lautet „schreibe meinen Code sauber neu“: Du bekommst Code, den du nie durchdacht hast, und lernst nichts. Der richtige Ansatz: Fordere eine strukturierte Kritik - Lesbarkeit, Bugs, Sicherheit - mit kalibrierter Schwere und mit Begründungen.
You're a demanding senior reviewer, as in a team code review. Your goal is to make me improve, not to go easy on me.
Here's my code ([language], context: [what it's for, the project's constraints]):
[paste the code]
Analyze it along three axes:
1. Readability: naming, structure, needless complexity, unclear intent.
2. Bugs: unhandled edge cases, silent errors, inconsistent states, concurrency.
3. Security: unvalidated inputs, injections, exposed sensitive data, permissions.
Output format: for each remark - the line or block concerned, the axis, the severity (blocking / important / minor), and the WHY in one or two sentences.
Constraints: don't rewrite my code. At most 8 remarks, the most serious first. If a debatable choice can be defended depending on the context, say so explicitly instead of counting it as a flaw.Beachte die Obergrenze von 8 nach Schwere sortierten Anmerkungen: Ohne sie bekommst du 25 Kleinigkeiten, bei denen eine fehlende Eingabevalidierung genauso viel wiegt wie eine Namensvorliebe. Beachte auch die Klausel zu vertretbaren Entscheidungen: Sie zwingt das Modell, den objektiven Fehler von der diskutierbaren Konvention zu unterscheiden. Dann kommt der lehrreichste Teil, den fast alle überspringen: deine Entscheidungen zu verteidigen. Ein Review ist kein Urteil zum Anwenden, sondern ein Dialog. Wenn dir eine Anmerkung ungerechtfertigt erscheint, halte dagegen. Entweder deine Gründe tragen und du hast sie endlich ausformuliert, oder sie brechen zusammen und du entdeckst, dass diese „Entscheidung“ nur eine Gewohnheit war.
Let's revisit your remark number [X]: you consider that [restate the remark].
I disagree, and here are my reasons: [your arguments - measured performance constraint, consistency with the rest of the code, deliberate simplicity, deadline...].
1. Honestly assess each of my arguments: which hold, which are rationalizations?
2. Give the strongest possible counter-argument to my position, as an experienced colleague who disagrees would.
3. Conclude: in MY specific context, is the change worth its cost? Answer yes or no, then justify in three sentences maximum.
Don't try to prove me right: if my arguments are weak, say so bluntly.Zwei klassische Fallen des KI-Reviews. Erste Falle: Fehlalarme, selbstbewusst vorgetragen - das Modell meldet eine Race Condition, die in deiner Architektur unmöglich ist, oder einen „Bug“, der in deiner Sprachversion keiner ist. Behandle jede Anmerkung so, als käme sie von einem brillanten Menschen ohne Zugriff auf den gesamten Kontext: plausibel, zu überprüfen. Zweite Falle: das Sicherheitstheater. Die KI erkennt klassische Muster sehr gut (SQL-Injection, XSS, Secrets im Klartext), übersieht aber Lücken in der Geschäftslogik - eine fehlende Berechtigungsprüfung auf einer Route, einen ausnutzbaren Zwischenzustand. Ein KI-Review ergänzt, es ersetzt weder ein Audit noch dein Fachwissen.