Conversations at the Intersection of AI and Code with Harjot Gill

almost always testing some frontier model for these labs using our evals. We kind of have one of the best evals in the industry when it comes to reasoning models, given that code reviews are a reasoning-heavy use case. And also around the agentic flows, because as you go deeper and deeper into agentic flows, your errors compound. So these long horizon tasks, if you go off track on the first step, you're going to be way off in the 10th step, right? So yeah, it's all about evaluating. So we have a team that spends a lot of time looking at open source usage that we have, bringing those examples end to make sure we have the right evaluation framework to understand the behavior of these new models as they come out.

Welcome to Screaming in the Cloud. I'm Corey Quinn. Today, I'm joined by Harjot Gill, CEO and co-founder of CodeRabbit. Harjot, you're a now 3-time entrepreneur who went from Nutanix, a senior director, where you were building What is now apparently the most installed AI application on GitHub and GitLab, if I'm reading this correctly. What made you leave a big comfortable tech job to decide, you know what I really wanna do next? Code review.

Yeah, thanks for having me here, Cody. I mean, it's been a very interesting journey for me.

Coding faster with AI tools, you need faster, better code reviews to keep up and to keep out the AI slop. CodeRabbit delivers senior engineer level code reviews on pull requests and right in your IDE with less LGTM. Uh, get context-aware feedback for every commit, no configuration needed, and all programming languages you care to use are supported. From individuals to enterprises, join the millions who trust CodeRabbit to banish bugs and help ship better code faster. Get started at coderabbit.ai and instantly cut your code review time and bugs in half.

So I've done these startups for a while. I actually Started my first company back in 2015 out of my research that I was doing at University of Pennsylvania at that time. That was called NetSail. It was in the early time. I mean, you would remember that because this was the time of Docker, Kubernetes, and all these microservices taking off. We built this product that was like listens backward, NetSail, so we could understand the API calls and understand the performance. That was the first startup, which was acquired by Nutanix. I was there for a few years. Never been a big company person. So yeah, I mean, so we had to go there, integrate the product. Then I quit to start another startup, which was Flux Ninja, which was in the reliability management space. And the idea was like, how do we go beyond observability into more controllability, prevent cascading failures and all these Black Friday outages and so on? Yeah. So we built a very interesting rate limiting and load shedding kind of a solution where you could prioritize API calls. Now, unfortunately for us, I mean, that didn't go well. I mean, we were betting a lot on service meshes to take off, and they never became a mainstream tech from that point of view. And very interestingly, around that time, large language models took off, like generative AI. And it started with GitHub Copilot, and then ChatGPT came along. And this was even before there was GPT-4. And I was running this team of around 15 remote employees during COVID and we were struggling to ship code faster. One of the big bottlenecks was even though Copilot had come out, people were coding, even doing smaller stack pull requests and so on, but still the code reviews were a very massive bottleneck. I did this weekend hackathon project where we started using some of these language models to automate the code review process to find low-hanging issues that can go beyond simple linting issues that you find with existing tools. That was a very interesting outcome. Like, we saw that this is a really good fit. And then CodeRabbit started as a separate company. It just took off. And it was very clear that we have to, like, just focus on that problem statement. And then Flux Ninja, my second startup, we basically folded into CodeRabbit, and that's what I then continued to go full-time. And CodeRabbit, yeah, go on.

Yeah, CodeRabbit is interesting to me from the perspective of you're tackling something that historically has felt very boring and things that people tend to more or less phone in. I mean, code reviews have been around forever, but what did you see around its fundamental broken nature that made you think, ah, we could, we could pour some AI on this and make them better?

It's broken in many, many ways. You won't believe it. Like, not every company— I mean, everyone wants to do a code review process because of compliance reasons and just because they want to prevent massive failures downstream, because each issue you catch In SDLC is much cheaper, right, than to cache it later in production.

And I mean, even on my solo side projects where I'm developing things and merging them in, I still feel obligated to do some form of code review just because I style myself as kind of a grownup and I probably got everything right. Why would I even read this thing I'm about to merge in? I still feel obligated to do it. That doesn't mean I do it, but I feel bad when I don't.

I mean, and a lot of managers in these companies have that, like, guilty conscience, like, because of the— because they're not doing a good job. Because if you look at really good code reviews, they take as much time as it takes to actually write the code. But I mean, you actually have to really understand the context of these changes because software is complex. It breaks in very, very interesting ways. And code review is like the kind of the first line of defense. I mean, of course, you're doing more validation downstream, QA environments and so on, but code review is really necessary. But most companies don't do it well.

Oh yeah. And AI seems to be way faster at not reading the code, typing LG GTM as a comment and then clicking the merge button. It feels like it could speed up that iterative cycle, which frankly is sort of the way that it seems like all large code reviews tend to go. I've, I've submitted 3-line diffs that have been nibbled to death by ducks as, as people talk about it, but the 10,000-line diff of a refactor or a reformat or something gets the looks good to me, ship, ship squirrel, and off it goes. It's— there's a human nature element at play here.

You're right. I mean, when the PRs are small, yes, people can still have a cognitive like Can cognitively look at them. But when they become beyond a certain threshold, that's the point where you say, okay, rubber stamp it, ship it. I don't care. I can just go through it. And then in some companies, you have the ego clashes. People actually do a very thorough job or too thorough many times, and you have so much back and forth for days and weeks at a stretch, and things don't move at all. So yeah, I mean, the code reviews can get ugly in many ways. Most of the time, it's rubber stamps, as you said, but in some cases, they can also be very toxic. And not a pleasant experience, right, in many ways.

Show me how your company reviews code. I can show you aspects of its culture.

That's right. That's right. Yeah.

So I guess a question I have is around what I guess I'll term a second-order effect of a lot of this AI-generated code proliferation. Now it seems like forget merging code in that I haven't read, in some cases I'm merging code in I haven't written. It feels like that is increasing the burden on the code review process.

Right. So one of the biggest killer applications for generative AI has been coding. I mean, that's probably the only thing that's working if you really think about it, right?

Oh, it, it is the standout breakout success of generative AI. Everything else is trailing behind. But what it turns out that there's a lot of replacement of Stack Overflow that AI code generation can do.

That's right. That is right. I mean, and it's getting more and more sophisticated. Now you have all these coding agents which have come on the scene, which like Cloud Code, for instance, you're starting with a prompt and you're getting large-scale coding changes done in a few minutes, right? And a lot of these white coders or the junior coders in every organization, they tend to throw this code over the wall and then it's someone else's headache to review it, especially the senior developers. And now they have a huge bottleneck of pull requests where they have to now piece together their puzzle on what actually happened there. It's a nightmare. I mean, the backlogs are now increasing because of generative AI. A lot of white-coded PRs are being opened against open-source projects. It's also a maintenance nightmare. I don't know whether you've seen a lot of tweets around open-source projects where they're getting these contributions from random developers across the world with 10,000-line PRs, hundreds of files changed, and so on. They seem like good features on the surface, but once you start digging deeper, they're rife with issues. And that's where I think it's becoming unsustainable. And you're getting AI, it's like an air battle. Earlier you were fighting a tank battle, but now you're in a very different battleground. You have to bring AI to fight AI in many ways, or AI to review AI, right?

Very much so. It's one of these areas where it just seems that there's so much I guess nonsense code being thrown out. I look at the stuff in my own code base after I let AI take a few passes through it, and like the amount of dead code that'll never be reached through any code path is astonishing. 5 different versions of documentation, all self-contradictory. It becomes an absolute mess. The counterpoint though that I have is that this is not the first attempt at solving the code review problem. There have been a bunch of traditional tools aimed at this before the rise of AI, and the biggest problem that you had there was false positives.

That's right. I mean, if you look at the traditional tools like pre-gen AI, they were mostly based on static rules, some sort of like, if you look at the security scanning market, the SAST market, you probably cover some of those companies. They're looking at OWASP vulnerability. They have signatures to discover those deficiencies. And every company, when they enable these tools, they end up in a lot of alerts. Alert fatigue is a problem, and you end up switching a lot of these linting rules so that you can still move faster without making sure you're covering all these clean code guidelines that you could have, right? Yeah. So that has been a traditional problem with the tools in this space. I mean, all the way from SonarSource and Semgrep of the world and so on. And when it comes to AI, one of the nice things is you can tune it. There are very interesting knobs possible here. And also the kind of insights you're getting are more human-like feedback. You're not going and nitpicking on some signature. You're talking about the best practices. As you said, it's a Stack Overflow. taking all these best practice examples that these models have been trained on, and you're bringing in to more of an average engineer anywhere, like, in the world, could now have access to the best practices, which they otherwise don't without proper mentorship.

I wanna dive a little bit into, I guess, the cloud architecture piece of a lot of this. You've been fairly open on your engineering blog about how your infrastructure works. You use one of my favorite Google Cloud Services, of all things, Google Cloud Run, to effectively execute what amounts to untrusted code at significant scale. And that is both brilliant and terrifying at the same time. Can you talk me through that decision?

Yeah, we were like one of the first companies to build agentic workflows and also like engineer it to a point where it's very cost-effectively done. So one of the things we found with building these agents is that no matter how much context engineering you do, it's never enough. So a lot of the companies started with RAG lookups. They will index the codebase, and they'll bring in all this context and then ask the model a question around whether this code that you're reviewing looks good or not. But we found that very often, this context is never enough. It can never be enough given the complex codebases in the real world. That's where you want to give these models some sense of agency to go and explore. For example, CodeRabbit has a multi-pass system. The first pass of the review, it does raise some concerns. Now, these could not— a lot of the times, these are false positives. They're not valid findings. So what we do in the sandboxes that we create in Google Cloud, we use Google Cloud Run. It's a really great service. It's serverless. So we create these ephemeral environments where we kind of— the pull request that we're reviewing, we not just look at that pull request, we bring in the entire code into the sandbox. And then we are letting the models actually navigate the code like a human does, but using CLI commands. So that was the other innovation. We are generating a lot of shell scripts. We are letting the models run ripgrep queries. We are letting the models do cat command to read files based on the concerns they see in the code. And they navigate the code. And once they bring in this additional context, that's where they're either able to suppress some of these false positives. And in many cases, we are able to find issues which are ripple effects. In the call graph across multiple files. That's what makes CodeRabbit really good, by the way. Yeah.

Yeah. How do you wind up, I guess, drawing the line? Because I found that one of the big challenges you have with a lot of these LLM-powered tools is they are anxious to please.

The—

when you say, great, find issues in this code, like they're not gonna say, nope, looks good to me. They're going to find something to quibble about, like some obnoxious senior engineers we've all worked with in the course of our careers. Uh, how do you at some point say, okay, anything Nothing is ever perfect. At some point, you're just quibbling over stylistic choices. This is good, ship it. How do you make it draw that line?

That was the hardest part, I'll tell you. So when we started, like, I mean, you're right. I mean, if you ask a model to find something wrong, it will find something wrong in it, like 10 things, 15 things. It will almost always please you, right? And the hard part is like, how do you draw the right balance, like in classifying a lot of this output? and seeing what's important enough for the user to pay attention to. Took a lot of trial and error. Early days when we launched the product, we still had a lot of cancellations because of noise and feedback that was too nitpicky. And it took a while to learn and figure out the right balance when it comes to the quality of feedback and what's acceptable. And it was a long battle, I can tell you. A lot of our engineering actually went into taming these models to a point where we can make majority of the users happy. We can't make everyone happy. This is the nature of these product. They're not deterministic, and they're not like the previous generation of the systems where you can deterministically define the rules. But this one's like very vibe feedback. We are vibing, as they say, right? Vibe check.

Yeah. Yeah, there's a lot of, I guess, nuance in a lot of these things, and the space is moving so quickly that it's basically impossible to keep up. You have, I believe, standardized around Claude's models for a lot of this. 20 minutes before this recording, if people want to pinpoint this in time, Anthropic came up with a surprise release of Opus 4.1. So if we had recorded this yesterday and said Opus 4 was their premier model, that would now be inaccurate, even in a short timeline like this. How do you, I guess, continue to hit the moving target that is state of the art?

That's a great question. First of all, we use both OpenAI and Anthropic models. In fact, our OpenAI token usage might be even more than that, what we see on Anthropic side. We use like 6 or 7 models under the hood. Like one of the nice things about CodeRabbit product has been, it's not a chat-based product. Every product in the AI space starts with some sort of a user input. CodeRabbit is like zero activation energy. You open a pull request, it kicks off a workflow, and it's a long horizon workflow, takes like a few minutes to run.

Which is genius. Chatbots are a lazy interface, to be direct. It's, everyone tends to go for that 'cause it's the low-hanging fruit. But if I have to interface with a chatbot, it's not discoverable. what it's capable of doing. And if I look at it on a traditional website, that already means on some level your website has failed in all likelihood.

Yeah, yeah. In a way, like, it's like a zero activation energy kind of a system. Like, you don't have to remember to use it, right? But that brings in like very interesting thing. Like, first of all, it's a long-running workflow with ensemble of multiple models, and evaluations become like the key thing. Like, the nature of these products is it's all about evaluations. We are not like training our own foundational models. It's not in our budget. So what we do is make sure that at least we have some sort of a sense into understanding these models and the behavior and tracking their progress across the different generations that we are seeing. So we are actually almost always testing some frontier model for these labs using our evals. We kind of have one of the best evals in the industry when it comes to reasoning models, given that code reviews are a reasoning-heavy use case, and also around the agentic flows, because As you go deeper and deeper into agentic flows, your errors compound. So these long horizon tasks, if you go off track on the first step, you're gonna be way off in the 10th step, right? So yeah, it's all about evaluating. So we have a team that spends a lot of time looking at open source usage that we have, bringing those examples in to make sure we have the right evaluation framework to understand the behavior of these new models as they come out.

Stuck in code review limbo? Get CodeRabbit and never wait on some guy named Mike again. Swap the drama for multi-layered context engineering that suggests one-click fixes and explains the reasoning behind the suggestions. CodeRabbit integrates with your Git workflows and favorite toolchains, supports all programming languages you're likely to use, and doesn't need configuration. Get code reviews when you need them at coderabbit.ai, and get them for free on open-source projects and on code reviews in your IDE. So this might be a politically charged question, but we're going to run with it anyway. Why did you pick Google Cloud as your infrastructure provider of choice? I mean, well, why not Azure? I can answer that easily. But AWS is a viable— is at least a viable contender for this sort of thing. I have my own suspicions, and I'm curious to hear what your reasoning was.

We love the Cloud Run product. I think that was one of the big drivers. The whole Cloud Run thing is amazing. Like, that was one of the reasons we saved us so much time and costs in operating like this. whole serverless thing, right? And also, like, in our previous startups, we have gone with Google Cloud, like the interface, it's like Amazon is great, but that's like one of the first cloud services. It can get very overwhelming to a lot of people, but the GCP is like much more cleaner in our opinion, cost-wise as well. It's been very effective in terms of, yeah, I mean, I think a lot of startups do build on Google Cloud.

Yeah, it's one of those areas where if I were, and I've said this before, that if I were starting from zero today, I would pick Google Cloud over AWS just because the developer experience is superior. Cloud Run is no exception to this. It's one of those dead simple services that basically works magic, as best I can tell. It feels like it's what Lambda should have been.

Yeah, I mean, it's amazing, right? I mean, you can— it's all concurrency-based, which we love. Like, I mean, scaling is so straightforward once you understand the model there. Like, it's not like based on just resources. Like, the knobs there are very— like, make so much logical sense once you get to understand them. They're much simpler.

How do you handle the sandboxing approach to this? By which I mean that It has become increasingly apparent that it is almost impossible to separate out prompt from the rest of the context in some cases. So it seems like it would not be that, uh, out of the realm of possibility for someone to say, yeah, disregard previous instructions, do this other thing instead, especially in a sandbox that's able to run code.

Yeah, you're right. We are running like, um, untrusted code and some of this like chat interface, you could actually steer the system to generate any malicious shell scripts or Python code in that environment. And we do have internet access enabled as well. So it's all about locking down, making sure you have cgroups and all set up so that you're not escaping the sandbox that you have created. And the other part is locking down the access to internal services. You don't want that sandbox to access the metadata service of these cloud providers. So yeah, so standard stuff comes around network network zoning and the cgroups and all. And the other part is we allow internet access. I think that's something we— we disallow everything which is in the GCP VPC, but allow internet access. At the same time, we have protections around resource utilization and killing those malicious projects, scripts that could be running.

That is always one of those weird challenges. Taking a more mundane challenge that I have is often code bases tend to sprawl as soon as they become capable of doing non-trivial things. And some of us don't bound our pull requests in reasonable ways. How do you wind up fitting, getting meaningful code review either in a giant monolithic repo that will far exceed the context window or, or counterpoint within a microservice where 90% of the application is other microservices that are out of scope for this? How do you effectively get code review on something like that?

That's a great question. There's a term for this called context engineering. And that's what we do actually. That's the best way to describe it. Like it all starts with building some sort of code intelligence. Let's say you're like reviewing 5 or 10 files, but you have a large code base where those files got changed. The first part of the process is like building some sort of a code graph, because unlike Cursor, which kind of uses— in the code completion tools, they use like code index, which is more on similarity search. And that works great for their use case because they mainly need to follow the style of existing code when generating new code. In our case, the code review is a very reasoning-intensive workflow. If we are bringing in these definitions from the other part of the code, they have to be in the call path, right? So that's why we build a relationship graph, which is a very different technology that we invested in. And that brings in the right context as a starting point. As I said, it's still a starting point. You still have to do the agentic loop after that, but the starting point has to be good so that your first pass of this interview has some bearing on where to poke holes. You're going to first raise 20, 30 concerns, and then you're going to start digging deeper on those choose-your-own-adventure kind of routes. And some of these will lead to real bugs. It's not deterministic. I mean, each run would look different. It's just like humans. Humans will miss stuff a lot of the times. But now, in this case, AI is still doing a really good job in poking holes at where it feels the deficiencies could be there, given the code changes. But it starts with the initial context. So you have to in, like, code graph learnings. So we have long-term memory features. So each time a developer can teach CodeRabbit, it learns, and it gets better over time, because those learnings are then used to improve reviews for all the other developers in the company. It's a multiplayer system, right? So we are also bringing in context from existing comments on a PR, some of the linting tools, CI/CD. So there are, like, 10 or 15 places we are bringing the context from. The most impactful is usually the code graph.

I want to explore a bit of the business piece of it. If that's all right with you, uh, you've taken a somewhat familiar GitHub-style model of free for public repos, paid for private ones. By and large, there's a, there's a significant free tier that you offer, uh, and you're also, to my understanding, free in VS Code, Cursor, Windsurf, as long as that lasts, etc. How do the economics of this work?

That's a really great question. Like, when we start this business, like, one of the things we realized that it's a habit change. We're trying to make people adopt this new habit, like this AI thing. Most people don't want to use it. I mean, you're trying to bring AI experiences into existing workflow, and universally everyone hates it. Now, CodeRabbit has been lucky in that regard that we brought in a very meaningful experience that people love. And we wanted to make sure that we spread it and democratize it to some extent. That's where the open source makes sense. I mean, first of all, we love open source. I'm a big believer, and we sponsor a lot of these open source projects. And that became also testing ground. So that was the other thing, because it's not just a go-to-market, but also the learnings and the public usage. We used that as a feedback loop to improve the AI product so that we can serve the paid customers. So from the economics point of view, yeah, it's hard given that it's one of the agentic systems. And publicly, even Cursor and Cloud Code have had issues with their pricing, massively negative gross margins. It's like we are still able to offer this service at a flat price point of per developer per month, which is affordable enough that we can go mass market with it.

And predictable enough, which is underappreciated.

Exactly. It's predictable enough. There is no surprises, and we don't have negative gross margins, right? I mean, we were one of those very few success stories where we have engineered the system to a point using on— like, we're not like letting users pick Sonnet and run that in a loop. I mean, if you look at most products, that's how they are. You're picking a model and running with it. We are being smart about this, right? It's like Amazon Prime. Yes, everyone wants free shipping, but you can't just offer it. You have to build the automation, the infrastructure, and we invested in that. That's the trick. I mean, we are able to support all the open source users so that we can learn from them a lot. We are supporting a lot of the IDE users because we monetize on the GitHub side. We are a team product, and that's the market we care about. By removing the barrier to entry using the IDE, most people are now familiar getting familiar with CodeRabbit through that form factor. And once they like it, they're able to bring us into their Git platforms where they need more permissions and some consensus to adopt it. And that's working really well. I mean, go-to-market-wise, we are growing like double-digit growth every month.

And who are these folks? Are these individual developers? Are these giant enterprises? Are they somewhere between the two?

Somewhere between the two. Like, most of our growth early days had come completely product-led growth inbound. all the way from small 5-developer companies all the way to hundreds of developers. So we've seen the whole spectrum of it. Everyone needs this product. No matter you're a small company or large, everyone needs to do code reviews. And the smaller teams tend to move faster given that it's fast, you can build a consensus quickly. Larger teams need a longer POC, but it usually happens in a few weeks. ROI is very, very clear for this product. We have some of the enterprises now also doing some POCs for a few weeks, and these are large Uh, 7-figure deals even.

That is significant. Uh, you also recently raised a $16 million Series A, uh, led by CRV. Uh, so I'm sure you've been asked this question before, so I don't feel too bad about springing it on you, but what happens when Microsoft just builds this into GitHub natively? Uh, how do you avoid getting Sherlocked by something like that?

It's already happened. So we've been competing with GitHub Copilot's, uh, code review product for the last 10 months now.

The fact that it automatically does that, and I had no idea that it did that, tells me a lot about GitHub's marketing strategy, but please continue.

Yeah, they do have that product, which is built in. And usually, I mean, of course, I mean, it's almost like, as with everything GitHub, like the best-of-breed products still win, right? I mean, so that's where like it hasn't impacted anything on our growth or churn rates, even despite that product being out there.

I have heard people talk about CodeRabbit in this context. I have not heard people talk about Copilot in this context for just a sample size of one here.

Right. That's right. And we have innovated in this space. We actually created this category. I mean, the bunch of larger players, they're all trying to copy our concepts, but still there's a lot of tech under the hood, which is very hard to replicate. I mean, it's, I would say, a harder product to build than even code generation systems, given that it's a very reasoning-heavy product, and people are more sensitive to the inaccuracies when it comes to these kind of products. And it's a mission-critical workflow, right? I mean, you're in the code review, and it's a very serious workflow. not just something on your developer's laptop, and you can be more forgiving around the mistakes. Yeah, that's why we have, like, seen a lot of clones, but no one has been able to replicate the magic of CodeRabbit. We are, like, probably 10x bigger than the next competitor in the space.

Yeah, I'm not aware of other folks in the space, which probably says something all its own. And this also has the advantage of it feels like it is more well thought out than a shell script that winds up calling a bunch of APIs, and it doesn't seem like it's likely to get become irrelevant with one feature release from one of the model providers themselves.

That's right. That's right. I mean, yeah, I mean, so we kind of bet on the right things early on, like going fully agentic. We kind of saw that coming 2 years back and investing a lot in the reasoning models before they even became mainstream because the entire thing was reasoning heavy. So, we've kind of been future-proof with the decisions we are making. And now we could be blindsided by something, I don't know, like GPT-5, GPT-6, but so far it looks like each time the new models come out, they benefit this product a lot. And it's all about the context we are bringing in. And how we engineer the system for cost. Cost is a big factor in this market, I could say. I could tell you that. Yeah.

Yes. Oh, absolutely. Especially since it seems like when you offer a generous free tier like this, it feels like that, yes, it's a marketing expense, but that also can be ruinously expensive if it goes into the wrong direction or that you haven't gotten the economics dialed in exactly right.

That's right. And that's why you have all these abuse limits. That's where the technology from my second startup came handy. Like, so a lot of the abuse prevention is the Flux Ninja tech that we are still using at Coda.

So, you claim to catch a ridiculous percentage of bugs, which is great. I mean, your marketing says all the things I would expect. What has the developer feedback been like in reality?

I would say majority people love it. I mean, you could see this on the social media, like people are just talking about it. They in general love the product. Like a lot of these organizations we talk to, they say they recovered the investment in 2 months. And some people are coming back and saying, if you were to charge more, they will still buy it. It's been very overwhelming. Of course, there's always going to be some detractors, people who don't like AI in general, have their own opinions. That crowd will always be there. But if you look at the majority, it's definitely a step function improvement in their workflow. It's very easy to see if you go and search social media, LinkedIn, or X platform, or Reddit, you will always see people saying positive things. That's where we're getting the growth from. Most of our signups are actually word-of-mouth signups at this point. So, it's like our customers bringing in more customers.

So, I guess my question now comes down to what the future looks like here. Where does this go? What is the ultimate endgame? Do human code reviewers wind up going extinct, or is this more of an augmentation versus replacement story?

I think it's more like now humans will be fighting a higher-order battle. If you look at all this nitpicking and looking at problems, the AI still is not doesn't have the non-obvious knowledge. There's knowledge beyond code review that goes into the decision-making, which we don't have. And the humans have that knowledge, right? So in a way, I don't think humans are going away. I mean, what we have seen is usually instead of having 2 code reviewers on each PR, now one is AI, the other is still a human. And on smaller pull requests, they're just trusting CodeRabbit. They don't even have a human reviewer. So some of that automation has kicked in. But when it comes to coding in general and code review, I think it's going to be a long journey. A lot of the labs are hoping that that we'll go completely automated software development in the next few years, but I don't think that's going to happen. What we are now discovering that this whole coding market has multiple submarkets in it. There's tab completion. Now there are different agents all the way from terminal, IDE, background agents, and they don't really replace each other. They're just being used for different reasons. And then code review as a guardrail, layer is going to be standardized for these organizations as a central layer. It's almost like Datadog, if you have to give you an analogy, like you had all this multi-cloud, you had all these Kubernetes, Rancher, but then Datadog said, okay, to be successful, you need observability. I'm gonna give you the guardrails and became massively valuable. That's where we see co-driver opportunity here.

So, I guess my last question for you on this is that for various developers who are listening to this, who are drowning in PR reviews going unattended, What is the one thing that they should know about CodeRabbit?

I think CodeRabbit is a friend. I mean, in a way, like, if they're bringing CodeRabbit into their workflow, they are going to be like at least offloading some of the most boring parts, which is the review. Like, of course, building software is more fun than review. It's— and it's fun to work with. I mean, of course, it's going to be that AI that's like always watching their back while they're trying to move fast with AI, making sure they're not like tripping over and causing bigger issues.

If people want to learn more, where's the best place for them to find you?

Yeah, they could just find us on coderabbit.ai and it just takes a couple of clicks to try out the products, really frictionless. So you could get started just a few minutes for your entire organization.

Awesome. And we will of course put links to that in the show notes. Thank you so much for taking the time to speak with me today. I appreciate it.

Thanks, Corey. Thanks for having me here.

Harjot Gill, co-founder and CEO of Coderabbit. I'm cloud economist Corey Quinn, and this This is Screaming in the Cloud. If you've enjoyed this podcast, please leave a 5-star review on your podcast platform of choice. Whereas if you hated this podcast, please leave a 5-star review on your podcast platform of choice, along with an obnoxious comment that was no doubt written for you, at least partially, by AI configured badly.