You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: blog/2023-08-26-welcome/index.md
+2-1
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,7 @@ description: AI and the Future of Code Reviews - A Deep Dive into CodeRabbit
5
5
authors: [gur, vishu]
6
6
tags: ["Rate limits", "Openai", "Prioritization"]
7
7
image: /img/blogs/founder_blog_meta.jpeg
8
+
hide_table_of_contents: false
8
9
---
9
10
10
11
<head>
@@ -81,7 +82,7 @@ CodeRabbit is built on top of the generative AI to provide the following key cap
81
82
82
83
The review process is multi-stage and shown in the figure below. CodeRabbit's workflow is triggered when a developer opens a pull request or commits code to an existing pull request. This is followed by various summarization and review stages.
83
84
84
-
85
+
85
86
86
87
CodeRabbit is not just a simple wrapper that does pass-through to the LLM models. To circumvent context size limits, CodeRabbit uses an innovative, multi-LLM and multi-stage approach to scale reviews for larger change sets. Unlike AI-based code completion tools, code reviews are a much more complex problem. The reviewer context is much broader than the developer context, as the reviewer needs to uncover not just obvious issues but also understand the larger context of the pull request and changes across multiple files. Below is a glimpse into the challenges we faced and the solutions we came up with:
Copy file name to clipboardExpand all lines: blog/2023-10-05-ai-code-reviews-reclaims/2023-10-05-ai-code-reviews-reclaims.md
+13-13
Original file line number
Diff line number
Diff line change
@@ -46,7 +46,7 @@ We'll discuss the regular stages of software projects and the impact of AI code
46
46
47
47
### The Typical Software Lifecycle Process
48
48
49
-
49
+
50
50
51
51
Ah, the software lifecycle—the process where we turn ideas into lines of code that build our products. If you're an engineering manager, you're already well-versed in the dogma: planning, coding, testing, deploying, and maintaining. It's a continuous cycle with its own set of challenges.
52
52
@@ -58,19 +58,19 @@ In the upcoming sections, we'll dive deeper into how the traditional and often c
58
58
59
59
### The Traditional Code Review Method
60
60
61
-
61
+
62
62
63
63
In the conventional approach, code reviews followed this pattern: one developer wrote the code and then passed it on to another person for evaluation. The reviewer took their time to meticulously inspect the code submitted by the developer. This involved examining lines of code and making notes, comments, questions, and identifying any problems. This process typically unfolded as follows:
64
64
65
-
-A developer creates a Pull Request (PR) and outlines the changes made, requesting a review.
66
-
-The reviewer, who might be another developer or an engineering manager, assesses the code, looking for specific aspects such as:
67
-
- Ensuring that the PR changes align with the scope of the associated ticket(s).
68
-
- Confirming the accuracy of business logic implementation.
69
-
- Maintaining or improving code quality by reverting unnecessary changes and upholding code quality standards.
70
-
- Verifying that the changes do not introduce security vulnerabilities.
71
-
-The reviewer either approves or rejects the PR.
72
-
-If approved, the PR can be merged.
73
-
-If rejected, the reviewer provides feedback on the required updates for approval.
65
+
- A developer creates a Pull Request (PR) and outlines the changes made, requesting a review.
66
+
- The reviewer, who might be another developer or an engineering manager, assesses the code, looking for specific aspects such as:
67
+
- Ensuring that the PR changes align with the scope of the associated ticket(s).
68
+
- Confirming the accuracy of business logic implementation.
69
+
- Maintaining or improving code quality by reverting unnecessary changes and upholding code quality standards.
70
+
- Verifying that the changes do not introduce security vulnerabilities.
71
+
- The reviewer either approves or rejects the PR.
72
+
- If approved, the PR can be merged.
73
+
- If rejected, the reviewer provides feedback on the required updates for approval.
74
74
75
75
This process has been a fundamental part of modern coding. It relies on the availability of both the reviewer to provide feedback and the developer to make changes based on that feedback.
76
76
@@ -90,7 +90,7 @@ The following sections will delve into how these AI platforms streamline code re
90
90
91
91
In code reviews, problems can happen even when everyone works in the same place. Sometimes, teams just agree without really checking. People might not get along, causing delays and making things tense. Plus, even if we try really hard, some issues can slip by us and turn into big, expensive problems like bugs or system crashes. So, we need better ways to catch these problems early.
92
92
93
-
Let's look at some numbers because engineering managers really like facts and figures. Studies tell us that developers spend around 20-30% of their time [doing code reviews](https://about.gitlab.com/blog/2021/09/03/the-code-review-struggle-is-real-heres-what-you-need-to-know/). There's even a study [here](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/#:~:text=Review%20fewer%20than%20400%20lines%20of%20code%20at%20a%20time,-A%20SmartBear%20study&text=The%20brain%20can%20only%20effectively,70%2D90%25%20defect%20discovery) that shows our brains struggle to review more than about 400 lines of code at once, making it harder to spot mistakes.
93
+
Let's look at some numbers because engineering managers really like facts and figures. Studies tell us that developers spend around 20-30% of their time [doing code reviews](https://about.gitlab.com/blog/2023/09/03/the-code-review-struggle-is-real-heres-what-you-need-to-know/). There's even a study [here](https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/#:~:text=Review%20fewer%20than%20400%20lines%20of%20code%20at%20a%20time,-A%20SmartBear%20study&text=The%20brain%20can%20only%20effectively,70%2D90%25%20defect%20discovery) that shows our brains struggle to review more than about 400 lines of code at once, making it harder to spot mistakes.
94
94
95
95
We all know time is super important. It doesn't just impact how much money the project makes, but it also affects how much your team gets paid and, in the big picture, how well the company does overall. When a big chunk of your developers' time is used up reviewing code, it's not just a tech thing anymore – it's a big deal for the whole business.
96
96
@@ -102,7 +102,7 @@ In the next section, we'll understand how AI-powered code reviewers offer a more
102
102
103
103
### AI-Powered Code Reviews: This Changes Everything
104
104
105
-
105
+
106
106
AI, or Artificial Intelligence, might sound like a trendy word, but in the world of reviewing computer code, it's not just a passing trend – it's a real game-changer. When we talk about AI in code review tools, we're not just talking about existing linters or static code analysis tools. Instead, we're referring to smart feedback that understands the context of your team's coding rules and the particular project you're working on.
107
107
108
108
But there's more to it. These AI-powered systems can chat with you, making the review process feel like a collaboration rather than a machine. This means you can ask questions, seek clarifications, and even discuss the best approaches, all in real time. It's like having your most experienced developer, who knows your code inside and out, ready for reviews 24/7.
0 commit comments