Reviewing Azure DevOps Pull Requests in JetBrains: Why the Web Portal Is Costing Your Team an Hour a Day

A first-person account of giving up on the Azure DevOps PR web UI and what changed in my workflow.

It was 2022. A Friday afternoon, 16:47, and I had eight tabs open. Three of them were Azure DevOps. Two of those three were the same pull request — one to read the diff, one to leave a comment, because if you opened a comment in the diff view, the diff scrolled and you lost your place. The other three Azure DevOps tabs were the work item this PR was closing, the pipeline running on it, and the YAML for the pipeline. The build was failing on something not actually in the PR, and I was about to spend twenty minutes figuring out why.

I was a developer. I wrote Kotlin. I lived in IntelliJ. And there I was, doing 70% of a PR review inside Chrome.

This is the story of the Friday afternoon that made me quit my job a few months later — and the napkin math on how much time most teams using Azure DevOps are still losing every week to the same problem I had.

The actual cost, on a napkin

Let’s not be dramatic. The Azure DevOps PR web UI is not unusable. It works. Plenty of people review code in it every day. But “works” and “doesn’t cost you anything” are different things, and the cost shows up in places you wouldn’t immediately notice.

Take a single PR review and break it into the actions you actually perform:

1. Open the link from Teams / email / Slack
2. Wait for the ADO web app to load (cold load: 2–4 seconds; warm: ~1 second)
3. Read the description, click the Files tab
4. Open one of the changed files in the diff view
5. Click into the codebase you have locally to understand a call site — wait, it’s not navigable in the browser, so you Cmd-Tab to your IDE
6. Find the file in the IDE
7. Cmd-Tab back to the browser
8. Leave a comment
9. Realize you want to suggest a refactor — Cmd-Tab to the IDE to copy a snippet
10. Cmd-Tab back, paste the snippet, save the comment
11. Approve

If I timed this with a stopwatch on a real PR back then — even a small one, four files, six diffs — it would take me eight to twelve minutes.

Multiply that by the number of PRs your team merges in a week. The average mid-size engineering team I’ve worked with merges 30 to 60 PRs a week. If every reviewer is losing four to six minutes of overhead per PR — three or four PRs per reviewer per week, three or four reviewers per PR — you get to an hour a day of compounding context-switch tax across the team, easily. That’s a developer-week per month, gone.

The frustrating part is that none of that overhead is intentional. Nobody designed the Azure DevOps PR UI to be slow. It’s the natural cost of doing knowledge work across two tools that don’t know about each other — your IDE and your source provider.

Why the web UI is the way it is

Quick aside, because I get this question every time I bring it up: I don’t think Microsoft is bad at this. Azure DevOps’s PR review UI is what it is for a reason. ADO was built to be the enterprise, governance-first source provider — file-level approval policies, complex branch protection, deep integration with Azure Boards and Power BI, compliance certifications that GitHub took years to match.

That set of priorities is wonderful if you’re a release manager auditing what changed across a 200-developer release branch. It’s less wonderful if you’re a single developer trying to read 40 lines of someone else’s diff at 4pm on a Friday. The web UI is optimized for the first use case. Most developers spend 95% of their time in the second one.

The mismatch isn’t an indictment of ADO. It’s an indictment of trying to do detailed code review in any browser, in any source provider, when you have a real IDE sitting right behind your current window.

What changed when I moved the review into the IDE

I had been doing this for a few months, half-deliberately and half by accident, before it clicked.

When I started building the AzD plugin (that’s a whole other story — I wrote about it here), the first thing I built wasn’t pipelines. It wasn’t work items. It was the PR list and the PR review view. Because that was the thing I was personally tired of doing in Chrome.

The shift was not “I moved one task from a browser tab to an IDE tab.” That framing makes it sound like nothing changes. The shift was that every single capability my IDE already had — go-to-definition, find-usages, syntax highlighting that knows my project, inspections, blame annotations, my own keybindings — became available during code review. The IDE wasn’t a different version of the browser. It was a fundamentally better environment for the same task because the IDE already understood my code.

A few concrete examples of what stopped being painful:

Finding the call site of the function being changed. In the browser: open a new tab, search GitHub, paste the function name, hope the search is good. In the IDE: Cmd-B with the cursor on the function name. Two seconds versus thirty.

Understanding “why is this change here at all?” In the browser: read the description, hope the author wrote enough, otherwise ask for a comment and wait. In the IDE: Cmd-Shift-A → Annotate, see the git blame of the surrounding code, understand the context yourself in fifteen seconds.

Leaving a comment that suggests an alternative. In the browser: type some prose, maybe paste a code block in triple backticks if you remember the syntax, hope the formatting works. In the IDE: select the alternative in your own editor, right-click, “Suggest Change.” It shows up as a suggested edit the author can accept with one click.

Knowing the PR’s build is green. In the browser: switch to the Pipelines tab, find the right pipeline, find the right run, hope you didn’t open a stale one. In the IDE: the PR row shows you whether its pipeline is passing, with a one-click jump to the logs if it isn’t.

None of these are dramatic on their own. The point is the accumulation. The cost of reviewing a PR drops by something like 40–60% across a normal mix of small and medium changes. Multiply by the team-week math from earlier and the recovered time becomes something a tech lead would actually notice during sprint retros.

What a normal Friday afternoon looks like now

I open IntelliJ. I have a tool window pinned that shows me every Azure DevOps PR assigned to me. The list looks roughly like this:

AzD tool window: every Azure DevOps PR assigned to me, in one IDE panel.

PR review inside the IDE, with an inline comment thread expanded.

I click one. The PR opens in a tab inside the IDE — the same Cmd-W shortcut to close it, the same Cmd-T to switch between PR tabs as I have for source files.

The PR overview inside the IDE: description, linked work items, build checks, and reviewer activity — all without opening the browser.

The diff renders with my project’s syntax highlighting, my project’s color scheme, my inspections live in the margin. I scroll, I leave inline comments, I navigate from a changed line into the surrounding file with Cmd-Down to get context.

Side-by-side diff with my project’s syntax highlighting, inspections, and an inline Risk comment.

When I’m done, I approve. Cmd-Shift-A → Approve, or click the button if you prefer the mouse. The browser does not enter the picture at any point.

If the PR’s build has failed, I see it on the PR row in the list. One click into the build and the failure logs — including the stacktrace — render right there in an IDE panel, with my project’s stacktrace navigation working on them. I don’t need to know which pipeline corresponds to which branch — the plugin knows. The “spend twenty minutes figuring out why the build failed” problem from 2022 is now thirty seconds.

Pipeline failure with the stacktrace rendered in an IDE panel — your project’s stacktrace navigation works on it.

The Azure DevOps web portal becomes the thing I open maybe twice a week, for the things it’s actually good at — managing branch policies, looking at a sprint board, reviewing security settings. Not for the things I do every hour.

The fair counter-argument

Two situations where the web UI still wins, in case anyone wants to push back.

Reviewing PRs you have no local checkout of. If you’re an architect or staff engineer who reviews PRs across ten repositories you don’t have cloned, the IDE flow has a higher setup cost. Cloning the repo, indexing it, then reviewing is more friction than just clicking a link. The break-even is something like three or four PRs in the same repository — under that, browser wins; over it, the IDE wins by a lot.

Triage and “what’s the state of the world” views. The ADO web portal’s PR list with filters, columns, and bulk actions is still a better tool for “I want to understand the state of all 60 open PRs across my team this morning.” The IDE flow is built for doing reviews, not for surveying them.

For 80% of the actual time a developer spends reviewing code, though, the IDE wins by a wide margin.

Where I’d start if you want to try it

Two ways to test the claim above on your own team without doing anything irreversible:

1. Time your next five PR reviews. Literally. Start a stopwatch when you open the link, stop it when you click approve. Note how many alt-tab switches you made. Most people are surprised by their own number.
2. Try the AzD plugin. Ten-day free trial, no commitment — it’s on the JetBrains Marketplace, works with Azure DevOps Service and Server, and JetBrains featured it as a Staff Pick. The full feature list lives in the docs if you want to skim before installing. If the hypothesis above is right, your next five PR reviews will feel different and you’ll know within an afternoon whether the saved time is real.

If you want the longer story of why this plugin exists and what I went through to build it, the plugin lives here. Short version: I quit my job to build it, and three years later it’s still the work I’m proudest of.

The shorter, less dramatic story is the one I told above. Most of us spend more time alt-tabbing than reviewing. The IDE was always the right environment for code review. It just took building this plugin to drag Azure DevOps along with it.

Have an opinion on this? I’d love to hear it. Hit me up in the comments or open an issue on the GitHub tracker — that’s where I actually read user feedback.