Dieses Prompt Liefert Ihnen Senior-Engineer-Code-Reviews von Jeder KI
Why this prompt matters
Generic 'review my code' prompts produce generic responses: vague suggestions, no line references, no prioritisation. This prompt enforces a specific output structure that separates critical bugs from architecture concerns from style improvements — the same mental model a senior engineer uses when reviewing a PR. The 'What's Done Well' section is intentional: it keeps the feedback calibrated and makes it easier to act on criticism when you also know what to preserve.
What we use it for
Developers who want high-quality code review feedback without blocking on a colleague's availability. Works for any language or framework — paste the function, class, or diff and get structured, specific feedback in seconds.
Prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows: **Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions): For each: state the line number, explain precisely why it's a problem, and show the corrected code. **Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain): 1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode. **Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better): Practical, specific suggestions. Reference line numbers. Show before/after where relevant. **What's Done Well**: 2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note. Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why. [PASTE YOUR CODE HERE]
Die Aufforderung an eine KI, "my code zu reviewen", liefert jedes Mal das gleiche generische Ergebnis: eine Liste von zu berücksichtigenden Dingen, ohne Priorisierung, ohne Zeilenreferenzen, und Ratschläge, die auf jede Codebasis zutreffen könnten. Das unten stehende Prompt löst dieses Problem, indem es die exakte Struktur durchsetzt, die ein Senior Engineer bei einem echten Pull-Request-Review verwendet.
Das Prompt
You are a senior software engineer with 15+ years of experience across production systems. Review the following code as if you were doing a thorough pull request review. Structure your feedback exactly as follows:
**Critical Issues** (bugs, security vulnerabilities, data loss risks, race conditions):
For each: state the line number, explain precisely why it's a problem, and show the corrected code.
**Architecture Concerns** (things that will cause problems at scale or make the code hard to maintain):
1–3 observations about structural decisions that should be reconsidered. Be specific about the failure mode.
**Improvements** (performance, readability, maintainability — things that don't change behaviour but make the code better):
Practical, specific suggestions. Reference line numbers. Show before/after where relevant.
**What's Done Well**:
2–3 specific things the author got right. Skip this section only if there is genuinely nothing positive to note.
Rules: Be direct. Use line numbers. Show corrected code snippets — do not just describe the fix. Do not use phrases like "consider refactoring" or "you might want to" — say exactly what to change and why.
[PASTE YOUR CODE HERE]Wie man es verwendet
Ersetzen Sie [PASTE YOUR CODE HERE] durch die Funktion, Klasse, das Modul oder den Diff, den Sie überprüfen möchten. Funktioniert am besten mit Claude Sonnet, GPT-4o und Gemini 2.5 Pro – alle haben ein ausreichendes Kontextfenster, um Dateien mit einigen hundert Zeilen zu verarbeiten, ohne sie aufteilen zu müssen.
Bei größeren Dateien fügen Sie den kritischsten Abschnitt ein (die Funktion mit dem Bug, die neue Klasse, die geänderte Methode) anstatt der gesamten Datei. Wenn Kontext wichtig ist, fügen Sie eine kurze Beschreibung vor dem Code hinzu: "Dies ist eine Express.js-Middleware in Node.js, die Authentifizierung behandelt. Das relevante Datenbankschema ist users(id, email, password_hash, role)."
Warum die Struktur wichtig ist
Die vierteilige Struktur spiegelt wider, wie erfahrene Ingenieure Feedback priorisieren. Critical Issues sind blockierend – sie sollten vor dem Merge behoben werden. Architecture Concerns sind heute nicht blockierend, werden aber bei Skalierung blockierend. Improvements sind für den Nice-to-have-Durchlauf. Die Trennung verhindert das häufige Fehlermodus von KI-Code-Reviews, bei dem eine Stil-Kritik das gleiche Gewicht bekommt wie eine SQL-Injection-Schwachstelle.
Die Anweisung, korrigierten Code zu zeigen (nicht nur die Behebung zu beschreiben), ist die wichtigste Einschränkung. Ohne sie neigen KI-Reviewer dazu, auf das Problem zu deuten – "die Fehlerbehandlung hier könnte verbessert werden" – ohne zu sagen, was Sie eingeben sollen. Die Anforderung von korrigiertem Code erzwingt Spezifität.
Anpassung für spezifische Kontexte
Fügen Sie Kontext am Anfang des Prompts für bessere Ergebnisse hinzu: Geben Sie die Sprache und das Framework an, die Deployment-Umgebung (Serverless, Container, Embedded), Leistungsbeschränkungen oder Teamkonventionen. Bei sicherheitskritischem Code fügen Sie "Achten Sie besonders auf Eingabevalidierung, SQL Injection, XSS und Authentifizierungs-Grenzfälle" im Abschnitt Critical Issues hinzu. Bei leistungskritischen Pfaden fügen Sie "die Funktion wird 10.000 Mal pro Sekunde in der Produktion aufgerufen" hinzu.
Das Prompt funktioniert in jeder Programmiersprache. Es wurde auf Python, TypeScript, Go, Rust, Java und SQL mit konsistenten Ergebnissen über alle drei Frontier-Modelle getestet.