Yes. A good prompt should push the model beyond superficial style comments and toward finding subtle correctness, design, and maintainability issues.
Here's a prompt you can use:
:::writing{variant="document" id="54821"}
Review this pull request as if you are the most experienced engineer on the team.
Do not assume the code is correct just because the tests pass or the implementation looks clean. Your job is to find issues that a human reviewer might miss.
Focus on:
- Correctness: edge cases, race conditions, null/empty handling, error paths, off-by-one errors, data consistency.
- Logic: places where the implementation doesn't fully match the intended behavior or likely requirements.
- API and design: unnecessary complexity, poor abstractions, leaky interfaces, hidden coupling, maintainability.
- Performance: inefficient algorithms, unnecessary allocations, N+1 queries, blocking operations, scalability concerns.
- Security: validation, authorization, injection risks, secrets, unsafe assumptions.
- Reliability: retries, idempotency, concurrency, timeouts, resource cleanup.
- Readability: confusing naming, misleading comments, duplicated logic, opportunities to simplify.
- Testing: missing test cases, brittle tests, scenarios that should be covered.
For every issue you find:
- Explain why it is a problem.
- Describe the real-world scenario where it could fail.
- Assess the severity (Critical / High / Medium / Low).
- Suggest a concrete improvement.
Do not invent problems just to be critical. If something looks suspicious but you're not confident, explicitly label it as a concern rather than a defect and explain what additional context would confirm or rule it out.
At the end, provide:
- Overall risk level for merging (Low / Medium / High).
- Top three changes you would request before approval.
- Whether you would approve, request changes, or leave comments only.
:::
If you want even stronger results, include the PR description, relevant architecture context, and the expected behavior. LLMs produce much better reviews when they understand why the code exists, not just what it does.
You can also ask the model to review from a specific perspective, such as "review this like a staff engineer responsible for production reliability" or "assume this service handles millions of requests per day," to bias it toward deeper architectural and operational concerns.
