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

So, let's get started. 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 a 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, like, 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 Fagin Inspection, named after the guy, Fagin, who invented this process. So what they used to do is, you know, they do this paper. The papers are nothing but the copy of your code. So multiple people in the team used to take the printout of the code, review it, like they used to actually write it with pen and pencil, like where this might go wrong, come together, 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, 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 happened in the 1990s.

Then the era of email or Internet came in 2000. I came to know about this when I was looking at some of the emails from Daniel Steinberg. Everyone knows Carl, and he mentioned in one of his posts. Internet access allowed people from different countries to collaborate asynchronously. People used mail and diff tools to share code for PRs. It became common to discuss and merge code over email, leaving a trail of communication.

In 2010, many of us started our careers. This marked a significant shift in the way code collaboration happened. The transition to asynchronous communication and remote collaboration became more prevalent. Projects that had been active for decades still had email trails showcasing the evolution of code review practices. It was a time where the industry, including seasoned professionals, adapted to new ways of working.

People used 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 Carl 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. Then 2010, this is where I think most of us started our career. Yep. 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 asynchronous, more collaborative. It was more web-based review using GitHub or GitLab. And no one needs to actually wait until the code is approved. Sorry, 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 were 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 have been doing it.

GitHub has been doing it for years. And then 2020, the remote and CICD, now actually it 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 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 the number of PRs a team is raising is exponential, with the introduction of AI. So this is 2020s, a lot of new checks started coming into GitHub, and people started using it to actually reduce their time.

Then code review became a bottleneck again. This is me asking my senior engineer to review my PR again. So yeah. Then the era 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 an 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 agents can actually give you bugs as well as part of your code. You can actually get instant feedback on GitHub, ID, CLI, there are multiple channels now apart from just the UI. And now more code is actually shipped with confidence.

So I'll just skip the slide, but what is next? So this is what people are already doing. So CLI, so people can go ahead and 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 our 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 afterwards. 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 God, but before you do your code review, don't trust anyone blindly. So go ahead and have a code review tool.

That's it from my side. Sorry. Yeah. That's it. Thank you.