The Problem Nobody Is Solving in AI Development: Code Explainability

The agents are creating massive amounts of code. As we say, the history doesn't repeat, but it rhymes. For me, it certainly does. Like, when I saw the opportunity here, I could just relate it back to my first startup coding. Now the coding is getting automated. The reviews would certainly become the next bottleneck. The biggest bottleneck in SDLC is now code review. And the second is explainability, because you still need to build trust in these outputs very quickly.

Right.

Say that, hey, is this garbage, slop that I could just close a PR, or is this something worth merging, right? So I kind of see this more of like a hamburger, like Jira linear, and you have Slack and Notion where you basically need to collaborate on what to build. And then downstream you have version control systems like GitHub, which is under too much tremendous stress right now, as you know.

Right.

And you at Microsoft probably know all about that, right? We were one of the first agents that just worked as soon as you open a pull request. There is no other human input, like it's a webhook. Yeah, that triggers an agent. The chat is more of a secondary feature. There is chat as well, but that's not the primary interface into CodeRabbit.

Welcome to this episode of the Cloud Girl Podcast. Today I have Harjot Gill with me. Harjot, welcome to the show.

Yeah, thanks for having me here, Priyanka.

Thank you, and thank you for sharing the, the CodeRabbit space and inviting me to the studio. But why don't we start with just a little bit of an introduction of who you are and what is CodeRabbit?

Yeah, so I'm co-founder, CEO of CodeRabbit, which you, as you know, is a leading provider of AI code reviews, essentially providing automatic validation and explainability for all these like agentic software development stack that everyone's adopting. Company is like roughly 2 and a half years old, but we have like several hundred thousand developers who use the product, love the product on a daily basis, monthly basis, and so on.

Yeah. So tell me a little bit about your background because it's very interesting. You have had multiple exits. Can you take us through some of that and then come to CodeRabbit? Yeah.

So CodeRabbit has been like dear to my heart, like being an engineering leader and as well as an entrepreneur in the space. So this is my third startup.

Yeah.

So my first startup was a spinout from University of Pennsylvania where you and I first met. Actually, I was a TA. Yes. Almost like a decade back. So that company was called NetSill and that was in the observability space. So NetSill was listen spelled backwards. And we at that time, it was kind of a very similar situation where cloud computing was taking off, all these orchestration systems. Yeah, like Kubernetes, microservices, Docker. And there was a lot of chaos, like humans were finding it hard to understand these fast-moving environments and a lot of the bottleneck shifted. Yeah, from the deployment was so easy, but then the bottleneck shifted to observability. Yeah, like the second-order effect. Right. And now fast forward to now, right, where we are seeing the same situation.

Yeah.

where there's a lot of chaos. The agents are creating massive amounts of code. Yeah. And as a second-order effect, explainability is becoming a bottleneck. Kind of like, as we say, the history doesn't repeat, but it rhymes. For me, it certainly does. Like when I saw the opportunity here, I could just relate it back to my first startup. Yeah, very interesting.

From the cloud to, to here in the, in the AI space. And you're so right. Like the customers, consumers I speak with, everybody is battling the same problem. Now we have 90% of the code written by AI, but my senior engineers, all of their time are spent— is spent in reviews. So how did the idea come about? And from there to today, the journey of CodeRabbit and the evolution?

Yeah, I mean, this happened in my second startup, which I kind of miss talking about. So I was doing another— like, I mean, the first startup exited at Nutanix, which is a big infrastructure company, and I was there for a few years. Started another company in the load management, reliability management space because at that time, like, some of this web-scale computing was taking off. But right around— it was during COVID and right after that, like, you'd know, like, GPT-3.5 arrived, GPT-4 arrived after that. And the killer app at that point was GitHub Copilot. There was no Cursor, by the way. So GitHub Copilot predates even ChatGPT. And as soon as I saw that, it was very clear to me that, hey, this is an inflection point. Like, the entire world is going to change.

Yeah, right.

So the bottleneck had been code reviews, uh, coding. Now the coding is getting automated. The reviews would certainly become the next bottleneck.

Yeah.

And running the small team, I could clearly see that, like, we were like a remote team because we started during COVID So we had people in Eastern Europe, India, the US, Canada, like a bunch of places.

Yeah.

And they were moving at a startup pace, as you know, like shipping multiple times a day.

Yeah.

And code reviews were already a pain. So we had automated a lot of our DevOps processes, the static analysis tools. People were trying to open small PRs doing stacked pull requests.

Yeah.

So even like had an internal tool we wrote. This was even before this Graphite company. Like Graphite was like, like they had released a CLI. We got access to the early access. Yeah, but we also had our own tool that was doing similar stuff and that tool was helping with the code reviews, but it wasn't fundamentally solving the problem of humans had to still understand the code changes. Like having small changes makes sense, but then you sometimes lose a bigger picture. So there were always tradeoffs with that thing. But when AI arrived, it was very clear that hey, this is like yeah going to everything is gonna change.

Yeah.

And that's where Code Rabbit started. It's my other co-founder who started the company. I mean, I came on board after the second startup struggle to raise more capital in that space where all the VCs lost interest. Right.

Yeah.

Right. And we were lucky. Like we kind of attacked and saw this pain point before others realized it will hit them. Now two years forward, two and a half years, very clear. that the biggest bottleneck in SDLC is now code reviews. Code generation is automatic.

It's realizations now for a lot of the enterprises because the adoption has increased for AI now. But you saw the space before it even emerged.

And it's very likely the lot of the value in agentic coding space is going to accrue in this bottleneck. Yeah, right. So code generation more and more is going to become commoditized.

Yep.

And even the models, you're going to see open source models are inevitable, right? And even beyond a certain intelligence level, code generation doesn't benefit. The 2 things that benefit are planning and reviews, which are like more reasoning heavy. But if you're talking about like just raw writing lines of code, even like simpler open source models are doing a great job. As you have seen with Cursor Composer 2, may not be as great as Opus, but it's really great in writing code.

It does. Yeah.

And you're going to see more of that. So very likely the bottlenecks are going to be around 2 things. One is how do I automate some of these validation steps?

Yep.

And the second is explainability, because you still need to build trust in these outputs very quickly. Say that, hey, is this all garbage slop that I could just close a PR, or is this something worth merging? Right.

So how do you I've described this to to people in the form of so we had linear process of like creation with like planning and test development and testing and all that. And now we are in the process we you beautifully said just now where it's it seems to me like an hourglass where coding itself is like the the smallest part of this hourglass and then the planning and the requirements gathering and all that there are tools in that space that will that are needed and innovation there. And then there's the lower part of the hourglass, which is the review side of things. As I talk to more and more CTOs, CIOs that are just on this journey of like, yes, our engineers are now starting to use AI coding tools. What do you see as the problem beyond the reviews? So there's some reviews that you can do with AI, but where do you see the human element continuing to play a huge factor?

Right. I mean, it's, it's kind of a good balance. Like some of the things AI is already better than humans.

Yeah.

When it comes to writing quality code or even doing finding issues in the code, but you still need explainability in terms of whether these changes make sense or not. Like Are they going to increase the entropy of my codebase? You want to understand the blast radius, like whether the code flows or some invariants have been rolled back because you sometimes don't know how your prompts ended up, right?

Yeah.

The other bottleneck, you're right, is upstream where the nature of human review is going to shift from line-by-line code reviews to actually reviewing the specification and deciding what to build as a team.

Right.

So I kind of see this more of like a hamburger, like, I mean, I mean, the outer loops. The inner loop is automated. The outer— and that inner loop is also very much single-player right now. Most of these coding agents are running on your local workstation.

Yeah.

You have Claude. I mean, depends on if you are an IDE person, you are using Cursor. If you are in the terminal, you are probably using Claude Code or OpenCode. And then if you are like using like desktop apps, like Codex desktop app, as you know, is getting really popular. So different people have different preferences to pick up these surfaces, but increasingly these tools are still local, right?

Yeah.

Background agents still haven't taken off in a meaningful way. Then what leaves the bottlenecks to be on the outer loops, which are team-based activities. So on upstream you have Jira Linear and you have Slack and Notion where you basically need to collaborate on what to build. And then downstream you have version control systems like GitHub, which is under too much tremendous stress right now, as you know. And you at Microsoft probably know all about that, right? So yeah, so the human review is— now we are moving from lower-level, um, understanding of code, the tank battle, to an air battle, right?

Right.

So you have to understand higher abstractions. At the same time, shift left a little bit, and you have to decide as a team what to build, describe your destination more accurately. Then these agents can run for longer. In fact, the longer they run, and if you don't describe the destination, they're almost always going to go off track.

Yeah.

Right. And, and those PRs never get merged.

Right.

So, so many pull requests getting opened and they don't get merged.

Yeah.

So there has to be some choke point upstream. There is no choke point right now. The only choke point we have is GitHub, which by the way, I feel is late. Like some— if once you bring in automations and triggers, like even agents opening PRs on each support ticket, You have too many of them, then the problem is not just automated reviews. You still have to triage and validate them.

Yeah.

So there has to be some choke point upstream, some sort of a repository of plans or prompts or has to exist. No one has got it right yet.

Right, right now. And everybody's experimenting. And this idea of because generating code is so easy and so fast, my experimentation earlier used to be let's plan more and we will build what we really want to. But now it can be we'll build 3 things and then we'll decide which one we should ship, right? What do you see? What do you think or see with your customers in terms of shifting into that type of thinking where building is so easy that let's just experiment with a lot more and then we'll decide which I do think there's, there's some problems with that approach because you still need— you've owned businesses, you know, you need to decide what you are going to build, right? What do you think about that type of thought process and thinking and where does it take us in terms of like, oh, here you basically dumped all of that into the review process?

No, it's interesting. Like, I mean, there are different degrees of I would say, AI automation in these code bases. Yeah, they're always going to be code bases which are touching real customers, are mature, and you won't be reckless. And we have seen like how AWS is now preventing engineers from being reckless with those agents because the outages can be crazy. And if you can understand, yeah, the changes, you shouldn't be introducing AI. So there's always going to be more of that. But then there are like some of the lower risk areas, especially around prototyping, as you mentioned, which is also like a Like it's kind of a golden age there. Now the PMs themselves are now becoming designers, right? They are able to quickly show a working prototype. You don't even have to— and you can always optimize the backend, scale it. Yeah, but getting to a quick prototype has removed so many barriers that you can actually see the ideas very quickly and even experiment them on the real world, whether it's going to stick or not. Like, and that's how the model labs are shipping. I mean, they are like having a very newsroom-style marketing on Twitter, like they're building public Yeah. And they're shipping every day. So the velocity on shipping has changed and the ideas at stake, that's the main thing, the learning. And then you can double down. The code itself has zero value now, right?

Yeah.

The other thing we have seen revolution is like internal tools. Like there was like so many things people wanted to do internally, never could find resources. Now people are stepping up and building amazing internal tools. Support team is building their own tools and sometimes those UIs would look even better than your main product, right?

It's amazing, right?

Yeah. Yeah. So it's It has generally removed the barrier where now multiple personas can now touch the code. Earlier they were like all on the periphery.

Yeah.

Guiding the engineers and all. Now everyone can contribute their own taste to the vision, to the idea.

Yeah.

And the how you run engineering team is, is, is getting evolved. Like even at Coda, I would, I would say we were running teams in a very different way 2 years back when it was an era of still tab completion was the fastest you could go. Go, right? In the last 12 months, it's just been amazing, right? I mean, you're going and having these agents, you're going from high-level prompt to large-scale changes.

Yeah.

And yeah, people— I mean, even I personally, I'm not in a code editor anymore for the first time in my life. Like, I've been coding, um, roughly 30 years now. Yeah, since '94, '95. And I would say this is the first time I'm not in a code editor, right?

What are you— what is your, um, tool of choice?

I love Codex desktop app. Yeah, that one I really love. I mean, this is the first time I've been able to stop using NeoVim. I was on NeoVim earlier, then I just jumped to Codex desktop app and yeah, I haven't looked back since. I've been like keeping it busy 24/7 pretty much.

And it's so fun to prototype and be able to like— you, I'm sure you're even launching features now and it's like I just built something. You talked about the engineering teams. I I talk to large organizations where they're worried about how we're going to structure our engineering teams over time because they're still early in, in the thinking. Would you share a little bit about how you've evolved the engineering team in the last— because you're at the, at the very top of like seeing these things very early. How have you evolved the CordRabbit engineering team to— with the use of AI? Yeah.

Yeah, I mean, it's evolved a lot. If you think about like now you're looking for the different kind of talent as well.

Yeah.

The talent which has, I would say, good taste. I mean, of course you still need some basic principles like around systems design and so on. So you could validate and ask the right questions, right, to the agent. I mean, I talk to the agent a lot. Like, I mean, sometimes you want to, in order to validate the work, you just talk to it. Yeah. But now you're looking at like more people can be part of the process. Now we're creating like pods, we call them like war rooms. Maybe put people like from product mindset, from design, engineering, even now some DevRel in the same room, um, so that multiple people can touch the product. Because when the PM is opening a pull request, they are like looking at their things, they want to like add a banner here or something. And designers like can go in and change the icons without talking to any engineer. Otherwise earlier there used to be like Figma mockups getting implemented. Now you can do it live.

Yeah.

So yeah, so, so multiple people are able to go and touch the artifact now, which is the code. And some people are good with systems design, will great do great distributed systems coding, right? And we will do a lot of distributed systems as well and, um, and, and hard stuff. Um, but also like the style is evolving, like things in the past which were like too hard. I mean, people were not investing a lot in Simulations or formal methods, right? Like we, for example, like recently we launched a Slack bot. We kind of explored using temporal logic of actions . So we modeled everything using AI, and then the code came. Wrote the code based on that once we could prove it's going to be correct software, right? Right. So yeah, so the style of engineering style has evolved. Now the things which used to be hard in the past are so easy. So why not do them? In fact, you need all those guardrails, right? In for AI to prove that it has done the right thing and how you run the marketing. I would say the bottlenecks have also shifted outside engineering, right?

Right.

Like our product velocity has exceeded our ability to talk about these products. That's why I'm saying like we started to embed DevRel into the same room as well, right?

You have to, because then they need to go out and talk about this right the day it comes out. When you think about the, the work and the bottlenecks shifting, Do you still think in the boundaries of— because I've heard very different views from very— from different companies and different people. Have you shifted the— just allowed more things to be done by the same individual because now they can do different things and more things beyond the scope of what they were able to do? Just like the PMs that you described, they can prototype and actually build a feature. Has that led to changing the team structure at all, or have you thought about the structure of the team, or is that fluid? I've seen organizations just experimenting with all of that, so I'm curious, what have you seen?

Some of these things have changed. Like earlier, like for example, ops, like people would in the past rely on another team to set up services or Terraform. Now, like, the developers are able to take things end to end much further. Even the PMs are able to take them Stuff like too much further along. Yeah. Yeah. So there are still some handoffs, but each individual is becoming more, more and more full stack.

Right.

And things they were also not doing in the past.

Yes.

Right. So, so that clearly is happening. Like ops is another area where we are seeing like a lot more people are now enabled with these agents. They can go to our— of course you have to put all the guardrails so that these agents don't like delete a database or something. But still, like, it's great. Yeah. How quickly or how much further the single person can now go and do.

So when you're hiring, you're looking at the ability to expand beyond what they have currently done. How are you hiring?

Yeah, I mean, one is like in the past, even location, let's talk about that. Like earlier, coding was a bottleneck. So you will go to all kinds of locations. As I said, like my second startup, even in Eastern Europe, India, because you wouldn't find all the talent you need in SF given the competition. The craziness. Now some of these constraints have gone away. Like now it's about product is the bottleneck, knowing what to build, right? So we are now increasingly hiring more local talent, for instance. And the other thing has been like in terms of the taste, like which is hard to measure. Like earlier I would interview people and look at how they work in a code editor, whether they know where they're comfortable with the tools. That kind of gives you a good hint on whether they've done work in large-scale code bases or not just by looking at how they operate. Um, sometimes we would in the past would have also done like one-day session, they build something and we see it. But now we don't know whether that's the skill we really need, right? Like some of the system knowledge, like they still have to like piece together a puzzle, like solve a murder mystery, because that's not the— they're debugging the code they haven't seen. Yeah, but they need to be able to ask the right questions or have the right hypotheses. That, that still is needed.

Yeah.

At the same time, taste, which is hard to describe. I mean, this is where you have to have people who really are passionate about something, which is like DevTools, for instance.

Yeah.

If you know, you really need to know that workflow in order to build it in the right way.

Yeah.

Like code reviews is one of them. I mean, the developers are very opinionated, a lot. So if you aren't a developer yourself, you have no business of building a product in this space. You can't.

You can't.

Yeah. And a lot of PMs we are hiring are also like coming from developer backgrounds only. The ones those are the kinds who are very successful. At the same time, the company building, like, is, is more than that. Like, one is the inward, but outside, like, PMs, if you look at it, we still need people who can go and talk to the world, right? Because that's not something AI has automated. Like, feedback is oxygen. So all that has to also come in.

Exactly. And then bringing, um, bringing all of that feedback, like, the people skills, like the relationships with the customers and all of that, it's still like—

Those are the real bottlenecks is what I would say. Like, now even a small engineering team which is highly skilled and has a breadth of knowledge of the taste, can keep a large sales force or a go-to-market team busy.

Yeah.

Unlike past. Yeah.

Yeah. So we didn't talk much about this, so I want to highlight a little bit of how CodeRabbit became CodeRabbit or got their early customers. Right. I think it was phenomenal developer relations mindset with open source as one of the front and center repos, right? So can you talk a little bit about— because I get a lot of questions about from founders, from AI startups where it's like, how do we get— how do we get customers, right? And, and this is, I think, a really classic and an amazing way of building a trusted base of people who want to talk about you, what CodeRabbit has done in this journey. So I'd love for you to shed a little bit of light on that.

There were many things and we continue to do many of those things still, right? And one of the things that was very clear in the early days of AI, not many people had experienced advanced models. Like tab completion was one way they were consuming, but we were always a reasoning-heavy system. So you had to see it to believe it.

Yeah.

And the idea at that time was how may— how we can get it into hands of as many people as possible. It was a, it was a habit change that we wanted to bring in the world, right? I mean, this was like no one was using AI in code reviews before CodeRabbit.

Yeah.

So, and it, and it was a very serious workflow, so it needed a new habit. So biggest thing was that like, and would people even like accept it? Because at that time people were trying to shove AI into everything and yeah, there's a lot of pushback, right? So one of the things we did really well is we made the product accessible to a lot of the open source maintainers. So we said, okay, like these people have a genuine pain point. They're doing a thankless job of— and I've like even like being an engineering leader, like we consume so many of these libraries and there's like— I even personally, I wanted to make a way of giving back. Yeah. So we made the product free for open source maintainers in the public repositories. That did 2 things for us really well. One was you could now see the product in action. So a lot of the developers in bigger companies who are not volunteering on the maintainer, but they're looking at the pull requests and all so they could see the product in action, see what it does, and then they want to bring it into their organization.

Visibility.

So the distribution. Yeah. So that whole flywheel around public open source repositories was a great strategy. The other thing we did really— I mean, other thing that it did for us is also improve the product very rapidly because public data you could see, unlike the private data. So we set up a feedback loop where we could see how people were using the product in open source and quickly improve the harness, which is all the context assembly And understand the effectiveness of our system, right?

Yeah.

The other thing we continue to do is like pricing innovation, right? So we are one of the few products which is trying to make this product very affordable, like so that everywhere, anyone in any kind of like developing nations and all, they can all like afford the product at the price point. Yeah. And which work hard, like there's a lot of engineering involved in keeping like a let's say flat price. for an agentic system, right? It's not a trivial problem.

Yeah, right.

So it took a lot of engineering to make sure that we are also able to not make it a very premium product we are selling at like, I know, hundreds of thousands of dollars per seat to larger enterprise only, right? Because traditionally, if you look at all the security scanning tools, they were like very expensive.

Yeah.

And going at top down, um, to the high-end market, and we wanted to be pervasive everywhere. Right now, CodeRabbit is installed on like 5 to 6 million repositories. Right. And we in fact recently crossed Snake in number of installs. So I'll compare with Snake because they kind of had similar insertion. Pricing-wise, we made it so affordable that we are everywhere.

Yeah, this is masterclass, right, in like how do you, how do you get the product to, to, to good level of adoption, right?

We set the ceiling. Even the competitors had to meet us at this price point. I mean, we kind of like gave a very hard problem to even the competition. And our own selves.

Yeah.

To make sure that we could meet the market at that same price point.

How do you sustain that though? Because if you— because as I understand it, you have— you're using the models, the foundational models, and then you're building on top of it. So you have to pay for all these. And these are not cheap models, right? So talk to me a little bit about like, how do you sustain that cost, that price, and the systems that are built around it.

Yeah, I mean, the magic is in the harness, right? I mean, if you're going to do a brute force way of just throwing the agents without a lot of bearing, they're going to like spend a lot of tokens just to understand which repository they are in and finding their way. So we invested a lot in— first of all, one of the very few companies which never let the user choose a model. Like think about back in 2023, every product had a chat interface and a dropdown to choose a model. We never had that.

Yeah.

So we were using always from day one using an ensemble of models, like a variety of like small models for like context assembly and then expensive models for reasoning. Right. And the other thing we did really well is around the code graphs and semantic analysis. Like how do you make sure that you're doing— giving the model enough context? Yeah. So they don't have to— they're not like flying blind, like you're giving them all the means to get to the answer very quickly. So we did spend a lot of time on the semantic analysis of the code, understanding basically the blast radius. Like, if you're gonna change a few files, how do I bring in the right definition or references and expand my— the fog of war a little bit to bring in the other context so that we have a good starting point what could be impacted, right?

Yeah.

The other thing we did really well, we were one of the very first agentic tools. Like, I mean, there was no term agent, there was no tool calling even. No, we predict even function calling, right? So we were doing sandboxes and running shell scripts in the sandbox to do code review. So we're generating code to do code review, getting a lot of evidence on whether the problem we are hypothesizing is even real.

Yeah.

And so back in 2023, we started doing subagents like there was GPT-4. I think GPT-3.5 was a subagent at that time. So we have always been like this, like a reasoning model and a lot of subagents underneath kind of an architecture, which of course has grown a lot. Now it's 8 or 10 different models now. But yeah, we did it very effectively and very cost-effectively as well. So a lot of engineering goes into making something fit into a flat price plan, which is very predictable while being so powerful. It wasn't trivial, right?

I can imagine. So if when you do a code review, let's walk through like a journey of a code review, I guess in this case, is CodeRabbit taking— let's say I said this particular PR, look at it and, and do a review on it, right? Do you— what happens as the first thing? Walk me through like the behind the scenes of like, are you taking the codebase, creating a sandbox? Take me through the journey.

Yeah. CodeRabbit is a background agent. So one of the very few products that doesn't need a human to remember to use it. So most of the products are chat-based. You go and talk to the agent and give it some work.

Yeah.

We were one of the first agents that just worked as soon as you open a pull request. There is no other human input, like it's a webhook.

Yeah.

That triggers an agent. The chat is more of a secondary feature. There's chat as well, but that's not the primary interface into CodeRabbit. As soon as we get a webhook, it's, it's a background agent system that of course runs a sandbox, clones your code, builds a code graph, which is live code graph. I mean, we Because the staleness is a real problem. So we do it live. Yeah, right. And that's also very efficient the way we built it. It's all like Rust code and all. Um, yeah. And then after that, um, we run a bunch of, uh, even some of the static analysis tool to ground the agent a little bit because there's like some low-hanging stuff like you're like have secret keys injected and all. Like we could scan some of this stuff. Um, the other thing we are doing is like a lot of the context preparation. So it's not like a single model call like there's, I know, variety of things which are like MapReduce-style workflows, like your like scatter-gather pattern, like you're going and parallelizing and then bringing the information together to get a bigger picture. So we do a lot of that, like, and the variety of models, even I kind of don't even know what's going on right there. A lot of people working on that project now. But that's the idea, like there's a lot of context preparation piece and then the reasoning models kick in. We try to make it as efficient as possible. Every token has a very high cost when it goes to reasoning models. So we want that context to be really relevant at that point, prune as much as we can. Yeah, like, because like the more context you throw to the reasoning model, the more off track they go.

Yes.

Right. So you have to be super sure that this is the right context that we need for the code review. And after that, it's never going to be enough. Yeah, because the code base is massive. So the reasoning models have an escape hatch to even go explore the code further, right? Like the surface level issues they can flag, but then they're like always issues that they, they feel could be an issue, but they need more evidence. And over there they can go and then run a bunch of the subagents, navigate the code, pretty much like fan out. And it takes a while for this whole pipeline to run, like 10 to 15 minutes typically.

Yeah. Which is why it's running in the background.

And it's almost like, like how you run CI/CD, you are waiting for your unit tests to run and complete. So you open up ER, you can go get a coffee or something, and by the time you're back, your unit tests are finished and you have a code review from AI. which is very high quality. It understands the intent and gives you very high quality feedback. And that feedback has been improving. Like, I mean, one of the things, like, of course the models get better, but secondly, our hardness has also been getting really good, right? In terms of like providing stronger and stronger evidence, the context assembly is getting more and more sophisticated.

Yeah.

Yeah.

So you talked about the open source and how it helped improve the product. What about the enterprise context? Because that has— that is always usually a challenge where it's like, oh, my enterprise. Like, there's lots of— there's lots of conversations I am in where it's like the code we have is unique, right? Which is, you know, true or true and not true in some scenarios and not— not in other scenarios. Right. How has the evolution of the product been, or the work on the product been to solve the uniqueness of enterprise codebase problem?

Yeah, we have a lot of enterprise customers, especially in the last year, like companies which are for like Fortune 500 and like even top like companies like with tens of thousands of developers, right? And some of them are like very legacy codebases, sometimes not even on Git platforms. You're talking about like Perforce. Yeah, right. And in those code bases, like one of the things we have done really well, like the how that system tunes over time. So one of the advantages we always had over every other tool out there, we were always a team-based product. So we built a global memory layer back in 2023 itself. At that time it was like Pinecone. Now we use something else, and where we are able to create learnings in global memory. Like, so each— like, the more developers who work in the product or the more developers that talk to it, the knowledge compounds over time. So the system really learns very quickly all the tribal knowledge or the quirks for the company, for the enterprise code. Yes. Okay. So in the complex code bases, like, the thing is that, okay, like, it's already a Step Function improvement when you adopt it, but over time you can actually tune it a lot by just talking to it. It's very natural. Like, and the second thing we do is like you can also explicitly provide instructions. So pass instructions, um, different ways of— there are many ways to tailor the system, right? Um, and it gets smart over time, almost becomes like a virtual teammate. So a lot of tuning happens based by just talking to it.

Just remember, the memory layer is taking care of that.

The nice thing is that each developer that contributes a memory helps everyone else, unlike a lot of the single-player tools that only remember your local conversations.

Yeah.

And get smarter only for you.

Yeah, that's exactly where I was going because this is such a critical piece of the puzzle in an enterprise where it's like there's a few developers who are doing an amazing job asking really great questions.

Right.

And that going— getting fed back into the enterprise context is—

That's where we had an advantage given the central nature of the tool. Also, like, think things like MCP servers, right? Like in Every tool, like going in manually, every developer has to go connect MCPs in the local Claude code or cursor, and everyone's doing it. Like you have 1,000 developers, they have to make 1,000 connections to, let's say, Datadog, right? In our case, like the admins will create MCP connection centrally once, and all your thousands of developers who open up ER benefit from that right away.

Yeah.

So it's much easy, like, to— like, given this is one of the very few background agents that have been successful, they haven't been successful in coding yet. Yeah, but at least for code reviews and how easy it is to like tailor the system for the entire org and the context. Yeah, those have been like big advantages and we have nothing to do with it. It's just our insertion point is central, right, that we benefit from it.

Is that also one of the reasons why adoption has been easier?

That's right, that's right. So in a way, like, this is not a product you can buy and then forget to use it or put it on a shelf.

Yeah.

If you're buying a product and launching it, everyone is made to go through it. So the adoption is always high.

Yeah.

Like every developer, every PR is reviewed by CodeRabbit. In fact, it's become so mission critical that people cannot ship software if we ever have even a small outage. Yeah. So we are as critical as GitHub at this point for, for a lot of these workflows.

Yeah. And an individual developer does not have to have a learning curve. For it?

Yeah, there is no— I mean, they don't even know it's there. Like, maybe if you're a first-time developer, like, you just open a PR and voilà, you have like a code review, right, done by AI. Yeah, but developers in general love the feedback. It's genuinely helped them like even uplevel their skills. Like, some of the things very interestingly here, like, AI is sometimes also like a great mentor, um, and like some of the tricks they never knew about the code. Yeah, but interestingly now no one's reading the code.

That's the other sad part. But it also helps, I think, down the lane when it goes to the senior developer for like the actual human review. If there's— if, if you need that for a critical piece of software that's going out, the time that they spend reviewing is also reduced because they know that, you know, parts of it as well.

We do 2 things for them. One of the things, they have some security that, okay, that AI has done a good job in finding low-hanging fruit so they can now focus on higher-level architectural questions. The other thing we have— we think it's like a really big deal and becoming even a bigger deal is explainability. So right now the outputs of AI have exceeded to a point that humans are not able to understand and comprehend. People are not reading the code, as I said, let alone now expect a reviewer to come and understand, right? So that explainability gap is widening day by day. Right, so now you need to bring in the tools that can now bring present the information in higher order abstraction, like more diagrammatic, more visual. Right, right. So that you can quickly build trust whether this is going in the right because the bugs, the nature of issues have evolved. Yeah. Like AI is not making the same mistakes like the human would. So it's not like they're silly, like missing error handling or try catch blocks. I mean, they're doing a good job.

Yeah.

But They are making mistakes at a larger level. Like the question is whether this thing is even needed or just right way, or is it too much repetition increasing the entropy of the code base? So you're talking about explainability. So we have like built a UI which is way better than what GitHub offers on the code reviews where you can understand things at the layer by layer. So you could understand the first layer I need to understand is like your schema changes went in, this is what it looks like. the next layer is you are now writing the business logic around it, then you are writing the API routes, then you build a UI. So just an idea like you can understand things like layers which speed up the code review. And then there are like a lot of diagrams like sequence diagrams and flowcharts to understand.

Yeah.

And build trust quickly.

What is the— it's— you have a lot of competition. What is your view on the evolution of this space and There's maybe let's start with like talking about what, what are the different types of companies in this space. So I can start by defining like there's like the no-code players, like the Lovables of the world, right? And the Bolt and others. And then there's in that case, like you really do not want to see the code. Like it's just you're building something and you just need to ship that. But the the pro-code developers. Like, you've got Cloud Code, you've got GitHub Copilot, and those, um, and then those are also evolving. Like you mentioned, Codex and those interfaces are evolving and all that. Um, but all these companies are working towards, um, getting to the end-to-end. So talk to me a little bit about, um, how you're thinking or what is keeping you up at like at night right now in terms of where do you want to take CodeRabbit?

That's a great question, right? I mean, one of the nice things is like, I'm happy we have competition given I've done startups where we had no competition, and that's the worst place to be, right?

Like, because nobody cares.

Yeah, nobody cares. Like, I mean, that was my second startup, right? So we had no competition. Actually, one company just started because we got funded like that, and I feel bad for them. I mean, wish they knew that we were not— we were also Struggling, right? So yeah, that was so funny, right? I mean, I mean, actually, if you have a space which have a lot of opportunity, yes, everyone will want a pie of it. I'm so happy to see larger players come in, smaller startups, and yeah, some of them are growing. But of course, we are like much further along, kind of seen as a gold standard. In fact, everyone compares to us and think about us when they want to do a bake-off, right? But competition is not a bad thing. It's first of all great. Yeah, for business, right? Um, the other thing we see is like how the space is gonna evolve. Like, I mean, we are seeing— I would say more than the competition, everyone, uh, when we go out, um, always has a question like, what is the future looking like? Is this workflow— would it even be there? That's the bigger question people have than the competition.

Yeah.

Because competition is easy. Like, you have the best product, people will always go for the best of breed. There's fragmentation. Like, it's not going to be one coding agent. Right. You can't grade your own homework. You need adversarial review. You need a clean context. You can't just ask the coding agent to go and check its work. It drifts too much. So you— and secondly, reviews have to be central. That's also very clear.

Right.

But the bigger question comes is like, are we going to see a complete disruption, singularity?

Yeah. Do we even need it in like 2 years?

If you look at Dario, like he comes up with a statement every other month and then investors are like just so uncertain, right?

Yeah.

I mean, I believe— I think that's a bigger question more than competition. I mean, we're not even worried about like given the products just been further along.

Yeah.

On all the dimensions that matter.

Yeah.

The other thing, the competition, the other thing has been just the space, right? I mean, I totally believe like some things are not future-proof. Like very clearly code editors are not future-proof, right? People are now been going into like CLIs. First time they moved out of code editor, now desktop apps, right?

Right.

So even VS Code was not future-proof.

No. Right.

And it's like self-driving. Even the steering wheel on a car is not future-proof, as you know.

Right.

But the 4 wheels on the car are. You still have to propel it somehow or drive, right? So code review, we believe some validation has to happen.

Yeah.

Right. Somewhere. Like now the question is, is it GitHub or somewhere else? But the choke point has to exist, right? You are not— if you are sending software to some real customers, you will need to at least look at it once and validate it before it goes out.

Right.

Right. So I think that—

And I think this is that point where—

Yeah, the code reviews have been, I think, more durable. I mean, if you, once the dust settles, I believe that this is where the value's gonna accrue. It's not very clear right now to a lot of people.

Yeah.

But I think everything else will keep changing. But this layer itself is going to be more and more valuable. In fact, most valuable layer in SDLC.

Right.

Right. And, Um, um, yeah, I mean, because this is a very clear choke point. Like, it's very hard to even do a choke point upstream. In fact, we are thinking about planning and all, but that workflow doesn't exist. Even Linear says that issue systems are dead.

Yeah.

So they, they've also even declared that that's not durable, right? Which I, I would disagree with them. Of course, their own company, they could say anything, right? But I think that some choke point has to exist upstream, but this one is definitely going to remain. Yeah, this is the final choke point before code merges and goes to production, right?

Yeah. And we can argue that, you know, the choke point earlier in the cycle could be that plan and requirements and like, what are we building? But even then, since the cost of building is so low, might as— maybe we build a lot more and that choke point is not necessary. Like you could build—

I mean, yeah, it's a new— yeah, that's going to be a new workflow. It's like a lot of garbage in, garbage out.

Exactly.

So once you have some of the background agents, let's say they take off, then you have hundreds of pull requests. to open, right? I mean, then also it's too much noise.

That's too much noise. Yeah. So we'll see a lot of changes in this space. But, but I agree with one of the key factors, which is anything that would go out needs to be looked at by a human at some point. And that point is somewhere closer to that, that code review stage.

I mean, even AI, like even it's risk management. Some things humans will look, some things they can say, okay, this is low risk. Let the AI decide whether it ships. But that Validation quality gate has to be still central, right? Right. Because just because people have different preferences, they are all picking different agents. So it's very hard to build consistency and everyone wants to do coding. Datadog wants to do coding, Postdoc wants to do coding, right? I mean, everyone's building coding agents. Yeah. So what the world we are living in is going to be more like, just like you can trust your developers to, let's say, unit tests is one example. You could run unit tests idly as a pre-merge hook. Yeah, but you will again run them in CI/CD. That never goes away. By the way, Datadog is another example. Like Kubernetes makes sure you don't crash, but it doesn't mean you take down your monitoring and your guardrails. So guardrails never go away.

Yeah.

So very likely this is a layer becomes more and more important even with a lot of autonomy. That validation layer will be standardized centrally no matter how you run the code, generate the code. Yeah, it will all go through this layer. The question is now, is GitHub going to remain that central choke point, which I believe is true? I think those issues they are facing are more temporary. Now everyone's trying to build a better GitHub, but it all actually looks like same as GitHub. So it's almost going to be Twitter versus Bluesky moment. So very hard like to move off a platform when every open source is there, all the ecosystem is there.

Yeah.

You can't just displace GitHub just because you have slightly better reliability or better performance. Yeah, I mean, it has to be something like a new workflow. Yeah, but assuming that GitHub remains, and I mean, that's going to remain as choke point.

Yeah, the workflow definitely seems like there'll be evolutions in that, more harness the loop engineering that we are seeing come around a lot more of, which all of that means there's just more code to manage. Yeah, it has to live somewhere.

That one thing is very clear. There is going to be a lot A lot more code to manage. None of these earlier techniques like stack pull requests. I mean, you bring— you have to bring in another AI. Like, the layers thing I'm saying is just kind of like stack pull requests without going through that workflow, right? Right. So you're going to talk about— you will naturally have PRs which are going to be bigger and bigger. Yeah, right. And then humans will need to move away from understanding lines of code to something else.

Structure of the, of the, of the application or architecture. Yeah.

But the code definitely is growing. I mean, especially some of the use cases where you don't need to provide a lot of input. For instance, like you're talking about translating something from like older language to newer, like taking your business application, the factors, even like adding another integration. If let's say you already have a GitHub integration, you want to add GitLab, it's so easy for these agents. So those kind of things have like we recently had a Slack bot I ran a goal for 40 hours to build a Discord version of it and it worked. So it's amazing. Like, I mean, some of these things you can just fire and forget and let the agent run in a loop validated against some goal. The other things you have to like steer, be on the steering wheel sometimes. And those experiences are still like very local on the developer's machine. So people are finding ways to like not let the laptop go to sleep or right, and they're like buying Mac Minis or something.

Yeah, it's exactly what I've done. It keeps running in the background. Is there anything else you want to talk about?

No, it's great. I mean, I think this has been at CodeRabbit like a ride of a lifetime. I've done a few startups, as you know. This one's been very clearly a very different animal. Like, in fact, I've done like multiple times fundraising this startup, and each time the story was so different because space moved so fast. Now I look back, 2 years back, we were like talking about different kind of concerns.

Yeah.

Right. It was like where the value is going to accrue. Now people understand the word harness. At that time we were trying to explain that, guys, the models are going to be a commodity end of the day, right? This was even before Anthropic was like, yeah, like this was like when the Sonnet 3 was not there. Yeah, we were talking about like the first fundraise back in '23, '24, right?

Yeah.

And the main thing was to explain that what's, what's going to be the model's value versus the applications on top.

You were already building harness for this.

Yeah. And we didn't know what to call it at that time. Yeah.

Yeah.

And then next day, I mean, so it's very interesting. And also the habits have evolved. Like, I mean, some of the things, as you know, have not been durable, but at least we have been in a space where it's been durable for us. Like, the tech moat we have has been compounding over time.

Yeah.

It's not like we had to go and remove everything we had and then find the PMF again in some other surface area.

Yes.

So for last 2 years, we've been building in this direction, and, and we've built a lot of tech in this direction, but it's not not disrupted yet.

Yes, it is about to and is like at the cusp of it, right? Like everybody's realizing this is where they need to focus. So perfect in that space. Is there any other product evolutions you're thinking about or focusing right on?

No, we are. I mean, in fact, like the reviews pretty much as a space, we believe we have cornered in a big way with the best product. almost becoming like kind of a Datadog in this space. Like, it's the best product if you don't want to waste your time DIY, then this is the best product you can just pick up.

Yeah.

Or you can fool around and come back. That's also happening.

That's also fine.

It's happening. We have seen that so many times. People try it, but then they give up and say, okay, let's just pick this up. Right. So now we're starting to like think about larger SDLC, like from a central vantage point, which is a unique position to be in, very hard to get into. let's say some customer's GitHub, right? Very few use cases get you access to that.

Yeah.

I mean, if you think about it, like Codex, for example, launched as a background agent a year and a half back.

Yeah.

Did not see success because people don't want to connect GitHub.

Yeah.

Unless it's mission critical, like code reviews or security or CI/CD, right? So they launched as a CLI and then desktop app. So we already have these many GitHub installs, which is crazy and And now the question is like, how can we make a jump from there to other collaborative surfaces like Jira, Linear? We don't think issue systems are dead, so we want to be in Jira and Linear. We also feel that we probably should be in Slack. We launched a Slack bot. So we started now extending our arms into other surfaces. And the whole idea of CodeRabbit is going to evolve from code reviews to being more collaborative AI for the teams, where reviews is one collaborative activity. that you're doing. Planning is another one. Incident response maybe is a third one. Like, so we're going after like those complex use cases, team-based use cases, because that's been our strength. Yeah, background agents, sandboxes, very efficient harnesses for those kind of use cases, team-based memories, and want to bring that into as many surfaces as we can.

Yeah, it's pretty exciting. Yeah, it is. Well, thank you so much for being with me, spending and sharing all the things that CoreDrivet is doing.

Thanks. Thanks, Priyanka. All right.

Thank you for watching. I am very excited for you all to drop your questions in the comments, and if there's any other guests you would like to hear from, let me know as well.