The New Battle In Software Engineering is Code Reviews

Coding used to be the slow part. Now with AI it’s the fastest part of the software development, and that’s the problem.

AI agents can spin up a working feature in minutes. But someone still has to look at what got shipped and decide: is this safe, is this right, does this actually do what we meant? That job hasn’t gotten any faster. If anything it’s gotten harder, because the code AI writes doesn’t fail the way human code fails. No missing try/catch blocks or sloppy null checks. The mistakes are architectural: unnecessary complexity, quiet duplication, changes that technically work but drift from what the system actually needed. You can’t catch that by skimming a diff.

So the bottleneck didn’t disappear when AI got good at writing code. It just moved. Straight into code review.

I sat down with Harjot Gill, co-founder and CEO of CodeRabbit, to dig into exactly this. Harjot’s been building in this gap since before “agent” was even a word people used, and the conversation ended up covering everything from pricing strategy to why GitHub isn’t going anywhere. Here’s the short version.

Watch the full episode on Youtube

Q: Why did you start CodeRabbit? Same rhyme, different verse. In his last startup (Netsil), the bottleneck moved from infrastructure to observability once cloud/Kubernetes made deploying easy. Now that AI has made writing code easy, the bottleneck has moved downstream to review and explainability.

Q: What does CodeRabbit actually do? It’s a background agent, not a chatbot. It fires on a GitHub webhook the moment a PR opens, no one has to remember to invoke it. It clones the repo, builds a live code graph, runs static analysis to ground itself, then fans out across an ensemble of models (small ones for context, expensive ones for reasoning) before returning a review in 10-15 minutes.

Q: Why not let users pick their own model? CodeRabbit never exposed a model picker, even back in 2023 when everyone did. Instead they invested in the harness: semantic code graphs, blast-radius analysis, and tight context pruning, so the expensive reasoning model only sees what actually matters.

Q: How did they get early traction? Free for open-source maintainers on public repos. That gave visibility (enterprise engineers watched it work on repos they already used), fed a feedback loop from real public data, and built trust before asking anyone to pay.

Q: How do they keep pricing flat despite expensive models? Heavy engineering investment specifically to make a flat, affordable price point possible at agentic-system scale, deliberately undercutting a market used to premium, per-seat security tooling.

Q: What’s changing in engineering teams? Roles are blending. PMs prototype and touch code directly. “Taste” and systems-thinking now matter more than raw coding speed. CodeRabbit runs cross-functional “war rooms” where product, design, and engineering all work in the same session.

Q: Will GitHub stay the center of gravity? Gill thinks yes. Every competitor trying to unseat it “ends up looking like GitHub.” He compares displacing it to Twitter vs. Bluesky: technically possible, but the ecosystem gravity is enormous.

Q: What’s the bigger threat than competition? Uncertainty about whether the whole review workflow survives disruption at all. Competing on quality is easy. The real question circulating the industry is whether some future model collapses the need for review entirely.

Q: Where’s CodeRabbit expanding next? Beyond reviews into Jira, Linear, and Slack; treating “collaborative AI for teams” as the bigger category, with code review as just one activity inside it.

What stuck with me most from this one: everyone’s chasing the coding agent, but Harjot’s betting the real value sits one layer downstream, in the choke point where humans still have to decide what’s actually safe to ship. Given how fast the space is moving, that might be the most durable bet on the board right now.

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

Harjot: Yeah, thanks for having me here, Priyanka. Thank you for sharing the CodeRabbit space and inviting me to the studio.

Priyanka: Thank you. But why don’t we start with just a little bit of an introduction of who you are and what is CodeRabbit?

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

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

Harjot: Yeah. So CodeRabbit has been dear to my heart, being an engineering leader as well as an entrepreneur in the space. This is my third startup. My first startup was a spin out from University of Pennsylvania, where you and I first met. I was a TA back almost a decade back. That company was called Netzil, and that was in the observability space. Netzil was “listen” spelled backwards, and at that time it was a very similar situation where cloud computing was taking off, all these orchestration systems like Kubernetes, microservices, Docker, and there was a lot of chaos. Humans were finding it hard to understand these fast-moving environments and a lot of the bottleneck shifted.

Priyanka: Yeah, like the second order effect, right?

Harjot: And now fast forward to now, right, where we are seeing the same situation. There’s a lot of chaos. The agents are creating massive amounts of code, and as a second order effect, explainability is becoming a bottleneck. As we say, history doesn’t repeat but it rhymes. For me it certainly does. When I saw the opportunity here I could just relate it back to my first startup.

Priyanka: Very interesting, from cloud to here in the AI space. And you’re so right, 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 is spent in reviews. So how did the idea come about, and from there to today, the journey of CodeRabbit and the evolution?

Harjot: Yeah, I mean this happened in my second startup, which I kind of missed talking about. So the first startup exited to 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 some of this webscale computing was taking off, but right around, it was during COVID, and right after that GPT-3.5 arrived, GPT-4 arrived. And the killer app at that point was GitHub Copilot, and there was no Cursor by the way. So GitHub Copilot type predates even ChatGPT. And as soon as I saw that, it was very clear to me that this is an inflection point, the entire world is going to change.

The bottleneck had been code reviews. Coding now the coding is getting automated, the reviews would certainly become the next bottleneck. And running the small team I could clearly see, we were a remote team because we started during COVID, so we had people in Eastern Europe, India, the US, Canada, bunch of places, and they were moving at a startup pace, shipping multiple times a day, and code reviews were already a pain. So we had automated a lot of our DevOps processes, static analysis tools, people were trying to open small PRs, doing stacked pull requests. We even had an internal tool we wrote, this was even before this Graphite company, Graphite had released a CLI, we got early access, but we also had our own tool doing similar stuff. That tool was helping with code reviews but it wasn’t fundamentally solving the problem, humans still had to understand the code changes. Having small changes makes sense but then you sometimes lose the bigger picture, so there were always trade-offs. But when AI arrived it was very clear everything is going to change. And that’s where CodeRabbit started.

It’s my other co-founder who started the company. I came on board after the second startup struggled to raise more capital in that space, where all the VCs lost interest. And we were lucky, we kind of attacked and saw this pain point before others realized it would hit them. Now two and a half years forward, it’s very clear that the biggest bottleneck in SDLC is now code reviews. Code generation is automatic.

Priyanka: It’s realizations now for a lot of the enterprises because the adoption has increased with AI now, but you saw the space before it even emerged, right, and it’s very likely a lot of the value in the agentic coding space is going to accrue in this bottleneck.

Harjot: Right. So code generation more and more is going to become commoditized, and even the models, you’re going to see open source models are inevitable. And even beyond a certain intelligence level, code generation doesn’t benefit. The two things that benefit are planning and reviews, which are more reasoning-heavy. But if you’re talking about just raw writing lines of code, even simpler open source models are doing a great job, as you’ve seen with Cursor Composer 2, may not be as great as Opus, but it’s really great at writing code. And you’re going to see more of that. So very likely the bottlenecks are going to be around two things. One is how do I automate some of these validation steps, and the second is explainability, because you still need to build trust in these outputs very quickly, to say hey is this all garbage fluff I could just close a PR, or is this something worth merging.

Priyanka: I’ve described this to people as, so we had a linear process of creation with planning and test development and testing, and now we are in the process, you beautifully said just now, where it seems like an hourglass, where coding itself is the smallest part of this hourglass, and then the planning and requirements gathering, there are tools 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 on this journey of yes our engineers are now starting to use AI coding tools, what do you see as the problem beyond the reviews? Where do you see the human element continuing to play a huge factor?

Harjot: It’s kind of a good balance. Some of the things AI is already better than humans at, when it comes to writing quality code or even finding issues in the code, but you still need explainability in terms of whether these changes make sense or not. Are they going to increase the entropy of my codebase? You want to understand the blast radius, whether core flows or some invariants have been rolled back, because you sometimes don’t know how your prompts ended up. 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. So I kind of see this more like a hamburger. The inner loop is automated, and that inner loop is also very much single player right now. Most of these coding agents are running on your local workstation. If you’re an IDE person you’re using Cursor, if you’re in the terminal you’re probably using Claude Code or Open Code, and if you’re using desktop apps, Codex desktop app is getting pretty popular. Different people have different preferences for these surfaces, but increasingly these tools are still local. Background agents still haven’t taken off in a meaningful way. Then what’s left as the bottleneck is on the outer loops, which are team-based activities. Upstream you have Jira, Linear, Slack, Notion, where you 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 at Microsoft probably know all about. So the human review is now moving from a lower-level understanding of code, the tank battle, to an air battle, you have to understand higher abstractions, at the same time shift left a little. 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, if you don’t describe the destination, they’re almost always going to go off track.

Priyanka: And those PRs never get merged. So many pull requests get opened and they don’t get merged.

Harjot: 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. Once you bring in automations and triggers, even agents opening PRs on each support ticket, then the problem is not just automated reviews, you still have to triage and validate them. So there has to be some choke point upstream, some sort of repository of plans or prompts, has to exist. No one has got it right yet.

Priyanka: No, and everybody’s experimenting, because generating code is so easy and 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 three things and then we’ll decide which one we should ship. What do you see or think 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 decide?

Harjot: I do think 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. There are different degrees of AI automation in these codebases. There are always going to be codebases touching real customers that are mature, and you won’t be reckless, we’ve seen how AWS is now preventing engineers from being reckless with those agents, because outages can be crazy, and if you can’t understand the changes you shouldn’t be introducing AI. So there’s always going to be more of that. But then there are lower-risk areas, especially around prototyping, which is kind of a golden age. Now PMs themselves are becoming designers, they can quickly show a working prototype, and you can always optimize the backend and scale it later. But getting to a quick prototype has removed so many barriers that you can actually see the ideas very quickly and even experiment with them in the real world, whether it’s going to stick or not. That’s how the model labs are shipping, they have a very newsroom-style marketing on Twitter, they’re building public and shipping every day. So yes, the velocity on shipping has changed, and the ideas that stick, that’s the main thing, the learning, and then you can double down. The code itself has zero value now. The other revolution we’ve seen is internal tools, there were so many things people wanted to do internally, never could find resources, now people are stepping up and building amazing internal tools, support teams are building their own tools, and sometimes those UIs look even better than your main product.

It has generally removed the barrier where now multiple personas can touch the code. Earlier they were all on the periphery guiding the engineers, now everyone can contribute their own taste to the vision, to the idea. And how you run an engineering team is getting evolved. Even at CodeRabbit we were running teams in a very different way two years back, when it was still tab completion. In the last 12 months it’s just been amazing, going from a high-level prompt to large-scale changes. Even I personally, I’m not in a code editor anymore, for the first time in my life. I’ve been coding roughly 30 years now, since ‘94, ‘95, and I would say this is the first time I’m not in a code editor.

Priyanka: Really? What is your tool of choice?

Harjot: I love the Codex desktop app. This is the first time I’ve been able to stop using Neovim. I was on Neovim earlier, then I just jumped to the Codex desktop app and I haven’t looked back since. I’ve been keeping it busy 24/7 pretty much, and it’s so fun to prototype.

Priyanka: You talked about the engineering teams, 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 the thinking. Would you share a little bit about how you’ve evolved the engineering team in the last, because you’re at the very top of seeing these things very early, how have you evolved the CodeRabbit engineering team with the use of AI?

Harjot: Yeah, it’s evolved a lot. You’re looking for a different kind of talent as well, talent which has good taste. Of course you still need some basic principles, systems design and so on, so you can validate and ask the right questions to the agent. I talk to the agent a lot, sometimes to validate the work you just talk to it. But now more people can be part of the process. Now we’re creating pods, we call them “war rooms,” we put people from product mindset, from design, engineering, even some DevRel in the same room, so multiple people can touch the product. When the PM is opening a pull request they’re looking at their things, they want to add a banner here or something, and designers can go and change icons without talking to any engineer. Otherwise earlier there used to be Figma mockups getting implemented, now you can do it live. 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 do great distributed systems coding, and we do a lot of distributed systems as well, hard stuff. But also the style is evolving, things in the past that were too hard, people were not investing a lot in simulations or formal methods, we for example recently launched a Slack bot, we explored using TLA, temporal logic of actions. 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. So the style of engineering has evolved, the things that used to be hard in the past are so easy, so why not do them, in fact you need all those guardrails for AI to prove it has done the right thing. And the bottlenecks have also shifted outside engineering, our product velocity has exceeded our ability to talk about these products. That’s why we started to embed devrel into the same room as well, because they need to go out and talk about this the day it comes out.

Priyanka: When you think about the work and the bottlenecks shifting, do you still think in the boundaries of, I’ve heard very different views from different companies and different people, have you just allowed more things to be done by the same individual, because now they can do different things beyond the scope of what they were able to do, like the PMs you described, they can prototype and actually build a feature? Has that led to changing the team structure at all, or is it fluid? I’m curious what you’ve seen.

Harjot: Some things have changed. Earlier, ops, people would rely on another team to set up services or Terraform, now developers are able to take things end to end much further, even PMs are able to take stuff much further along. So there are still some handoffs, but each individual is becoming more and more full stack in things they were also not doing in the past. Yes. So that clearly is happening, ops is another area where we’re seeing a lot more people enabled with these agents, they can go set things up. Of course you have to put all the guardrails so these agents don’t delete a database or something. But still it’s great, how quickly the single person can now go and do things.

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

Harjot: One thing is, in the past even location, let’s talk about that, earlier coding was a bottleneck, so you would go to all kinds of locations, my second startup even 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, now it’s about product being the bottleneck, knowing what to build, so we’re increasingly hiring more local talent for instance. The other thing has been the taste, which is hard to measure. Earlier I’d interview people and look at how they work in a code editor, whether they’re comfortable with the tools, that gives you a good hint on whether they’ve done work in large-scale codebases or not. Sometimes we’d do a one-day session where they build something and we see it, but now we don’t know if that’s the skill we really need. Some of the system knowledge, they still have to piece together a puzzle, solve a murder mystery, because they’re debugging code they haven’t seen, they need to be able to ask the right questions, have the right hypothesis, that’s still needed. At the same time, taste, which is hard to describe, you have to have people who are really passionate about something like dev tools, you need to know that workflow to build it in the right way. Code review is one of them, developers are a very opinionated lot, so if you aren’t a developer yourself you have no business building a product in this space. And a lot of PMs we’re hiring are also coming from developer backgrounds. Outside of that, you still need people who can go and talk to the world, because that’s not something that’s automated, feedback is oxygen, all that has to come in too, bringing the people skills, the relationships with customers, those are still the real bottlenecks. Now even a small, highly skilled engineering team with breadth of knowledge and taste can keep a large sales force or go-to-market busy, unlike in the past.

Priyanka: We didn’t talk much about this, so I want to highlight a little bit of how CodeRabbit became CodeRabbit, or got the early customers. I think it was a phenomenal DevRel mindset, with open source as one of the front-and-center repos. Can you talk about that? I get a lot of questions from founders of AI startups, how do we get customers, and this is a really classic and amazing way of building a trusted base of people who want to talk about you. What has CodeRabbit done in this journey?

Harjot: There were many things, and we continue to do many of them. One of the things that was very clear in the early days of AI, not many people had experienced advanced models, 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. And the idea at that time was how do we get it into the hands of as many people as possible. It was a habit change we wanted to bring to the world, this was a new, serious workflow, no one was using AI in code reviews before CodeRabbit, so it needed a new habit. The biggest thing was, when would people even accept it, because at that time people were trying to shove AI into everything and there was a lot of pushback. So one of the things we did really well is we made the product accessible to a lot of open source maintainers. We said, these people have a genuine pain point, they’re doing a thankless job, and even as an engineering leader I consume so many of these libraries, I wanted a way of giving back. So we made the product free for open source maintainers on public repositories. That did two things really well. One, you could now see the product in action, so a lot of developers at bigger companies, not maintainers themselves, but looking at the pull requests, could see the product in action, see what it does, and then want to bring it into their organization, that’s visibility, distribution. The other thing it did for us was improve the product very rapidly, because public data you could see, unlike 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, the context assembly, and understand the effectiveness of the system. The other thing we continue to do is pricing innovation. We’re one of the few products trying to make this very affordable, so anyone in any kind of developing nation can afford the product at the price point. We worked hard, there’s a lot of engineering involved in keeping a flat price for an agentic system, it’s not a trivial problem. It took a lot of engineering to make sure we’re not making it a very premium product, we’re not selling at hundreds of thousands of dollars per seat only to larger enterprise, because traditionally security scanning tools were very expensive, going top-down to the high-end market, and we wanted to be pervasive everywhere. Now installed on five to six million repositories, we recently crossed Snyk in number of installs. Pricing-wise, we made it so affordable that we are everywhere.

Priyanka: This is a masterclass in how you get the product to a good level of adoption. You set the ceiling, even the competitors had to meet you at this price point.

Harjot: Right, we kind of gave a very hard problem to even the competition and ourselves, to make sure we could meet the market at that same price point.

Priyanka: How do you sustain that though? Because as I understand it, you’re using the foundational models and building on top, and those aren’t cheap. Talk to me about how you sustain that cost, that price, and the systems built around it.

Harjot: The magic is in the harness. If you’re going to do a brute force way of just throwing agents without a lot of bearing, they’re going to spend a lot of tokens just understanding which repository they’re in and finding their way. So we invested a lot, first of all we’re one of the very few companies that never let the user choose a model. Think about back in 2023, every product had a chat interface with a dropdown to choose a model, we never had that. We were always using an ensemble of models from day one, small models for context assembly, expensive models for reasoning. The other thing we did really well is around code graphs and semantic analysis, how do you make sure you’re giving the model enough context, so they’re not flying blind, you’re giving them the means to get to the answer quickly. We spent a lot of time on semantic analysis of code understanding, the blast radius, if you’re going to change a few files, how do I bring in the right definitions or references, expand the fog of war a little to bring in other context, what could be impacted. The other thing we did really well, we were one of the very first agentic tools, there was no term “agent,” no tool calling, we predate function calling. We were doing sandboxes and running shell scripts in the sandbox to do code review, generating code to do code review, getting evidence on whether the problem we’re hypothesizing is even real. Back in 2023 we started doing sub-agents, GPT-4 I think, GPT-3.5 was a sub-agent at that time. So we’ve always had this reasoning model with a lot of sub-agents underneath, an architecture that’s grown a lot, eight or ten different models now. We did it very effectively and cost effectively. A lot of engineering goes into making something fit into a flat price point that’s predictable while being so powerful, it wasn’t trivial.

Priyanka: I can imagine. So when you do a code review, let’s walk through the journey. Let’s say I tell CodeRabbit, look at this particular PR and do a review on it. What happens first? Are you taking the codebase, creating a sandbox? Walk me through the behind the scenes.

Harjot: CodeRabbit is a background agent, one of the very few products that doesn’t need a human to remember to use it. Most products are chat-based, you go talk to the agent and give it work. We were one of the first agents that just worked as soon as you open a pull request, there’s no other human input, it’s a webhook that triggers an agent. 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 a background agent system that runs a sandbox, clones your code, builds a code graph, a live code graph, because staleness is a real problem, so we do it live, and it’s also very efficient the way we built it, all Rust code. Then we run a bunch of static analysis tools to ground the agent a little, some low-hanging stuff like secret keys injected. The other thing we’re doing is a lot of context preparation, it’s not a single model call, there’s a variety of things like map-reduce style workflows, scatter-gather patterns, parallelizing and then bringing information together to get a bigger picture. We do a lot of that, a variety of models, a lot of people working on that project now. There’s a lot of context preparation, 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 the reasoning model, so we want that context to be really relevant. Prune as much as we can, because the more context you throw at the reasoning model, the more off track they go. So you have to be sure this is the right context needed for the code review, and after that it’s never going to be enough, because the codebase is massive, so the reasoning models have an escape hatch to go explore the code further. Surface-level issues they can flag, but then there are issues they feel could be a problem but need more evidence, and they can go run a bunch of sub-agents, navigate the code, fan out. It takes a while for this whole pipeline to run, 10 to 15 minutes typically, which is why it’s running in the background, almost like how you run CI/CD, waiting for unit tests to run and complete. So you open up a PR, you can go get a coffee, and by the time you’re back you have a code review from AI, very high quality, it understands the intent and gives you very high-quality feedback. That feedback has been improving, the models get better, but our harness has also been getting really good in terms of providing stronger evidence, the context assembly getting more sophisticated.

Priyanka: You talked about open source and how it helped improve the product. What about the enterprise context, because that’s always a challenge, “our code is unique,” which is true and not true in different scenarios. How has the evolution of the product been to solve the uniqueness of the enterprise codebase problem?

Harjot: We have a lot of enterprise customers, especially in the last year, Fortune 500 companies, tens of thousands of developers, and some of them have very legacy codebases, sometimes not even on Git platforms, Perforce for example. One of the things we’ve done really well is how the system tunes over time. One of the advantages we always had over every other tool, we were always a team-based product. We built a global memory layer back in 2023 itself, at that time it was Pinecone, now we use something else, where we’re able to create learnings, a global memory, so the more developers who work in the product or talk to it, the knowledge compounds over time. The system learns very quickly all the tribal knowledge, the quirks for the enterprise code. So in complex codebases, it’s already a step function improvement when you adopt it, but over time you can actually tune it a lot just by talking to it, very natural. The second thing we do is you can also explicitly provide instructions, there are many ways to tailor the system. It gets smart over time, almost becomes like a virtual teammate. So a lot of tuning happens just by talking to it, the memory layer takes care of that. The nice thing is each developer who contributes a memory helps everyone else, unlike a lot of single-player tools that only remember your local conversations and get smarter only for you.

Priyanka: That’s exactly where I was going, because this is such a critical piece of the puzzle in an enterprise, where there are a few developers doing an amazing job asking really great questions, and that gets fed back into the enterprise context.

Harjot: That’s where we had an advantage given the central nature of the tool. Think about MCP servers, in every tool, every developer has to go manually connect MCPs in their local Cloud Code or Cursor, everyone’s doing it, you have a thousand developers, they have to make a thousand connections to let’s say Datadog. In our case, admins create MCP connections centrally once, and all your thousand developers who open a PR benefit right away. It’s much easier to tailor the system for the entire org and the context.

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

Harjot: That’s right. This is not a product you can buy and then forget to use, or put on a shelf. If you’re buying and launching it, everyone is made to go through it, so the adoption is always high. 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, we’re as critical as GitHub at this point for a lot of these workflows. An individual developer doesn’t have to have a learning curve for it, they don’t even know it’s there, maybe if you’re a first-time developer you just open a PR and voila, you have a code review by AI. But developers in general love the feedback, it’s generally helped them uplevel their skills, interestingly AI is sometimes also a great mentor, some tricks they never knew about the code, but interestingly now no one’s reading the code, that’s the other sad part. It also helps when it goes to the senior developer for the actual human review, if you need that for a critical piece of software going out, the time they spend reviewing is also reduced because they know parts of it have already been handled.

Priyanka: We do two things for them, one is they have some certainty AI has done a good job finding low-hanging faults, so they can focus on higher-level architectural questions. The other thing we think is a really big deal, and becoming an even bigger deal, is explainability. Right now the outputs of AI have exceeded a point that humans are able to understand and comprehend. People are not reading the code, let alone expect a reviewer to come and understand. So that explainability gap is widening day by day, now you need to bring in tools that present information in higher-order abstraction, more diagrammatic, more visual, so you can quickly build trust. Because the nature of issues has evolved, AI is not making the same mistakes a human would, it’s not like they’re silly, missing error handling or try/catch blocks, they’re doing a good job, but they’re making mistakes at a larger level, like whether this thing is even needed, or is it the right way, or is it too much repetition increasing the entropy of the codebase. So we’ve built a UI that’s way better than what GitHub offers on code reviews, where you can understand things layer by layer. First layer, understand your schema changes, this is what it looks like, next layer you’re writing the business logic around it, then the API routes, then you built a UI. Lots of diagrams, sequence diagrams and flowcharts to understand and build trust quickly.

Priyanka: You have a lot of competition, what’s your view on the evolution of this space? Let’s start with the different types of companies. There are the no-code players, the Lovables of the world, the Bolts, and others, where you really do not want to see the code, you’re just building something and need to ship it. Then there are the pro-code developers, Cloud Code, GitHub Copilot, Codex, and those interfaces are also evolving. All these companies are working towards getting to the end to end. What is keeping you up at night in terms of where you want to take CodeRabbit?

Harjot: That’s a great question. One of the nice things is I’m happy we have competition, given I’ve done startups with no competition, and that’s the worst place to be, because nobody cares. That was my second startup, we had no competition, actually one company started because we got funded, and I feel bad for them, wish they knew we were also struggling. If you have a space with a lot of opportunity, everyone wants a piece of it. I’m happy to see larger players come in, smaller startups, some of them are growing, but we’re much further along, kind of seen as the gold standard, everyone compares to us and thinks about us when they want to do a bake-off. Competition is not a bad thing, it’s great for business. The other thing we see is how the space is going to evolve, we’re seeing more than competition, everyone when we go out always has a question, what does the future look like, is this workflow even going to be there, that’s the bigger question people have than the competition. Because competition is easy, best product wins, there’s fragmentation, it’s not going to be one coding agent, you can’t create your own homework, you need adversarial review, you need a clean context, just ask the coding agent to go and check its work, it trusts its own diffs too much. And secondly, reviews have to be central, that’s also very clear. But the bigger question is, are we going to see complete disruption, singularity, how quickly, do we even need it in two years? Dario comes up with a statement every other month and investors are just so uncertain. I believe that’s a bigger question more than competition. We’re not even worried about that given the products are just further along on all the dimensions that matter. The other thing about competition, the space, some things are not future-proof, code editors are not future-proof, people are now going into CLI, first they moved out of code editors, now desktop apps, so even VS Code was not future-proof. It’s like the self-driving, the steering wheel on a car is not future-proof, but the four wheels are, you still have to propel it somehow, drive. So code review, we believe some validation has to happen somewhere, now the question is is it GitHub or somewhere else, but the choke point has to exist. If you’re sending software to real customers you will need to look at it once and validate it before it goes out. I think this is the point where, once the dust settles, I believe this is where the value is going to accrue, it’s not very clear right now to a lot of people, but everything else will keep changing, this layer itself is going to be more and more valuable, in fact the most valuable layer in SDLC. Because this is a very clear choke point, it’s very hard to even do a choke point upstream, in fact we are thinking about planning, but that workflow doesn’t exist, even Linear says issue systems are dead, they’ve declared that’s not durable, which I would disagree with, of course it’s their own company, they could say anything, but I think some choke point has to exist upstream, but this one is definitely going to remain, this is the final choke point, we code, merges, and goes to production.

Priyanka: And we can argue that the choke point earlier in the cycle could be plan and requirements, what are we building, but even then, since the cost of building is so low, maybe we build a lot more and that choke point isn’t necessary.

Harjot: That’s going to be a new workflow, it’s a lot of garbage in garbage out. Once you have some of the background agents take off, then you have hundreds of pull requests open, that’s too much noise. So we’ll see a lot of changes in the space, but I agree with one key factor, 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 code review stage. Even AI, it’s risk management, some things humans will look at, some things they can say this is low risk, let the AI decide whether it ships, but that validation quality gate has to be central. Because just because people have different preferences, they’re all picking different agents, it’s very hard to build consistency, and everyone wants to do coding, Datadog wants to do coding, Postgres wants to do coding, everyone’s building coding agents. So the world we’re living in is going to be more like, just like you trust your developers with, let’s say unit tests is one example, you could run unit tests idly as a pre-merge hook, but you’ll again run them in CI/CD, that never goes away. Datadog is another example, Kubernetes makes sure you don’t crash, but it doesn’t mean you take down your monitoring and guardrails. So guardrails never go away, very likely this layer becomes more and more important, even with a lot of autonomy, that validation layer will be standardized centrally, no matter how you run or generate the code, it will all go through this layer. The question is whether GitHub remains that central choke point, which I believe is true, I think those issues they’re facing are more temporary, everyone’s trying to build a better GitHub but it all actually looks the same as GitHub, it’s almost going to be a Twitter versus Bluesky moment, very hard to move off a platform when every open source project is there, all the ecosystem is there, you can’t just displace GitHub because you have slightly better reliability or performance, it has to be something like a new workflow. But assuming GitHub remains that choke point.

Priyanka: The workflow definitely seems like there’ll be evolutions, more harness, the loop engineering we’re seeing come around, a lot more of, all of that means there’s just more code to manage.

Harjot: Yeah, it has to live somewhere, that one thing is very clear, there’s going to be a lot more code to manage. None of these earlier techniques like stacked pull requests, I mean you have to bring in another AI, the layer I’m seeing is kind of like stacked pull requests without going through that workflow, so you’re going to naturally have PRs that are bigger and bigger, and then humans will need to move away from understanding lines of code to something else, structure of the application, architecture. But the code definitely is growing, especially some use cases where you don’t need to provide a lot of input, for instance translating something from an older language to a newer one, taking your business application, key factors, or adding another integration, if you already have a GitHub integration and want to add GitLab, it’s so easy for these agents. We recently had a Slack bot, I ran a goal for 40 hours to build a Discord version of it, and it worked. It’s amazing, some of these things you can just fire and forget, let the agent run in a loop validated against some goal. Other things you have to steer, be on the steering wheel sometimes, and those experiences are still very local, on the developer’s machine, people are finding ways to not let the laptop go to sleep, buying a Mac or something.

Priyanka: Exactly what I’ve done, it keeps running in the background. Is there anything else you want to talk about?

Harjot: No, it’s great. I think this has been, at CodeRabbit, a ride of a lifetime. I’ve done a few startups as you know, this one’s clearly been a very different animal, I’ve done fundraising multiple times for this startup, and each time the story was so different because the space moved so fast. Two years back we were talking about different kinds of concerns, 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, this was even before Anthropic was, when Sonnet 3 wasn’t there.

Priyanka: We’re talking about the first fundraise back in ‘23, ‘24, right?

Harjot: Yeah. And the main thing was to explain what’s going to be the model’s value versus the applications on top. You were already building a harness for this, and we didn’t know what to call it at that time. It’s very interesting, and also the habits have evolved, some of the things haven’t been durable, but at least we’ve been in a space where it’s been durable for us, the tech we’ve built has been compounding over time. It’s not like we had to go remove everything and find PMF again in some other surface area. For the last two years we’ve been building in this direction, we built a lot of tech in this direction, but it’s not disrupted yet, it is about to, and is at the cusp of it, everybody’s realizing this is where they need to focus.

Priyanka: Perfect, in that space, is there any other product evolution you’re thinking about or focusing on right now?

Harjot: In fact, reviews as a space we believe we’ve cornered in a big way with the best product, almost like a Datadog in this space, it’s the best product, if you don’t want to waste your time DIY-ing, this is the best product you can just pick up, or you can fool around and come back, that’s also happening, that’s also fine, we’ve seen that so many times, people try but then give up and say okay let’s just pick this up. So now we’re starting to think about the larger SDLC, from a central vantage point, which is a unique position to be in, very hard to get into, let’s say customers’ GitHub, very few use cases get you access to that. If you think about it, Codex for example launched as a background agent a year and a half back, did not see success, because people don’t want to connect GitHub unless it’s mission critical, like code reviews or security or CI/CD, so they launched as a CLI and then desktop app. We already have these many GitHub installs, which is crazy, and now the question is how can we make a jump from there to other collaborative services like Jira and Linear, we don’t think issue systems are dead, so we want to be in Jira and Linear, we also feel we probably should be in Slack, we launched a Slack bot, so we’re now extending our arms into other surfaces. The whole idea of CodeRabbit is going to evolve from code reviews to being more collaborative AI for teams, where reviews is one collaborative activity you’re doing, planning is another one, incident response maybe is the third one. We’re going after those complex, team-based use cases, because that’s been our strength, background agent sandboxes, very efficient harnesses for those kinds of use cases, team-based memories, and we want to bring that into as many surfaces as we can.

Priyanka: Yeah, it’s pretty exciting. Thank you so much for being with me, spending time and sharing all the things CodeRabbit is doing.

Harjot: Thanks. Thanks, Priyanka.

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.