Reaching industrial economies of scale (Interview)

27:57A lot of times those other teams don't necessarily care too much about the change that you're trying to land because they have their own priorities and they're incentivized to work on those and not, you know, anything else that happens in the company. So, you know, who knows how long it'll take to get all the stakeholders to sign off on that change. Or, you know, maybe you realize through the review that you get from like a senior engineer that this whole approach was wrong because you didn't do enough like search and discovery. So it's almost like this game of chutes and ladders. Like you have a potential to shoot all the way back to scratch.

28:29Like you just wasted, you know, a week, a month's worth of work because you built the wrong thing. Best case, you know, it takes a lot of, like, time getting people to approve it. You finally get it approved. It rolls out to production. Maybe it breaks something. Maybe there's, like, a test that breaks that you didn't catch locally and so on and so forth. Once it gets into production, there's, you know, a long tail of issues that could arise, too, in terms of, like, you know, it triggered some bug or maybe there was some, like, security vulnerability that got introduced. Anyways, I don't have to sketch this out.

29:00It's already painful. just describing this. I'm wanting to quit right now. I'm like, gosh, save me. Yeah, and this is just like a simple feature, right? Like it could be the simplest thing, like center this div or add support for this authentication protocol or whatever. And most of your time is spent not on thinking about the end user problem and mapping that to the algorithms and data structures that you can use. Like that's the fun part of the job. Like if I could do that all day, every day, I would do that all day, every day. But most of it is spent on like box checking, writing boilerplate, finding answers to questions that you know have already been answered many times before.

29:40And so like Sourcegraph essentially targets all the kind of critical pain points and slowdowns in that process. So, you know, in the planning and search and discovery phase, like that's where people use a lot of our code search functionality. or now we kind of have like a deep research for your code base like feature that's built into the web application where you can ask our AI a question about the repository. It will go and do a bunch of searches and file readings on your behalf and print out like what is usually a pretty reasonable summary of, you know, the relevant files to read and how those fit to the tasks that you're trying to accomplish.

30:13so automatically like that shortcuts you from having to have and wait on all these like conversations with humans that let's be honest like developers as a collective group we're not like the most personable or like affable people um i mean many of us are but like you know speaking in terms of averages we we tend towards like introversion just like you know like the spending time with our computers like that that's why we're doing what we do right right plus you know So even the ones that want to help, if you've answered the same question from like three or four different people in the past week, you're at the point where you're like, I just want to do my freaking work.

30:51I don't want to have to deal with any of these other things, even if they're like reasonable requests. So we can shortcut that process and just help you figure that out yourself through a combination of search and question answering. Then within the editor, there's all this stuff that reduces to boilerplate++, which is like in the sweet spot for what AI can do. So you tag in the relevant file or you ask it to do a search for the relevant code snippets on your behalf and then ask it to generate code. It generates the code. You can refine that in the chat window, apply it into the file. And that is just such a, it adds value in a couple of different ways.

31:29The first is like the raw time saved because you don't have to manually type out all the characters for that, you know, boilerplate plus plus. The second thing we've noticed is that it kind of changes the psychology a little bit because it keeps you in flow state more. Like if you don't have to page out all the working state in your brain because now you need to go down this rabbit hole and like complete this side quest to get your feature built. If Cody can essentially do that for you or even get you like 90 % of the way there, you essentially don't have to page out the context for doing the main thing.

32:01And as a consequence, you can kind of remain in flow state for much longer. You don't have this like context switching that is very destructive. And so like that is where we probably see like an insane amount of productivity boost. I think like the number that Palo Alto quoted at us using their own kind of like internal metric or proxy for developer velocity, it was depending on which number you specifically is between 40 and 57%, which is a crazy speed up. That's like a game changing speed up. And it turns out like it just makes the job more fun too, right? Because like you don't want to spend all your hours writing boilerplate or pattern matching against stuff that's already written.

32:42You want to get to the fun stuff of the job, which is really thinking about like the user experience and then the underlying algorithms and data structures. Once you push things up to review, Two, what we built in collaboration with a couple of our customers is now in early access. And probably by the time this is released, we'll have open access for it, is a review agent. So this is code review that understands how your organization does code review. And so the idea here is, one, we want to automate the process of code review because there's a bunch of comments that humans don't think to leave or just they don't get around to leaving.

33:23There's the old adage, like if you push up a 10 line pull request, you get 10 comments. But if you push up like a 10 ,000 line PR, you'll just get a rubber stamp like looks good to me because no human. Yeah, it's too much. It's like, what else am I supposed to do today other than review this PR? I got a life to live. I got work to do. Well, like an AI can just sit there and spend the time to surface like a bunch of common things that you as a human, it's probably a waste of your time to check. All this stuff is automatable now with modern LLMs. So we want to do that. There's also kind of like a psychological component here where we don't see our code review agent as being a complete replacement for human review yet, but it's at the point where if it leaves at least a first pass of comments, number one, it allows you as the author of the change to kind of iterate quickly against that.

34:19And also it incentivizes the reviewer to go in and do a more thorough review too, because the comments kind of reflect, uh, like a summary of the change itself and just having like a comment exist on the PR, it just makes the task seem like already halfway done. And so you momentum, yeah, momentum. It just, it, it, it leads people to, to like quicken the review cycle too. Psychology, baby. Yeah. Yeah. It's a combination of like, if you introduce efficiencies, you also get these like nice second order psychological effects that further speed up the development cycle. Right. Especially after a few cycles of this, you begin to gain some trust for the system, let's just say.

35:00I don't want to anthropomorphize this thing, but we tend to. Sometimes we even say please or thank you to our agents, which is cool, whatever. You do your thing, just waste some tokens, basically. But you begin to trust it. So it's like, well, I at least know oh, I've got to start somewhere. And so this analysis of the code review makes me feel like even if I only had to do 10%, it's better than 100%, you know, because now I can actually do my job today. I can do the two meetings I have planned and actually potentially get a review in to potentially get this into production. And that's a great thing.

35:38Totally. It provides, it's almost like a smoother on-ramp. There's like an activation threshold you have to get beyond to get started on a particular task. like in this case, code review. And without AI, it's like, oh, I'm dreading this because it's like, it's going to, I need to get over that threshold. Now we can like do the first like one or two steps. And then that kind of like leads you into, it's like the same thing as like, you know, how some writers, they say like making a mark on the page, like writing a anything. Yeah. Anything like a very bad first draft. That's just like God awful.

36:13Or like if an artist just like drawing a squiggle on the paper, it kind of unblocks you. It gets you past this like blank slate mental block that I think a lot of people suffer from, especially if it's a task that you associate with toil, which I think a lot of people do. It's like, I can't even do this. Yeah. I've been there. I've definitely had to do some code reviews and I was like, yeah, rubber stamp that thing looks good. Yeah. Let's just, let's test in production. you know let's yeah yeah right it's like you wrote a lot of code i think you probably understand this you know much better than i do let's just you know we'll say it looks good and then we can both get on with our lives i think that some version of that conversation happens all the time inside enterprises and you know it happens out of necessity but it's it's not good that it happens right because like you have reviewing standards for for a reason and that's how bugs and security vulnerabilities and, you know, bad architecture and loss of cohesion.

37:13Yeah.

37:31Well, friends, I'm here with Scott Deaton, CEO of Augment Code. Augment is the first AI coding assistant that is built for professional software engineers and large code bases. That means context aware, not novice, but senior level engineering abilities. Scott Flex for me, who are you working with? Who's getting real value from using Augment Code? So we've had the opportunity to go into hundreds of customers over the course of the past year and show them how much more AI could do for them. companies like Lemonade, companies like Kodem, companies like Lineage and Webflow. All of these companies have complex code bases.

38:10If I take Kodem, for example, they help their customers modernize their e-commerce infrastructure. They're showing up and having to digest code they've never seen before in order to go through and make these essential changes to it. We cut their migration time in half because they're able to much more rapidly ramp, find the areas of the code base, the customer code base that they need to perfect and update in order to take advantage of their new features. And that work gets done dramatically more quickly and predictably as a result. Okay, that sounds like not novice, right? Sounds like senior level engineering abilities.

38:44Sounds like serious coding ability required from this type of AI to be that effective. 100%. You know, these large code bases, when you've got tens of millions of lines in a code base, you're not going to pass that along as context to a model. right? That is would be so horrifically inefficient. Being able to mine the correct subsets of that code base in order to deliver AI insight to help tackle the problems at hand. How much better can we make software? How much wealth can we release and productivity can we improve if we can deliver on the promise of all these feature gaps and tech depth? AIs love to add code into existing software.

39:23You know, our dream is an AI that wants to delete code, make the software more reliable rather than bigger. I think we can improve software quality, liberate ourselves from tech debt and security gaps and software being hacked and software being fragile and brittle. But there's a huge opportunity to make software dramatically better. But it's going to take an AI that understands your software, not one that's a novice. Well, friends, Augment taps into your team's collective knowledge, your code base, your documentation, dependencies, the full context. You don't have to prompt it with context. It just knows.

39:57Ask it the unknown unknowns and be surprised. It is the most context aware developer AI that you can even tap into today. So you won't just write code faster. You'll build smarter. It is truly an ask me anything for your code. It's your deep thinking buddy. It is your stay in flow antidote. And the first step is to go to augmentcode.com. That's A-U-G-M-E-N-T-C-O-D-E.com. Create your account today. Start your free 30-day trial. No credit card required. Once again, augmentcode.com.

40:36So is that where I think we're here because we talked about the day in the life of. Where do we go from after code review? Like you're painting the landscape of source graph, what a engineer may have access to, to reduce or remove some of the toil in the process. Yep. So broadly speaking, I think where the day in the life of a developer moves to is, yeah, I talked about inner loop and outer loop before. Our vision for these two loops is essentially like accelerate the inner loop. like we should provide facilities that automate boilerplate and toil inside the inner loop such that it feels like we're building leverage around human creativity, because that is still the thing that is like, quote unquote, like out of distribution of the models and something that is not like yet replicable with today's LMs.

41:26And I don't see kind of like a clear line of sight to actually like replicating that. I think that is truly the essential part of the job. That is the fun part of the job. It's like thinking of a new idea, connecting that with the user need, and then finding just the ideal best data structures and algorithms that fit within your existing architecture to solve that. That is the essence of the job. And that's the thing that we want to enable people to spend 99 % of their time on, as opposed to 1 % of their time on. So we're accelerating in the inner loop. And then the outer loop, I think, we want to automate as much of that as possible, because everything in the auto loop is kind of like a factory.

42:08Like you spend all this time refining the creative aspects in the inner loop. And now the outer loop is just like, how do I get this thing that I have produced in my developer environment into production? So like the whole process of like doing the review and refining it, making sure there's adequate test coverage, like doing an automatic rollback, adding the necessary telemetry. In ideal world, that is all within the realm of automation. It's kind of like we built this like this gigafactory in a way where, you know, if you got it working in your development environment, everything else to get it into production should be like pattern matchable by the LLM.

42:45So in the future, I think the future that we want to work towards is like, it doesn't matter what size code base you're working in. It could be the smallest thing or could be like the largest, oldest code base in the world. You express your intent. We accelerate you getting to the experience that you want in your development environment. And then thereafter, like the machine just takes your change and lands it in production, guaranteeing security, reliability and robustness. Love those buzzwords. Love those buzzwords. I'm being serious. I'm seeing this where you're going. I was just half joking there.

43:20That was some buzzword city there, though. Yeah. Yeah. Robustness. Well, that's that's what you want, right? You do want those things. Our tagline is like, move fast, but don't break. Okay, sure. I like that too. And that is now possible. With today's technology, it is possible to enable an extremely fast development cycle that augments human creativity. But the things that could break your system, like a security vulnerability or too much technical debt or a bug that wasn't caught because you didn't think to add the appropriate test. Like all these things are in the realm of automation now. Like they are automatable.

44:07We just got to go and automate them. You know what? I'm all for that because there's scenarios where developers will want to deploy code. Don't forget, oh, I didn't write or consider this one security thing that I should know about. But because I'm a human, I got limited, even emotional will, willpower, which is a finite resource to any human being. Yeah. Right. We all have brains and those brains give us a certain amount of power. Regardless of how smart you are, you could have not had your Snickers that day. So, you know, maybe maybe you're you're Joe Pesci for a moment or two. Yeah. And you're just not you know, you're not thinking straight.

44:44Yeah. Or it's four o 'clock and you're trying to get this thing over the line because time, you know, and you don't write the test or you forget about a critical thing. We should have automations and checks and balances in our flow from the REPL, which you're talking about, this inner loop, which says, okay, now it's out of my safe world. It's out of my safe idea world, my innovation world. I've tested, I've done all the things I can. Now it goes out to the outer loop, which is that's where automation should live because you want to confirm, is it a threat or is it an ally, right? Is this thing that has been done a threat or an ally?

45:21And if it's an ally, to prod. If it's a threat, let's check those threats. Yep, that's exactly right. And I think this willpower as a finite resource, that is a really good way of phrasing it. I think I'm going to steal that. We've seen it play out, not just on the timeline of like a day in the life, but like we've seen it play out on the span of like months and years. So like to give an example, like we have a customer where we partnered with them to build a sort of like code migration agent that was targeting a project to retire all these like dead feature flags that they had strewn about the code base.

46:00So like feature flags, you add them to do some experiment. And then once experiment is over, like you decide, okay, we're going to either turn it to a hundred or turn it to zero. But then like no one is really incentivized to like remove the feature flag from the source code. So over time, you just, these things kind of like grow linearly and they add to the complexity of the code base because no one is quite sure just looking at the source, like whether it's fully turned on or not. And there's like, you know, branches. Yeah, well, it'll break. Which one of these branches actually execute, you know, depending on like what feature flag configuration I have currently in production.

46:30So they had a migration project. The target date for the project was 10 years down the line. And literally, this is the sort of thing where like the only people with the context to lead this conversation are the very most senior engineers in your organization. because they are the only ones who know the entire code base. They know all the nuances of how these future flags can break if you remove them improperly. And they're the only ones you trust to initiate like a migration that literally touches every single repository in your code base. So like the joke is like, have you ever read like Kerouac?

47:09You know, I saw the best and brightest minds of my generation. Like the developer equivalent is like, I saw the best and brightest developer minds of my generation. go insane because they had to spend 10 years of their lives working on dead feature flag removal. Instead of anything interesting or fun, like building new features for your users or customers. Stuff that really matters, basically. Yeah, exactly. And so when we ran that project with them, it's still ongoing, so it's not through to completion yet, but we're basically able to say 80 % of these feature flag sites you can automate within the next month or so.

47:45So it's kind of like, you know, in sitting down and just like figure out how to like compose, like build like an agent to do this migration, we've gotten you within the realm of like retiring 80 % of these within essentially like a month. And then, you know, the remaining 20%, they're a little bit trickier and those will probably involve, you know, some amount of human in the loop. but already like it's like we got 80 % of the way there within a month this thing is not going to take 10 years uh any longer right and just just think of the like that like that's a good chunk of your life right for multiple people uh for multiple like really really smart people uh who can now like go and focus on other things that actually move the needle for the business and and for the user experience.

48:36Yeah, that really is the best use case really for automation or intelligent automation. Because one thing I like about the idea of, I would say, using today's newest frontier models or generation or reasoning in problems like that is because it can run scenarios. Like it could be like, well, you know, if it's sophisticated enough, It can say, run the scenarios that these five flags were removed, what would happen? Because it has awareness of the database. It has awareness of its scalability of it. You know, what the database actually is or what the language might be or how it's sharded or not sharded or like whatever the scenario is for the application.

49:22It knows that and it can to some degree quantify or try to quantify some of that reasoning. So that when you get there, like the PR, you're mostly there. Instead of having to go 100 % of the way, maybe only go 50 % or in this case, 80%. You've gotten 80 % done and you only have to deal with 20%. So, hey, smart fellas, smart folks, go and tackle this problem. Now you only have to do 20 % of the work versus 100%. I would be so much happier, you know, if I were that intelligent person having to deal with that issue because it's important, but not so important that you should spend 10 years of your life doing it.

49:57Yeah. And the remaining 20 % is like the fun 20%. Like that's the interesting problems. The ones where you can actually like wear your computer science hat and, you know, God forbid, actually make use of some of the things that you learned in college. Right. Yeah. OK, so that's one more layer of the day in the life. This is a long day in the life. Wow. Code migration, code review. What's left? What's left in this day of life? This outer loop that you're going to automate? Is there more? You know, I think we've covered most of it. There's specific pieces that we can get into, but broadly speaking, it's accelerate the inner loop through an amazing in-editor AI experience.

50:45Help automate the boilerplate, help automate the grunt work of doing simple things. And then in the outer loop, fully automate as much as we can. So I think the last remaining piece here would probably be some sort of like automate a remediation of production incidents that happen. And I think there... So you want to automate incidents now too? Yeah, I think like the entire software development lifecycle, we essentially want to be the platform that performs all of that. Like we're essentially building like an agent construction mechanism into Sourcegraph where like the code review agent is just kind of like patient zero for that.

51:23Like that'll be like a first party agent that is customizable and composable so that people can tune it to the specific needs of their enterprise. But that's just the beginning of the long and fat tail of toil that exists inside enterprises. So like the common points here will probably be things like code review, test generation, issue and incident remediation. Those probably are the most salient things for us. But then inside every org, there's kind of like a long tail of very specific things that you need to do for that organization, right? Like, you know, if you're a big bank, you might have compliance requirements, or, you know, checks for proper handling of like PII.

52:07If you're in healthcare, there's a lot you have to do around like data privacy and making sure that that doesn't, you know, get leaked to a part of the system. Every industry has its own set of things that they need to enforce in this lifecycle. And so the way we've approached this automation problem is we're not trying to build like a one-size-fits-all thing that just does like code review. What we really want to build is like an agent authoring platform to enable our customers to go build the automations they need to build to address the toil that exists in their organization. So like this...

52:43You're the runtime. They still write the scores to it. We're the runtime. We provide like the common Lego bricks and building blocks like a common inference point, a common context fetcher, a common way of composing these agentic chains. And then their developers are essentially able to go and like with very low friction, assemble these blocks into the things that target the toilet they experience. I love that. I kind of joked earlier about, you know, smart cron jobs. You feel that's kind of what this is? I mean, maybe at some level, there's some things you do with cron jobs where you script something and you automate it based on certain timing and, you know, it runs and then you observe it and did it fail or did it pass?

53:30And there's logs and there's obviously the effects of the change that you construct. Is there a day where, you know, we will no longer write simple, let's just call them dumb cron jobs and we'll write smart ones that are very agent like? I think there will be. And I think the point that we want to get to, the way we've constructed our code review agent is to make it so that for the most part, you don't have to think about the imperative logic of the review agent itself. what you can do with source graph is you can define these like rules that should hold in a certain part of your code base so a rule is just a declaration of some invariant that should hold across a certain set of files uh in in your code base so maybe it's something like it could be as as simple as like hey if you are writing the the name of your company make sure to like camel case appropriately because a common misspelling is, you know, people forget the camel case and that's not good.

54:36Or it could be, you know, much more complex than that. Like, hey, here's a complete style guide for writing code in Go. You know, we've like copy and pasted the open source Google style guide because like that's treated as canonical. Make sure all the Go code in the organization follows this style guide to the best of your ability. Almost every invariant that you want to describe is describable in a statement like that. And we want to give people the power to define these rules in one place and then have them be enforced across their code base. And the mechanism of enforcement, there'll be at least three places where this surfaces.

55:19One is inside the editor. So like make the rules part of the context that guides the generation of code inside the editor so that you feel confident that like if, you know, most of your developers are like vibing their code into existence, that vibed code actually follows your organizational standards. So it's not going to be like, you know, you're not gonna have to rework 90 % of it because it's using some framework that, you know, you don't want to use. You want to use this other framework or whatnot. The second layer is code review. So at review time, if anything falls through the cracks or if someone wrote that code manually, enforce these rules to make sure that nothing gets committed that causes any of these rules to break.

56:01And then the last thing is what you're describing with the cron jobs. You should just have a multitude of background agents in flight at any given point in time, just constantly crawling your code base to ensure that these rules hold. And if they don't, if there's ever like a point where they don't hold, push up a PR and then, you know, automate the review of that PR so that like a human can come in and be like, okay, yep, yep, yep. You check the right things. This looks good. And like you've added the appropriate unit test to make sure that nothing breaks. Looks good to me to ensure that those invariants hold.

56:36I think the combination of these three methods of enforcement will allow your technical leadership, the people who carry the architectural vision of the codebase, to really enforce consistency and coherency across the entire codebase. Not just catching the typo things, but you can actually describe architectural constraints. This component, if it talks to this component, should go through this interface because that's the intention of the architect. It's very important that we maintain this interface boundary because that allows us to keep the code clean and changeable moving forward. That's the sort of thing where without this system, without AI, it would have been like a losing battle because you only have a certain number of senior developer hours in the day.

57:25And at some point, some PR is going to sneak past the reviewer because they got other stuff to do. And then at that point, you've broken the over time. And that to us, to get back to the industrialization point, that's a linchpin of being able to make coding a truly industrial craft. Another point of reference for us is, if you've ever read The Mythical Man Month, that's the classic. I have not. Oh, you haven't. Oh, you got to read it. Oh, man. I'll put it on my list. The book was written in the 70s about challenges that developers faced building mainframe software, but it is still like, it's like 98 % applicable to the way development currently works today, which is like the thing that holds software back and prevents these actual economies of scale from being realized is the loss of architectural vision and coherency that occurs when you scale up the size of the team working on the software and contributing to the code base.

58:26And so like, this is a perennial problem that has plagued software development since, the mainframe software of the 60s and 70s, which this book was written about. But the same general principles apply today. With our system, this system of rules and invariants enforced through AI at different ports of the SDLC, our mission, our vision here is to give the architect of your code base a lever by which they can enforce the constraints and architectural rules that must hold in the code base to preserve the overall kind of like cleanliness and design of the code base. Like now for the first time in history, I'm not saying it's a solved problem.

59:13We're still in the process of solving it. But like now for the first time in history, we have line of sight to solving that. And I think if you're playing around with these technologies and using them day to day, you can see how we get from here to the point where people can define these rules in one place and just constrain and control the evolution of the architecture as code grows. If we can do that, then we basically solve the fundamental problem of the mythical man month. And that ushers us into a new age of software development. We're literally transitioning from cottage industry or artisanal craft into actual industrial processes where we do have economies of scale and we do have efficiencies where the team can actually, you know, not even not get slower, but actually get faster.

59:58The, the, the larger the, the code base becomes. Yeah. I'm seeing this world. I mean, I don't, are we there yet? Let's just, let's stop for one second. Are we there yet? Not quite. No, not quite. And we're, we're in the midst of building up like, you know, this gig factory, Yeah. Okay. For us, it's really about like building these factories in collaboration with our partners. So like one of the things that differentiates us is like, first of all, we're thinking about this problem at all. And second of all, we can sit down with like the technical leadership at, you know, the booking.coms of the world or the Palo Alto networks of the world and make this system work well for them.

1:00:33Because building the gigafactory is very different than building something that works inside like a small code base with a couple of contributors. And I think, you know, the low hanging fruit is definitely like the small code bases, which is great. Like, I'm glad there's like a bunch of people working on that and making that better. But I think where we see a strong alignment with our mission and what we want to do in the world is really enabling software development to go much more smoothly and quickly inside these large, like industrial scale code bases. Well, what the picture it seems you've painted, if I can just analyze a little bit, is if I'm an IC in any of these organizations and they're, like you mentioned, there's a certain interface I may have to write code to.

1:01:15It always has to go that way. So the agent that may confirm that that's a truth or not for my code base. Yeah. When I deploy code, if I can do my REPL, my inner loop, my creativity, and I have insurances outside of it, like no matter what I throw out there, outside my circle of trust, let's say within my own brain or my own team's brain of innovation, creativity, moving the ball forward. If I know whatever bounces back holds true against rules that my organization trusts, holds near and dear, is orchestrated and designed by the most thoughtful people. If I can be creative within confines, it's like you still have constraints, but now it's not rogue because you can add more and more smaller teams to be creative and to throw things outside their circle of trust and get bounced back against this wall, so to speak.

1:02:06Yeah. And the robot should be able to handle somewhere between like 90 to 100 % of the back and forth, right? Because like before this would be very painful because like you push up your new feature, you're all happy about it. But then some like architects would be like, no, like it violates this constraint. Like this part is not clean. You have to go and do a bunch of rework to fix it. And then you push it back up again. There's more comments. And this process just drags on and both sides get increasingly frustrated because, you know, finite willpower at the end of the day. But now you can have the robots handle like the vast majority of the back and forth.

1:02:39And so, yeah, now it's like, you know, you focus on the fun parts. Worst case, you're mad at Cody or whatever you need the next robot, right? Yeah, and if you get mad at Cody, the brilliant thing is that like, hey, just tag in Cody to go address Cody's comments, right? Nice, yeah. You'd mentioned in the pre-call specifically some things you do for enterprises and government agencies. What is it that those, I mean, we probably talked about some of it, but... What is it that those organizations need that has only been uniquely designed and engineered by Sourcegraph to help them do better? Yeah, so there's two things here.

1:03:20One is the context awareness, like building that in as like a first class citizen. I mentioned that we were first to market for that. And we actually have a way of delivering that really effectively into the enterprise. Like Sourcegraph has been self-hostable for many years now, because a lot of our early customers were very large enterprises. And so we've built all this DNA around delivering the best context for human developers in the form of code search and code navigation into all these different deployment environments. And we can essentially offer those same context features as a kind of like game changing tool or capability for LMs as well, like any sort of AI code generation or question asking.

1:04:01The other facet of this is just the security and compliance requirements that a lot of these larger enterprises have to comply with or are constrained by. So in terms of like being able to deliver something into a purely self-hostable environment, I think we're basically like the leader in being able to do this. Like even Microsoft or Copilot, you know, with all their kind of like enterprise branding, there's still components of their infrastructure that have to be tied to their cloud. and that essentially rules them out for a lot of, frankly, the largest software engineering organizations in the world.

1:04:37They're ones that you haven't heard of, but they're literally powering half the economy and they have very stringent security and data privacy constraints. So you can self-host everything we talked about today? Yes, yes. And it's by design. That's not obviously by accident because you wouldn't do it by accident because that's very hard. It's very hard to self-host. so does that make it challenging to build source graph to to sort of have two deployment targets or i guess infinite really technically yeah because you've got your own cloud i'm sure which i can go there and be a cloud customer or yourself you're hosted it versus my own hosting it's absolutely a challenge and it's something that has slowed us down a bit like um like the The in-editor experience, I think, we've had a bit more challenge in pushing that forward.

1:05:31We ideally would have liked to move faster on the in-editor UX, but because we're targeting a variety of different editors and deployment constraints, that has constrained what we've been able to do there to a certain extent. But I think now we're at the point where we've figured out all the most important parts for how to deliver this into large-scale organizations. And so now revisiting the core UX, I think we feel pretty good about the degree to which we can implement all the things that people want in terms of AI code generation and agentic automation within the editor. But it does remain an ongoing challenge.

1:06:10It's not a trivial problem by any stretch to solve. And it's something that a lot of the upstart people trying to do things with code plus AI they have not solved yet. And I think we'll take some time for them to solve. Is your most popular editor VS Code or your target where a lot of the generation is happening? I think probably by usage numbers, VS Code is the most popular, but we have a ton of JetBrains users as well. And we also support Visual Studio and Eclipse, which you know it might be surprising to some folks in your audience but like there are like very large government agencies that are still on Eclipse and they are constrained by factors beyond their or our control and being able to deliver this into that editor is kind of like game changing where we're literally bringing like the latest technology into a very kind of like old school legacy editor uh and it it it just like it it completely upends uh the speed at which they're able to move uh inside the those code bases i know that um one of your teammates i think went to zed i'm thinking like why wouldn't you just build your own editor or acquire one you know they want to just acquire zed and make it easier yeah so that's the best editor ever out there yeah um So I think the teammate you're talking about is Thorsten Ball.

1:07:48He's awesome. He actually just bounced back, actually. I saw that. He rejoined us. That's why I felt comfortable mentioning his name in this scenario because he's back again. And look, he's awesome. I think, look, I love the Zed folks too. Like we've had one of them on our podcast back in the day. I really love what they're doing. I think it's a fantastic editor. And I sincerely hope that it becomes like really big. I think they have a unique approach here. You know, they're not a VS Code fork. They're really kind of like rebuilding an editor up from kind of like first principles and focusing very much on performance, which I absolutely love to see as a developer.

1:08:35And yeah, like I hope they succeed. Like I would love that to be like an editor that I could use someday. As far as our business is concerned, the way we view the in-editor experience is... I think maybe there's a difference in our vision for the world compared to some of the other players in the space. But we don't think that there's going to be a single code editor that is universally adopted for every language and every platform in the future. much less like a closed source one. I think open source in the editor remains important because it's so near and dear to the inner loop and the individual developer workflow.

1:09:21And so when we think about the type of in-editor coding experience that we want to enable, we start from a point of wanting to deliver that experience into the best editor for your particular ecosystem or your platform. I guess that's somewhat of a contrarian view these days because there's all these VS Code forks floating about that, frankly speaking, they've done a really good job on some of the core UX and kind of push the frontier in terms of showing people what's possible with AI. But the long story, I guess the short of it is for us, We are thinking about building for the large code bases that make the software that power the world.

1:10:10Those are multi-editor environments. They're also environments where it's not just the context inside your editor that matters. It's actually connecting it back to the overall context of your organization and the entire code base. And so the way we're approaching about building for the editor is to bring the best AI UX in the field in a way that feels native to each of the editors that we support. We eventually hope to support all the editors out there. That makes sense. I mean, in essence, what you said was go where the developers are, right? Versus force them into your stadium. You're going to all stadiums.

1:10:45Yeah. A world tour. Yeah, basically. And part of this too is when we look at the UX of how people employ AI inside their editor today, we don't see anything that fundamentally requires a different editor. especially looking forward with like model capabilities evolving as quickly as they are i would say our point of view is that every six to nine months uh there is a step function increase in lm capabilities where the assumptions that you had to build around in terms of like what sort of like user experience you enable um or what what are the facilities that you have to build around on the model, those entirely change every six to nine months.

1:11:39Because the kind of like gaps that you had to fill because the previous generation of models couldn't just one shot the thing that you're trying to do or couldn't just find the right tool, those constraints no longer exist. And the constraints that you have today in another six to nine months won't exist either. And that has been the pattern since the release of ChatGPT. So we've seen a progression of these step function models. There was GP3.5, GP4, then Claude, Claude 3.5 Sonnet, and now 3.7 Sonnet. I think each of these has moved the needle in a way where a lot of the prior assumptions and constraints no longer hold.

1:12:23And so when we look at the ideal editor UX today, looking forward, we actually think there's a very clean way to integrate AI-generated code into every editor that doesn't involve a lot of extra UX Chrome or things. It's mostly just relying on the model reasoning capabilities, providing it the right set of tools in the form of both local tools and tools that call out to code-based-wide context fetching. And then having a constrained set of hooks into the editor, Like how do you render a proposed diff into the editor buffer? How do you render an edit suggestion into the editor? These sorts of things, which, you know, look, you have to build those integrations so they work well, but it's a very narrow set.

1:13:11It's a narrow API that we think we can implement really well. And I think the thing that we'd like to build is kind of like an AI kernel that you can port to every editor and maybe even to the command line, because like it's a lot of the same usage patterns. that you see there, where it's like you want to describe the change that you want, you want to see what edits are proposed, you want to accept those, and then you want to continue doing what it's doing, but keep you in the loop as to what it's doing and how that affects the rest of the code base. Yeah, it's a certain framework that happens no matter what.

1:13:42There's certain interfaces you expect. Yes. No matter if it's your Zed editor, because I'm telling you to acquire it, or suggesting that you should, or every editor out there that developers use, no matter where it's at, even legacy ones. or I suppose lesser used, I should not say legacy, like Eclipse. There's still lots of folks using Eclipse for good reasons, I'm sure. Yeah, yeah. For good reasons. If you think about, there's another analog here, which is like a couple years back, a big innovation in the editor space was the introduction of the language server protocol, LSP. And that showed that, hey, you didn't have to build bespoke code navigation for every single editor.

1:14:22Before that, it's like, oh, I want to use this editor because like some hacker out there spent, you know, night and day over the course of like weeks or months hacking into, you know, this compiler to rip out the internals. And now like that editor supports really good go-to-definition for my language of choice. LSP came along and basically said like, look, fundamentally, what do you need to do? You need to go-to-definition, you need to find references. And then there's kind of like a short list of other functionality that's really useful to have. we can abstract that away and make that feel native in every editor so that you don't have to reinvent the wheel.

1:14:56And I think something like that is possible with LM driven cogeneration.

1:15:13Well, friends, I'm here with Samar Abbas, co-founder and CEO of Temporal. Temporal is the platform developers use to build invincible applications. So Samar, I want you to tell me the story of Snapchat. I know they're one of your big customers, well-known, obviously operating at scale, but how did they find you? Did they start with open source, then moved to cloud? What's their story? Yes, Snapchat has a very interesting story. So first of all, the thing which attracted them to the platform was the awesome developer experience it brings in for building reliable applications. One of the use cases for Snap was Snap Discover Team, where every time you post a Snap story, there is a lot of background processing that needs to happen before that story starts showing up in other people's timelines.

1:16:01And all of that architecture was built, composing, using queues, databases, timers, and all sorts of other glue that people kind of deal with while building these large-scale asynchronous applications. and with temporal the developer model the programming model is what attracted them to the technology so they start using our open source first but then eventually start running into issues because you can imagine how many snap stories are being posted every second especially let's say on a new year's eve so this is where temporal cloud was a differentiated place for them to power those core mission critical workloads which has very very high scalability needs although they started with open source, but then very quickly move to Temporal Cloud and then start leveraging our cloud platform.

1:16:49And they've been running on top of Temporal Cloud for the last two, three years, and then a pretty happy customer. Okay. So maybe your application doesn't require the scale and resilience that Snapchat requires, but there are certain things that your application may need. And that's where Temporal can come in. So if you're ready to leave the nineties and develop like it's 2025, and you're ready to learn why companies like Netflix, DoorDash, and Stripe Trust Temporal as their secure, scalable way to build invincible applications. Go to Temporal.io. Once again, Temporal.io. You can try their cloud for free or get started with open source.

1:17:25It all starts at Temporal.io.

1:17:32Let's dig into, I think, something that you have a unique perspective and vantage point on, which is the frontier models, what is being used, what's being deployed. You obviously give access to all the frontier models from Cloud to Sonnet, you know, all the different ones, you know. What is most useful to developers? Do you offer them all because they all have unique perspectives on code generation? Is there one you particularly like best? What are you hoping for in terms of frontier models, like open source, non-open source? Are you a DeepSeq user? I don't see it in your list. yeah it's a swath of things let's go from there yeah so the landscape today you know march 5th 2025 is uh change tomorrow it could change tomorrow by the time this comes out maybe maybe it'll be different but that's why i say the date because uh you know i want to make sure that i'm pegging the statement to a specific point in time the the preferred model for our user base is uh the Claude Sonnet family of models.

1:18:32So we have a lot of users still using 3.5 and a lot of users using 3.7. I think there's been some interesting discussion around like 3.5 versus 3.7. For instance, like I saw a bunch of like Cursor users tweeting that like 3.7 didn't feel like a big improvement. In some cases, like worse than 3.5. For the Kodi users, it's actually been the opposite. And I think it's actually because Cursor has done more legwork around like optimizing their prompts around 3.5. Like we've done less of that because we've been more model agnostic in our approach. And what we found is 3.7 just has like certain capabilities, especially around tool use that have gotten like substantially better.

1:19:14And so that's why we're building, like the future of Kodi is really gonna be built around the set of capabilities that are now unlocked with 3.7 Sonnet. I think we see, so we also see a lot of usage of kind of like reasoning oriented models for trickier problems or problems more around code-based understanding where a non-reasoning model might make a hallucination or an incorrect interpretation, like a shallow interpretation of some set of context. So we do see some usage of the reasoning-based models, like O3 mini and things like that. DeepSeq is really exciting. I actually think it is available now in the model dropdown.

1:19:56Yeah. Marketing says no, but I'm not inside the application. I'm on slash Cody of sourcegraph.com and it's not there. So. Oh yeah. Yeah. Probably need to be inside the editor. Deep seek is also really exciting because it's, I think at the frontier of the open source models and like the open source models are also very interesting to us because one it's like, you know, we always like supporting open source, especially at the model layer that makes it attractive from a variety of different points of view. I think LAMA is also an awesome family of models that is available through Kodi and that we also see a lot of future potential around.

1:20:35The second reason why DeepSeek and LAMA are very exciting is their fine-tunability. So there's a bunch of use cases inside the editor, like suggesting the next edit or applying a proposed change into the editor, where these open source models provide a very good foundation for tuning a very fast model that's specifically targeted at those use cases where like the use case is very latency sensitive so we want to preserve the context awareness and preserve the intelligence as much as we can but since it's constrained to the specific use case it doesn't have to have as much of the general intelligence that like a frontier model has but because we have relaxed that constraint we can push the latency and cost down to the point where it feels more instant.

1:21:16Can you explain to me how, or is this proprietary, how you interact with the various models? You mentioned you're agnostic. So I imagine just like you want to go where developers are, which means whatever editor they're using. So that means that you've got an agnostic approach to how you gain your context via source graph and apply that to the model that's going to give back the generation or give back the reasoning. How do you, can you explain to me how that works from prompt to source graph context to the model and back again? Yeah, so model choice was something that we prioritized as like a key original design constraint around Kodi.

1:21:58We basically made the bet that the model landscape would shift. Constantly. And evolve. I think that like prediction has panned out. And so we never wanted to be like overly constrained to one specific model or the current generation of models. And so we architected the code in such a way that we could easily introduce new models and also customize the prompts that we use for each model so that we can use the best prompt structure given each new model that comes along. And so because of that, one, it's advantageous if your user. If you want to play around with the latest model on the day it drops, Most of these models we make available within 24 to 48 hours for users of Kodi Pro.

1:22:43And then if you're an enterprise user, this is also helpful because sometimes you have constraints around which model you can use. There's a bunch of enterprises, for instance, that don't want to use DeepSeek because the progeny of that model just rules that out. For whatever reason. Yeah, for whatever reason. And so, you know, we don't have to use DeepSeq in that case. Some people, you know, cannot use Anthropic or OpenAI. Like maybe they're tied to like Azure OpenAI or AWS Bedrock. So they're constrained to the models that are available on that platform. And we can easily, you know, make the functionality available given their model constraints.

1:23:24Can the person or persons over the source graph org, I suppose, can they delimit or remove the opportunity to even select a model they can't use? Yes. That's cool. You can do that at the admin level. That makes sense. Yeah. That's the way to do it, man. Yeah. Yeah. Any plans to, is there any more on that front? Did I cut you off? I mean, I said we partner very closely with all the various frontier model development shops. I obviously can't share anything that's not public, but I think we're seeing a lot of exciting things coming down the pipeline. And so we're kind of like building our future and editor experience with an eye towards where we see the puck going in terms of model capabilities, which is very exciting for the future.

1:24:14I think the thing that I'll say here is that like AI has already gone through two to four mini disruption cycles. Like we typically think of disruption cycles as being on the order of like years at least, right? But the shift and the step function improvement in model capabilities that we see every six to nine months or so essentially like resets the the game for what the ideal ux is at that cadence like every six to nine months um so you know rewind to the ancient age of uh one year ago one year ago 2023 right 2023 co-pilot was king they seemed unassailable uh everyone wanted autocomplete. No one even cared about like chat or context awareness in that chat, right?

1:25:11Because autocomplete was where it's at. You want it to be fast. You want it to be snappy. You want it to be like a little bit context aware, but people just wanted it to be fast, right? Like, and that was like the UX paradigm that was dominant at the time. And then in 2024, like the paradigm completely shifted. I think it first shifted with GPT-4 where like, okay, that was a model that had a step function improvement in its ability to one-shot applications. So now it's like, why would I sit there auto-completing stuff when I could literally just generate an entire mini-app from scratch? It also got a lot better at incorporating context.

1:25:45So now you can do context-constrained code generation, which we deployed, and it had massive success in the enterprise. But then there were still certain things that it couldn't do well. The code was often sometimes broken or didn't quite compile. And then when Sonnet rolled out, that was another step function. Now all of a sudden, these things that were just beyond the capability are now firmly within, I can trust this thing to reliably emit JSON, for instance. That's a solved problem now. People used to write entire thought pieces around, how do you constrain the model output to produce valid JSON?

1:26:24Like these days, it's like you don't even think about that because the model has been trained to treat that as a solved problem. So and I think now we're seeing it in terms of like in-editor agents like that is the future. And that's what we're building towards. You know, a year ago, I think if you're pushing agents, there were certain like companies that were, you know, we're going to build like the agent that like eliminates the developer entirely. I think now people recognize that as they were kind of like selling beyond their existing capabilities at the time. It made for a great kind of like marketing moment and they got their name in the headlines, but there was a disappointment in the actual product experience.

1:27:04Now with like the newest set of models, we're seeing this approach just like this is kind of like the new paradigm. That's what we're building for. We have kind of like a wait list of people who want to get access to the thing that we're currently building in collaboration with a lot of these frontier shops. And it works very well in large, messy code bases as well. Because again, that's the problem that we're solving for. And so I think the future is very bright. And at some point, I think we might plateau in terms of model capability. But at least for the past two years, there's just been this regular cadence of step function improvements and model capabilities.

1:27:41has just been really exciting to see that and sort of like ride the wave of the development and maturation of this technology. This wait list, is it a secret? These details behind it, can you enumerate at all? When is this episode going out? Next Wednesday. Oh, next Wednesday. Oh yeah, it's closed right now, but I don't know, like DM me on Twitter. We're playing this like very ad hoc right now just because, I don't know, what we've learned over time is that like new uh kind of skunk works projects like this it's never good if you make them like overly formal uh too quickly so we like it to be scrappy we like to be just like a a handful of devs kind of like locked in a garage-like environment of some sort just like hacking on stuff but uh you know i think we'll have more to more to share uh here soon you've already long betted on the the UX inside the editor.

1:28:39So that's not changing. It's an improvement or maybe something like that with a particular model or model developer. Yep, basically. And so the way we think about it is basically like this. What we are doing, what I'd recommend other organizations do, is you want to position what you're building inside your organization to ride the wave of model improvements. And so what that means is you have to just assume that the reasoning capabilities and the latency will continue to improve at approximately the same clip as they have been. So what do you do? Like to a certain extent, you have to hack around the existing limitations, but you don't want to invest too much in those because another six months rolls around and like those are kind of like, you know, obviated.

1:29:26I think where you do want to invest in right now is very high quality tools, tools and capabilities that can be composed with the rapidly advancing reasoning capabilities of frontier models. And so it's essentially, for us, it's kind of nice because we've essentially been building these tools the entire time at Sourcegraph. It's like we're building tools to help human brains explore the code base effectively and build up a working understanding of it and write effective code pattern matching against the existing patterns and validate that that's correct and consistent within the style of your organization, the rules in your organization.

1:30:09Now, increasingly, we're seeing the LLM brain being swappable in for the human brain in a growing number of tasks. Every kind of advancement in reasoning capability or context awareness or pattern matching capability advances the frontier of where like an LLM serving as the coordinator of these tools, the orchestrator of these tools can now automate something that previously like a human brain would have had to attend to. And so the way we view it is like we are really investing in the tooling ecosystem and infrastructure that we build around the model with the assumption that like all the frontier labs are going to be pouring, it seems like all the money in the world, right?

1:31:01Like billions, if not trillions of dollars into pushing the advancement of this reasoning technology as far and fast as they can. So like that's the big wave right now. And the way we're designing our platform is to just like provide the best tools for accelerating and automating the software development lifecycle under the assumption that there's going to be kind of like a, you know, maybe Moore's law is not the right analogy here, but there's, I think you can assume some pace of like advancement and reasoning capabilities for at least the next, you know, couple of years. Yeah. Well, I'd imagine that you're getting this access and you can call these folks partners and work in this degree because is Sourcegraph is a deployable target for all of them, essentially.

1:31:52They can't assume that I go to the Cloud website or to the OpenAI website or to my own way is that Sourcegraph's Kodi is just one more way to deploy and distribute those LLMs and those reasonings, so to speak, to developers where they're at. I'd imagine that's probably true. Can you speak to how saturated your user base is with, like, of the developers who are developers, in quotes, to Sourcegraph? I don't know what you call your people, so to speak, your user count. I don't know. I'm trying to get your lexicon in my brain. Yeah, yeah. Do they all use Kodi? You know, is everyone using Kodi? Is Kodi, you know, one of your most successful products?

1:32:36I would say Kodi has been, I think, by far and away, the most successful product that we've shipped. with code search being kind of like a close second, if you track by kind of like user count. If you track by revenue, like we have other features that drive a lot of revenue as well, like bash changes, which is the large-scale refactoring thing. It's very, very useful and very, very valuable for large message code bases. But in terms of like overall user count, developer count, I think Cody has been extremely successful. it's not there's not 100 % overlap yet like we do still have some people using code search who don't use Cody or some people using Cody that don't use code search but we see an increasingly number of people kind of float between kind of like you know generating code with AI to like looking up context myself to make sure that I understand like what the code actually does and and what APIs it's using, et cetera, et cetera.

1:33:38And yeah, I would say that we are seeing an increasingly amount of people starting at one point and getting pulled into the other. And for that reason, we've also made this AI question answering interface available in the web application, where you can go to any repository in the source graph UI and ask questions when you're viewing the code in the source graph web application. So just trying to connect the dots. We kind of developed Kodi as a separate independent thing, but increasingly our user base is really pulling us to integrate it into the unified source graph experience. It's hard to see from the outside how Kodi is independent because you can go to slash Kodi, which is what it is, but the headline does not say buy Kodi.

1:34:28you know the headline I don't even know what it says but it doesn't say that you know I think it's like the enterprise AI code assistant you know and then somewhere in the line it's like with Cody you can do X you know there's not this named thing where it seems like it's a standalone product that also is deeply integrated yeah I say candidly like our marketing messaging hasn't been the greatest I think there's some confusion over like what the overlap is very much yeah and that's something that we're trying to address. I think one of the challenges for us is we built so many capabilities around accelerating and automating the SDLC over the years that there isn't a succinct way of describing what the whole platform does other than it accelerates and automates your SDLC, especially if you're in a large code base.

1:35:20But that's not as punchy as... What is SDLC? Software Development Lifecycle. I thought so, but I just wanted to make sure. unless it was something on the inside I'm like what is this DLC? Okay What's left unsaid? I know that we've talked a lot, you've got a short amount of time you've got some other places to be what can we say in closing? What's on the horizon that no one knows? Or knows less of that you can mention in the closing? I think for us it's really mapping back to these two loops, like the inner and the outer loop, so expect a huge overhaul and improvement to the in-editor experience that we provide around what the AI can do when you're coding, when you're vibe coding, or when you're writing code in your editor.

1:36:13And expect an increasing amount of automation around that long and fat tail of the outer loop of the SDLC. and I think like philosophically the way we're trying to build this is we think the in-editor should be as open and adaptable as possible so open source, cross-editor these are the things that we value as developers and I think pre-AI like every developer would say they valued that I think the first generation of AI coding assistant has kind of muddied that a bit because a lot of folks have kept their solution closed source, but we think the end game here is going to be open and we aim to build in the open here.

1:37:03And then in the outer loop, I think the way we approach the automation here is that we're not trying to anticipate all the different ways in which we can compose the different building blocks. We want to build the building blocks and use those to provide a handful of first party automation tools like the code review agent. But at the end of the day, we want to hand this platform over to our users or developers, after all, to go and combine these things into the things that tackle the things that eat up your time and produce toil for you today. So that is our philosophy. We've been doing this for over a decade now.

1:37:47So we've kind of like fully internalized the challenges and what a solution needs to be in order to work in the context of a large messy code base, as well as how to deploy that solution into your environment. And like I said at the very beginning, we chose this domain because we felt that easily spend our entire lives working on this. This is where our passion is. And, you know, I see a long and bright future ahead for us as a company, essentially bringing all the biggest, most important code bases in the world to the point where they actually can achieve these industrial economies of scale. Industrial economies of scale.

1:38:35I love that. I mean, I mean, I think it sounds cool. yeah i'm excited about uh you know just the economies of scale really at that point because like it's it's generally been harder to add more developers to a team and get better yeah you might go faster but not necessarily always better and it's not their fault yeah necessarily because of willpower you know right yeah or just or just like human nature you know like i don't like you or you don't like me. It's hard to work together. Or I had a bad day or my weekend sucked. Yep. Whatever makes you less effective or productive. Absolutely. And you should absolutely go read the Mythical Man Month because what you just said there is kind of like the core thesis of the book.

1:39:23It is adding more people to a software development project makes it take longer, which is, it is the truth that has held true since the dawn of software development. It is the fundamental challenge that we aim to solve. And it's frankly like the thing that's holding back the quality of most software in the world today. Very cool. Thank you, Beyond, for sharing the depths of Sourcegraph and your journey. It's been fun. Thank you. Absolutely. Thanks for having me on again, Adam. When I first thought about the phrase, when I first said it out loud, industrial economies of scale, sounds kind of scary.

1:40:05Sounds kind of, you know, bureaucrat, corporate buzzword potentially. But as I thought about it more and more, the ability for us to not just scale our teams to slow down, but to scale our teams to go faster, to achieve the mission, to create better software, to really work on this inner loop and this outer loop that Beyond talked about. You know, I have the luxury of marinating on this podcast for a week because we recorded last week. We shipped this week and that's how it works, you know. So you get it firsthand right now, but I've kind of been sitting on this for a week. And I'm telling you, when I think about achieving industrial economies of scale for software teams, I kind of get excited because every time I've thought about in my career, adding more people or adding more things or whatever it might be to my teams.

1:41:00Now, mind you, I don't operate in high performance teams with large code bases, but I do think deeply about software. And I do think deeply about software with many people on this show. And so by proxy, I think about this. By proxy, I think about how would I accomplish the mission? How would I accomplish solving customer problems? How would I help organize and maintain morale to do the things that we love doing most as software individuals, as software teams? And this is resonating with me. I don't know about you. I'd love to hear your thoughts. Zulip is where it's at. Go to changelog.com slash community and join us in Zulip.

1:41:43That is our Slack alternative, real-time threaded conversations for teams. Hey, we're a team, we're a community, and this is where you can call your home. So changelog.com slash community. It's free, and I want to see you in Zulip. Okay, big thank you to our friends over at Retool, retool.com. And big thanks to our friends over at augmentcode.com. And big thank you to our friends at Temporal, Temporal.io. Yes, also big thanks to our friends at Fly.io, the home of changelaw.com, Fly.io. And to the beat freak in residence, those beats are banging. Breakmaster Cylinder, bringing new beats. Love those new beats.

1:42:28Okay, there is a bonus for our Plus Plus subscribers. Learn more at changelog.com slash plus plus. It is better. Yes, it is better. Change law plus plus bonus content closer to the metal stickers in your inbox and a free coupon for a hug. IRL stick around. If you're a plus plus subscriber or go to changelog.com slash plus plus and subscribe. Okay, that is it. This show is done. We will see you on Friday.

1:43:17I had forgotten that you open source Cody. Yep. And I feel deeply like, like how do I not know that? But there's so much that happens in our industry. I can't remember it all. Yeah. But I think what made me not realize this is like to get, it seems like to get into Cody, I have to have a source graph account. Yeah. And then I don't know how to have a source graph account because I try to have a source graph account that says that email doesn't exist. I'm like trying to sign up even. I was doing it during the show and I was like, what's happening here? So I don't know how that works or what's going on there, but share with me this wart that I've exposed.

1:43:58We are fixing this. So here's the historical context. A couple years back, we made the really bad decision to eliminate any self-servability in our platform. And at the time, it was just a matter of focus. We're bandwidth constrained. And a lot of the pull that we saw in the market was for enterprise code bases. Because those are the people for which the pain that we saw becomes existential. right it's like you feel the pain of like context gathering in a small code base but you know you're still small the code base fits inside your editor it's not like the end of the world once you reach a certain scale then it's like holy crap we can't get anything done uh this is existential so that's where the pull in the market for us