#287 Sahil Bansal: Why Developers Are Switching to CodeRabbit's AI Code Reviews

Try OCI for free at http://oracle.com/eyeonaiThis episode is sponsored by Oracle. OCI is the next-generation cloud designed for every workload – where you can run any application, including any AI projects, faster and more securely for less. On average, OCI costs 50% less for compute, 70% less for storage, and 80% less for networking. Join Modal, Skydance Animation, and today's innovative AI tech companies who upgraded to OCI…and saved. AI-generated code is exploding, but reviewing it all has become the new bottleneck for engineering teams. In this episode, Sahil Bansil from CodeRabbit reveals how their AI-powered platform is transforming the code review process, helping developers ship faster without compromising quality. He explains how CodeRabbit uses advanced LLM context engineering to deliver senior-level review quality, reduce pull request merge times by up to 50%, and catch more bugs before they reach production. Whether you're a developer, engineering manager, or CTO, this conversation shows why automated code review is essential in the AI era and how CodeRabbit can help your team scale software delivery while keeping quality high. Cut Code Review Time & Bugs in Half. Instantly with CodeRabbit: https://www.coderabbit.ai/ Stay Updated: Craig Smith on X:https://x.com/craigssEye on A. I. on X: https://x.com/EyeOn_AI(00:00) LLMs & Why Context Matters (02:26) Meet Sahil Bansil from CodeRabbit (04:04) AI Code Boom & The Review Bottleneck (06:05) Why CodeRabbit Focused on Reviews, Not Generation (09:55) Keeping Humans in the Loop for Code Quality (14:30) IDE Reviews vs PR Governance (17:51) Inside CodeRabbit's Context Engineering (20:42) Building Context from Code Graphs & Jira Tickets (22:15) Eliminating AI Hallucinations with Verification (27:19) Empowering Junior Developers & Legacy Code Support (32:40) CodeRabbit's Open Source & Enterprise Success Stories (36:56) Cutting Review Times & PR Merge Delays (44:35) Scaling CodeRabbit & The Growing Market

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  At the end of the day, the L L M's are only as good as how you prompt them. And the prompt enrichment comes from the context that you bundle into it. While we don't train our A I agents on any code base, we do extensive evals of the L L M's. At the end of the day, the L L M's are trained on different code bases. Whenever a new model comes out and we have a very close working partnership with both OpenAI and Anthropic. So we get early access to those L L M's before they are released to the world. So we are able to test out, okay, this new model, if we have early access to it. Now, let's test our A I agents with the new model against some sample code bases.

• 0:40Speaker 00

  And then we see the review feedback quality and we tune our L L M prompting appropriately.

• 0:46Craig S. Smith?

  In business, they say you can have better, cheaper, or faster. But you only get to pick two. What if you could have all three at the same time? That's exactly what Kohair, Thomson Reuters, and Specialized Bikes have. Since they upgraded to the next generation of the cloud, Oracle Cloud Infrastructure. OCI is the blazing fast platform for your infrastructure, database, application development, and A I needs. Where you can run any workload in a high availability, consistently high performance environment, and spend less than you would with other clouds. How is it faster?

• 1:32Craig S. Smith?

  OCI's block storage gives you more operations per second. Cheaper? OCI costs up to 50% less for compute, 70% less for storage, and 80% less for networking. Better? In test after test, OCI customers report lower latency and higher bandwidth versus other clouds. This is a cloud built for A I and all your biggest workloads. Right now, with zero commitment, try OCI for free.

• 2:10Craig S. Smith?

  Head to oracle.com/ionai. Ionai, all run together, E Y E O N A I. That's oracle.com/ionai.

• 2:25Speaker 00

  It's great to meet you. I've been listening to a bunch of the Ion AI podcasts and love that you've been bringing in guests from so many different backgrounds. My name is Sahil Banse. I have a master's in electrical and computer engineering from Purdue University. And these days I work at CodeRabbit mostly on our enterprise go-to-market strategy. Occasionally, my friends who are not in the space, they ask me, what exactly does that mean or what do you do? And sometimes I joke and say that my core skill is translating engineering speak to sales speak or to customer speak.

• 3:07Speaker 00

  Right? The way the the way the engineers spend their time and what the customers really need to hear, those are sometimes two completely different languages. So I have to bridge that gap a little bit.

• 3:21Speaker 00

  But in the past, you know, I've had my career in multiple domains of the tech stack everywhere from silicon to SaaS. Worked at Applied Materials on their silicon semiconductor devices for a couple of years and then in the cloud infra space for like about seven years. Most notably at a company called Nutanix. But then just the lure of the startup world and trying out new ideas and, you know, just the excitement of being in the middle of trying something new. That brought me into a couple of different startups and most recently I joined CodeRabbit about coming up to about a year ago now.

• 4:02Craig S. Smith?

  Can you talk about, you know, there's a lot of talk about vibe coding and and how it's helping developers code faster. But at the same time, it's adding a burden to code review. Because there's so much code that's being written by AI. Can you talk about how CodeRabbit helps?

• 4:30Craig S. Smith?

  In that problem.

• 4:32Speaker 00

  Yeah, absolutely. Would love to just share with your listeners like the background of our co-founders and where they came from. So Code Rabbit was founded maybe July twenty twenty three, about two years ago now. And our co-founders were engineering leaders in their own rights and while the term wide coding hadn't come around until much later, but the use of AI for code generation had already taken off by that time. And what they were realizing as they were trying to get their teams to implement the early versions of the AI coding assistance in the ID was that a lot of these new AI tools were helping code generation become faster. And obviously, in the last two years, that that industry has just evolved so much.

• 5:17Speaker 00

  We've gone from AI basically being a quote-unquote smart autocomplete to now agents running completely in the background independently and potentially even new exploration happening with multiple agents spinning up at the same time and trying to get complicated tasks done in parallel. But what our co-founders at Code Rabbit realized a couple of years ago was as engineering leaders, they were measured on the amount of stuff that gets shipped out. And while obviously you can't really ship more stuff unless you create more stuff, but just creating more stuff wasn't resulting in more stuff getting shipped out.

• 6:02Speaker 00

  And they decided to, you know, focus on what the real bottleneck to shipping code was. And that is, you can't really rely on unrevealed code. You don't want to put any code out there, whether that's written by human being or AI agents or whoever. So code reviews are were really the bottleneck even two years ago, which is, you know, what, twenty years at the way the industry is moving. And so that's where they've decided to focus their efforts on and we built Code Rabbit, which is an AI code review platform.

• 6:42Speaker 00

  So it's completely analogous or orthogonal to your cursors and wind surf and GitHub Copilot, where we don't go into the code generation space. But once the code is written, developers or somebody is still going to have to review that code. And so that's where our USB comes in, is to really help the developers not be blocked in terms of their release velocity and to just focus our capabilities on the code review side. And you talked about wipe coding, right?

• 7:21Speaker 00

  So with wipe coding, we've seen the need for code reviews has gone up even more. Manual code being reviewed, obviously, being written, obviously, still needed to be reviewed. But with wipe coding, we've heard from our customers that the developers feel like they've now sort of like moved away from the best parts of their job. The parts that they enjoyed the most was writing the code, but now they're getting stuck in just reviewing the code written by the AI agents. And that's where we've sort of like built a tool that's tried to help them. And we've had some great feedback and great traction in the market where people are now

• 8:06Speaker 00

  able to fasten their code reviews. We're not eliminating the human from the code review process at all, but we are automating the stuff that used to take them more time. Quite often that, you know, extra time that goes into the code review process is simply because of factors that might be out of your control, like office politics in a way, right? Like you might raise your pull request and then you have to wait for somebody to come in and take a look. And you might be in a distributed team globally, or you know, the people that you tag as reviewers, they may not necessarily like you, or whatever kind of interpersonal relationships you might have with them.

• 8:47Speaker 00

  And quite often, these pull requests would just keep sitting there for days, if not longer. But that's the part that we can automate as soon as the pull request is raised, is do that first pass of the human review and leave the comments just as a human reviewer would. But then still let the humans come in and review the comments and decide whether they want to accept those comments or not. So that's essentially, you know, what we've seen with the rise of wide coding, more so recently, but just with the rise of AI coding agents in general, it sort of created a second order effect where the new bottleneck,

• 9:28Speaker 00

  or you know, the even before the AI coding agents, the release bottleneck was always for code reviews. But that bottleneck just becomes worsened with more and more code being generated. But you know, developers really being bogged down with code reviews. So that's sort of like the process that we've tried to automate and try to find the bugs that the developers can then just come in and review and accept the comment, accept the comments and make the changes and so on.

• 9:55Craig S. Smith?

  Code Rabbit, it writes comments, it doesn't change any code.

• 10:03Speaker 00

  Not without a human being taking any explicit action. Can we, can we make the code changes based on the review feedback? We can, but never without a developer explicitly saying, "Okay, Code Rabbit, I agree with your feedback. Go ahead and you have my approval. Go ahead and make this."

• 10:21Craig S. Smith?

  I mean, in that sense, it's a little bit like the, the, the original Copilot that, that acts as a pairs programmer that, that is offering you snippets of code as suggestions and you decide to accept or not. What, why, why does that have to happen after the code is written? Why couldn't it happen?

• 10:55Craig S. Smith?

  In the uh while the code is being written.

• 10:59Speaker 00

  Yeah, yeah, absolutely. Uh if let's take AI out of the question. Let's pretend we are seven years. Uh we've found that time machine and now we're back in twenty eighteen, pre-AI or something. Nobody cares about a word called pandemic or anything. And developers are mostly writing code manually. Um I would ask the question, at that time, why do we have code reviews? Because you you the developers are never really self-certifying. Okay, I wrote the code. I also reviewed my code. And my review passed the checks and there are no bugs and the code ended as window function. Properly, we we we didn't push out the code that way. It's the same with the AI coding agents.

• 11:43Speaker 00

  That whole need for writing the code doesn't change. Just because there is now an LLM that is involved in the process of writing the code. Really, it's just that the way you review the code. Um you we come in with a different lens. We are not biased because we didn't write the code. Right, the the LLM or the coding agent that is writing the code isn't really going to say. Here I generated the code. Now I now let me review my code. Oh, I found bugs in my own code. You you need a different pair of eyes that is unbiased by how the code was written. And that is not simply an LLM wrapper.

• 12:28Speaker 00

  Right, if it's just making any API call, then yeah, exactly what you said. You know, you're making the API calls during the code generation. You could just do that for review. But really, the review process, if you think about how do humans do reviews? Let's say if I'm tagged in a pull request and I generally don't have a whole lot of idea about the uh code changes. I'm going to come in and review file by file. Okay, what are the changes that has have happened? Uh I will try to understand the dependencies of those files. Uh what are the downstream dependencies? I might go to the past pull request where those files were previously included. I might look into the code base, how the various functions are interacting with each other.

• 13:12Speaker 00

  I might, you know, run some sort of like static rules analysis. But in the complex, dynamic code-based nature of today, most of the bugs are just coming because of the system dependencies. Right? How is the code change going to impact other aspects of the code base? So you you need some some sort of a mechanism, whether that's a human reviewing the code or whether that's an AI agent reviewing the code, that doesn't come in with that biased nature of the entity that wrote the code. That's why we believe there needs to be a completely separate market of AI agents that can help to review the code, even if that code is written by other AI agents.

• 13:56Craig S. Smith?

  Yeah, and and does CodeRabbit review the entire code base? Or or can you give it a window like of how much the code base you want it to review? Or does it only review the fresh, freshly written code?

• 14:16Speaker 00

  You know, in in college or in school, whenever I would see an option that said all of the above, I would sometimes glance over the question and just tick all of the above because I knew that would always be the right answer. So the answer to your current question is all of the above. So we work both in the IDE as well as in your Git platform, whether that's GitHub, GitLab, Bitbucket or whatever. When we are reviewing in the IDE, at that time, it's reviewing the individual commits. What as it's up to the developer as they're generating the code, they can just ping CodeRabbit and say, okay, go ahead and review these hundred lines of code or fifty lines of code or whatever.

• 15:00Speaker 00

  But at that time, you're really relying on your entire team.

• 15:06Speaker 00

  Uh, to have that review, right? Um, big companies might have hundreds of developers, thousands of developers. It becomes really hard to enforce a governance layer. If you're just saying, everyone, hey, in your IDs, guys, go ahead and make sure that you've reviewed the code. And again, thinking of the pre-AI world, we always mandated reviews in the pull request. Because that's where all the commits are coming together. That's a single choke point. That's where none of your commits, none of your code changes are going to go uh, unreviewed if that's where you enforce the code reviews. Uh, and that's really where a lot of the cross-file dependencies are easier to understand.

• 15:49Speaker 00

  When the developers are building code in their isolated environment, a lot of those uh, issues because of downstream dependencies just won't show up even if you did the reviews in the ID. Uh, so we have a dual approach to code reviews. Our reviews are completely free in the ID. We believe that should be just be an easy way for you to review your code changes locally. But the reviews in the pull request is what is mandatory. That's where you can enforce the governance layer and that's where you can uh, catch most of the bugs. Uh, but doing the reviews in the ID can be a quick, easy way to catch some simple bugs. And then the thorough review happens in the pull request.

• 16:31Speaker 00

  Uh, that's where you are reviewing your entire code changes that have happened. And in the ID can be more bite-sized reviews.

• 16:39Craig S. Smith?

  And how often does it happen that, uh, well, uh, two things. Wh- wh- what's, wh- what's the engine behind CodeRabbit? Is it a proprietary LLM? Is it a RAG? Uh, database, a vector database full of properly written code or common coding mistakes? I mean, what, where uh, is the decision coming from? And the, and the other thing is every coder.

• 17:15Craig S. Smith?

  I mean, although code is deterministic, it's all there's also a many ways to write a function.

• 17:23Craig S. Smith?

  So. How do you know that code rapid is not just suggesting a different way to write a function that that actually a unit tests completes on, you know, so that it's it's it's a preference thing, not a an error.

• 17:45Speaker 00

  Yeah, absolutely. Let me please allow me to break that question down into two parts. The first part is like, really, how does code rabbit work? So we work with both OpenAI and Anthropic, most of their latest models.

• 18:00Speaker 00

  But the in order to get the best feedback from the LLM, so the LLM is doing the actual review feedback. But the USP is really in how you prompt the LLM. The other day I saw Karpathy, Andre Karpathy, talk about context engineering, and that really struck a chord with me. At the end of the day, the LLMs are only as good as how you prompt them. And the prompt enrichment comes from the context that you bundle into it. If I have a function

• 18:39Speaker 00

  in my code where I've incorporated some changes, what has happened in the past? Right? If I just throw that code change at the LLM, it's not really going to understand all of those dependencies that can only come from the additional context. If a developer has

• 18:59Speaker 00

  attached a certain Jira ticket to the pull request, what was the actual request in the Jira ticket? Did that actually get met by the pull request? If there were 20 things asked in the Jira ticket and the pull request says, oh, this pull request closes that Jira ticket, does that actually add up? Or if there are, you know, if we're using the latest Go language version, maybe there's a security patch. The L L M has, has the L L M actually been updated up to that latest version? Does it have the latest version? Or if it's not, can you get gathered from the internet? So there's a lot of context engineering that we do in our L L M prompt.

• 19:42Speaker 00

  And when we send the prompts to the L L M, it's more or less like a fifty fifty ratio of the code and the context that we have generated that explains the code. And then there is also a lot of goodness in how you package the prompt. You will have a complex code dependency graph. That's something we generate in real time every time we start a review. And then we have to build that graph for the L L M from bottoms up. You can't start middle out, right? You really have to explain, okay, these are the base functions and here are the other

• 20:26Speaker 00

  functions that they're calling and then build it out from there. And then you, you package all the, that context in, in a certain order. And then you prompt the L L Ms. And then I, I mentioned the Jira tickets. So we index all the Jira and Linear tickets. We index your repositories and create a clone of your repositories. And that's, the clone is what we run the reviews on. But we also look at your ask pull requests. Maybe I'm changing a certain functionality right now and it could be dependent on some other functionality changes that have happened in the past.

• 21:05Speaker 00

  So, and then we package about forty linters and static tools out of the box. Most customers might have three linters, four or five linters that are configured with them, but we spend the time to provide forty linter configurations out of the box. That means you'll catch more bugs. If you have more rules that are checking with, along with the dynamic context enrichment, that's the way to catch bugs that would be missed otherwise if you're just doing a simple L L M API call. So that's the, we take a lot of time up to like five minutes or so in all of that packaging of this context.

• 21:47Speaker 00

  Then we feed the L L M, we explain to the L L M, okay, here is what is happening. Now that you have the context, now give me feedback on this code. And then the L L M's will return some review comments. And then we also run verification to weed out the hallucination. We don't simply pass on the every comment from the L L M. Because there could be hallucinations, it could maybe even not hallucination might provide a feedback that was already implemented by the developer. So we verify the feedback that's coming from the L L M. Does it actually add value to the code? So we run our own internal verification scripts in an isolated sandbox environment and drop off the low value feedback.

• 22:31Speaker 00

  So all of that context enrichment and you know, post review verification before you post the comment back to the developer. That's really the U S P of how we find bugs that you wouldn't find otherwise if you haven't taken the time to build that context engineering.

• 22:47Craig S. Smith?

  Right, and and the in production, have you done tests of

• 22:56Craig S. Smith?

  code bases that run in production and then have been reviewed by CodeRabbit and improved according to CodeRabbit's review and then run the improved version in production to see what the difference in production is. Again, that's certainly there there are bugs, but there

• 23:22Craig S. Smith?

  a lot of bugs don't really impact production outcomes.

• 23:29Craig S. Smith?

  So yeah, is uh is there some way to measure the effectiveness of Code Rabbit?

• 23:35Speaker 00

  Yes, so while we don't train our AI agents on any code base, we do extensive evals of the LLMs. At the end of the day, the LLMs are trained on a different code basis. But we uh whenever a new model comes out and we have a very close working partnership with both uh OpenAI and Anthropic, uh so we get early access to those LLMs before uh they are released to the world. So we are able to test out, okay, this new model is, we have early access to it. Now, let's test our uh AI agents with the new model against, you know, some sample code bases.

• 24:14Speaker 00

  Uh and then we see the uh review feedback quality and we tune our uh LLM prompting uh appropriately. But in terms of um whether or not to post a certain feedback, because maybe it's really not a bug and the customer doesn't care about it, that power we give back to the user. They can tell Code Rabbit, great, I saw, I see the feedback that you posted me. I don't care about this, don't give me this feedback in future. Uh so our our uh uh bot in a way, it's it's basically implemented as a GitHub app um and similarly on the other platforms. And you can chat with it just like you would with any other human reviewer.

• 24:58Speaker 00

  And we learn from the that feedback and then the next time we won't give you feedback of a certain nature. Um now chat can be very quick and easy and very intuitive way to provide feedback for on reviews. Sometimes you want uh the review to be more deterministic, like always do X, Y, Z for a certain file. Maybe in my directory named uh application, new application twenty twenty five, always validate against the latest JavaScript style guide. So that's also something that you can provide. As instructions, path based instructions in this directory in the for files that match

• 25:39Speaker 00

  a certain path, always run these rules or do not run these rules. Those can be custom and you know, our customers make extensive use of those kind of rules. And then we include those rules and we'll tune our feedback accordingly. But these days, a lot of those rules are already now being written in the AI coding agent themselves. And if you've already written the rules for the code generation, makes sense to also expose those to the code reviewer. So if you have something like your cursor rules, markdown file setup, Claude code, GitHub Copilot, you name it, we integrate with virtually all of the commonly used AI coding agent tools.

• 26:23Speaker 00

  We'll automatically import those rules and tweak our code reviews based on those. So that you, it's really up to you how you want the review feedback to come up to you.

• 26:34Craig S. Smith?

  Yeah, and I guess generally code review falls to a junior employee, junior coder, or at least a mid level coder. And, and the idea is that, that you know, with the context and with the, looking at the entire code base, that Code Rabbit will actually do a better job than giving it to a mid level coder who's, doesn't want to do the job in the first place.

• 27:11Speaker 00

  Is a really interesting phrase that one of our customers, Key Value Systems, said during our discussions with them. That Code Rabbit has helped raise the floor of the knowledge of their team. Because their junior developers now felt more comfortable asking the AI agent questions about the code, right? Like if there is an ongoing review, you can simply ask us questions. Wait, I don't understand, why are you telling me to rewrite this function? I thought this would work perfectly, why? Tell me more, explain me your thought. And so you can do sort of like a Q and A about your code base even. And code rabbit will explain to you, okay, here is what I see in your code base and here is how this will work.

• 27:53Speaker 00

  And this is why I'm recommending you to refactor your code. And quite often, the junior developers may feel intimidated, reaching out to a senior developer or somebody who's been with the company for a long time. And so it was really interesting to hear from this customer that, you know, the junior developers now feel like they were more empowered. But in terms of reviews, the review quality is actually what I would say is at a more of a mid to even senior level engineer. You know, and with all these AI agents, there is no longer any blocker on any languages. We support, our architecture is completely language agnostic.

• 28:34Speaker 00

  There have been customers, I believe, Sales Rabbit, Groupon was another one, where portions of their code bases were written in legacy languages, C hash. Right now, there's various reasons why that code base might can come into your company. In the case of Sales Rabbit, it came through an acquisition, but they didn't have anybody who knew C hash. So that's where now you can go in and ask the AI agent to review the code that you might not even have the expertise in-house to review. So we really see the review capabilities at the mid to senior engineer level.

• 29:13Speaker 00

  But we also see that the entry level junior engineers, they feel more empowered by being able to use AI and not having to try to people please or anything and not having to rely on any kind of interpersonal relationships to get their reviews unlocked.

• 29:29Craig S. Smith?

  And the idea is that with your, with the context you feed the L L M and the guardrails against hallucinations, this is a focused

• 29:46Craig S. Smith?

  tool that will give better performance than just a garden variety or even like Claude.

• 29:55Craig S. Smith?

  Sonnet three point seven uh because you've done all this uh sort of prep work on the code before you run the review.

• 30:05Speaker 00

  Exactly, that prep work is really, you know, where uh you can really elevate the review quality. Otherwise, you're just relying on the non deterministic nature of the L L M. You really have to feed the L L M information with the proper context in byte sized chunks and the right amount of context. If you give it too much context, it will get overwhelmed and it will try to uh create different portions of your code base with relatively the same importance. If you give it too little context, it might not catch some of those complex bugs that come in because of uh the interdependencies.

• 30:48Speaker 00

  So really that tweaking is what uh the uh uh engineering that we've built in in-house. How to give it the right amount of context? What are the sources from where we should gather the context? And those sources include custom uh rules that you might have set up. Uh more than forty linters for the static analysis. Uh doing a real time web search in case the L L M might be out of date. Uh building that file dependency graph. And a lot of this context building happens in real time. Every time a review is triggered, then we gently prompt the L L M with the right context. Uh get the review feedback, validate the review, is this actually going to address uh the comments or is the review not worth it?

• 31:33Speaker 00

  And then we post the review feedback. And that's actually really, if you think about it, that's how a senior engineer would have done the uh review anyway. So we're really mimicking that human way of thinking. Uh but automating it so that the review starts immediately and you know even catching um. The edge cases, uh, sometimes people might forget to up update their documentation or to update their unit tests, uh, because of new edge cases that will get, uh, introduced. And just by the very nature of our, you know, human way of thinking, it's not always easy to capture those edge cases, but the AI can do that. Uh, so we can capture those edge cases and prompt you, um, you need to update your unit

• 32:17Speaker 00

  test to catch these edge cases, or you made a certain change, but it's not documented and we, we can do all of that, uh, for you.

• 32:26Craig S. Smith?

  Uh, can you talk about some of the customers, uh, that have used, I mean, you mentioned one, but, uh, about some real world success stories with Code Rabbit?

• 32:38Speaker 00

  Yeah, absolutely. Um, uh, we have more than six thousand, uh, paying customers. Uh, we use Code Rabbit today for their PR reviews and more than, I believe, seventy, eighty thousand open source projects. Uh, so a lot of our initial, uh, traction came in from the open source community. Uh, if, if you think about it, you know, that's really where the pain of the reviews is even worse. You might have an open source maintainer or a few maintainers, but there's loads of contributors. And now those maintainers have the thankless job of reviewing all of the contributors' code. So they really, uh, like it a lot when they have the power of AI to come in and automate their code reviews for them.

• 33:20Speaker 00

  And a lot of times, you know, they are working in their own, uh, day jobs and so then they use the Code Rabbit for their open source project, bring it into their day jobs. That's really how, uh, the company got a lot of product led, uh, growth in its early days. Uh, but lately we've also been seeing a lot of expansion into the enterprise space, you know, where, um, you have big teams, complex, uh, code bases, uh, no individual person really has the grasp of, uh, the full picture, so to speak. Um, so we have Linux Foundation, uh, who's been using us for their platform engineering, where they host all of their hundreds of, uh, projects. Uh, we have Groupon and, uh, Groupon was such an interesting story.

• 34:03Speaker 00

  They came in, started their free trial, hooked it up to their, um, uh, uh, repositories on GitHub, liked it so much, after just a few hours posted on LinkedIn. Tagged our, our page and by that time, none of us, none of our sales team had a chance to even react, oh, we got a sign up from Groupon, let me reach out to you. And our social media guy had to come in and be like, guys, Groupon is tagging us on LinkedIn, can somebody take a look? So completely self-serve, within five minutes, you'll see the value of it and, and go on and adopt it. And a bunch of other enterprise companies as well, Chegg, SeatGeek, Rolls Royce, The Economist,

• 34:48Speaker 00

  just, just a few that I can think of the top of my head. And it's really the, where the goodness shines is where the reviews are already complicated. Because your team is disparate, spread across, databases of layers and layers, code bases of layers built over the years. And that's really where the, the context enrichment really adds a lot more value.

• 35:17Craig S. Smith?

  Yeah, and, and you guys advise that, that, that on, on a team, there is one person handling CodeRabbit and reviewing the code? Or is this something that ever, every coder is going to do sort of a rolling review of code as they're working on it?

• 35:44Speaker 00

  The latter is what we see more commonly. I would say the former is maybe a little bit more common in smaller teams. You know, let's say if you might have less than 10 people engineering team, then yeah, you typically assign the code review duties to one senior developer. But what we really see amongst the vast majority of our customers is you will, one developer will open a pull request. They will tag two, to up to two, maybe sometimes maybe more, their colleagues to do the reviews. And now CodeRabbit becomes one of those reviewers. And then CodeRabbit can come in and leave its feedback.

• 36:22Speaker 00

  The other developers, not the person that opened the pull request, but somebody else can come in and further add their comments. And then the PR author can then go in and resolve everyone's comments. And the moment all of CodeRabbit's comments are resolved, then we will go and mark the PR as approved from the CodeRabbit side. But we advise Use CodeRabbit's review approval as only one and not the only review approval. So still have a second human reviewer. But most customers are able to bring down from like two human reviewers to one plus CodeRabbit. So effectively now you've saved one full developer's worth of time from going into code reviews.

• 37:08Speaker 00

  And you can typically see that thirty, forty, fifty percent faster PR merge time. And about fifty to sixty percent comment accept rate, which we in a way translate as okay, that's the bug acceptance rate. Right? Some of the other comments, they don't get accepted because they might be nitpicks, they might be things like, okay.

• 37:34Speaker 00

  This is not in the right style guide or something. And a lot of times developers will leave that as they'll review it and market as okay, I don't care about this. But we see more than fifty to sixty percent of the comments being accepted. So in a way, that's a validation that we're finding fifty percent more bugs than we might have found without CodeRabbit. And fifty percent faster PR merge time, saving up to one human developer's worth of time completely from code reviews.

• 38:03Craig S. Smith?

  What's the range of industries that that you're working with? And are there some industries that for compliance reasons are prohibited from using this kind of AI assistant?

• 38:20Speaker 00

  We haven't really had any issues with compliance because we have our SOC two, GDPR, all of the compliances. And mostly we are able to pass that, those compliances because we run all the reviews in a siloed environment in our SaaS for our SaaS product. They are called sandboxes in GCP, our SaaS runs on GCP. And after the review, that sandbox is discarded. So your code is not really sitting anywhere long term in in CodeRabbit's database. Unless you've enabled session, but that's something that is entirely up to you, you can disable the session. We will, we will not store any of your code.

• 39:03Speaker 00

  We do have some other customers who are very stringent on not even using that. And for those, we provide a self-hosted solution.

• 39:14Speaker 00

  So in that case, everything still happens in their private infrastructure, whether that's in their cloud VPC, whether that's in their data center. So we have huge customers who are also running us completely siloed in their data center. And in that case, everything stays within your environment. In terms of industries, it really spans the gamut, right? Reviews is something, is a pain that everybody feels. Doesn't matter if you're a technology company, media, finances, healthcare, but there are some industries where the cost of a bug shipping out is just inherently a lot more worse.

• 39:54Speaker 00

  Right? Like maybe if you are a car company, we have a bunch of the car, big automakers who use us. And if you ship out a bug in their software and that causes an accident, that's just unacceptable. So some, some industries, just the cost of the bug shipping out is just really high. Medicine is another one of those and, and sometimes financial banking sectors is another those. So some industries, just we see a lot more represent, overrepresentation amongst our customer base relative to the, the baseline. Uh, but really it's, if you are a developer, you feel the pain of the code reviews and you, uh, so that, that's what we can come in and automate and, and find more bugs for you.

• 40:40Craig S. Smith?

  Uh, how, and you, you say there's a SaaS version, is there an on-prem version?

• 40:48Speaker 00

  Yes. So we provide a container image. You can spin up your containers in your preferred environment, whether that's in your on-prem, whether that's in your cloud VPC. And in that case, um, if you want, you can also, uh, give us access to your own, uh, way of reaching out to OpenAI or Anthropic, your own API keys instead of using our API keys. So in that case, your, uh, your, uh, integration with, uh, the L L Ns also remains private. Uh, and, and we do have a bunch of customers, uh, who prefer to run it that way.

• 41:21Craig S. Smith?

  And and the SaaS version is is it based on seats or usage?

• 41:29Speaker 00

  It's based a little bit on both seats and some on usage. For most of our customers, it's just the number of seats per developer.

• 41:39Speaker 00

  We are adding some more agentic capabilities, things like automate my doc string generation or automate my unit tests. So those are slightly different capabilities on top of the basic reviews. We are exploring ideas on how those might be consumption based because some developers use those capabilities a lot, others don't. So those the value really shines in terms of how often you use those agentic workflows. Sometimes developers will come and chat with CodeRabbit and say, go ahead and open a Jira ticket for me with all the review feedback and we'll automate that process.

• 42:21Speaker 00

  We'll create a Jira ticket, tag you, include all the feedback. Okay, this is what the code originally was, this is what it should be changed to. Or you can copy paste our feedback into your AI coding agent and let the coding agent incorporate the code changes. This is a bunch of agentic workflows, but for the most part, it's seat based. Twenty four dollars per month per developer for our most common plan that includes most of our capabilities and the enterprises, it's a more of a high touch engagement with the sales seat.

• 42:55Craig S. Smith?

  Yeah, so it's it's for an individual developer, it's affordable.

• 43:00Speaker 00

  Yes, absolutely. Individual developers, we also have a lighter version of the plan. Sometimes they don't care about, you know, us finding a lot of those complex dependencies because they might not have that much of a complicated code base. So we also have a lighter version of the plan. This is only like fifteen dollars per month per developer and we have a whole bunch of people who use those. And for open source, we're completely free. We've kept it completely free for the open source communities and they still get most of the features that are in the in the paid version of the product.

• 43:30Craig S. Smith?

  And for someone who wants to try it, can they? Use it just for one month without committing to a multi-month plan?

• 43:40Speaker 00

  We have a fourteen day free trial. You can visit our website, coderapid.ai. It will, it takes less than five minutes to just use your GitHub or any of the other Git platforms login. Give us access to the repository that you want us to do the reviews in and create a new pull request or a merge request. And CodeRabbit will start within minutes. If you need more time, Richard, our sales team would be happy to work with you if you need more of a free trial time.

• 44:08Craig S. Smith?

  Yeah, that's fascinating. And how is this space growing? As we said at the beginning, the amount of AI-written code is just piling up. And one of the challenges is reviewing it all. It seems like your market is expanding rapidly. Can you scale to keep up with the market?

• 44:35Speaker 00

  The market is as big as the number of software developers. Again, if I think back to a pre-AI world, you know, there was software generation and software reviews were two things that happened in parallel. And from our vantage point, the software review market is just as big as the AI for software coding market. The, obviously, the AI for AI coding agents found their initial foothold. And now we're seeing customers realizing the pain of more and more code being generated. But you can't rely on the AI tool that wrote the code to self-certify that its code is bug-free. So you need something else come in and do the reviews.

• 45:18Speaker 00

  Whether that's manual reviews or whether that's using AI to also automate those reviews. And we are aggressively hiring and expanding a team based out of the Bay Area mostly, but we have a distributed team across the world, some colleagues in Europe, a bunch of colleagues based out of India. But the team headquarters is here in Walnut Creek, California. And we're expanding on a nonlinear basis, month over month, double-digit percentage growth, month over month. So it's really an exciting time. I've been in the industry long enough. I've seen the semiconductor boom and then the cloud infrastructure boom. I've never really seen anything like the AI boom that we're living through. And it's a perfect and an exciting time to be in this, in this market.

• 46:02Craig S. Smith?

  Absolutely. Yeah. Okay. Well, is there anything I haven't asked that you want listeners to know?

• 46:10Speaker 00

  No, it was a fun, engaging conversation, Craig. You covered all the great points. We look forward to listening to more of your podcasts and bringing the all that's happening in the world to your listeners.

• 46:22Craig S. Smith?

  In business, they say you can have better, cheaper, or faster. But you only get to pick two. What if you could have all three at the same time? That's exactly what Coher, Thomson Reuters, and Specialized Bikes have. Since they upgraded to the next generation of the cloud, Oracle Cloud Infrastructure. OCI is the blazing fast platform for your infrastructure, database, application development, and AI needs. Where you can run any workload in a high availability, consistently high performance environment, and spend less than you would with other clouds. How is it faster?

• 47:08Craig S. Smith?

  OCI's block storage gives you more operations per second. Cheaper? OCI costs up to 50% less for compute, 70% less for storage, and 80% less for networking. Better? In test after test, OCI customers report lower latency and higher bandwidth versus other clouds. This is a cloud built for AI and all your biggest workloads. Right now, with zero commitment, try OCI for free. Head to oracle.com/eyeonai.

• 47:51Craig S. Smith?

  Eye on AI, all run together, E Y E O N A I. That's oracle.com/eyeonai.