To review a pull request that AI wrote, first get a plain summary of what it does, then read the changes in the order the code runs, and check each change against the reason it was made. Comment on specific lines as you go, and only approve once you could explain the change to someone else.
It's the same job as reviewing a person's pull request, with a bigger diff and an author who may not know every line. Below is the method step by step, with how Hyperpowers, a free VS Code extension, helps with each step. You can do every step by hand too.
Why is an AI-written pull request harder to review?
An AI-written pull request is harder to review because it is often large, and the person who opened it may not have read all of it either. Generated code also looks tidy whatever is underneath, so the surface tells you less.
With a pull request a person wrote, you can ask the author why a line is there and get an answer from memory. With an agent, the author asked for a feature and got 40 files back. A second agent may already have left review comments, and the first agent may have fixed them. By the time you open it, nobody in that loop has read the whole change, and you are the one who approves it.
So the reviewer has to rebuild the understanding the author would normally bring. The method below is a way to do that without reading 40 files top to bottom.
Step 1: Find out what the pull request actually does
Before reading code, write down in two sentences what the pull request does. Use the description, the issue, and the prompt if you can get it. If you can't write those two sentences, you aren't ready to read the diff.
Then write a short list of what a correct version would have to do. A diff shows what the code does. It can't show what it should have done and didn't, so you bring that list with you.
In Hyperpowers: paste the pull request's link in VS Code and click Create Walkthrough. Your own Claude Code reads the change and writes a start page: what the pull request does in a few points, and how it flows in numbered steps. A small pull request takes about a minute, a big one a few minutes. It is written by a model, and it says so. Treat it as a first draft of your two sentences, and check it against the code.
Step 2: Read the code in the order it runs
Read the data first, then the code that uses it, then the code that calls that, then the interface, then the tests. GitHub lists files alphabetically, and that order has nothing to do with how the change works.
If you start at the database migration, you know what is stored before you read the service that writes it. By the time you reach the page, you know what the API returns.
In Hyperpowers: each changed file is put in an area: database, backend, frontend, tests, setup, docs or other. The review reads them in that flow order, with setup and docs last, and inside an area a file comes after the files it uses. If you only need one part, pick an area on the start page, such as Frontend, and the review keeps to it.
Step 3: Check each change against the reason for it
For each change, answer two questions: what does it do, and why is it here? If you can't answer the why, that is worth a comment even when the code looks fine.
AI-written pull requests often carry changes nobody asked for: a renamed helper, a changed default, a removed function the agent decided was unused. Each of those needs a reason that traces back to the request.
In Hyperpowers: press Start the review. The review shows one change at a time, such as Change 3 of 11, with its area, what changed in two or three points, and why. The change opens in the editor beside it as a diff. If the code was written with Claude Code on the machine that created the walkthrough, the why comes from what was asked in those sessions, so you can compare the code with the actual request. If a change is unclear, ask Claude about it right under the change.
Step 4: Comment on lines while the context is fresh
Write comments while the context is fresh, and keep them pending until you finish. A later file may answer an earlier question, and you can delete that comment before anyone sees it.
Good comments say why, and ask when you are unsure. "What happens here if the user is signed out?" gets an answer. "This is wrong" gets an argument.
In Hyperpowers: hover a changed line and click +, or click Comment in the note above a change. Comments wait in Your Comments, where you can edit or delete them. Nothing goes to GitHub until you press Submit review.
If you want a second pair of eyes, Review with Claude reads a file, an area or the whole pull request and drafts a comment for each thing worth raising. Each finding comes with the lines, the reason and a draft written as a question to the author. You press Add as comment, Edit or Skip on each one. Nothing is posted on its own.
Step 5: Decide, and say what you didn't read
Approve, comment or request changes, and write two or three sentences at the top: what you think the change does, which comments block the merge, and what you didn't review.
You don't have to read every line to decide, but you should know which lines you didn't read. Saying so tells the next reviewer where to look.
In Hyperpowers: Finish the review opens a check before anything is sent. It says how much you read, such as "You read 4 of 11 changes", lists the files not read yet, and shows your comments and any Claude findings you haven't decided on. Submit review asks Comment, Approve or Request changes, takes an optional summary, and posts your comments to the pull request as one review.
What should you look for in AI-written code?
Look for changes nobody asked for, library calls that don't exist in your version, tests that pass without testing anything, errors that get caught and turned into empty values, and security settings loosened to make an example work. Reviewing code an AI wrote: what to check goes through each of these with examples.
Try it on a real pull request
You can step through an example pull request in the browser version, with nothing to install. To use it on your own pull requests, install the extension and follow Your first review. It is free, and it runs on your own Claude Code.
Common questions
Can I let an AI review the pull request instead?
You can, and a bot reviewer catches some mistakes well. Someone still approves the merge, and if that person doesn't understand the change, nobody does. Hyperpowers is for that person: it explains the change, and you decide what to comment on.
Do I need the author's Claude Code sessions?
No. Without them, the explanation comes from the diff and the pull request's text. With them, the why comes from what was actually asked. The sessions are read on the machine that creates the walkthrough, so an author can create one and export it as a .walkthrough file for the reviewer.
Does Hyperpowers post anything to GitHub by itself?
No. Your comments stay in VS Code until you press Submit review, and Claude's findings only become comments when you add them.
Does it work outside VS Code?
It works in editors built on VS Code, such as Cursor, Windsurf and Antigravity, from the same .vsix file. Reading works with any git repository. Posting your review needs GitHub.