Hello everyone. This is Howie Xu, chief AI and the innovation officer at Gen. We do a lot of things. Among other things, we do the AI native browser. If you are watching this show, send me a note. I'll give you the free activation code. But today, I'm so glad to talk to two entrepreneurs. In the last few days, we have been talking to founders, CEOs who have raised hundreds of million dollars in the past. Now, you are the two smallest startups, but rising stars Massi from Metabob and Lalit from Delty. So good to meet you. Yeah, good to <inaudible>. Massi, why don't you start?
Yeah, so thank you for having us. My name is Massi. I'm the CEO of Metabob. We're an AI tool that helps developers debug and refactor code. We specialize on legacy code. So whenever there is a large amount of code and very unique use cases that LLMs alone are not able to either fix, refactor or generate new features of, that's where our tool come into place. It can be deployed both on-premise or on the cloud. So we are integration of like, we're on VS Code, but obviously if you use Cursor or other code generation tools, most of the time you can use Metabob to just-
Well, I can't help asking immediately. If you have Cursor, why do we need a Metabob?
Well, I guess so we get there immediately. Well, Cursor is an amazing tool for code generation but for people that uses it, you notice that when you deal with either complex code bases, not just large but just very unique use cases, just the way LLMs function as a sequential token, they struggle to create new features or to identify in the refactoring process what they... They kind of tend to get into the loops. And so you usually need the developers to look into that and trying to resolve the problem. Now, there is where we come into place.
So especially when there is a large code base?
Not just large. It's not just the size, but it's more like unique use cases. So that's why also right now we tend to function very well when it comes to legacy code because legacy code is not just the size that matters, it's also the fact that it's very outdated. So it's hard right now, like LLMs are trained on usually model processes. So when they look at all code or something that doesn't fit their code, they tend to again get into the loops and tend to have hard time to figure out how to build those features.
So pretty much you want it to be the steroid for Cursor?
We can say so. So we act in the background. We provide a dish, like different type of inputs to LLMs. We use a mix of graph neural networks and LLMs, but the GNN itself enabled us to read code as a computer rule. So our input is really the code property graph, which is something that LLMs don't do. LLMs look at code in the way humans write code. While we don't look at code in that way. We look at code as a computer will look code and that's enabled us to understand how data flow through the projects, understand the full architecture and what's more likely to change over time. So in terms of that, why Cursor is not able to do that? Again, amazing tool, but our point of view is that LLMs alone in the future of coding, it should be a multimodal like application. It can't just rely on LLMs alone.
Okay. We'll get to the technical side a little bit more. Yeah. Sorry about that. Let's actually get to Lalit. Tell us about Delty.
And in particular, I'm curious, because you just recently graduated from YC, right?
Congratulations for raising that around.
But there are so many companies out there already. Cursor, Augment, even me, I interviewed so many co-founders the last few days. Why do you come into this field, but start with what do you do?
Yeah. So Delty is an AI staff engineer teammate. It helps you design systems and it guides your junior engineers and coding agents. I want you to think of software development in three big buckets. Right in the middle is your coding part, where you change this verbose and esoteric syntax, you modify it, you create new syntax. Then there's activities to the right of code, which is how can we build, deploy, tests, and safely roll this out to our users. And then there's this big problem on the left which is, hey, what code should we be writing? Just figuring out what software or what code should be producing is going to be a big, big bottleneck to produce the 10X amount of software using the same number of people. The bottleneck is not producing syntax that compiles and works-
So in your model, you talk about three segments. One is the what to build. The middle one is how to build it. And then you are saying that how to build is going to be free or going to be frictionless in no time. And then there's another portion to operationalize it, to make sure things are working. So those are the three portion. So the middle one is what you're attacking in the sense that you see that the staff engineer's job can be automated?
Yeah, staff engineers do the middle part only 20% of their whole time. So I was a staff engineer myself at YouTube. I was leading a team of 45. I spent, including the other 10 engineers that I was leading, we all spent less than 20% of our time writing code or reading code. I was responsible for two million lines of code. I was telling people every day how those lines of code should evolve. I had never looked at those lines of code. I'm not capable of reading two million lines of code in my time, but that's the kind of job staff engineers, senior engineers do, which is mainly to the left off coding and a little bit to the right of coding as well, but not the coding. The coding is the job of a junior engineer, which is going to get automated away pretty fast. LLMs-
Wait a second. You said junior engineers, but then at the same time you are seeing that to do staff engineer's job. How can I reconcile the two statements?
Yeah, so junior engineers produce code, right? Staff engineers decide what code should be produced.
Got it. So your Delty is not automating away staff engineers, but automating away the junior engineers job. That's how you look at it.
Yeah. So we are augmenting all that work that you do to the left of code. So we help you brainstorm different architectural choices. We'll help you make the right framework data model, how you can build a product that your product manager or your marketing team needs, and then we seamlessly hand off to coding agents like Cursor or Cloud Code or Devin for that example.
So you said you were a staff engineer at Google, you led 45 engineers, many of them maybe like L3, L4, L5, right? Level 5 engineer. What's going to happen to them once you have Delty everywhere?
We are starting with augmenting. There's a reason staff engineers get paid $700,000 a year. You cannot replace them. You cannot fully automate them away when you have systems that are serving billions of users and making you billions of dollars. So there's going to be a phase where you start by augmenting. Pretty similar to how coding agents augment the work of a programmer, we are starting early, we have a head start. We are augmenting the work of a senior and staff engineer. But over time, to answer your question directly, every human engineer is going to evolve into a senior or staff, the kind of work every human engineer will do. It looks like the job of a senior and staff engineer today. So everyone's going to go through this rapid cycle of upskilling where they're doing high leverage work rather than doing the laborious job of producing syntax.
So today's L4 engineers, you think you are going to promote them to be senior staff engineer once they have tools like the Delty. That's what you're saying?
Yeah. I wouldn't know. I wouldn't claim that they would get paid as much as staff engineers. The job will evolve to look like what I did at YouTube pretty soon for an L4.
Cool. So Massi, you were talking about your stuff is actually complementing a lot of those tools, the Cursor the world. So now you listen to, hey the middle part, that writing code is going to be free or almost free. Where is Metabob fitting to that framework?
Well, it's actually from what he was talking about it. We have a similar point of view. Obviously, the hardest part when it comes to coding and it's harder to automate is really understanding the architecture, like the design application. It's not necessarily writing the code. That's already, it's mostly automated and we're just going to a direction where it's going to be fully automated. But just as it was mentioning the challenge is to understanding how that application is built. And how to build an application fully automatically, that's where we come into place. The goal in the future is to just provide in English straight guidelines to an agent and then the agent will build the entire application. We're pretty far from there because again, just as I was saying in the beginning, LLMs right now, especially for unique use cases or for complex application, they tend to go into loops and most of the time you need an engineer, a staff engineer and senior person to look it up and see and try to support it. In our case again, to tell you a little bit about our approach. As I was referring earlier, our tool look at the code from the code property graph to understand how... We really look at how a computer will look at code. So not in a form of text like LLMs do, but in a form of a graph. And that's enabled us to understand, first of all, what are the most relevant area of a code and to be able to predict what the next interaction of the code will be. So our tool, it's really like, as an LLM will do, will complete when you give them a task, they don't think really ahead, they just look at completing the task. For us, we are a predicting tool. So we help them to be able to predict what will come next and what are the area of the code that are more likely to change over time and that's really would-
So once Cursor of the world or Delty in the future has that sort of additional enrichment data, then they can do a better job?
Yeah. Our goal is to enable them to build full application just by providing, in plain English, guidelines. We are not an agent, but just as you say, we are supporting agents. It's a tool running the background. It's almost looking at almost like a database you can see ourselves, but not just like a large <inaudible> base-
Because with your graph neural networks you have more kind of a richer data than larger language model is able to.
It's just different. I think we complement very well LLM's weaknesses. I wouldn't say richer or not richer, just the way... It's not a token-based like training. It's a little bit different. We look at different type of data that an LLM will do. And so really what we send to the LLM are our nodes that we send is just to again complement what we strongly believe is LLM's weaknesses as of today, which prevent them to really build application from scratch, right?
Right, right, right. It's like self-driving car is not perfect today yet. If you have navigator, if you have the map, it could have complemented. Before, the fully autonomous coding agent is perfect, which still sometime away.
Yeah, of course. Yeah, we help them direct LLMs to exactly what to look for. That's exactly the way you look at us. Whenever LLMs look at, specifically for unique use cases or things where they struggle to, they get into this loop I was talking about it, we help them to tell them what are the code areas that they need to look for and to prioritize those code areas. Because LLMs cannot do that properly and so yeah, that's the way do it.
So Lalit, you probably would agree, right? With a Cursor or you or those autonomous coding is not perfect yet. They're still some time away, but what's your vision? When do you think a coding agent is going to be really good enough to do that, this middle thing, coding is going to be free. When is that going to be?
I think pretty soon from what I've seen. I am not an expert in that. I would ask Michael from Cursor how far along they are. But if the laws of scaling upholds, we are seeing the reasoning capabilities of foundation models getting better over time. So it's only a matter of maybe a few months or six months to one year where we see a wild increase in terms of the capabilities of these agents. So that's what we are betting on in fact.
With that, like you said, ask Michael and he's probably going to be bullish, why do you enter this race at this moment? Because Cursor is everywhere, it's the talk of the town, there is Augment, there is the Factory, there's so many other players. So why do you enter this race right now?
Yeah. The answer would go back to 2008 when BlackBerrys were, they were all the rage. They had these physical keyboards and they were the top of the market. It worked really well for a use case that people had at that point in time. But the disruptor's advantage that Steve Jobs had was he could jump, take a huge leap into the future and design for the future. And that's what we are doing. We are betting on a future where human engineers do not open a code editor. They do their work collaboratively with other humans and machines in meetings, documents, group chats and whiteboards. And if you look at the current UX of all these tools, like Windsor Cursor and so on, it's very primarily optimizing a flow that exists today and that's the problem incumbents have. That's the problem Blackberry had. You have millions of users, you have 500 million ARR, you need to satisfy the needs of today. And as the innovator's dilemma, that doesn't allow them to take a huge leap into the future. Whereas for someone like us, we can build something that only will augment the flow but is ready for the future that will happen.
In that future world, just for me to understand it, Cursor is still optimized for developers. You still need the editor, but for you, you don't have editor anymore.
So humans will not use a code editor in the future. Two years down the line, the amount of time every software engineer spends in a code editor is going to be 20% of the time. You will have these copilots, which are staff engineers on your team that you go talk to with a problem at hand. Like you're a product manager, you go to Delty, you're like, 'We want to build this feature. Tell me what it'll take. What are all the right decisions I need to make?' Delty makes the decisions for you and then coordinates a team of coding agents to build the software under the hood. 20% of the time, things break down and you have this expert, very lean-edged team that goes and takes a look to figure out what is going on. But most of the times, humans are not going to be opening a code editor as they do today.
So what's the skill set needed to drive Delty, your product in the future? What's the skill set? Well, you need to know the language, right? English language as example.
What else do you need to know?
Yeah. You need to understand code as architecture. You need to not-
Do you need to have a computer science one-on-one, sort of the concepts?
Oh, you're talking from people that interface with Delty?
I think you need to be technical.
Trade-off, latency versus-
Performance.
You also need to know your product and business really well. A lot of technical decisions are made based on what do you think the product will need one month down the line, six months down the line. So we are going to see the evolution of this NGPM hybrid role where you're a little bit to be able to interface with a staff engineer Delty, but you also have a really good sense of the product and the business needs and what the users want. How do you distill from what your customers need to be able to interface with the staff engineer? So you're like the bridge.
So the sort of the skill set I need is some technical skill set and then some product sense, a combo role, then I'm going to drive Delty and then get a lot out of it.
Exactly, exactly. But right now, we are augmenting engineering teams. We have product managers using Delty as well as sort of this deep technical expert on their team that understands the overall architecture where what is the technical roadmap of the team and so on. But over time, that is exactly the evolution.
Right. So yes, you talk about a lot of the tools today still need a coding editor, but it is also a trend that many of those tools started moving towards the direction of English is the prompt rather than the code editor. From that point of view, are you guys are all converging towards the similar direction from that point of view?
There will always be an aspect of what is the scale of software you're building. If you look at tools like Replit, Lovable and so on.
