A Brief History of Code Review (And What's Next)

So I work at a code review company. You know, I started working for them five months ago, Code Rabbit. And when I joined them, I was like, oh, how did this all process of code review started? Because my earliest memory is not reviewing the code at all. Like, I started as a person who was working in a single person company. I was the only developer who was actually writing code, building it, shipping it, deploying it.

So my first introduction to actually reviewing code was GitHub. I think most of us, right? I think that's where we started. We started seeing the UI and that's where we started collaboration. So I thought, why not go deep and see the history? So that's what I'm going to share with you. So let's see.

So earlier invention in code review happened way before 2000. So it was 1990s. What do you think these people are doing? Wasting time. No, actually, they are doing code review. So this was the earliest invention which happened in 1990. It's called Fagan inspection, named after the guy, Fagan, who invented this process. So what they used to do is, you know, they do this, the papers. The papers are nothing but the copy of your code.

So multiple people in the team used to take the print out of the code, review it, like, they used to actually write it with pen and pencil, like, where this might go wrong. And discuss if this code is something which can be pushed to the production. So this is 1990. So the process was very, you know, tedious, time consuming. People used to meet in person. So it's like planning, overview, preparation. Then meet finally. If there is a rework, then the whole process happens again. Someone takes the printout, goes ahead and then, yeah. If there is no follow-up question, people think it's all good. There is no infinite loop. Let's go and merge the PR. So this is what 1990s happened.

And then the era of email or Internet came in 2000. I think I came to know about this when I was actually looking at some of the emails from Daniel Steinberg. I think that guy is a legend. So everyone knows. And he actually mentioned in one of his posts. So he pushes everything as a blog post on his website. And you can see there is actually mention of emails. I was like really people used to do this? So in 2000, what happened is, of course, Internet came. And this was the era where collaboration started.

Like people who have Internet access sitting there in other countries apart from the U.S., of course. And then they can actually raise a patch to another person who is sitting somewhere else in the world. So this is the era where synchronous, no in-person meeting started happening. People use mail and diff tools to share the code and say, hey, this is the PR unit to push and merge. And it really happened over email. So it was like a big trail of email. If you see, I think that Curl is the best example. I think you can still find some of the email trails there.

And I was at FOSDEM and there were so many projects who are like decades old. And they also have this mail trail somewhere. In 2010, this is where I think most of us started our career. Yeah. We are old now. So this is the era of pull requests. GitHub came in. Now you can actually see the diff in the UI. So it was the birth of modern code review. And then it started happening as synchronous, more collaborative. It was more web-based review using GitHub or GitLab. And no one needs to actually wait until the code is approved, right? You need to wait until the code is approved. So now you can actually put guardrails, which was not there before. But I think there are still many in-person reviews which was happening with the introduction of GitHub, because it was still not the era of remote work. Remote work was not there. Maybe there are a few companies which has been doing it. GitHub has been doing it for years. And in 2020s, the remote and CI and CD started asynchronous, global, efficient. Everyone started working from anywhere. More checks on CI. So now actually code review became a little bit easier. You got your linting, you have your hooks on CI, CD. You can actually check, like, what can go wrong. You can also check the build status before you actually go ahead and review the PR. But there was still one thing missing. Developers were waiting for days to get their PR reviewed. This is something which is still happening, because number of PRs a team is raising is exponential with the introduction of AI. So this is 2020s. Lot of new checks started coming into the GitHub and people started using it to actually reduce their time. Then code review became a bottleneck again.

And this is me asking my senior engineer to review my PR again. So, yeah. Then there are, which is now, 2024, which is AI augmented. Now it's asynchronous and it's the future of code review, which we are all going through. So no need to wait for your senior engineer to review your code. You can actually just ask AI agent and it reviews your code. It gives you the initial signals if you are, like, if it's a good code or if there is any bugs. All the AI agents can actually give you bugs as well as part of your code. You can actually get instant feedback on GitHub, IDE, CLI. There are multiple channels now apart from just the UI.

Now more code is actually shipped with confidence. So I'll just skip this slide. But what is next? So this is what people are already doing. So CLI. So people can use CLI to actually review their code. People are using agentic AI to review their code, where actually the agent can work in a loop and look through all your code base, review, fix, and actually give you the final code, which has no comments. At CodeRabbit, we are trying to actually change how code review looks like. And it can be used for agents as well as humans. This is a new UI. We are actually experimenting with it. So if you have an open source project, go ahead and give it a try. It's available for everyone.

Sorry. Someone was taking a picture. I'll just go ahead and share. And you can meet me afterward. I'll show you. It's free for open source as well. And before you decide not to do code review, I read this poem a lot. You can trust in a God, but before you do your code review, don't trust anyone blindly. So go ahead and have a code review tool. So that's it from my side. Sorry. Yeah. That's it.