codingcode review

Code Review Feedback Generator

Reviews code for bugs, performance, security, readability, and best practices with specific line-by-line feedback.

Prompt

You are a senior software engineer conducting a code review for a [industry/domain] application. The goal is to ensure production-readiness, and the target audience is the development team. Review the following [language] code and format your feedback as a structured list grouped by category: (1) Bugs: logic errors, off-by-one errors, null/undefined handling, race conditions, (2) Security: injection vulnerabilities, exposed secrets, improper auth checks, unsafe deserialization, (3) Performance: unnecessary loops, N+1 queries, missing indexes, memory leaks, unoptimised algorithms, (4) Readability: unclear variable names, missing types, overly complex functions, (5) Best Practices: error handling, edge cases, DRY violations, SOLID principles. For each issue found, provide: the line number, severity (Critical/Warning/Suggestion), what's wrong, and a corrected code snippet. For example, a Critical issue might be 'Line 42: SQL query uses string concatenation and is vulnerable to injection. Use parameterised queries instead.' You must give an overall verdict: 'Approve', 'Request Changes', or 'Needs Discussion' with a summary. Avoid inventing issues. Only flag genuine concerns. Do not suggest stylistic changes unless they affect readability. Here is the code:\n\n```[language]\n[PASTE CODE HERE]\n```

Why this prompt works

The five-category breakdown (bugs, security, performance, readability, best practices) is what makes this output usable as actual review feedback rather than a list of generic concerns. The line-number requirement plus the severity classification (Critical/Warning/Suggestion) means each comment is actionable: a reviewer reading the output knows what to address first. The 'don't invent issues' instruction matters more than it sounds, because the model defaults to flagging at least one item per category whether or not the code has issues there; the constraint pulls it back to honest feedback. The overall verdict (Approve / Request Changes / Needs Discussion) gives the output the same shape as a real PR review, which makes it easy to paste into a tool.

When to reach for it

You're reviewing your own code before opening a PR and want a fresh pair of eyes that catches what you missed.
You're a junior engineer or contractor and want to learn what kinds of issues a senior reviewer would flag in your code.
You're inheriting a codebase and want to triage which files need attention first.
You're using AI review alongside human review and want the AI pass to focus on specific categories so the human can focus on architecture.

How to customise it

The language field is the most consequential input. JavaScript and Python produce reviews that focus on different categories (JS leans heavily on async edge cases; Python on data shape errors). Be specific about the framework or runtime if it shapes the issue surface (e.g. 'Node.js with Express' vs 'browser-side React'). For security-sensitive code, tell the model 'treat this as production code handling user data and lean toward false positives over false negatives in the security category'. For performance-critical paths, mention them in the brief; the model otherwise weights all five categories equally.

What good output looks like

Feedback grouped by the five categories, each with line numbers, severity tags, descriptions, and corrected code snippets. An overall verdict at the end with a one-paragraph summary. Length scales with code complexity, typically 500 to 1,500 words for a 50 to 200 line file. The Critical issues are the section worth reading first; Suggestions are stylistic and worth skimming.

Watch out for

The model can confidently flag issues that aren't issues, especially around async/race conditions in code patterns it doesn't fully understand. Treat the Critical and Warning items as candidates to verify, not facts. The 'no stylistic changes unless they affect readability' rule is permissive; the model still tends to suggest renaming variables for the sake of it. Push back on rename suggestions where the existing name is functional. The verdict line is the least reliable output; weight your own judgment more heavily.

code reviewbest practicessecurityperformancebugsChatGPT / Claude