Here is my small collection of AI prompts for code review. Actually I focus on two main ideas: one comment per file, and asking the agent to rate its own work. Below I share both my insights on those approaches and ready-to-paste prompts.
Prompts in this post:
What is important for me in AI review prompts
One comment per file
I've noticed that, regardless of the tool I use (Copilot CLI, Gemini CLI, Jules, droid) reviewing code directly in terminal is extremely cumbersome. The wall of text is unreadable and unmanageable. That's why it is beneficial to instruct an agent to:
- Create every review comment in a separate file.
- Open those files in
code- this trick saves a ton of time. Especially since I close those files in the IDE, as I am done with them or moving to a folder like "closed" or even deleting them to forget. Everything to keep the environment clean.
This allows me to carefully review file by file, issue by issue, and not be overwhelmed by the amount. I can also put comments in the file and ask an agent to review my comments and redo its review (sic!) based on my input, and then open the file in code again of course!
Assess your work!
Another important thing is to ask an Agent for assessment of its own work. This is quite a common technique, which you can find across many prompts. I've noticed that this significantly increases the quality of the results. I also love adding things like "Add 3 arguments pro your proposals and against" to some of the prompts if I want a more detailed insight.
[PROMPT] You HATE this implementation
The base for this one is taken from a post made by u/cleancodecrew in r/ClaudeAI, at the beginning of 2026.
Do a git diff and pretend you're a senior dev doing a code review, and you HATE this implementation. What would you criticize? What edge cases am I missing?
I found it when I didn't have access to my own prompts and I needed something to run with Google's Jules. As Jules rejects writing normal review comments on GitHub, I have developed something like this.
So this is oriented to work well in the web-only interface of Google's Jules - notice the hard break of lines, which instructs this tool to also keep lines short. Of course, you can instruct Jules to send this review as a pull request, but I never found it comfortable.
Notice the last sentence, which instructs proposing a split of the PR. My PRs too often contain too many changes, as I really like to improve the code base as I am reading it.
This is the first prompt I've met which takes the "HATE" approach. In comparison to the approach "review DRY, SOLID..." there is a visible difference. I cannot say it is better, but it is... different. And that's why it is valuable - it brings another perspective.
It is hard to say for me at this moment how to call this perspective, but it seems to be a good addition to a more structured approach. I would say this is more like a very good teacher, who has bad day. When that teacher is too sincere, and wants you to get off, and finds every possible issue in your code. That makes it find more interesting issues, than those structured ones, which are more like a checklist.
So the main sentence here is "and you HATE this implementation", which sets the tone and, surprisingly, approach. It must be interesting training data, that the hateful reviewers have something valuable to say :D.
Prompt
In the first line there is the name of the branch main which points to the root of the current branch.
Adjust it accordingly to your specific case.
I would love to have some lightweight template application like Ditto, which would ask me to change things like that on every paste.
Do a git diff and pretend you're a senior dev doing a code review from current branch against the `main` branch, and you HATE this implementation. What would you criticize? What edge cases am I missing?
Every comment write to separate {number}-{slug}.md file. under /.review/ folder. Number is just a next unique number, like a local id.
Every file should have a structure like a proper review comment on github:
- Location - put the problem context, where to find an issue you are criticizing.
Say what this/those lines of code were supposed to do.
Put at least one line before and one line after.
You can add more lines if it is needed for context.
- Say what is wrong and why in a professional way.
- Propose a solution. If appropriate provide a code block.
But only for simple changes.
- Do not touch actual code. you can only create those md files under /.review/ folder.
- Assess importance of the comment review in scale from 1 to 6, when 6 is an excellent, easy to implement and very valuable improvement and 1 is a poor idea, which you are unsure.
- Keep lines short, to keep them readable in narrow window.
## Example of expected output
Please format your response exactly like the example below for every issue you find.
Filename:
/.review/01-inefficient-memory-filtering.md
````md
# Location and context
`Controllers/OrderController.cs:29-35`
This block is supposed to retrieve a user's orders asynchronously, calculate the
total amount, and return it as an API response.
```csharp
28: // Get user orders and calculate total
29: [HttpGet("{userId}/summary")]
30: public IActionResult GetOrderSummary(int userId)
31: {
32: var orders = _orderService.GetOrdersAsync(userId).Result;
33: var total = orders.Sum(o => o.Amount);
34: return Ok(new { UserId = userId, Total = total });
35: }
36:
```
# What is wrong
Using `.Result` (or `.Wait()`) on an asynchronous Task inside a synchronous method
is a fatal architectural flaw known as "sync-over-async". By blocking the current
thread while waiting for the Task to complete, you are holding a thread hostage.
In an ASP.NET Core environment, doing this prevents the thread from returning to
the Thread Pool to serve other requests.
The critical edge case you are missing here is application behavior under load.
While this works fine on your local machine with 1 user, during peak traffic,
a burst of concurrent requests will instantly exhaust the Thread Pool. This will
cause a deadlock or thread pool starvation, bringing the entire application to
a grinding halt (503 Service Unavailable). This implementation is actively dangerous
to system stability.
# Proposed solution
Embrace "async all the way down". Change the controller action to be asynchronous
and use the await keyword so the thread is yielded back to the pool during the
I/O operation.
```csharp
[HttpGet("{userId}/summary")]
public async Task<IActionResult> GetOrderSummary(int userId)
{
var orders = await _orderService.GetOrdersAsync(userId);
var total = orders.Sum(o => o.Amount);
return Ok(new { UserId = userId, Total = total });
}
```
# Assessment
6/6 - it is easy to do and makes a code clean.
````
If you think that, the PR is doing way too much, propose in separate file how to split it into smaller ones.
Order them from smallest to biggest.
Doing a code review is just only one usage of above prompt. You can easily change the role of AI agent to be for example, an expert about blogging. Then you can ask it to review your blog post and create comments in separate files, which you can then easily review and implement.
Afterword
Using an AI agent today seems more like a duty than a choice. I am observing how more and more tools are growing around to replace everything that I do. But I cannot trust AI to work well enough. I even observe something that I call "Hidden AI Debt" which is created when too much trust is put into AI. But this is a good topic for another blog post.
Nevertheless, this post shows my approach to working "Human First, AI augmented". Because it would be a lie to say that AI does not bring any value as an element of the toolchain.
I plan to add here the rest of my review prompts, which I use across many tools, as soon as I refine them. This was the first version and I hope you liked it! If you see a better way how to share them with others, or you have some suggestions how to improve them, please let me know in the comments.
]]>