00:00:00:00 - 00:00:14:08
Speaker 1
The most impactful thing in 2025 is going to be the birth of vibe coding. Just the idea has really dictated a lot of what happened within it throughout 2025. I have a love hate relationship with this term. It was a promise ahead of its time.

00:00:14:09 - 00:00:18:00
Speaker 2
Where do you think the tooling will move in 2026 from there?

00:00:18:02 - 00:00:21:22
Speaker 1
What I think they did right is they gave engineers what they wanted in the moment that they wanted.

00:00:21:22 - 00:00:27:10
Speaker 2
And it proved to the ecosystem that you don't necessarily need a better model to get better outcomes.

00:00:27:12 - 00:00:44:16
Speaker 1
The context is King has to be on par with the idea. If a human was to do this task, what information would they require in order to do the job?

00:00:44:18 - 00:01:03:10
Speaker 2
Welcome everyone to the first ever, Code Rabbit podcast episode recorded here, right from our San Francisco office. My name is Hendrik. I'm the developer advocate s code rabbit, and I'm super excited because today I'm going to be joined by David, our VP of AI. Hey, David. Hi. Thanks for taking the time today. Yeah.

00:01:03:10 - 00:01:04:07
Speaker 1
No worries.

00:01:04:09 - 00:01:28:10
Speaker 2
Awesome. Well, it is January 2026, and I think, there's no timelier moment then to have a little, review of the crazy year and 25 that has been for AI coding for code review and, yeah, make some predictions on what 26 might look like based on that. So, obviously, David, you have a lot of opinions on that.

00:01:28:13 - 00:01:52:10
Speaker 2
Yeah. So I'm super grateful to have you here. I think I want to start, with, you know, chronologically going through it a little bit, one moment, that kind of, at least for you, not only, the build the community, but also the, the global politics and economics was quite impactful. Was the deep seek at one moment that was kind of sending a shockwave through, you know, the world.

00:01:52:10 - 00:02:03:14
Speaker 2
And, my question to you is, can you share a little bit about what, you know, changed from your perspective? In terms of, you know, open models and the work that they did for all of us?

00:02:03:20 - 00:02:23:05
Speaker 1
I think you could look at it from two perspectives. One was the model itself, and people using that model. And there was a lot of obviously, heightened level of interest suddenly in that model and, and ultimately finally realizing that there are teams outside the US that are building sort of very impactful open models. Right? And so there's the model itself.

00:02:23:05 - 00:02:47:18
Speaker 1
And ultimately, you know, models change constantly and the ability to make better and better models every single month, pretty much there's like a new model in some level, either it's open source or a proprietary model that that moves past where it was previously. But this was a big moment in a different way for me. From my perspective, that model sort of opened up, the possibility of what an open model could do for a budget.

00:02:47:21 - 00:03:09:19
Speaker 1
Right. So previously we thought in order to make a model that had any, capabilities even close to OpenAI or anthropic models, you had you needed a tremendous budget, you needed immense resources. Their technique, and just the way that they viewed the problem and trying to think of it more from an optimization perspective, that opened up the possibility in a lot of in a lot of other people's minds.

00:03:09:20 - 00:03:37:15
Speaker 1
Now you have people engaging in the idea of creating more open models that are more capable. Who previously would have thought, that's impossible, I don't I can't possibly do that. And so I think that for me is going to be probably the lasting impact that that model will have going forward. And I'm hoping we'll see more of those in the future where another brand new idea comes out and suddenly, again, things shift and we can imagine open models going even further and coming even closer to the best proprietary models.

00:03:37:17 - 00:03:45:03
Speaker 2
Yeah, talking even more about impact, like, what do you think? How did that force, for example, close model providers to, to react to that?

00:03:45:09 - 00:04:07:23
Speaker 1
So I think there was this notion that they were untouchable, right? That no matter what you did, OpenAI anthropic, you know, meta to a certain degree as well. And, and Google, they're going to be the main purveyors of LMS and the ability to engage with, AI on some level right now, generative AI especially, I think that opened up a crack.

00:04:08:00 - 00:04:30:09
Speaker 1
Right? So everybody's perspective suddenly shifted like, oh, it's not necessarily just going to beat them. And again, I think from their perspective, that's like a code red kind of thing to use Sam, all this term or anyone else's. But that's put a little fear into that. Right? So to a certain degree that can be good. Right? So if you want to spur innovation, if you want to make sure that things suddenly move forward, competition is good.

00:04:30:09 - 00:04:48:13
Speaker 1
And so that opens up a lot of potential competition. So again, that momentum, the idea of I need to make sure I'm doing things in an efficient way, not just a way that just pours money into a problem. I think it's a good thing. It ultimately either way, whether you believe that OpenAI is going to win or not, it's going to, you know, move things forward.

00:04:48:15 - 00:05:12:17
Speaker 2
Yeah. No, I'm super excited about, the innovation that we're going to see in that space coming down the line in 26. Moving on to February 25th, there was Andrej Karpathy, popularizing this term, vibe coding, which became super mainstream. Can you maybe give you opinion on why that spread so quickly, why was such a fitting term, and maybe also give an opinion on how that impacted Code rabbit as a company.

00:05:12:19 - 00:05:41:08
Speaker 1
I have a love hate relationship with this term. Ultimately, you know, it's catchy, right? So I can see why it goes viral. And I think the other reason why it goes viral is because the notion of coding without looking at code, what does that do? Right. It doesn't do a lot necessarily for an engineer necessarily, but it does a lot for people who have ideas, who don't know engineering and have never built a program in their life, but they have this cool idea and they want to do something, and that's what it unlocks, right?

00:05:41:08 - 00:06:01:23
Speaker 1
So that's why that I think that term takes off. That's why it gains virality. Because it it it helps people identify with the idea of building something without having to be an engineer. And so that that speaks to way more people. So obviously that's I think the main potential there. And it comes with a lot of caveats. Right.

00:06:02:00 - 00:06:22:13
Speaker 1
It was a promise ahead of its time. It's the it's the idea of it, not the reality isn't there yet. And so that's why, you know, when you're talking about how does it impact code rabbit vibe coding or the idea of coding without necessarily looking at the code itself, opens up a world of errors. You know, a whole new world of bugs.

00:06:22:13 - 00:06:43:04
Speaker 1
And we just released a report recently, right? That looking at the data of how many bugs are generated by these systems, the density of those bugs per line of code is just much, much higher. Like, sometimes three x, the amount of bugs, depending on the type of bug in question. Right. And so obviously that's good for us in a certain sense.

00:06:43:09 - 00:06:59:00
Speaker 1
You need something like Code Rabbit when you're generating so much code, especially again for the for the group that this really applies to, which is people who don't know engineering, if they want to build something and they want to release it, they're also not going to know how to evaluate that code and check it for all these little issues.

00:06:59:00 - 00:07:03:18
Speaker 1
And so Code Rabbit is going to become more and more of a necessity over time.

00:07:03:20 - 00:07:23:17
Speaker 2
Yeah. No. Great. Thanks for for putting that into perspective. March madness I was kind of another viral moment that I, I remember very vividly trying that as, like one of the first long running agents that really was doing something different in the sense that it proved the, ecosystem, that you don't necessarily need a better model to get better outcomes.

00:07:23:17 - 00:07:33:06
Speaker 2
But this term of context engineering, became a big rise. And I think there's a big parallel to what we do here at Code Rabbit. So can you give us like an a picture of you?

00:07:33:06 - 00:07:53:21
Speaker 1
So you think about few shot learning as sort of a degree of context enrichment. Right. So I have a task. And this notion existed and was well studied. Right. If I give the model examples of input output of behavior that I want and I give it a new example, it's going to do much better than if I just gave that example directly.

00:07:53:23 - 00:08:16:17
Speaker 1
And people had just studied this very, very thoroughly. It's not much of a leap from there, but it's still an interesting, conceptual leap. Right? The idea that now, instead of giving a prompt, the few short examples, I'm going to dynamically figure out the context requirements for a task. Right. And make sure that that context is appropriate and optimal for that particular task.

00:08:16:17 - 00:08:40:17
Speaker 1
And then the model is going to it's similar again to the few shot learning. I'm going to give it what it needs to answer the question accurately. And so then it you're relying less on the model's pre-trained knowledge, and you're leveraging more its ability to think and to reason into to extrapolate information based on what it knows. And so that's I think, where again, you're talking about tipping points, this idea of like, how do I leverage that then?

00:08:40:17 - 00:09:01:11
Speaker 1
And so man did a very interesting job. And again, the long running agent side of things that this idea of, I don't need one monolithic prompt that just does a huge amount of work. I want to make sure each system knows exactly what it's supposed to do, has exactly the context necessary, so I don't blow the context window, have it accomplish these smaller tasks, and then accumulate them at a long running task.

00:09:01:11 - 00:09:23:12
Speaker 1
And so that idea against a very interesting idea, right, has a lot of consequences downstream. We use these concepts internally a code rabbit. And and to your point context engineering. Just as a general framework is pretty much the job, right? I mean, the job of coder view even even looking code generation. But let's stick a code review. The context is king.

00:09:23:12 - 00:09:48:11
Speaker 1
If I ask a human to review a PR at a company they've never worked for, and don't allow them to explore the code base, to look at documentation, to look at anything, that review is not going to be able to just to sort of rise to the occasion and actually do a thorough job. And at the level of a senior or a principal level engineer to make sure that that code is really, you know, up to standards.

00:09:48:12 - 00:10:10:14
Speaker 1
And so the context that you have to provide to the lab has to be on par with the idea of if a human was to do this task, what information would they require in order to do the job? And that's, that's a tricky problem. And ultimately it's dynamic, right? It changes all the time. And the question becomes like, do you do it all in one go, or do you do it in piecemeal where every single type of thing?

00:10:10:14 - 00:10:37:03
Speaker 1
I need to build a different context to accomplish that task. And so you really have to think of the problem holistically from the perspective of how would I do this? And then which parts of this can I then automate and can I leverage. Right. And I can ultimately do an even better job because it doesn't get bored, doesn't lose concentration, it hasn't had too little sleep and can't can't sort of operate at the same, level it was yesterday.

00:10:37:07 - 00:10:51:20
Speaker 1
And so in a way, if you can figure that out, what information is required and if you can figure out the optimization problem, then you unlock something. It's not just human level, it actually will exceed what humans are capable of in that regard.

00:10:51:22 - 00:10:52:12
Speaker 2
It's difficult.

00:10:52:17 - 00:11:06:10
Speaker 1
Well, it's extremely difficult. It's a challenging problem. It's ever changing. Models come out all the time, and you have to constantly be on top of all of this. And and you're constantly evolving and making sure that you're getting that, that, that optimization problem right.

00:11:06:12 - 00:11:31:04
Speaker 2
Yeah. Taking that tangent and talking about more, interesting agents, you already touched briefly on on coding agents leaping a little bit forward into May 25th. We had the rise of Codex and Cloud Code, obviously, gaining a lot of popularity. So what was the command line becoming such a crucial battleground for coding agents, and how did it change how, you know, developers using, building, tools these days?

00:11:31:06 - 00:11:52:10
Speaker 1
So I don't know that it was, strictly speaking, just the command line. I feel like it was the ability to step outside this interface that sort of is constraining in a way. The idea is really, really as interactive viewpoint into into what coding was. Right? It's it's an engineering problem. You have the code there, you're iterating on the code.

00:11:52:12 - 00:12:16:10
Speaker 1
And so it makes sense as an initial foray into generative AI and coding, that you would stay there because that's that's sort of one step away from where you currently are. But the idea I think of the CLI being a thing is you're interacting with it more. Again, at a more human level. You're just talking to it. You're abstracting the idea that the code exists away, you're still aware of it, but you're less aware of it than you would be before.

00:12:16:12 - 00:12:36:22
Speaker 1
And so I think cloud code, the way that they did it ultimately is like one of those moments again of like, oh, this, this makes a lot more sense for a lot of people. It's if I don't want to look at the code, I'm doing this vibe coding thing. If I'm investing in this idea that I want to have five windows open, all sort of making different things and working in different problems, I can't do that in the idea.

00:12:37:00 - 00:12:53:17
Speaker 1
It shouldn't live in the IDE that, but that would be somewhat cumbersome within the IDE. So this this idea of using the CLI, I mean, this goes back to terminal days and things like this that people are very familiar with the CLI engineers are very familiar, so it's not too far away from sort of what we're used to.

00:12:53:23 - 00:13:18:21
Speaker 1
And at the same time, it gives us a lot more freedom. The system can now run commands. It makes sense to me why it's there and all this stuff. Right? I still think that Cloud Code was like a massive turning point in the vibe coding ecosystem because of that interface, the idea and codex, ultimately, again, this idea of of open AI, anthropic Google like Google has now their, their, their agent system again, which is kind of like an IDE.

00:13:18:23 - 00:13:32:20
Speaker 1
The idea behind leveraging Lmms to generate code is just something that makes, makes a lot of sense. And at the end of the day, provides a lot of immediate value. And so I can see why these things sort of took off.

00:13:32:22 - 00:13:35:20
Speaker 2
What do you think is the implication for code review them?

00:13:35:22 - 00:13:48:15
Speaker 1
So I think it brings code review into the idea of like, can I again, if I have my terminal is open and I have all these things going, can I have code review be automatically run as part of this process? And the agent again is just sitting there in the background consuming that review and then acting on it.

00:13:48:15 - 00:14:03:00
Speaker 1
Right. And so we have our own CLI. So as a result, you know we see we see people want this. They want the ability to code in the CLI platform. And so it makes sense then that you bring review into that as well.

00:14:03:02 - 00:14:22:19
Speaker 2
Actually taking taking the same topic a bit further, I mean just shortly after that Codex and Cloud code moment, we had, you know, the summer furlough with windsurf and AI and, and all that. I'm not getting into the politics here, but just thinking about it seems like Windsurf and Corsair and these other ideas, they do have a place in AI coding as well.

00:14:22:19 - 00:14:29:16
Speaker 2
What did they do especially right. And where do you think? The, the dev tooling will move in 2026 from there?

00:14:29:21 - 00:14:47:09
Speaker 1
What I think they did right is they gave engineers what they wanted in the moment that they wanted it. Right. So again, again, labs are really great at coding. There's a lot of data. So they're really good at the idea of tab completion. Right. Existed previously. You're just making it much more effective. And so the market, so to speak, already exists.

00:14:47:09 - 00:15:06:02
Speaker 1
You're bringing something to people that are already there. And so bringing it to that makes a lot of sense. And I think bringing that technology to engineers first is the right way to go. And that's why they're super successful. There are a ton of engineers. This also makes them extremely more productive than they were previously. They're able to accomplish a lot more.

00:15:06:07 - 00:15:29:18
Speaker 1
They're able to evaluate code a lot faster. There's a lot less just mundane boilerplate work they need to do. There's just so many benefits to these IDE tools. Right. And so I can see why everybody likes using this to one degree or another. I still not sure, 100% convinced that we have reached the ultimate interface when it comes to what it looks like in the vibe coding world.

00:15:29:23 - 00:15:47:06
Speaker 1
If I just take a step out of the the engineering mindset, which I think is going to live in the IDE still for quite some time, because I was listening to, I think it was Elon Musk talking about the fact that momentum, the inertia and the momentum that we have is very strong for any kind of system. So engineers exist in the IDE.

00:15:47:08 - 00:16:12:14
Speaker 1
I don't think that's going to go away anytime soon. And so the need for systems to still be in there in that environment is going to exist. The CLI again, engineers are used to being in CLI. So I guess that interface makes a lot of sense. I don't know that we've come up with that moment of like the iPhone moment of like this brand new thing, this brand new interface that fits perfectly with the moment of a vibe coding kind of ecosystem.

00:16:12:16 - 00:16:29:11
Speaker 1
There are other ones, right? There's there's like lovable in the way that they do things. And there's other, interfaces for modifying UI code where you click on an item and then you type in what you want to change to. So there's a lot of imagination that still hasn't fully come to fruition when it comes to what does this look like?

00:16:29:11 - 00:16:41:19
Speaker 1
In the ideal case, I don't know what that is. I'm excited to see what people come up with over time. But I think from an engineer's perspective cursor, windsurf, the IDE, the CLI, it makes perfect sense to me.

00:16:41:21 - 00:17:03:07
Speaker 2
Okay, okay. Interesting. Because, I mean then October cloud for the web launched and then all of a sudden you were seeing people demos. I remember going to that beacon and there was like a big demo, of like somebody calling their agent to, like, complete a ticket. So what do you see this type of def workflow. So I think that's a very interesting questions evolve into 2026.

00:17:03:07 - 00:17:13:04
Speaker 2
Are we. You know I'll just going to use send century logs to Claude weapon. And they're going to completed this that where the dev tool flow is going. And where does code review fit into that as well?

00:17:13:07 - 00:17:28:16
Speaker 1
I think the web version is again a step into what is the ideal interface look like. Right. And I'm not sure that that's it yet. I don't know if the adoption rate has indicated that we've reached again, that moment. I think it makes again like to your point, accessibility higher. Right? I don't need to be on my computer.

00:17:28:16 - 00:17:43:14
Speaker 1
I don't need to be my in my ID or have access to a command line interface. I just send a notification out. Potentially the thing just starts going. And so that's a really cool idea, right? So how do I make that make sense. So in a certain sense I can look at logs. I can maybe hook things up.

00:17:43:14 - 00:18:05:07
Speaker 1
That way. It opens up possibilities. I do think the idea of where do I see that going is, is into the realm of as these systems get better and better, more and more things happen in the background, rather than me having five terminals open with five different things working, I just basically spawn up a bunch of jobs and I just walk away and it's accessible from anywhere.

00:18:05:07 - 00:18:11:14
Speaker 1
I don't need to be at my computer. I can go to a different computer in the same jobs or running and and so that makes a lot of sense.

00:18:11:14 - 00:18:13:03
Speaker 2
Sounds like a dream.

00:18:13:05 - 00:18:30:07
Speaker 1
Yeah. I mean, to a degree. Right. If, if at the end of that, all five of those things are perfectly done code reviews it, everything goes perfectly smoothly and you integrate them in. That's that's great. And I do think we will get there. I still think there's for people who are not engineers. The question is going to be like, how do they evaluate that?

00:18:30:12 - 00:18:49:20
Speaker 1
How do they iterate on that? What does exactly that look like? Right. Because to a degree, you can think of the progression of engineering over time, right? So this idea that the English language is somewhat imperfect, imprecise, I should say. And so what do we do? We build something that accepts machine codes because we're being very precise and that's too hard.

00:18:49:20 - 00:19:19:03
Speaker 1
So we build, you know, punch cards and that's that's too difficult. So we build languages, right? We build higher and higher order languages to accomplish more. And more complex task in a very precise way. That's very, very, defined, right and very constrained. And so we're going backwards in a certain sense. We're going to English language. So in order to be able to, to evaluate that system and make, you know, iterations on it, I need to then look at what I, what exactly what I prescribed and be able to figure out exactly where it may have gone wrong.

00:19:19:09 - 00:19:34:09
Speaker 1
And so there's going to be some, some of think systems that might go into, okay, I'm no longer debugging code now I need to debug and sort of review my prompts that go into the system. How did it go wrong? Why did it go wrong. So there's something else in there. I think at a certain point that's going need to come out.

00:19:34:14 - 00:19:59:09
Speaker 2
Yeah, that's a very interesting topic. I'd love to dive into more. I mean, this entire day of tracing and all the entire evolution of prompt engineering is, for another episode. Yeah. November. Google Gemini, launched a Gemini three. And, I think that really took a lot of leaderboard with the storm. So can you shed a little bit of light about what's what's special about it, you know, what is it good at?

00:19:59:09 - 00:20:10:04
Speaker 2
Where where maybe it's vulnerable against, some of the other frontier models and, how does it rank maybe also for our proprietary code rarity vaults that we have here.

00:20:10:06 - 00:20:30:08
Speaker 1
Yeah. So I think Gemini three was the first one that I was like, okay, Google's back in the race at this particular point. You know, the benchmarking systems across the board, like you can obviously, over emphasize on them. And like the question for me is always, how does it behave in the 90% use case of most people's day to day lives when they're building software?

00:20:30:10 - 00:20:49:01
Speaker 1
And I think you've seen the response to that being very positive. So you can see that Google's managed to chip into the market, of where cloud code and cursor have have existed. Right. And I never really doubted that Google would eventually get there. I was a little surprised it took them that length of time. But in our own benchmarks, Gemini three performs extremely well, right?

00:20:49:03 - 00:21:07:01
Speaker 1
It's it's reasoning ability, its ability to follow instructions. It's the ability to, have multi-hop reasoning where it has if this, if then this, maybe, and then this and this, and then finally, this is the answer that had been lacking. If you look at Gemini 2.5 and previous versions, a lot of that just failed in our system.

00:21:07:03 - 00:21:35:04
Speaker 1
And so it really didn't, wasn't a viable option when it came to, for us for code review, for really, getting at those hard to find problems, concurrency issues, memory leaks, things that even humans have a hard time reasoning through. Sometimes across especially across larger code bases. And so, yeah, I'm really I'm really pleased to see that we have another, again, another competitor in this space, hopefully again, driving more innovation towards solving these really, interesting problems.

00:21:35:10 - 00:21:54:18
Speaker 1
And, and I'm looking forward to seeing where they, where they go with this now that they've kind of managed to figure out that initial, how do I get on top of the leaderboard now? How do I maintain that? Well, it's it's I don't think it's just a matter of data. They have a ton of data. It's a matter of how do I view the problem and how do I solve some of these issues that it's not doing well at right now?

00:21:54:23 - 00:21:59:06
Speaker 1
It's not always a data problem. Sometimes it's the harness. That's what Cloud Code did particularly well.

00:21:59:06 - 00:22:03:20
Speaker 2
So maybe quick excursion again. So how did it rank for us on code review.

00:22:03:22 - 00:22:37:21
Speaker 1
It was on par with opus and GPD 5.2 opus 4.5 in terms of overall like finding of the really, really tough problems. Again, like those really hard ones, it was on par with those. The difference was, the delivery, the delivery of those comments is slightly different. Gemini is much more dense. And the information that it gives, it tends to be a little bit more, wanting to give really, really detailed explanations in terms of why a bug is there.

00:22:37:23 - 00:22:53:11
Speaker 1
In a much more compact format. So it's not necessarily I mean, you can tease some of that out and you can probably prompt specifically for that model to then get it to, to stop doing some of that. But as far as like a default, way that it likes to think about the world is much more, dense.

00:22:53:16 - 00:23:10:06
Speaker 1
If I look at opus, for example, opus is much more kind of like a developer. It's much more conversational. It's much more we have a bug. We we should probably fix this. We should do this, much more inclusive in this language. GPT five and five up to five to is is much more direct in its language.

00:23:10:09 - 00:23:23:19
Speaker 1
So each of them tends to have a certain personality associated with it without changing it. It's very interesting to see what different organizations have emphasized in the way that they've chosen to build their models, for sure.

00:23:23:21 - 00:23:37:18
Speaker 2
December, there was big news that anthropic acquire the JavaScript runtime ban that we love here at Code Rabbit as well. And the question kind of arose, like what? What does that mean for cloud code? And how does that change the game for open source tooling?

00:23:37:20 - 00:24:02:10
Speaker 1
I think it really, I hope, gives people this notion of open source tooling is extremely important, right? It's extremely useful. And ultimately large companies are willing to invest a lot in open source tooling in an extremely amazing project. Right. And ultimately, cloud code leverages it very, very heavily. And so it makes sense for me for them to want to invest a lot in that particular system.

00:24:02:10 - 00:24:30:15
Speaker 1
And I think if I'm thinking about, tool usage and MXGp and how cloud code might use that in the future, it makes sense that, you know, ban being a micro execution environment would be make a lot of sense for again, LMS are really great at generating code. So if I want to do something that I can distill down to generating TypeScript or generating some sort of piece of code and then executing that within a safe environment, I can accomplish a lot more than potentially just leveraging only MXGp.

00:24:30:17 - 00:24:46:10
Speaker 1
I think that's potentially where it's going to go. But again, this is like a lot of, a lot of, trying to guess the future and predict the future. And so we'll see where where it ends up happening. But I think it shows a lot of value and the value that open source systems create.

00:24:46:12 - 00:24:51:06
Speaker 2
So do you think we'll see more, open source tool equipment acquisitions in 26?

00:24:51:08 - 00:25:12:15
Speaker 1
I'm hoping that I, I'm not going to say, like, I don't necessarily think that acquisition is the only mechanism that makes sense in this regard. I think sponsoring these projects and providing value by contributing back to them, I'm hoping we see more of that. I ultimately, whether they decide to acquire other open source systems or not, is really going to depend on how much they rely on them.

00:25:12:15 - 00:25:29:17
Speaker 1
Right? And so we'll see whether other ones sort of come to the forefront. But it could happen for sure, especially in the in the case where in AI, where there's so much money floating around that and that people really want to make sure that whatever system they're leveraging is there for the long term, that they have a lot of say over what happens.

00:25:29:17 - 00:25:30:14
Speaker 1
Then you might see more of.

00:25:30:14 - 00:25:58:07
Speaker 2
That, right? Right. Well, great point to mention. I wish that we had, code. I would also have a 1 million pledge to open source tooling. So if you're listening to this and, you're building something impactful, please do reach out. Just a side note. Yeah, last item on my list. Even though you know that we could have talked about many more and probably also donated the MCP protocol to the Linux Foundation, which, I think was quite impactful in the sense that this is clearly a play for framework standardization.

00:25:58:07 - 00:26:19:08
Speaker 2
But then they also launch something else, agent skills. So I think that was already in October and which was more like a practical tooling move, but somehow people, confusing or a little bit misunderstanding these two, tools, maybe you can shed a little bit of light on, like what each of them is used for and how they're going to evolve into 2026.

00:26:19:10 - 00:26:42:14
Speaker 1
Yeah. So I mean, MCP being an open protocol makes a lot of sense, right? Ultimately, there's a push towards people adopting stuff that can talk to our LMS. Let's make it. Let's formalize it. Make it open. Right. Ooh. And we'll see. Even like how long term again that that protocol evolves right. As we get more and more understanding of the limitations of these systems and where they do really well, we'll see how it evolves.

00:26:42:16 - 00:27:03:02
Speaker 1
I think when it comes to skills versus MCP, from a high level, I like to think of MCP as a way of talking to external systems. That's been formalized in a way that that natural language can take care of. Right? So if I want to make API calls to external systems, obviously I'm not going to do that directly within, within, the LM necessarily, but I want to formalize that in some way.

00:27:03:07 - 00:27:19:22
Speaker 1
So there's been a few different ways that people have tried to do that. MCP being sort of the most ubiquitous of the ones that are available. When I think of agent skills, I think more of if I'm making a bunch of sub agents and they have very specific tasks, what are they supposed to accomplish? And and this goes back to our discussion earlier.

00:27:20:00 - 00:27:44:18
Speaker 1
We're talking about manas. Right. And this idea of like context engineering and having a task and then scaling the agents out to to have a long running view of what's happening. But each Asian is in charge of a specific thing. By having a skill, you're able to set the context around what that that system is trying to accomplish very in a very, very controlled way, rather than having it be part of a large prompt where the system can potentially do a whole bunch of different things.

00:27:44:18 - 00:28:07:16
Speaker 1
Let's really formalize specifically what this is supposed to do. And I think when you do that again, you you can see where it messes up in and fine tune just that one aspect, rather than potentially trying to wonder which part of my prompt is affecting it. But it's I think that of it more in that way. Right? I want to control and really, focus what the LM is doing in this moment.

00:28:07:18 - 00:28:27:12
Speaker 1
MacPhee is, is, is a communication mechanism that you have grabbing information that then I can then transform and put into dynamic context. This is about really focusing the agent on one specific thing. As you can imagine, they can play into each other. I have an agent is specifically geared towards code review. I have an agent specifically geared towards something else, the code review agent.

00:28:27:16 - 00:28:38:08
Speaker 1
And the other one might take the same information from MCP and look at it very, very differently because of the skills that I've sort of set up within them. So that's that's the way I kind of view the two systems.

00:28:38:10 - 00:28:54:01
Speaker 2
Now, that makes a lot of sense. Maybe I can challenge you to give me a little summary. Could you summarize 2025 for AI coding in like 1 or 2 sentences? And what would be the maybe 2 or 3 most impactful moments that maybe impacted your work or asked code rabbit the most the.

00:28:54:01 - 00:29:21:08
Speaker 1
Most impactful thing in 2025? It got to be the birth of vibe coding and ultimately the release of things like Cloud Code, right? Just the idea, even though it hasn't reached its full fruition, has really dictated a lot of what happened within throughout 2025 and really has cemented things like code as being absolutely essential as part of the development software development lifecycle, I would say things like manners and into other agent systems.

00:29:21:08 - 00:29:32:13
Speaker 1
This idea of having a lot of smaller sub agents doing tasks and then accumulating those has proven to be, very effective at code generation, but also at code review.

00:29:32:16 - 00:29:37:01
Speaker 2
So what do you say, the claim 2025 year of agents. Is that true?

00:29:37:01 - 00:29:45:15
Speaker 1
I would say that's very true. Yes. And it's been, I think, where most effort has been placed in, ultimately, at the end of day, where we've seen most the most evolution over the course of the year.

00:29:45:19 - 00:30:03:17
Speaker 2
Speaking about vibe coding, I think this entire shift of vibe coding really rose one narrative that we've been hearing over and over again, which is that software engineering is a junior, software engineers are dead kind of. We've heard it over and over again, but I think it's important to talk about it one more time. Can you, given, yeah.

00:30:03:20 - 00:30:06:21
Speaker 2
Your opinion, do you agree? Do you not agree? Why do you not agree?

00:30:06:21 - 00:30:27:20
Speaker 1
I mean, I hire people, as one of my main tasks, right? And hire interns are junior engineers. I think the the notion that junior engineers instead is not the right framing. I think junior engineers who don't leverage AI, that's that's gone. Right. This idea of coming in and just being a junior engineer in coding and learning how to do all this stuff, that expectation is just gone.

00:30:28:00 - 00:30:47:09
Speaker 1
You have to come in, you have to know how to leverage these tools, and you have to be willing to learn them very, very quickly. And so I would say, in order to make yourself, very valuable in the market, is really, really understanding how to leverage these systems to their utmost, how do I use agents in a way that's very effective?

00:30:47:09 - 00:31:12:06
Speaker 1
How do I make it so that I can investigate a new code base very effectively, much, much quicker than I used to, because that makes you no longer what we used to consider a junior engineer. It makes you more of a Omid intermediate level engineer in terms of your effectiveness and the amount of productivity. Right. And you got to keep in mind, like as people become more productive using these systems, it's not like companies are going to say, oh, I'm just I'm just going to stop my productivity gains.

00:31:12:06 - 00:31:30:22
Speaker 1
Now we're just going to hire than more people and get more productive and get more, even more productive and so on. Right. You have all these tools available to you now if you want to make yourself, you know, really, attractive in the market, you can go and build a lot of things right now and really showcase not just any more engineering talent, but also creativity.

00:31:30:22 - 00:31:47:08
Speaker 1
Right. What are the other things that that make an engineer really great? Is their ability to think outside the box when it comes to solving problems? I think of when I'm when I'm interviewing people and I'm trying to think whether someone is going to be a good fit is like, are you a builder? Do you really, really enjoy building things?

00:31:47:10 - 00:32:00:20
Speaker 1
Because if you do, if if that sort of is the thing that makes you wake up and get going in the morning, then I know you're going to come in with that mindset, right? And and that's what I'm looking for. And it's not junior versus senior. It's like, are you effective at using the systems that exist today?

00:32:01:01 - 00:32:03:17
Speaker 2
Practical tip number one build something.

00:32:03:23 - 00:32:04:10
Speaker 1
Yeah.

00:32:04:12 - 00:32:07:10
Speaker 2
Do you have number 2 or 3 that people should double down on?

00:32:07:16 - 00:32:31:01
Speaker 1
It's really hard to keep up with everything that's going on. But I would say you have to be an avid consumer of as much of what's happening as possible, getting in there and actually fooling around with it, right, trying it out. And this goes back to the building aspect of it as well. But a lot of these systems need you need to actually experience them to understand where the limitations are so that you can be effective at using them.

00:32:31:01 - 00:32:40:23
Speaker 1
Because if you just always go in and use every tool in every circumstance, it doesn't make sense. It's like not everything is a nail just because I have a hammer, right? You got that? You got to think, what's the right tool for the right circumstance.

00:32:41:01 - 00:32:50:16
Speaker 2
Right? Oh, great advice. That kind of brings us to the end of our episode here. So I would like to wrap up with maybe three of your best predictions on on 2026.

00:32:50:16 - 00:33:16:03
Speaker 1
I think code review is going to become again of ubiquitous necessity when it comes to your software development lifecycle. I think people who've been putting that off are going to start just understanding this is just an absolute necessity when it comes to my developers ability to handle the amount of code that's coming through, into production. As far as models go, I definitely see Google dominating a lot this year.

00:33:16:03 - 00:33:37:23
Speaker 1
I think that the fact that they've gotten to this point, we're going to see a lot of velocity from them. And and the DeepMind sort of side of things, going forward, and not only in terms of the coding agents, but just the reasoning systems in general. And I think that they're going to offer a lot more, available for free for people than than sort of other players in the space.

00:33:38:00 - 00:33:59:05
Speaker 1
I'm also really looking forward to. I really hope that we see some unique mechanisms, through which people can interact with these systems through AI, for coding, for for building. Right. I think there's going to be a lot of interesting things that come out this year as people think about these problems and have now more experience with them and where the limitations are.

00:33:59:07 - 00:34:08:21
Speaker 1
So I think I'm looking forward to seeing what people do when it comes to the mechanisms through which we interact with AI coding and and building.

00:34:08:23 - 00:34:20:08
Speaker 2
Well, there you have it folks. Wishing you all a very successful 2026. Get your hands dirty, build things, and, hope to see you again at the next episode. Thank you.