Leading in the era of AI code intelligence
source link: https://changelog.com/podcast/580
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Transcript
Changelog
Play the audio to listen along while you enjoy the transcript. š§
So Quinn, itās good to see you, good to have you backā¦ I want to really talk about the evolution of the platform, because the last time we talked it was kind of like almost pre-intelligenceā¦ It was kind of almost still search. And like just after that you went buck wild and had a bunch of stuff happeningā¦ And now obviously a whole new paradigm, which is artificial intelligence, a.k.a. AIā¦ But good to have you back, good to see you. How have you been?
Yeah, itās great to be back. Iāve been good. I think, like everyone, itās been quite a whirlwind over the last four years, over the last year with AIā¦ And weāve come a long way. We talked two years ago, and we talked a lot about code searchā¦
Was it two years ago?
Two years ago.
So a lot changed in two years.
Yeah, thereās been about 10 years in the last two years, through the pandemic, and now AIā¦ And we have grown a ton as a company, our customer base, and all thatā¦ And yeah, two years ago we were talking about code search, and thatās what we had built, and we still have code search that looks across all the code, and understands all the calls, the definitions, the references, the code graph, and all those great things. And weāve got a lot of great customers on that. You know, much of the FAANG companies, and four of the top ten US banks, and Uber, and Databricks, and governments, and Atlassian, and Reddit, and so on.
[00:05:56.12] But itās not just code search anymore. The world has changed for software development in the last year so much.
What is it like being CEO of a company like that? I mean, youāre a founding CEO, so this isnāt like āOh, you inherited this awesomeness.ā You built this awesomeness. How does it feel to be where you are?
Sometimes it is exciting and scary to realize that I as CEO have to make some of these decisions to go and build a new product, to change our direction. And I feel so lucky that I have an amazing team, and that people are on board, and people are bringing these ideas and need to change upā¦ But itās definitely weird. I mean, itās one thing to try a new side project that is dabbling with some of these new LLMs; itās another thing to shift a 200-person company to going and building that. But as soon as you do that, just the progress that you see - I mean, itās so validating. And then obviously, hearing from users and customers, itās so validatingā¦ So itās been I think a whirlwind for everybody.
When you make choices like this, do you have to go to ā I know youāre funded, so you probably have a board. So you have other people who help you guide the ship. So itās not āHey, Iām CEO, and we just do whatever I wantā¦ā You also have Beyang Liu, your founding co-founder, CTO. Iām very keen on Beyang, Iāve known him for years. I want to go backtrack a little bit, but I want to stay here for a minute or two. When you make a choice to go from code search to code intelligence, to now introducing Cody, your product for code gen, for ā and code understanding as well. I mean, itās so much more. Itās got a lot of potential. When you make a choice like that, how do you do that? Do you have to go to the board? Whatās that, like? Give me an example of what it takes to sort of change the direction of the ship, so to speak.
Yeah. If you go back to the very founding of Sourcegraph, we decided on a problem to solve, which is big code. It was way too damn hard to build software. Thereās so much code, thereās so many devs, thereās so much complexityā¦ And back when we started Sourcegraph 10 years ago, we felt that, you know [unintelligible 00:08:05.01] companies felt thatā¦ Now you start a brand new project and it brings in like 2,000 dependencies, and you have to build on all these super-complex platformā¦ Stuff is getting so much more complex. So we agreed on a problem, and we got our investors, we got our board, we got our customers, our users, our team members all aligned around solving that problem. And not one particular way that we solve it. And if you go back to our plan, actually, in our very first seed funding deck, it talks about how first we want to build the structured code graph. And then we want to do Intelligent Automation. Thatās IA. I think we probably would have said AI, except back at the time if you said AI, people thought that you were completely crazy.
You know, itās unfolding ā I wonāt say exactly; we didnāt have a crystal ball back then. But itās unfolding roughly as we expected. And we knew that to do more automation and code, to take away that grunt work from developers, so they could focus on actual problems and the stuff they love, that you needed to have the computer have a deep understanding of the codebase. It couldnāt just all be in devsā heads. So it was no big surprise to our board or our team that this was something that we would do, that we would go and build our code AI. And it was also not some complete luck of the draw that we found ourselves in a really good position to go and build the most powerful and accurate code AI. So none of this is coincidental. But when do we do that? And I think if we had started to do that say in 2018, where there were plenty of other attempts to do ML on code, I think that we would have failed, because the fundamental underlying technology of LLMs was just not good enough back then.
[00:09:57.16] And the danger there is if we had started doing it in 2018 and we failed, we might have as an organization learned that stuff doesnāt work. And then we would have been behind the ball when it actually did start to work. So getting the timing right was the tough part. And I actually think that we probably waited too long, because we could have brought something to market even sooner. But itās still so early in terms of adoption of code AI, and even less than 0.5% of GitHub users are using GitHub Copilot, so itās still very early. Most devs are not using even the most basic code AI that exists. So itās still very early.
But getting the timing right, and making a big shift, starting back last Decemberā¦ That was when we started to see Cody really start to do some interesting things. That felt early to a lot of people on the team. And it took a lot of work to get the team on board, and to champion what the team was doing that was working, and to shift some of the things that we could see were not going to be as important going forward.
What a shame though, right? ā¦that less people are using code AI-related tooling. I think itās like a ā Iām not sure what it is exactly happening, because thereās this idea that it might replace me, and so therefore I just resist it. And Iām just assuming thatās probably some of the case for devs out thereā¦ Because Iāve used it, and I think itās super-magical. And Iām not trying to generate all the things, Iām trying to move faster, with one more point of clarity, if not an infinite point of clarity that can try something 1,000 times in five minutes for me, so I donāt have to try it 1,000 times in a week or two. Whatever it might be. And that might be hyperbole to some degree, but itās pretty possible. I just wonder, why are people not using this more frequently? Is it accessibility? Is the access not evenly distributed? What do you think is happening out there? Whatās the sentiment out there of why more tooling like this isnāt being used?
Well, I think this applies even to ChatGPT. ChatGPT ā itās amazing. It changed the world. Itās mind-blowing. It can do incredible things. And yet, you ask the average person how often are they using ChatGPT in their everyday life or their everyday workweek, and the answers I usually get are āMaybe one or two times.ā You hear the stories of people that say āI ask it to write emails for me. And what it writes is ten times too long.ā And the technology is there, the promise is there, but in terms of actually something that is so good, and understands what someone is doing, understands the code they need to write for developers - thatās still not completely there yet. And at the same time, the promise is there.
So I really want to make sure that we as an industry, everyone building Code AI, that we level with developers out there, with what exists today, what works well today, what doesnāt, whatās coming in the future, and not lose credibility by overhyping this whole space. I think thatās a huge risk. And I actually look at self-driving cars. 10-15 years ago you started to hear about autonomous vehicles; there was so much hype. People thought āAre humans even gonna be driving in the year 2020?ā
Clearly, we areā¦ And some people are kind of jaded by all that hype, and they just dismiss the entire space. And yet, in San Francisco here, thereās two companies where you can get a self driving taxi. And that is amazing. That is mind-blowing. The progress is real. It was a little slower than people thought if you were just reading the hype, but I think that most of the industry experts would have said āYeah, this is about the rate of progress that weād expect.ā
So we donāt want that kind of mistake to happen with code AI. We want to be really clear that itās not replacing developers. Those tweets you see where itās like āOh, you fire all your junior developers. You can replace them withā, whatever, this AI tool someone is shilling. Those are completely false, and those detract from the incredible progress that weāre seeing every single day with code AI getting better and better.
[00:14:20.18] The autocomplete that code AI can do is really powerful. I think that could probably lead to a 20% boost to developer productivity, which is really meaningful. But then having it write entire files, having it explain code, understand codeā¦ Weāre working on that with Cody, and Cody does a pretty good job of that. Itās really helpful. And you see a lot of other work there. That is really valuable. And it doesnāt need to be at the point where, you know, itās Skynet for it to be changing the world.
Yeah, for sure. Can we talk about some subtle human leveling up thatās practical for ChatGPT? I mean, I know itās not Cody. Do you mind riffing a little bit? So last night my wife and I, we were hanging up pictures of our beautiful children. We took pictures of them when they were less than one week old, and then we have pictures of them in the same kind of frame at like their current ages, and oneās seven and oneās three. So it doesnāt really matter about the age. Theyāre just not one week old anymore. So you have this sort of brand new version of them, and then like current version, to some degree. And itās four pictures, because we have two sons, and we want to hang them on the wall. And my wife was trying to do the math - and we can obviously do math; itās not much. Itās like an eight foot wide wall; we want to put them in a [unintelligible 00:15:29.05] with even spacing, all that good stuff. Iām like āBabe, we should askāā And like, Iām more versed in this than she is; not so much that she doesnāt use it often, she just doesnāt think to. And I think that might be the case of why itās not being more widely used, is they donāt think to use this. And Iām like āI donāt want to use it. Itās a word calculator.ā Or āI want to use it, itās a word calculator.ā I donāt want to think about this problem myself. I donāt want to do the math. I could just tell it the problem; my space, my requirements, and it will just ā it will tell me probably too much, but it will give me a pretty accurate answer. Iām like āLetās just try itā, and sheās like āOkay.ā And so I tell it āHey, ChatGPT, I have this eight foot, five inch wall in width, and I want to have these pictures laid out in a grid. Theyāre 26 inches squared, 26 wide, 26 tall, and I want to have them evenly distributed on this wall in a four grid.ā
It gave me the exact answer, told me exactly where to put them at. We did it in five minutes, rather than like doing the math, and making a template, and writing all these things on the wall. It was so easy, because it gave us the exact right answer. Thatās cool.
Thatās awesome.
That to me is like the most uniquely subtle human way to level up. And I think thereās those kinds of problems in software that are being missed by developers every single day, to not X their day. And what I mean by that is like 1x, 2x, 5x, whatever it might be; if I can do a task in five minutes, not because it does that for me, but it helps me think faster and get to the solution faster. Then I want to do that, versus doing it in 15 minutes, or an hour or so. What do you think about that?
Yeah. So when you asked it that, did it give you the exact right answer on the very first reply?
Yes. Yes, it did.
Thatās awesome.
Yeah. Iāve found a way to talk to it that it does that. And I donāt know if itās like a me thing, but I get pretty consistently accurate answers. Now, it also gave me all the theory in a way, too. āThe combined width of this and that, and two times this, and whatever thatā, I donāt really care. I just want to know the end, which is says āSo if you want six inches in between each picture frame, you should do this and that and this and that.ā Like, it gave me the ending; just skip to the ending. Just give me the good parts.
But Iām willing to like just wait; literally, maybe 10 seconds extra. Thatās cool with me.
Yeah. Well, thatās incredible. And I think that thereās probably ā
Isnāt that incredible?
[00:17:52.05] Yeah. Thereās so many things like that in your everyday life where you could use it. And it probably wonāt get it 100% correct, but I mean, what an amazing time to be living, where that new technology is suddenly possible. And itās not trickled down to all the things that it can change. And when you think about that underlying capability, this kind of brain that can come up with an answer to that question, how do we make it so that it can do more code? The way that a lot of people think about code AI is autocomplete the next line, or few lines. And thatās a really good problem for AI, because just like with your picture framing example, the human is in the loop. The human is reviewing a digestible, reviewable amount of code, of AI-suggested code. And so youāre never having to do things that the human cannot look at. If the AI told you āHey, if you want to put pictures up on the wall, first crack some eggs, and put them on the stove.ā Youād be like āThat makes no sense.ā And you would have caught it.
So that human in the loop is really important. The next step though, and how we get AI beyond just a 20% productivity enhancement is āHow do we have the AI check its own work?ā And I donāt mean the LLM, I mean how do we have an AI system? One very simple example is right now any AI autocomplete tool will sometimes suggest code that does not type check, or does not compile. Why is that? That should no longer be the case. Thatās one of the things that weāre working on with Cody. So donāt even suggest code that wonāt type check. How can you bring in context about the available types in the type system so that it will produce a better suggestion, and then filter any suggestions that would not type-check. And in some cases, then go back to the LLM, invoke it again, with additional constraints. And you know, then why stop at type checking? Letās make it so you only suggest code where the tests pass; or you suggest code where the test donāt pass, but then you also suggest an update to the tests, because sometimes the tests arenāt right. And itās all about all the advances in the future with code AI that I think are critical for us to make it so amazingly valuable are about having the AI check the work and bringing it to real world intuition, so itās not relying on that human in the loop.
Yeah. I guess my concern would be latency, right? Like, if youāve got to add, not just generation, but then checking, linting, etc, testing, correctly testing, canceling outā¦ Like, youāve got a lot more in that buffer between the prompt, which weāre all familiar with, to get that response, and the ending of the response. I always wonder, why does it take ChatGPT in particular time to generate my answer? Is it really thinking and itās giving me like the stream of data on the fly? Or is there some sort of ā is that an interface thatās part of usability, or part of UX? And I just wonder, in that scenario that you gave, would the latency affect the user experience?
Yeah, absolutely.
Of course, right?
Yeah. We have incredibly tight latency budgets. We look at getting the 75th percentile latency well below 900 milliseconds. And once you start invoking the LLM multiple times to check its own work, to go back and redo the work, once you start invoking linters, and type checkersā¦ I think weāve all been in a situation where we hit Save in a file in our editor, and we see āOh, waiting for the linter to complete.ā Sometimes that can take a few seconds in big projects. So this requires I think a rethinking of a lot of the dev tooling. Because in the past, it was built for this āHuman is editing a single file at a timeā, itās interactive, and itās in CIā¦ But thatās where latency is not that sensitive. But I look at just the difference between like Bun running tests in a JavaScript project, versus another test runnerā¦ And bringing that down to 200-300 milliseconds instead of 5 or 10 seconds or more is really critical. I look at things like Ruff, rewriting a Python linter in Rust to make it go so much faster. I mean, I wish something like that existed for ESLint. And we need to bring the latency of all these tools that devs use in that edit loop down by several orders of magnitude to make this possible. But I think the reward, the pot of gold at the end of the rainbow if we do all of that is so great, because it will enable AI to take off so much of the grunt work that we ourselves do. So I donāt know if thatās the motivation behind some of these linters and new test runners and so on, but I love that those are coming out there, because that will make this fundamentally possible.
So recently, at All Things Open, Jerod conducted a panel with Emily Freeman and James Q. Quickā¦ And really, one of the questions he asked was ā you call it grunt work in this scenario, and Jerod argued that maybe thatās the joy work. Does AI steal the joy work, Quinn? Some of this stuff is fun, and some of it is just a means to an end. Like, not all developers really enjoy writing the full function themselves. And some of them really do, because they find coding joy. What are we doing here, are we stealing the joy?
I love nothing more than having six hours of flow time to fix some tech debt, to do a really nice refactorā¦ And as CEO, sometimes thatās the best code for me to be writing, because I do love coding, rather than some new feature, some new production codeā¦ So yeah, I totally feel that. And at the same time, I choose to do that by writing in TypeScript, by using a GUI editor, Emacs or VS Code - I choose to do that by writing in Go. Iām not choosing to do that by going in and tweaking the assembly code, orā¦ You know, weāre not using C. So Iāve already chosen a lot of convenience and quality of life improvements when I do work on tech debt. Itās not clear to me that the current level is exactly right. I think that you can still have a lot of the really rewarding puzzle-solving, the fun parts of the grunt work, and have the AI do the actual grunt of the grunt work. And I think itās different for everyoneā¦ But as we get toward AI starting to ā and to be clear, itās not here yet. But as we work as an industry toward AI being able to take over more entire programming tasks, like build a new feature, then weāre gonna have to do both the grunt work and the fun work from the programmer. And if someone only wants to use half of that, thatās totally fine. My co-founder Beyang - he uses Emacs, but in a terminal, not in GUI. So itās a free country, and devs can choose what they want.
Thatās right. Okay. I guess I was saying that more as a caution to you, because half of the audience cringe when you said grunt work, and the other half was like āYouāre taking my joy away.ā Some of them are happy, and then some of them are like āLetās not use a pejorative towards the work we love.ā You know what I mean?
Well, I think grunt work is different for each person. I think a lot of people would consider the grunt work to be all the meetings, and all the reading of documents, and the back and forth, and the bureaucracy of their jobā¦
They hate that part. And they just love coding. And I say we need it, we need AI in the future to be able to digest all that information that comes from all these meetings, and to distill the requirements. So let the AI do that for them, and then they can just have a glorious time coding. And we used to joke with Sourcegraph that we hoped that Beyang and I would create Sourcegraph, itād be so damn good that we could just retire and spend all our day coding in some caveā¦ And look, I totally feel that, and we want to bring that to everyone. And if they want to do that, then they should be able to do that.
Yeah. So two years ago we would not have opened this conversation up with a discussion on artificial intelligence. Two years ago you were talking about like that was the last time you did the work, not me. I didnāt even look at the last time we talked. I knew it was not yesterday, and it was not last year. I just wasnāt sure how far back it was. What has changed with Sourcegraph since then? I mean, youāve grown obviously as a company, youāve got two new pillars that you stand on as a companyā¦ Code search was the origination of the product, and then you sort of evolved that into more of an intelligence platform, which I think is super-wiseā¦ And then obviously, Cody, and cogeneration, and code understanding, and artificial intelligence, LLMs, all the good stuff. What has changed really, from a company level? What size were you back then? Can you share any attributes about the company? How many of these FAANG and large enterprise customers did you have then versus now? Did they all come for the Cody and stayed for the Sourcegraph, or was it all one big meatball? How do you describe this change, this diff?
[00:30:02.09] Yeah, two years ago we were code search. And thatās like a Google for all the code in your company. Itās something that you can use while coding to see how did someone else do this, or why is this code broken? How does this work? You can go to find references, go to definition across all the codeā¦ And at the time, we were starting to introduce more kinds of intelligence, more capabilities there. So not just finding the code, but also fixing the code with batch changes, with code insights so you could see the trends. For example, if youāre trying to get rid of some database in your application, you could see a graph where the number of calls to that database is going down, and hopefully, the new way of doing things is going up. So all these other kinds of intelligence. And that stuff is incredibly valuable. Millions and millions of devs love code search and all these things. And with code search, that was about feeding that information to the human brain, which is really valuable. And the analogy that I would say is Chat GPT, again, changed the world, but we all use Google search, or whatever search you use, way more than you use ChatGPT today. And yet, everyone has a sense that something like ChatGPT, that kind of magic pixie dust will be sprinkled on search, and weāll all be using something thatās kind of in between. ChatGPT is probably not the exact form factor of what weāll be using. Google Search circa two years ago was not what weāll be using. But thereāll be some kind of merger. And thatās this journey that weāve been on over the last couple years, taking code search, which fundamentally builds this deep understanding of all the code in your organization, and weāve got a lot of reps under our belts by making it so that humans find that information usefulā¦ Now, how do we make that information useful to the AI, and then make that AI ultimately useful to the human? So how can we use this deep understanding of code to have Cody, our code AI, do much better autocomplete, that has higher accuracy than any other tool out there? How can we have it use that understanding of how you write tests throughout your codebase, so that it will write a better new test for you using your framework, your conventions. How do we make it really good at explaining code? Because it can search through the entire codebase to find the 15 or 20 relevant code files.
So weāre building on this foundation of code searchā¦ And what Iāll say with code search is I use it all the time. I think every dev would do well to use code search more. Itās so good at finding examples. Reading code is the best way to uplevel as a software engineerā¦ But Cody and code AI is something that every dev thinks that they should be using. So given that they solve so many of the same problems, this problem that caused us to found a company; if itās so damn hard to build software, itās really hard to understand code. They both solve the same problem. And if what people want is Cody, more than code search - well, code search still exists, and itās growing, and itās the foundation for Codyā¦ But weāre going to be talking about Cody all day, because thatās what people are asking for. And thatās what we hear from our users. We see a lot of people come in for Cody, and then they also realize they love code searchā¦ But I think Cody is going to be the door in. Itās so easy to get started, and it is just frankly magical. I think everyone can speak to that magic that they see when AI solves their problem. Like you did with that picture frame example.
Yeah. Can you speak to the ease of which it was to sell Sourcegraph, the platform two years ago, to how easy it is to sell it now? You kind of alluded to it to some degree, but can you be more specific?
Yeah. Two years ago would have been 2021, the end of 2021, which was the peak of the market; the peak of kind of everything. And I think thereās been a lot of big changes in how companies are hiring software engineers, and budget cuts, and so on. So weāve seen a big change over the last two years. Code search has grown by many, many times since thenā¦
[00:34:01.11] But what we saw is with companies realizing āHey, maybe weāre not going to be growing our engineering team at 50% each year.ā We saw a lot of kind of developer platform, developer happiness, developer experience initiatives get paused in favor of cost cutting. āHow can we figure out what are the five dev tools that we truly need, instead of the 25? Where in the past, if a dev loved something, then yeah, weād go in and plop down a bunch of money.ā
And so we were well positioned because we had such broad usageā¦ And because a lot of companies looked at us as a platform, they built stuff against our API, and every team used it, we were in a good position there. I think though, if AI had not come out about a year ago, then I donāt know what the DevStack would look like. I think youād have a lot of companies that realized āHey, weāve been keeping our eng hiring really low for the last two yearsā¦ā Iām not sure now ā companies see AI As a way to get as much as they were getting in the past, but with less developers. And developers see it as a way to improve their productivity. And I think the missing piece that weāre not fully seeing yet is thereās a lot of companies out there that would love to build more software, but were just unable to, because they didnāt know how to, they were not able to hire a critical mass of software engineers, they were not in some of the key engineering hiring markets, developers were too expensive for them to hireā¦ But all these other companies that would have loved to build software, they were just bottlenecked on not being able to find the right engineers. I think that AI is going to help them overcome that, and youāre gonna see software development be much more broadly distributed around a lot of companies. And that is whatās exciting.
So looking at the overall software developer market, around 50 million professional developers, around 100 million people, they write code in some way in their job, including like data analysts. I fully expect that number to go up, and I fully expect that pretty much every knowledge worker in the future is gonna be writing some code in some way. So Iām not pessimistic on the value of learning how to code at allā¦ But thereās just been massive change in how companies are seeing software development and the structure of teams over the last couple of years.
I think when we talked last time you were saying, either exactly, or in a paraphrasing way, that it was challenging to sell code search. That it was not the most intuitive thing to offer folks. You obviously, founders, understand how deeply it was useful, because you worked inside of Google, you saw a different lens towards code searchā¦ And most people just saw Command+F, or even Command+Shift+F as just something that was built in, rather than something that you went and bought, and stood up separately as a separate instance, that had this other intelligence. And that was hard to sell. However, code search that is being understood by an LLM, Cody, is a lot easier to offer, because you can speak to it. Very much like weāve learned how to chat with artificial intelligence to generate and whatnot like that.
So Iām curious, even when we were done talking on the last time on Founders Talk, you werenāt ready to share this intelligence side, which was also the next paradigm. I think this intelligence factor - obviously, code search gives you intelligence, because you can find and understand moreā¦ But it was the way that you built out insights and just different things like that, that allowed you to not only manually, like a caveman or cave person type in all these things you can into search; you could just sort of form an intuitive graph towards, like youād mentioned before, the calls to a database going down, and calls to the new database going up, and you can see the trend line towards progress. Clearly. And even share that dashboard with folks who are not in development, in engineering. Sharing with comms, or marketing, or CEOs, or whomever is just not daily involved in the engineering of their products. And Iām just curiousā¦ Give me really specifics, like how easy it is to sell now because Cody just makes the accessibility, the understandability of what Sourcegraph really wanted to deliver so much easier?
[00:38:11.25] Yeah, Cody does make it so much easier. And yeah, going back two years ago, we had a fork in the road. We could have either made just code search, something that clicked with so many more developers, and overcome that kind of question which is āYou know, Iāve been coding for 10 years. I havenāt had code search. I have it in my editor. Why would I need to search across multiple repositories? Why would I need to look through different branches? Why would I need kind of global [unintelligible 00:38:39.15] definition? Why would I need regex search that works?ā We got a lot of questions like that. We could have just doubled down on that and tried to get, for us, way more devs using it for open source code, and within our customers 100% of every developer, and all of our customers using code search. We could have done that. What we decided to do was go deeper into the intelligence, to build things that were exposed as more power user tools, like the code insights. Code Insights is something that platform teams, that architects, and security teams, managers - they love, it has incredible value for them, but for the average application engineer theyāre not really looking at code insights, because theyāre not planning these big, codebase-wide refactors. Same with batch changes. Platform teams love it, people that have to think in terms of the entire codebase, rather than just their feature, they need it. And I think we got lucky, because given that right around that time, thatās when developer hiring began to really slow down. It was really helpful for us to get some really deep footholds in these critical decision-makers, just from a sales point of view, in companies, to have like very deep value, instead of kind of broad, diffused value.
So that ended up being right. It also ended up being right in another way, which is we got deeper in terms of what does Sourcegraph know about your codebase? And that was valuable for those humans over the last couple of years, but itās also incredibly valuable now, because we have that kind of context that can make our code AI smarter. But I do really lament that most devs are not using code search today. I think itās something that would make them much better developers, and thereās absolutely a part of me that wishes I could just go have 50 amazing engineers here work on just making it so that code search was so damn easy to use, and solved every developerās problem. Now weāre tackling that with Cody, because weāve got to stay focusedā¦ And to your point, they do solve the same problem. And with code search, if youāre trying to find out āHow do I do this thing in code?ā, code search will help you find how all of your other colleagues did it. Cody will just look at all those examples and then synthesize the code for you. And so thereās so much similarityā¦ And we are just finding that Cody is so much easier to sell.
But we did have a cautionary moment that I think a lot of other companies did. Back in February to May of 2023 this year, if you said AI, if you said āOur product has AIā, literally everyone would fall over wanting to talk to you, and theyād say āMy CEO has given me a directive that we must buy AI. We have this big budget, and security is done, legal is done, we have no concerns. We want it as soon as possible.ā And it didnāt matter if the product wasnāt actually good. People just wanted AI. And that I think created a lot of distortions in the market. I think a lot of product teams were misled by that. Iām not saying that the customers did anything wrong. I think we were all in this incredible excitement. And we realized that we didnāt want to get carried away with that. We wanted to do the more boring work, the work of āTake the metric of accuracy, and DAUs, and engagement, and overall a lovable product, and just focus on that.ā We did not want to go and be spinning up the hype.
[00:42:04.06] So we actually really pulled back some of this stuff and we level-set with some customers that we felt wanted something that nobody could deliver. And that was one of the ways that we came up with these levels of code AI taking inspiration from self-driving cars. We didnāt want the hype to make it so that a year from now everyone would become disillusioned with the entire space. So definitely a big learning moment for us. And if thereās an AI company out there that is not looking at those key user metrics that have always mattered, the DAU, the engagement, the retention, the quality, then youāre gonna be in for a rude awakening at some point, because exploratory budgets from customers will dry up.
Well said. I think itās a right place, at the right time, really. I would say the right insight a long time ago to get to the right place, to be at the right place, at the right time. Because everything that is Cody is built on the thing you said you lament that developers would use; itās built on all the graph and all the intelligence thatās built by the ability to even offer code search, at the speed that you offer it. And then obviously, your insights on top of that. So itās like, you took ā itās like having the best engine and putting it in the wrong car, and nobody wants to buy the carā¦ And then suddenly, you find like this shell that performs differently, maybe itās got better ā I donāt know, just in all ways it feels better to use, and itās more just straightforward to use; you still have the same engine, itās still the same code search, but itās now powered by something that you can interact with in a meaningful way, like weāve learned to use with having a humanistic conversation with software running on a machine.
I think thatās just such a crazy thing to be ā thatās why I wanted to talk to you about this, because youāve hadā¦ I mean, some people think that Sourcegraph was born a year or two ago, that know your name. And youāve been like on a decade journey. I donāt even know what your number is; itās getting close to a decade, if not past a decade, right?
Yeah. We started Sourcegraph a decade ago.
And so Iāve been a fan of yāalls ever since then. And for a long time, just a fan hoping that you would get to the right place, because you provided such great value, that was just hard to extract, right? The ability to extract the value from Sourcegraph is easier thanks to Cody than it was through code search, because of obvious things we just talked about. Thatās an interesting paradigm to be in, a shift to be in, because youāre experiencing that, Iām assuming, to some degree, a hockey stick-like growth, as a result of the challenges you faced earlier, that now are diminished to some degree, if not all degrees, because of the ease of use that Cody and things like Cody are.
Yeah. And code search, when we started bringing that to market in 2019, that was a hockey stick. But now we realized that was a little league hockey stick, and that now this is the real hockey stick.
And Iāve been reading ā I love reading history of economics, and inventions, and so onā¦ And Iāve been reading about the oil industry. The oil industry got started when someone realized āOh, thereās oil in the ground, and this kerosene can actually light our homes much better and much more cheaply than other kinds of oil, from whales, for example.ā And initially, oil was all about illumination. Make it so that humans can stay up after 6pm when the sun goes down. And that was amazing. But thatās not how we use oil today. Oil is just this energy that powers everything; that powers transportation, that powers manufacturing, that powers heating, and so on. And there were people that made fortunes on illumination oil, but that pales in comparison to the much better use of oil for our everyday lives. And now, of course, you have renewables, and you have non-oil energy sourcesā¦ But for a long time, we saw that that initial way of using oil was actually not the most valuable way.
[00:46:14.09] So seeing that this just happens over and over, that a new technology is introduced and youāre not quite sure how to use it, but you know that itās probably going to lead to somethingā¦ And thatās how we always felt with code intelligence, and thatās ā us getting new Intelligent Automation is so exciting for us now.
One of the really exciting things weāre seeing is because ā so many people are shocked that these LLMs, you speak to them humans. They seem to feel much more human-like than what we perhaps anticipated AI would be like. We think of AI from movies as being very robotic, of lacking the ability to display empathy, and emotion, and thought processes. But actually, that is exactly how we see LLMs. Iāve seen some studies even the show that LLMs can be better at empathy than a doctor with a poor bedside manner, for example. And for us, this is absolutely critical, because all this work we put into bringing information about code to the human brain - it turns out that AI needs that same information. That AI - well, the human, if you started a new software engineering job, you get your employee badge, you go read through the code, read through the docs, if thereās an error message youāll look at the logs, youāll go in team chat, youāll join meetingsā¦ Thatās how humans get that information. And AI needs all that same information. But the problem is, you cannot give AI an employee badge and have them roam around the halls and stand at the watercooler. Thatās just not how AI works.
So we just happen to have broken down all that information into how can we think of it programmatically. And now thatās how we teach it to Cody.
I always throw the word yet in there whenever I talk about status quo with artificial intelligence or innovationā¦ Because my son - heās three; he loves to watch āthe robot dance videoā, he calls it. It was Boston Dynamics, that āDo you love meā song. And they have all the robots dancing to it. And Iām just thinking like āWhen is the day when itās more affordable, or to some degree more affordable to produce that kind of humanoid-like thing that can perform operations?ā Now, I know itās probably not advantageous to buy an expensive Boston Dynamics robot to stand at your water cooler. But thatās today. What if 50 years from now itās far more affordable to produce those, and theyāre en mass produced with the things that are completely separate from it in the future? Maybe it might make sense eventually to have this water cooler-like scenario where youāve got a robot thatās the thing that youāre talking to. Iām just saying. Thatās why I said the word yet.
Yeah, yeahā¦ And youāve got to have this humility, because who knowsā¦?
Okay, so letās talk about some about winning. Can we talk about winning for a bit? So if youāre on this little league hockey stick with search, and then now itās obviously major league hockey stick - I think your head-nodding to that to some degree, if not voicingly affirming thatā¦
When I search āGitHub Copilot versusā, because I think Copilot has a brand name because they were one of the first AI code-focused tools out there. Now, obviously ChatGPT broke the mold and became the mainstream thing that a lot of people know aboutā¦ Itās not built into editors directly. It might be through GitHub Copilot and Copilot Xā¦ But even when I search āGitHub Copilot Xā or just Copilot by itself versus, Cody does not come up in the list. Tabnine does, and even VS Code doesā¦ And that might be biased to my Google search. And this is an example where Iām using Google versus ChatGPT to give me this versus. Now, I might query ChatGPT and say āOkay, who competes with GitHub Copilot?ā And you might be in that list. I didnāt do that exercise. What Iām getting at is, of the lay of the land of code AI tooling, are you winning? Who is winning? How has it been compared? What are the differences between them all?
Yeah, Copilot deserves a ton of credit for being the first really good code AI tool, in many waysā¦ And I think at this point itās very early. So just to put some numbers to that, GitHub itself has about 100 million monthly active users, and according to one of GitHubās published research reports - thatās where I got that 0.5% number from - they have about a million yearly active users. And thatās the people that are getting suggestions, not necessarily accepting that even. So a million yearly actives - what does that translate into in terms of monthly actives? Thatās a tiny fraction of their overall usage. Itās a tiny fraction of the number of software developers out there in the world. So I think itās still very early. And for us, for other code AI tools out there, I think people are taking a lot of different approaches. Thereās some that are saying āWeāre just gonna do the cheapest, simplest autocomplete possibleā, and thereās some that are saying weāre gonna get jumped straight to trying to build an agent that can replace a junior developer, for example. I think that youāre seeing a ton of experimentation. What we have, which is unique, is this deep understanding of the code. This context. And another thing that we have is we have a ton of customers, where Sourcegraph is rolled out over all of their code. And working with those customers - I mean, I mentioned some of the names beforeā¦ These are customers that are absolutely on the forefront, that want this code AI, and itās a goldmine for us to be able to work with them.
So when you look at whatās our focus, itās how do we build the very best code AI that actually solves their problem? How do we actually get to the point where the accuracy is incredibly high? ā¦and we see Cody having the highest accuracy of any code AI tool based on completion acceptance rate. How do we get to the point where every developer at those companies is using Cody? And thatās another thing where weāve seen ā thereās a lot of companies where, yeah, theyāre starting to use code AI, and five devs over here use Copilot, five over here use something elseā¦ But none of this has the impact that we all want it to have until every dev is using it. As we learn with code search, itās so important to make something that every dev will get value from, that will work for every dev, that will work with all their editors, that will work with other languages. And thatās the work that weāre doing now.
[00:56:17.09] So I donāt know the particular numbers of these other tools out thereā¦ I think that everyone has to be growing incredibly quickly, just because of the level of interest, but itās still very early and most devs are up for grabs. I think the thing thatās going to work is the code AI that every dev can use and instantly see working. And what are they gonna look at? Theyāre gonna say āDid it write good code for me? Is that answer to that code question correct or not? Did it cite its sources? Does it write a good test for me?ā And itās not going to be based on hype.
So we just see a lot of ā itās kind of like eating your vegetables work. Thatās what weāre doing. Sometimes itās tempting. When I see these other companies come out with these super-hyped up promises that - you know, ultimately, I think we all try their products and it doesnāt actually work. We do not want to be that kind of company, even though that could probably juice some installs, or something like that. We want to be the most trusted, the most rigorous. And if that means that we donāt come up in your Google Search autocomplete - well, I hope that we sell that by the time Cody is GA in Decemberā¦ But so be it, because our customers are loving it, our users are loving it, and weāre just so laser-focused on this accuracy metric.
And by the way, that accuracy metric - we only can do that because of the context that we bring in. We look at, when weāre trying to complete a function, where else is it called across your entire codebase? Thatās what a human would look at to complete it. Thatās what the AI should be looking at. Weāre the only one that does that. We look at all kinds of other context sources. And itās taken a lot of discipline, because there is a lot of hype, and thereās a lot of excitement, and itās tempting to do all this other stuffā¦ But Iām happy that weāre staying really disciplined, really focused there.
Yeah, the advantage I think youāre alluding to directly is that Sourcegraph has the understanding of the codebases that it has already available to it. That might require some understanding of how Sourcegraph actually works, but I think to be quick about it, that you sort of ingest one or many repositories, and Cody operates across those one or many in an enterprise. You mentioned a couple different companies; pick one of those and apply it there. Whereas, famously and infamously, GitHub - not X Copilot - was trained primarily on code available out there in the worldā¦ Which is not your repository; itās sort of everybody elseās. So you sort of inherit, to some degree, the possibility of error as a result of bad code elsewhere, not code here, so to speak.
I think Tabnine offered similar, where they would train an artificial intelligence code tool that was based upon your own codeās understanding, although Iām not super-deep and familiar with exactly how they work. We had their CEO on the podcast, I want to say about two years ago, again. So weāre probably due for a catch-up there, to some degree. But I think itās worth talking through the differences, because I think thereās an obvious advantage with Sourcegraph when you have that understanding. And not only do you have understanding; like you said, youāve done your reps. Youāve been eating your vegetables for basically a decade, you know what Iām saying? So youāve kind of earned the efficiencies that youāve built into the codebase and into the platform to get to this understanding for one, and then actually have an LLM that can produce a result thatās accurate is step two. You already had the understanding before, and now youāre layering on this advantage. I think itās pretty obvious.
Is a lot of your focus, it sounds like, is on vertical in terms of current customer base, versus horizontal across the playing field? Like you probably are going after new customers and maybe attracting new customers, but it sounds like youāre trying to focus your reps on the customers you already have, and embedding further within. Is that pretty accurate? Whatās your approach to rolling out Cody, and how do you do that?
[01:00:07.02] Hereās my order of operations when I every three hours look at our charts. First, I look at what is our accuracy.
Every three hours?
Oh, yeah. Yeah. I love doing this.
Do you have an alarm or something? Or is this an natural built-in habit youāve got?
I think a natural built-in habit. So first, I look at what is our accuracy, our completion acceptance rate, and how is that trending, broken up by language, by editor, and so on. Itās the first thing I look at. Next, I look at latency. Next, I look at customer adoption, and next I look at DAU, and retentionā¦ And that gets all this broad adoption. And everything is growing. Everything is growing in a way that makes me really happy, but the first and most important thing is a really high-quality product. That is what users want. Thatās what leads to this growth in users. But thatās also what helps us make Cody better and better. Thatās what helps us make Cody so that it can do more of the grunt work, or whatever parts of the job that developers donāt like. If we were just to be at every single event, and we had all this content, we could probably get our users higher, faster than making the product better. But thatās not a long-term way to win.
And so instead, weāre seeing āHow do we use our code graph more?ā How do we get better, entire codebase references? How do we look at syntactical clues? How do we look at the usersā behavior? How do we look at - of course, what theyāve been doing in their editor recently, like Copilot does, but how do we take in other signals from what theyāre doing in their editor? How do we use our code search? How do we use conceptual search and fuzzy search to bring in, where this concept of say GitLab authentication exists elsewhere in their code, even if itās in a different language? How do we bring in really good ways of telling Cody what goes into a really good test? And if you just asked ChatGPT āHey, write a test for this functionā, itās gonna write some code, but itās not going to use your languages, your frameworks, your conventions, your test setup and teardown functions. But we have taught Cody how to do that. Thatās all that stuff that weāre doing under the hood, but we donāt need developers to know about that. What they need to see is just this works. The code that writes is really good. And by the way, with the things I mentioned - those are six or so context sources that if you compare to other code AI tools, theyāre maybe doing one or two. But weāre not stopping there, because - you know, take a simple example; if you want the code AI to fix a bug in your code - well, itās probably gotta go look at your logs. Your logs are probably in Splunk, or Datadog, or some ELK Stack somewhereā¦ And so weāre starting to teach Cody how to go to these other tools. Your design docs are in Google Docs. Youāve probably got tickets in Confluence that have your bugs; thatās important for a test case. And you also have your product requirements in JIRA. JIRA, Confluenceā¦ You want to look at the seven static analysis tools that your company uses to check code, and thatās what should be runā¦ So all these other tools, Cody will integrate with all of them. And they come from so many different vendors, companies that have in-house toolsā¦ And that ultimately is the kind of context that any human would need if they were writing code. And again, the AI needs that context, too.
We are universal. Weāve always been universal for code search, no matter whether your code is in hundreds of thousands of repos, or across GitHub, GitLab, Bitbucket and so onā¦ And now itās ā well, what if the information about your code, the context of your code is scattered across all these different dev tools? A good AI is going to need to tap all of those, and thatās what weāre building. And then you look at other tools from vendors that are ā you know, maybe the future of their code AI will tap their version of logging, their internal wikiā¦ But very few companies use a single vendors suite for everything and are totally locked in. So that universal code AI is critical. And thatās how weāre already ahead today with context, that leads to better accuracyā¦ But thatās how we stay ahead. And developers have come to look at us as this universal, this independent company that integrates with all the tools they use and love. So I think thatās gonna be a really long-term, enduring advantage, and weāre putting a ton of investment behind this. Weāre putting the entire company behind this. So it takes a lot of work to integrate with dozens and dozens of tools like this.
[01:04:27.25] For sure. What does it take to sell this? Do you have a sales organization? Who does that sales organization report to? Does that report to both you and Beyang collectively, or you because youāre CEO, or is there somebody beneath you they report to and that person reports to you? And whenever you go to this metrics every three hours and you see letās say a customer that should be growing at a rate of x, but theyāre not, do you say āHey, so and so, go and reach out to so and make something happen?ā or get a demo to them, because weāre really changing the world here and they need to be using this world-changing thing, because we made it and theyāre using us, and all the good things? How does action take place? How does execution take place when it comes to really winning the customer, getting the deal signed? Are there custom contracts? I see a way where I can sign up for free, and then also contact. So it sounds like itās not a PLG. Kind of PLG-esque. You can start with a free tier, butā¦ Are most of these deals, are they homegrown? Is there a sales team? Walk me through the actual sales process.
Yeah, everyone at Sourcegraph works with customers in some way or anotherā¦ And weāve got an awesome sales team, we also have an awesome technical success team, that goes and works with users that are our customers. We see a few things come up. When I look at a company, sometimes Iām like āMan, if every one of your developers had Cody tomorrow, they would be able to move so much faster.ā And yet, you know, I canāt just think that and expect that to happenā¦ So one of the reasons that we see companies slower to adopt code AI than perhaps they themselves would even like to is theyāre not sure how to evaluate it. Theyāre not sure how to test it. Theyāve got security and legal questions, but sometimes they want to see what is the improvement to developer productivity. Sometimes they want to run a much more complex evaluation process for code AI, than they would for any other tool out there, just because thereās so much scrutiny, and nobody wants to mess this up. So what we advocate for, what GitHub advocates for is thereās so much latent value here. Look at accuracy, look at that completion acceptance rate, and that is the quality metric. And then thereās a lot of public research out there showing that if you can show a favorable completion accuracy rate inside of a company, then that will lead to productivity gains, rather than having to do a six-month-long study inside of each company. So thatās one thing that helps.
Another thing is sometimes companies say āWe want to pick just one code AI tool.ā And I think thatās not the right choice. That would be like a company picking one database in the year 1980, and expecting that to stick forever. This space is changing so quickly, and different code AI tools have different capabilities. So we always push for āGet started with the people that are ready to use it todayā, rather than trying to make some big top-down decision for the entire organization.
Okay, so two co-founders deeply involved day to dayā¦ One thing I really appreciate - and I often reference Sourcegraph, and I suppose you indirectly by mentioning Sourcegraphā¦ Sometimes you by name, you and Beyang by name, but sometimes just āthe co-foundersā. So I lump you into a moniker of the co-founders. And I will often tell folks like āHey, if youāre a CEOāā I often talk to a lot of different CEOs, or foundersā¦ And they really struggle to speak about what they do. They literally cannot explain what they do in a coherent way very well. It happens frequently, and those things do not hit the air, letās just say. Right? Weāre a podcast primarily.
[01:08:13.11] Or I have bad conversations about possible partnerships and possible working with them, and itās a red flag for me. If Iām talking to a CEO in particular, that has a challenge describing what they do, Iām just like āDo we really want to work with them?ā But you can speak very well. Congratulationsā¦ You and Beyang are like out there as almost mouthpieces and personas in the world, not just to sell Sourcegraph, but you really do care. I think you both do a great job of being the kind of folks who co-found and lead, that can speak well about what you do, why youāre going the direction youāre going, and thatās just not always the case. How do you all do that? How do you two stay in sync? Has this been a strategy, or did you just do this naturally? What do you think made you all get to this position to be two co-founders who can speak well about what you do?
We have learned a lot since we started Sourcegraph on this in particular. And even when describing Sourcegraph, we say āCode search. And now we also do code AI.ā And I think some people are definitely relieved when they ask āHey, what does Sourcegraph do that itās four words?ā Because I think thereās a lot of companies where they do struggle to describe what they do in four words. And yet, we were not always at this point. Iām coming here from a position where we have a lot of customers. Weāve validated that we had product-market fit, that a ton of people use those products, and that I can say that. But before we had that, there was a lot of pressure on me from other people and for me internally to make us sound like more than code search. Because code search feels like a small thingā¦ Which, seems silly in hindsight. Does Google think that search is a small thing? No. But there was a lot of pressure to say āWeāre a code platform-platform, a developer experience platformā, or that we revolutionize and leverage, and all this stuff. Thereās a lot of pressure ā
ā¦but nothing beats the confidence of product-market fit, of having a lot of customers and users just say what you actually do. And one way we started to get that even before we had all that external validation was Beyang and I use our product all the time. We code all the time. I donāt code production features as much, but we fundamentally know that code search is a thing that is valuable. That Cody, that code AI is the thing thatās valuable. And we felt that two weeks after we started the company. We were building Sourcegraph and we were using Sourcegraph, and for me, it saved me so much time, because it helped me find that someone had already written a bunch of the code that I was about to write for the next three weeks. So it saved me time in the first two weeks. And from then, itās clicked. So I think as a founder, use your product, and if youāre not using your product, make it something ā make it so good that you would use it all the time. And then iterate until you find the thing that starts to work, and then be really confident there. But itās tough until youāve gotten those things.
Thatās cool, man. It does take a journey to get to the right place. I will agree with that. And just know that out there you have an Adam Stacoviak telling folks the way to do it is Sourcegraph.
You guys are great co-founders, you guys seem to work great togetherā¦ I see you on Twitter having great conversationsā¦ Youāre not fighting with people, youāre not saying that youāre the best, youāre just sort of out there, kind of iterating on yourselves and the product, and just showing up. And I think thatās a great example of how to do it in this world where all too often weāre just marketed to and sold to. And I donāt think that you all approach it from a āWe must sell more, we must market more.ā Thatās kind of why I asked you the sales question, like how do you grow? And you didnāt fully answer, and thatās coolā¦ You kind of gave me directional, you didnāt give me particulars. But thatās cool.
[01:12:04.16] Yeah. Well, lookā¦ If you just take the customers that we have today, we could become one of the probably at the highest adoption code AI tool, the highest value code AI tool just by getting to all the devs in our existing customers; not even adding another customer. And that just seems to me to be a much better way to grow, through a truly great product, that everyone can use, that everyone can adopt, thatās so low frictionā¦ Rather than something thatās not scalable, than getting billboards, or buying adsā¦ Thatās all part of the portfolio approach that youāve got to take, but ultimately, the only thing thatās gonna get really big is a product that not only do people love so much they spread, but where they ā it gets better when they use it with other people. Thatās the only thing that matters. Anything else, youāre gonna get to a local maximum.
Very cool. Okay, so weāre getting to the end of the showā¦ I guess, whatās next? Whatās next for Cody? Give us a glimpse into whatās next for Cody. What are you guys working on?
For us itās really two things. Itās keep increasing that accuracy. Just keep eating our vegetables there. Maybe thatās not the stuff that gets hype, but thatās the stuff that users love. And then longer term, over next year, itās about how do we teach Cody about your logs, about your design docs, about your tickets, about performance characteristics, about where itās deployed? All these other kinds of context that any human developer would need to know. And ultimately, thatās what any code AI would need to know if itās going to fix a bug, if itās going to design a new feature, if itās going to write code in a way that fits your architecture. And you donāt see any code AI tools even thinking about that right now. But thatās something where I think we have a big advantage, because weāre universal. All those pieces of information live in tools from so many different vendors, and we can integrate with all of themā¦ Whereas any other code AI is going to integrate with the locked-in suiteā¦ And youāre probably not using whatever vendorās tools for a wiki, for example, and their logs, and all that. So thatās a huge advantage. And thatās how we see code AI getting smarter and smarter. Because itās going to hit a wall, unless it can tap that information. And you already see other code AI tools hitting a wall; not getting better much over the last one or two years, because they cannot tap that context. Itās all about context, context, context, whether youāre feeding that into the model at inference time, whether youāre fine-tuning on thatā¦ Itās all about the context. So thatās what weāre gonna be completely focused on, and we know the context is valuable if it increases that accuracy. And what a beautiful situation with this incredibly complex, wide open space, that you actually can boil it down basically to a single metric.
So thatās our roadmap - just keep on making it better, and smarter, and in ways that means developers are going to say āWow, it wrote the right code, and I didnāt think that it could write an entire file. I didnāt think it could write many files. I didnāt think it could take that high-level task and complete it.ā Thatās what weāre gonna be working toward.
Well said. Very different conversation this time around than last time around, and I appreciate that. I appreciate the commitment to iteration, the commitment to building upon the platform you believed in early on to get to this place, and - yeah, thank you so much for coming on, Quinn. Itās been awesome.
Yeah, thank you.
Changelog
Our transcripts are open source on GitHub. Improvements are welcome. š
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK