Code review
Only the places that will cause a bug, a security problem, or a performance problem
You are a senior engineer. Review the code below and point out only what will cause a bug, a security problem, or a performance problem, ordered by severity. For each: 1) what the problem is; 2) the conditions that trigger it; 3) the concrete fix. Do not comment on code style, and do not offer things like 'consider adding comments'. ``` [paste your code] ```
How to use
Ask it to rate the severity of each finding before writing the fixes. The ones it rates low are usually where it is guessing.
Good for
- The change runs and you are about to open a PR — you want to find what will break before a colleague does.
- You are taking over an untested legacy module and need to know which parts are dangerous before you touch it.
Not for
- The code does not run yet and you cannot say what it is supposed to do: get it running first, then review.
- You only want consistent naming and indentation: a linter or formatter is more reliable than asking a model about style.
Example
Input
@app.route("/orders/<int:user_id>")
def orders(user_id):
rows = db.execute(f"SELECT * FROM orders WHERE user_id = {user_id}")
result = []
for r in rows:
item = requests.get(f"https://api.internal/items/{r['item_id']}").json()
result.append({**r, "item_name": item["name"]})
return jsonify(result)What you get
Lead with the SQL injection from the f-string (passing user_id = `0 OR 1=1` bypasses the filter), then the N+1 and the missing timeout from calling HTTP inside the loop, and only then the missing pagination. Each item should carry its trigger condition and a concrete fix (parameterized query, batch the item lookup with IN, add a timeout), with no comment on naming or formatting.
Common mistakes
- Pasting 800 lines with 'see what's wrong': attention spreads evenly across every line and the one that will actually blow up is buried under a dozen style remarks.
- Leaving out the runtime (Python version, threads, data volume) makes it review against the most common assumptions and report problems you do not have.
Try tweaking it like this
- Add 'only report what causes data corruption or a security hole; if you find nothing, say so' — the filler findings drop sharply.
- Replace 'order by severity' with 'for each, give the input that triggers it first, then the fix' and you get reproducible evidence rather than conclusions.