From Code Search to AI Agents: Inside Sourcegraph's Transformation with CTO Beyang Liu

0:00This is the first time in computer science I can think of where we've actually abdicated like correctness and logic to us. Like in the past, it was a resource, right? So maybe the performance is different, maybe the availability is different, but like, whatever I put in, I'm going to get back out. But now we're like, figure out this problem for me. You talk to some devs and they're like, you know, I've never been more productive, but coding isn't fun anymore. That's one of the things that we're trying to solve for it. It's like, amazing new technology, it feels like magic. Never experienced anything like this before in my life.

0:27The narrative that was spun was like, this thing will just, you know, run our lives for us or it's going to kill us all. Total annihilation. Like Terminator. And there's just like absolutely no danger that like this thing's going to, you know, acquire a mind of its own and like try to reach out to the computer and kill you. If you use this every day, right, this idea that this thing could take over the world. Yeah, exactly. That narrative, I think, is is largely been dispelled within our circles. But I think that it's it's sort of like taken on a life of its own in other circles. And it's made its way to some of the halls of policymaking in the U.S.

1:00This is the old adage of like, you know, do you blame it on ignorance or malice? I honestly don't know, but it is clearly like nonsensical. And I think very much in the national interests to be still telling this story. The United States invented the AI revolution. We built the chips, trained the frontier models and created the entire ecosystem. But right now, if you're a startup building AI products, you're probably writing your code on Chinese models. Today's guest is Byung Liu, one of the co-founders of Sourcegraph. Byung is joined by A16Z's Martin Casado and Guido Appenzeller to talk about the shift he's seeing on the front lines of software development today.

1:41Sourcegraph's coding agent, which is hit number one on the benchmark for merged pull requests, runs on open source models. Many of them are Chinese. Not because of ideology, but because they work better for what the company needs. Here's the tension. Byung studied machine learning under Daphne Kohler at Stanford. He spent a decade building developer tools. He knows the technology cold. And his view is that we're sleepwalking into a dependency problem, not because Chinese models are dangerous, but because American policy has made it nearly impossible to compete in open source AI. We dig into why the Terminator narrative around AI safety might be our biggest strategic mistake, whether it's already too late to catch up, and what happens when the atomic unit of software isn't a function anymore, but a stochastic subroutine you can't fully control.

2:28Brian, thanks for coming and joining. So the topic today is AI encoding, but I mean, I would say you're one of the world's experts on this. And so we would love to kind of do a deep dive in kind of how you view the problem, how you view the solution. Of course, you're a co-founder and CTO of Sourcegraph. So we'll talk a bit about that as well. Of course, we've got Guido. Thanks for being here. And so maybe just to start, we can do a bit of a background on you and then we'll just kind of dig into details. Yeah, so background, I've been working on dev tools for more than the past decade of my life.

2:59I started Sourcegraph about 10 plus years ago, brought the world's first kind of like production legit code search engine to market and pushed that to, I think, a good portion of the Fortune 500. Prior to that, I was a developer at Palantir. And I guess now it's like the early days, right? That's where I met my co-founder Quinn and we were working on data analysis software and a lot of large enterprise code bases that we're kind of like dropshipped into and realized that there was a big need for better tooling for understanding massive code bases. And then before that, I guess relevant now is I actually did machine learning as a concentration when I was doing my studies.

3:36So I did some computer vision research. I didn't know that. Yeah, under Daphne Kohler at the... I did this. You are actually an AI guy. Yeah, yeah. OGAI. Dawson Angler, like Tyler stuff. I thought you were a systems guy. You talked like a systems guy. Yeah, yeah. For me, like this whole phenomenon of like LLMs and coding, it's almost like a homecoming of sorts I didn't know that. That's awesome. Definitely taught me AI as well. She's a great teacher. I got to say, that was like the one class I was so happy I comped out of because I didn't think I would do well. If I didn't pass the comp, I thought it would defeat me.

4:12I think I failed to comp too many times. You had to do it. There were those two. I was the TA for that class, actually. What, 21? 228. 228. Yeah, that's right. That's what it was. Yeah, yeah. So, cool. Great. So Sourcecraft started code search, navigation, but then now you've been making ways with AMP, which is like, you know, an agent, would we call it? So maybe talk through a little bit about what you've been working on, maybe pre-AI and now, just to level set. Yeah, so kind of like the history of the company is we were really built to make coding a lot more efficient inside large organizations and to make the practice of actually building software way more accessible, primarily to professional software engineers.

4:50But I think our eventual vision was always to expand the franchise. And we started by tackling like the key problem, which is enabling humans to understand code. Because if you've ever worked inside a large code base, you know that that probably takes anywhere from 80 to 99 % of the time. And then the remainder is when you actually understand the problem well enough to actually write the code. So that's where we kind of like built up our domain expertise. And then when LLM sort of matured, it was something that we were always kind of like monitoring in the back of our minds. originally looked at LLMs and embeddings as a way to enhance the ranking signals that we're incorporating into our search engine.

5:26And then when things really hit their stride with Chachapiti and all that, it was fairly obvious to us that there was a big opportunity to combine LLMs, which are this amazing technology, with a lot of the stuff that we'd built up to that point. And then, I guess, to round that out, finally, our latest product is this coding agent called AMP. What's interesting about AMP, and I don't want to be a couple of things about AMP, because it's kind of viewed as like a very sophisticated kind of opinionated view on agents. Do you share that or is that just kind of the outside? I would say there's certain things that we're doing that I think are quite unique.

6:00It was the top recently on one of these benchmarks, right? Yeah, I think there's like some startup out there that compares pull request merge rates or something. We managed to claim the top spot. That's awesome. Yeah, it was very gratifying to see. But again, like I would say that I think we're opinionated on some parts of our philosophy of building agents. And my own take is I think a lot of these opinions will soon become widespread. But there's other elements of what we're doing, which are like people like to read in a lot to AI these days. And sometimes it's just like, look, we actually did something very simple here at Yield of Good Results, and we shipped that and it works very well.

6:35Okay, so I think your focus is really on a large code basis. How is that structurally different from, you know, me coding my little Homebrew 201? Yeah, so it's funny you mentioned that. Like historically, the company's focus has really been on large code bases. But with AMP, we decided to build it almost completely separate from the existing code. And the reason for that was, one, we built AMP. AMP is really, at this point, like seven, eight months old. So we started AMP in around like February, March this year. And that was right at the wave of this new type of LLM hitting the world, the like agentic tool use LLM.

7:11Finally worked. Yeah, finally worked, right? Like after so many demo videos, finally there was a model that could actually do robust tool calling and compose that with reasoning. And our original tack was like, okay, let's build this into some of the existing things that we've created. But the more we started playing around with the technology, the more we sort of came to the conclusion that this was actually truly disruptive and we should actually start from first principles to see, you know, build the agent from the ground up and see what tools we really need. So what we've arrived at is the coding agent, which works, I think, very well in large code bases because, again, we push this to a lot of our customers.

7:46But it's also great for, like, hobby coding. Like, I spun my dad up recently on it, and he's been using it to create these, like, iPad games for our kid because, you know, typical Asian dad. Trying to teach him math, right? I want to teach him arithmetic and whatnot. And so my dad, who's never written a single line of code in his life, is able to just, like, hey, make a simple game that has him count the numbers, and then if he gets it right, a little rocket ship blasts off. So it's kind of interesting. It's a really interesting time to be building because even if you're building for professional developers as we are, a lot of the technology ends up being just kind of widely accessible.

8:24This is the new parroting. You talk as a parent not to write the games for your kids that are age-appropriate and they're well-integrated with curriculum, what they're supposed to learn. I love it. Another thing that's been kind of made kind of splash is you've recently decided to go to an advertisement-based model. So like, on one hand, so I've got this dissonance internally, Which is on one hand, I'm like, this is the boutique. Yeah. Sophisticated. On the other hand, I'm like, and it's also for everybody with ads. And so, like, how do you kind of reconcile? It's really funny because I think we had this sort of reputation for being, like, the primo agent.

8:55Yeah, totally. Like, the super intelligent one. But we never had, like, a flat rate pricing model. We did pure usage-based pricing. And that also meant that there was never any incentive to switch to a cheaper model for our users. So our attack was, like, the most intelligence and you just pay for the inference cost. But as we built more and more, we kind of realized there's sort of this efficient frontier that you can draw. This two by two grid and one axis is intelligence, but the other axis is latency. And there's multiple interest points along this tradeoff curve. It's not just that having the smartest model makes your experience the best.

9:29The smartest model often tends to be a significant amount slower than other models on the market. And so we felt that there was like an opportunity for us to create like a faster top level agent that couldn't do as complex of coding tasks, but it could do these like targeted edits. And when we started to play around with these small, fast models, we realized that, hey, actually, the inference costs are significantly lower. And that got us thinking like going back to folks like my dad, right? Like he's just doing this stuff on the side. He doesn't want to spend hundreds of dollars per month to create these kind of like simple games.

10:00We're like, hmm, maybe there's like a model here. I think it started as a joke. Someone was like, we should just do ads and see how that works. And everyone was like, nah, that'll never work. But then it just kind of kept coming back up. And at one point, we're like, all right, let's just try it and see how it works. And we launched it, and it's been growing very quickly since then. Can I dig philosophically into this just a little bit? So I had a conversation with somebody that works on Cloud Code, which is a very successful CLI tool. And this person was like, you know, what we've done over time is we've literally just removed, you know, stuff between the user and the model.

10:32Like, that's it. Like that's like kind of like the way that we improve things are we just like do less and let the model do more. And so I guess that makes, you know, it sounds kind of intellectually or intuitively interesting. It kind of makes sense. But on the other hand, it seems expensive. You're like, here is this state of the art model that costs a billion dollars to train. And like now it's just the user and the model. And so it's almost like that statement is almost contrary to an advertisement-based model or like what you're talking about, like, you know, like a fast model or smaller models.

11:09Yeah. So, like, are we seeing two parallel paths in the industry? I, so there's definitely, you can, there's definitely different, like, working styles, right? Like depending on the task or maybe depending on the person, you talk to people using coding agents and some of them are like, I just want to write a paragraph long prompt and then have the agent go figure it out. I want to come back to something that's like mostly working. And then there's other people who say like, actually, I don't want to do that because half the time I myself don't have a clear idea of what I want yet. The creative process is sort of one where you kind of like figure out what the software looks like as you go along.

11:53And sometimes it's the same person saying both things, right? Like when I go, there's some features where it's like implement billing, where I'm like, okay, I know exactly what protocols we need to support and the Stripe integration. I know what feedback loops we need to hit. Then it's like, okay, big prompt, agent, go at it. But then there's other types of development where it's like, you know, I want to build a brand new feature. We just shipped this code review panel in our editor extension. And that was a kind of like situation where I was like, I don't actually know what this review experience should look like because it's not me reviewing other people's code, it's me reviewing agent's code, which is like a new workflow.

12:30And for that, I kind of did want like a more interactive back and forth interaction between me and the agent. So I don't think it's necessarily like these two things don't have to be completely separate products, but they are distinct working modalities. Interesting. That's a great way to put it. How do you think about the difference between using somebody else's model, like one of the Soda Labs versus building your own model versus using an open source model? How does that fit in your philosophy? Yeah, so I would say our philosophy is not model-centric, it's more agent-centric. So we view the model as an implementation detail.

13:12Yeah, I don't know what that means. Okay, so let me explain. So when you're interacting with an agent, at the end of the day, you care about how that agent is going to respond to your inputs. You know, what tools it's going to use, what sort of trajectories it's going to take, what sort of thinking it does. A lot of that goes back to the model, but it's not solely dependent on the model. There's a lot of other things that can influence how an agent behaves. There's the system prompt. There's a set of tools that you give it. There's a tooling environment. There's a tool descriptions. There's the sort of instructions that you give it for connecting to feedback loops.

13:43and with the same model with wildly different like tool descriptions and system prompts you actually get like you know completely different behaviors out of that model. Is that true in both directions? Like with the same prompts and two completely different models would get different behaviors? Oh for sure, for sure. It's like if you have like an agent harness like a set of tool descriptions and you swap out the model then there's no guarantee that that thing is going to work well with the model that you swapped in. And so what we view as like the kind of atomic composable unit is not the model.

14:14It's this thing called the agent, which is essentially this contract of like user puts text in and gets certain behaviors out. And that agent is really a product of both the model plus all these other things that I just listed. And so when it comes to like figure out what models we want to use, it's not so much like, hey, we want to use like the latest quote unquote frontier model from XYZ lab. It's really about, hey, what behavior do we want the agent to take, or in some cases the sub-agent, and how do we find the right model that enables that agent to do its job? It sounds so hard to me. Like, this is the first time in computer science I can think of where we've actually abdicated, like, correctness and logic to a certain degree.

14:59Like, in the past, it was a resource, right? So, like, whatever, it's not logic. It's like, okay, so maybe the performance is different, maybe the availability is different, but like whatever I put in, I'm going to get back out, whether it's a database or a compute or whatever. Like these are like, you know, but now we're like, figure out this problem for me, right? So you're kind of abdicating like, you know, core logic and correctness. Your unit test comes back with works 45 % of the cases. Yeah, yeah, yeah. The non-determinism is something that people struggle with a lot. But so for me, I actually do think, you know, like historically, pre-AI, like when you think about computer systems, the basic unit of composability is like the function call in programming, right?

15:39So it's like when you think about your system, it's like this function calls out to these other functions and those other functions delegate to these other functions. I do think there's still an analog to that in the agent world. Like the agent is really the analog of the function, but just updated or generalized to AI. Can I just push on this? Because I mean, listen, call me a traditionalist. Yeah. For me, like computer infrastructure is compute network and storage, right? And like databases. And these are resources that are abstracted. Sure. Like, so give me storage, give me network. Yep. But, like, the semantics, like what actually happens, I write, right?

16:16That's, like, my code. We're here. We're, like, figure it out for me. It's, like, we're abdicating actual, like, logic and correctness. It just feels, like, in a way, like, a little bit, you know, like, in your case, for example, if you pick up, you know, let's say you're using model V2.1 and then you go to model V2.2. Like, you're going to have wildly different answers, right? It's almost like a new instruction set or something. Yeah, you might have different answers, but I think if you construct the agent right, they're not going to be wildly different. So, like, for instance, we have a sub-agent that's designed to search for things, like uncover relevant context.

16:51And, you know, it is a bit of a dice roll every time, right? Like, it takes a slightly different trajectory. It might search for different things. But it's to the point now where if I want to find something in the code base, I have, like, 99 % confidence that this thing will eventually be able to kind of like stochastically iterate to the right answer. And so in that way of thinking, it's like, yeah, how it gets there might vary, but if I wanted to do a specific thing, it's reliable enough that I can invoke it. It feels like there's kind of a backlash right now in the industry to evals. Like, do you view like this is an eval problem or like a runtime system problem?

17:30Yeah, so, you know, my take on evals is evals are definitely effective as a sort of like unit test or a smoke test. Yeah. Because if you push a change to your agent and it breaks something, you want to know, right? Like if there's like an important workflow that you're like, hey, this should work reliably well, because if this doesn't work, then probably a lot of other things break. And that's a great instance where you want an eval that will alert you when it goes from green to red. I think where it gets hairier is treating evals as a kind of like optimization target. Because any eval set, like what are you trying to capture?

18:09If you're building an end user product, at the end of the day, what you care about is the product experience. And so you construct the eval set to kind of proxy the vibes of the user using the product. And by definition, that means your eval set is always like lagging a little bit from the frontier. because it takes time to like distill what is a good product experience into a set of evals. And we've had multiple times in our past where we've picked a number. Just to take an example, like with, you know, back in the kind of like code completion days of, you know, 2023 or whatnot, we had a coding tool that would do coding autocomplete and the kind of like banner top line metric there was completion acceptance rate.

18:50You know, like, given that I suggest this change to the user, what is the likelihood they're going to accept? That seems like, you know, bulletproof, right? But actually, like, I think in building that, we ended up over-optimizing that to a certain extent. Because there's, like, any metric you choose, there's going to be a way to game it. Well, I mean, even in this one, like, okay, so, like, the developer accepts it, but do they end up committing it? Yeah. Oh, they committed it, but, you know, like, whatever. Did, like, the pass code review? Yeah, exactly. Did the PR get accepted? There's, like, a subtle bug introduced or whatnot.

19:20Or, yeah. You know, did it get merged into Maine? Like, I mean, it just feels like, you know. Yeah, yeah. You know, like, this is kind of an adjacent topic, but something that Guido and I discuss a lot is to what extent the market is Pareto efficient on the Pareto frontier. Like, if you can trade off, like, let's say, performance for cost or intelligence for cost, like, will the market kind of adopt that uniformly, or does it just optimize only for speed only for correctness. Like, being on the front lines, we would love, you know, your sense on this. Here's a simple question. We ask this question a lot and nobody seems to know.

20:00Like, is the question here, like, what matters more, speed or intelligence? It's whether the Pareto frontier is what matters or if it's kind of, there's points on the Pareto frontier that matter, right? So you can imagine. Oh, okay, yeah. So traditional pricing psychology is you're the expensive one or you're the cheap one, right? And everything in the middle is called the value gap, which people don't, use, right? And so, originally, we were like, oh, that happens here. So, either you buy the most expensive one, you buy the cheapest one. But actually, as we kind of look in the market, it actually feels like most of the frontier is pretty full.

20:31Like, developers are pretty sophisticated. Like, you know, different, you know, there's different cost sensitivities, different price sensitivities. Yeah. So, you know, it's funny that you mentioned this, like, you know, the cheap option versus, like, the premium option. It just so happens that AMP has two top-level agents. There's a smart agent, and there's a fast agent. Oh, that's interesting. And the Fast Agent is the one that's ad-supported, like, that we can offer for free. And the Smart Agent is the one where we're like, okay, we're not, we will always only do usage-based pricing for that because we want to keep that at the frontier of smartness.

21:02But that being said, like, I don't know, like, maybe there's, like, a third point in there that could make sense. It really just comes out of the vibes at the end of the day, like, as we use this more heavily and see the usage patterns emerge. The mid-agent. Yeah, the mid-agent. Like, I honestly, yeah. Well, if you put it that way, then they're like, oh, like, yeah, the galaxy brain idea is you either want, you know, smart or fat. Cool. So, I mean, if you're open to it, I'd love to dig into a bit on kind of your view on open source models. Yeah, sure. Do you use them? Yes. You know, do you think that they are an important part of the ecosystem?

21:43Yeah, so we do use a variety of open source models. You know, we use both closed source and open source models quite heavily. But the open source ones, I think, are becoming a bigger theme now for a couple reasons. One is, you know, with an open source or open weight model, you can post-train them, right? Which means, like, if you have a domain-specific task, like AMP has a growing number of sub-agents that are specialized for a specific task like contact retrieval or like extra reasoning, library fetching. Those are more constrained tasks where you don't necessarily need like frontier general intelligence.

22:25If anything, you want faster, right? And so the benefit of having open weight models is you can look at the thing that you're trying to optimize for, like what that subagent needs and post-train the model to accomplish that more effectively. And the other element of open-weight models that's very appealing is just the pricing aspect of it. Like there's now more and more like effective open-weight models that are emerging on the scene that are actually quite robust at agentic tool use. You know, the landscape has changed immensely since like June of this year. We've gone from like, you know, there was really only one really good agentic tool use model to now there's like...

23:11Could you name that? I mean, it'd be great to actually, I mean, I opened... Yeah, I mean, like, so, you know, originally there was Claude, right? Like Sonnet or Opus. That was the first agentic tool use model. And that sort of, you know, ushered in in the current agent wave. But now, you know, there's GP5, there's KimiK2, there's QuantryCoder, GLM. Are these open source models on par or pretty close? It depends on the workload. So I would say in our evaluations for kind of like the top level smart coding agent driver, we still tend to prefer Sonnet or GPT-5. but for kind of like quick targeted edits or specific sub-agents I think more and more we're preferring smaller models because they have better latency characteristics and because the complexity of the task isn't high like you reach a ceiling it's like once you reach a certain level of quality there's diminishing returns and then you start optimizing for latency because that gets you more, you know, interactivity.

24:28What's the smallest models you can use for an effective agent? I mean, for an agent right now, it's probably still fairly large, like talking to probably like hundreds of billions of parameters for kind of like a top-level agent. But for like search agents, you could go smaller than that. And then we also have a model that does kind of like edit suggestions. So, you know, for those times where you still have to go into the code and manually edit stuff, this thing suggests the next edit that you'll make. And for that, we use a very small model, like, you know, single digit billions parameters. So do you train your own models?