Santosh Yadav
May 26, 2026
7 min read
May 26, 2026
7 min read
Share
Cut code review time & bugs by 50%
Most installed AI app on GitHub and GitLab
Free 14-day trial
Three years ago, I was migrating code that generated a very large diff. My principal engineer was concerned and asked “could we break this PR down into smaller PRs so it would be easier to review.”
I explained to them that it was a migration PR, which is why it was much larger than any other PR i’d otherwise submit.
Migration PRs are common, and companies take them on for many reasons, whether it’s moving from React to Angular or modernizing an aging stack. Before AI, though, these efforts were incredibly time-intensive and typically resulted in massive diffs that were difficult to review.
Beyond the migration work itself, one of the biggest challenges organizations face is figuring out how to review these PRs effectively.
My own migration experience happened before today’s wave of agentic coding tools and advanced models. Back then, generating the migration was the hard part. Today, AI has dramatically lowered that barrier, and the bottleneck is shifting toward something else entirely: reviewing the large, complex diffs that migrations inevitably produce.
One of the biggest and most recent examples of a migration the world saw recently was Bun being rewritten from Zig to Rust. It involved over 1 million lines of code being modified across roughly 2,000 files, over a few days.
Yes, you read that right, a few days.
In the case of Bun, the project started small and picked a language that was easy to understand and scale. Recently, the project was difficult to scale and dealt with memory leak issues, which was one of the many reasons why Bun migrated off Zig to Rust.
Thousands of people were surprised, and even some were angry, as the migration itself was written by AI. I understand the frustration of users, but, it opened up for discussion that migrations at this scale will be more common in the future.
AI coding agents can program in any language, which changes the whole conversation around migrations. Before, teams used to pick a language or framework based on what they were comfortable writing code in, and even hired individuals specifically to the tools they were going to or already use.
Slowly, syntax is becoming irrelevant, and the principles and basics of programming as a whole are far more important than ever before. Uncle Bob Martin, famous for his book Clean code, recently wrote on X (formerly Twitter):
https://x.com/unclebobmartin/status/2055016815047164304
While AI agents are language agnostic for programming, the review process of PRs is still a challenge for organizations or OSS projects, as it’s hard to understand what changed especially in a language you are not familiar with.
Sure syntax still matters to an extent, but understanding what is being shipped and discussing it during the PR review is still where most developers struggle, and as PRs are only getting larger, this problem is compounding over time.
For years, the PR review view was meant for PRs that are small, so developers could understand what changed during the review process.
As a developer, it’s hard to imagine a world before GitHub launched. I still remember sending patches over email to my colleagues, and when GitHub launched and allowed us to see the diff in the browser it changed our code shipping experience as not only an individual but as a team.
We all know that with AI writing most of the code nowadays, the size of PRs is only increasing. Despite this new reality, the diff has been the default review interface for nearly two decades.
Take the Bun PR everyone is talking about; the PR has more than 1,300 discussions, and all of them are hidden. All useful discussions in the thread are not visible until you expand them.
Sure a rewrite of this size is impressive and opens up the door to the possibilities that AI can complete in terms of migrations, but the harder problem to solve is getting reviewers to understand the migrated code at large scale across any programming language.
We need a view with details that can explain the intent behind those changes. We are solving this issue at CodeRabbit and I couldn’t be more excited about it.
Be honest with yourself for a second. How often do you read the code when doing a PR review?
It’s fairly common for reviewers to not have the bandwidth to read through large PRs line-by-line and understand what has changed. I have been writing and reviewing code for close to two decades now and when I review code I look for intent and ensure the code solves the correct problem.
Most of us do the same; we check why the PR is open and what problem it's trying to solve. In some cases, you have more context about how the changes can affect the codebase, so you look at the CI/CD pipeline and approve or leave a comment.
So, if you think about the PR review process, the two most important things are intent and context. At CodeRabbit, we ship improvements to our context engineering approach daily and have SMEs fully dedicated to this process.
With CodeRabbit Review, we are providing developers with everything they need to review a PR with the intent and context behind the changes.
The context and intent regarding the code changes stay where the code is, avoiding the back and forth that comes with context switching when reviewing code.
CodeRabbit Review knows which changes should be reviewed together and stacks the changes, which makes the work easier for anyone looking at the PR and understand the changes with better context.
It’s quite common for PR comments to get lost in the discussion and CodeRabbit Review helps navigate these situations and puts the comments right next to your files so they are easy to find to speed up the review process.
The open-source world is moving faster thanks to AI, and OSS maintainers can ship bug fixes and validate changes faster than ever. However, in conversations we’ve had with users, discussing large PRs with users is still an issue. CodeRabbit Review can handle this use case and allow maintainers to better understand changes to larger PRs in a faster amount of time.
Try CodeRabbit Review on the next large PR in your queue. CodeRabbit Review is free for a limited time for every CodeRabbit user. You can find it by clicking Review Change Stack in the CodeRabbit PR summary comment.
