Coding Intermediate Any model

Thorough Code Review with Prioritized Findings

Get a structured code review that catches bugs, security issues, and design problems ā€” ranked by severity, not listed randomly.

code-reviewqualitysecuritybest-practices

What it does

Reviews code the way a senior engineer would: checking for correctness first, then security, then design, then style. The critical difference from a generic “review this code” request is the severity ranking ā€” you see the must-fix issues before the nice-to-haves, and you get actionable fixes, not vague suggestions.

The Prompt

Review the following code. Prioritize findings by severity.

Language/framework: [LANGUAGE AND FRAMEWORK]
Context: [WHAT THIS CODE DOES ā€” a brief description of the feature or system]
Code:
[PASTE CODE HERE]

Review in this order of priority:
1. BUGS: Logic errors, off-by-one, null/undefined risks, race conditions, unhandled edge cases. For each: what breaks, under what conditions, and the fix.
2. SECURITY: Injection vulnerabilities, auth/authz gaps, data exposure, unsafe deserialization, hardcoded secrets. Reference OWASP category if applicable.
3. DESIGN: Unclear abstractions, tight coupling, violated SOLID principles, missing error boundaries. Only flag design issues that would cause real problems ā€” not theoretical purity.
4. PERFORMANCE: O(nĀ²) where O(n) is possible, unnecessary allocations, missing indexes (if DB queries), N+1 queries. Only flag if the performance impact is meaningful at expected scale.
5. STYLE: Naming, consistency, readability. Lowest priority ā€” only mention if something is genuinely confusing, not just non-standard.

For each finding:
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- Line(s): Where in the code
- Issue: What's wrong (one sentence)
- Fix: The specific code change (not "consider refactoring")

If the code is solid, say so. Don't invent issues to fill categories.

Usage Notes

  • The “don’t invent issues” instruction matters. Without it, AI models will find 15 “issues” in perfectly fine code, which dilutes trust in the real findings.
  • For large codebases, review one file or function at a time. Reviewing 500+ lines in one prompt leads to shallow analysis.
  • The severity ranking ensures you spend time on what matters. A CRITICAL bug in line 42 is more important than a MEDIUM style issue in line 3, but without ranking, they’d get equal weight.
  • For security-focused reviews, add: “Assume all user input is attacker-controlled. Trace data flow from input to output and flag any path where input reaches a sensitive operation unvalidated.”
  • Pair with the Systematic Debugging prompt if a finding reveals a bug you need to investigate further.