PR Radar: three lessons from building AI-assisted code review

We almost built a reminder bot

Two efforts started at Miro around the same time, and at first neither knew about the other. One was an investigation into review latency. It combined review data, assignment settings and interviews with engineers and engineering managers. The other was a local tool that Ankit Borawake built because they were tired of juggling windows. The two efforts met partway through, and what the investigation found decided what the tool became.

The findings were messier than we expected. Most review requests got a first response quickly, but the tail was long. The P90 time to first response was 41 hours, so one request in ten waited longer than that. Some requests got no response at all, and their authors had to chase reviewers. Team workload did not explain that tail. Three things did go with longer waits: bigger changes, when a request arrived, and requests that crossed team boundaries into unfamiliar code.

Hours from a pull request becoming ready to its first review. The median was 29 minutes, yet one request in ten waited more than 41 hours.

Our first idea was accountability. Name a reviewer, send reminders, escalate. Feedback showed the downsides fast. More notifications meant more fatigue. Splitting big changes into smaller PRs made each review easier, but the author then waited longer for the whole change to land. Other process changes were already underway, so we put the process redesign on hold. We set a narrower goal instead, which was to shrink the work a reviewer does before they can make a decision.

Without the diagnosis, we would have built a reminder bot.

Instead, you can see the diagnosis in the product. The inbox groups requests by risk and sorts each group by waiting time. We count weekday hours since the latest review request and skip weekends. After 24 weekday hours, the inbox marks a request as overdue.

Quick review gives small changes a shorter path through the queue. A change qualifies only if it:

• is rated low risk
• has under 200 changed lines
• has no merge conflicts

Quick review shows the eligible changes like a slideshow: one diff on screen at a time, overdue ones first. The difference is that every slide ends with a decision. Approve, comment, or skip, each a deliberate action with a four-second undo window. The 200-line limit is our policy choice. The research didn't give us that number. It found that waiting time rises gradually with size, and there is no size at which a change suddenly becomes dangerous.

The highest-risk requests stand out, and in each risk group the requests that have waited longest come first.

Quick review puts small, low-risk changes on a shorter path through the queue. Clear rules decide which changes qualify.

The higher risk rating always wins

A reviewer who opens an unfamiliar change needs several answers at once. What changed? Why? What could it affect? Has AI reviewed this version? What did it find?

PR Radar answers them on one screen. It shows the explanation and findings from our internal AI review agent next to the changed files and a suggested review focus. It also shows the blast radius, which is what the change could affect beyond the lines it edits. That tells the reviewer where to look before they open a single file. The diff and the full files stay one click away, because an explanation you can't check is just a claim. The summary gets you started, a finding tells you what to check, and the diff settles it. The reviewer can follow a question into the code, comment on the pull request and approve, all without leaving the workspace.

Risk reasons, the AI verdict and the findings sit next to the files they describe.

The risk rating behind the queue follows one rule, and the rule is lopsided on purpose. PR Radar combines two signals and takes the higher one:

• Path rules. Any change that touches authentication, permissions, infrastructure or migrations is always high risk.
• AI review. It rates the risk of the current commit and explains why. A blocking verdict also makes the result high.

The risk rating is the higher of two signals. AI can raise the rating; it can never lower one.

So a small edit under an authentication path stays high risk even if the AI rates it low. A reassuring AI review can't cancel a known reason to look closely. AI can tell us to look harder. It can't tell us to look less.

The same rule covers uncertainty. If no path rule matches and there is no AI review for the current commit, the request stays unrated. An AI review of an older commit can't vouch for the current one, because a new push changes the evidence even when the title and description look the same. When the current version has no AI review, PR Radar says so instead of hiding the gap, and the reviewer can request one right there.

Playing it safe has a cost. Path rules also flag tests and harmless refactors. They point attention at an area, and they know nothing about what the code really depends on. So the interface keeps the two signals apart. A sensitive path marks an area to examine. An AI finding describes a possible issue to verify.

We apply the same care to review actions. Approvals are designed to be deliberate:

• Each approval has a four-second undo window before PR Radar submits it.
• Each submitted review names the commit the engineer actually looked at.
• Before it posts, the backend checks the current head and rejects the review if the code has moved on.
• If GitHub's response goes missing, PR Radar shows the result as pending. It doesn't retry quietly and risk posting a duplicate.

Less friction only helps if the reviewer always knows which code they reviewed and what action went out.

The reviewer follows a finding to the flagged line, leaves a comment and submits the review from the same workspace.

Don't automate what you haven't measured

The early signs are good: engineers report less switching between tools and faster reviews, while still reading the code. Good signs are not evidence, so our pilots ask two separate questions. Does the tool work reliably? Does it improve review outcomes? The second question needs first-response times, unanswered requests and quality signals such as reverts and rollbacks. Quick review also picks easier changes on purpose, so any comparison has to account for that.

The tempting next step is selective auto-merge for low-risk changes with a small blast radius, backed by linting and CI checks. It's still future work, and it stays that way until we have clear eligibility rules, the right repository requirements and evidence that quality holds up. The order matters. Automate a decision before you measure it, and a review tool quietly becomes a rubber stamp.

PR Radar started as a local TypeScript prototype. A Go rewrite was next: Go can embed the UI and the server in a single executable, which made local installs easy. Then we realized that the easiest install is none at all, and PR Radar moved into Backstage, our internal developer portal. Each step had the same aim as every other choice in this post. Make the right thing cheaper to do, then check that it actually happens. Today, AI prepares the review and an engineer decides. The open question, for us and for anyone who builds their own version, is which decisions are narrow enough and well supported enough to hand over, and which will always need a person to look closely.

A footnote on the future, and a personal view from the authors: this field moves fast, and code review as we know it may change beyond recognition. If it does, the safety net moves somewhere else. Linting stops bugs before they land, CI/CD pipelines become the real gate, and reverts are quick and easy when a deployed change goes wrong. None of that changes how code is reviewed and released at Miro today. We built PR Radar to make today's reviews better, and to collect the evidence that will tell us if that day comes.