For a while now, reviewing pull requests has been the hardest part of my week.
Not because the code is bad. Most of it reads fine. It's that there's more of it than ever, and much of it was written with AI. The author can produce a 600-line PR in an afternoon. I still have to understand it.
Here's what I realised: line-by-line review doesn't catch the problems AI code actually has.
What goes wrong in AI-written PRs
The lines are usually fine. The structure is where it slips:
- A new helper that duplicates one that already exists two folders over
- A function that works, but ignores how the rest of the codebase does the same thing
- A change that's correct today and painful the day the data grows
- A test that passes, but tests the wrong thing
None of these show up in a diff. You only see them when you look at the code around the change.
The questions I ask now
When I review, I'm less "is this line right?" and more:
- Does it fit? Does it follow how the codebase already works?
- Who calls it? What breaks if this changes?
- Is it tested? And does the test check the thing that matters?
- Will it scale? Not just "does it run", but will it hold up?
- Does it already exist? Are we adding something we already have?
I can't answer any of these from a diff page. All of them are one click away in an IDE: go to definition, find usages, open the test.
So I built a tool that moves the whole review into the editor.
Review Lens: the review happens where you read code
Review Lens is a free plugin for JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, GoLand). You pick a pull request, and it opens in the window you already have open.
You read it like your own code. Full files, with the PR's changes marked in the gutter. Go to definition, find usages and your tests all work.
The conversation comes to you. Everyone's GitHub comments sit under the lines they're about. You reply right there, without opening a browser.
You never lose your place. Tick each file as you read it. The ticks sync with GitHub, and a file that changes after you've viewed it gets flagged.
You post once. Finish review sends your comments and verdict to GitHub as one review.
Your work is safe. Whatever you were working on is set aside before the PR opens, and comes back when you're done.
Not just for reviewing others
Read your own PR first. Before asking for a review, open your own PR and step through it commit by commit. You'll see how it grew, and catch the structural mistakes before your reviewer does. This is the habit I'd recommend most to anyone shipping AI-assisted code.
Keep up with new pushes. If someone pushes after you've reviewed, the PR tells you, and you review only what's new.
See the whole repo at a glance. Every open PR is in one list in the IDE, the ones waiting on you first, and each one's comments are a click away.
Try it
In IntelliJ IDEA, PyCharm, WebStorm or GoLand (2026.1+): Settings → Plugins → Marketplace → search "Review Lens". You'll need git and the GitHub CLI signed in (gh auth login).
- JetBrains Marketplace
- Source on GitHub (Apache 2.0)
Over to you: what's the structural mistake you catch most in AI-written PRs? I'll start: duplicated helpers. Every time.
Top comments (0)