We're all Builders now (Interview)

27:01And he actually enumerated some of the points that you're making. You're saying it's great for us as developers, right? Because we have the agency we speak of. And we're really, I guess, adept at handling our tools and changing our tools. And that makes it somewhat of a fickle audience because what have you done for me lately? That's right. And so in that sense, I guess, how is Copilot changing? because I remember when it first came out and it was autocomplete and it kind of was game-changing in that way, but it was really a non-deterministic autocomplete. That was good, but had its problems and has grown since then.

27:32You guys continue to iterate, make it more and more awesome. And this year, you're announcing a lot of it being a coding agent. Can you tell us all about it? Yeah. Well, so, you know, in a lot of senses, Copilot has gone through the same epochs that AI itself has gone through, right? Over the past couple of years, like, you know, The AI basically got to the point where it was good at doing token prediction and things like that. But then over the last couple of years, we introduced chat. And that allowed you to have a conversation with a knowledge base based on retrieval augmented generation. And then just over this past year, it started to get to the phase where it could actually start to take actions.

28:16because the models themselves got to the state where they could actually reason over what they were working on. And so for Copilot, we started with completions and the completions at first were just a single line of code and then they got to full function bodies and then they got to longer, maybe a whole file. And then last year we introduced multi-file edits, right? So that you could actually make multiple changes to your code base at once based on a basic prompt. We introduced chat capabilities, which could be based in the context of the project or the source code that you're already working in and the repo.

28:57And that kind of started to change the game. But I would say nothing has accelerated the capabilities as quickly as what we introduced with agent mode this past February. And then it's kind of rolled out over the past few months. But agent mode, it is shocking what you can accomplish in just a really short amount of time, just letting it go. Basically, what you do with that, and it's also had its own acceleration. But what you do with agent mode is you go into the prompt, into the co-pilot chat experience, and you switch it to agent mode. Pick a model, whether you want, you know, Sonnet 3.7 or you want, you know, GPT-40 or whatever.

29:42you want to use. And then you give it a prompt, like add tests for this particular project. And it will then iterate and self-evaluate as it's iterating. So for example, in my demo earlier today, all I did was I gave it source code repo for a website. And I said, test this solution and write some tests, write some integration tests for me. And it basically started to do all of the automation to bring up the playwright automation framework, bring up the website, start to traverse all of the different paths that it could go through in terms of the various different customer journeys on the website.

30:25And then it started to generate the tests themselves. And so what used to take me hours, maybe a half day, I can now get done in just a couple of minutes using agent mode. And so I think that's really like changing the equation in terms of what these tools are capable of. Yeah. It's really ramping up the potential gains. One thing that I fear with that is the more you change, the harder it is to find the thing that went wrong. You know, it's like the needle in the haystack problem where if it's an auto complaint of a single line, cool. I can just see what it says. If it's a function, I can kind of read through that real quick or maybe go in and make changes.

31:05if it's a file, okay, now it's getting big. But as it's like multi-file changes with all of this stuff going on and like it's been thinking for four minutes and I'm not sure what it was thinking. It'll tell me if I want to look at it. But, you know, here's this big change we're going to make. Change a log. Exactly. And now I got my code review step basically. And there's so many things there that I just get a little bit apprehensive of like, am I going to be able to find potentially where that one needle is in the haystack that maybe made the whole thing go haywire? Are there guards? Are there helps?

31:36Are there concerns that that might be an issue? I think that's something, first of all, that we need to think about in the design of the tool itself, right? We need to make sure that we are not introducing something that creates so much cognitive load for you to ingest in terms of change management that it's beyond your ability to reason over, right? So we are very intentional in terms of how we guide the prompts to control just how much code is actually going to be generated. Other reasons that we do that as well. But I think the other thing is we really want to make sure that we are working with the workflow that you're used to.

32:12So another thing that we introduced today is the coding agent. where if you think about agent mode in VS Code as the experience that allows you to give it a prompt and then you can do synchronous supervision over how it's completing all of the tasks in that prompt, the coding agent is asynchronous. And so you can almost think about it as agent mode is your peer programmer. It's looking over your shoulder. It's accelerating your capabilities. But the coding agent is your peer programmer where you can assign tasks to it as though it was another member of the team. And so it's just like in GitHub, if you're assigning an issue to your colleague, you would instead assign it to Copilot and it can asynchronously go and execute that task and figure out what it, come up with a plan and go and create a pull request and complete that task for you, right?

33:10And so what that I think enables is for you to then still think about the tasks that you're assigning to the agent in the same granularity that you would assigning it to another developer on your team. Right. So you could theoretically do a multi-file edit, like build something, prompt it for that, and then run an agent against that and say, debug this, make sure it's sound code. Correct. So versus, you know, like your question was the fear of the code sucking, basically. Right. I got my code review agent. I got my coding agent. Well, don't worry, because at the end, you can just unleash your agent and just say, agent, check that.

33:47I mean, you could certainly have parallel, you know, adversarial agents kind of working against each other. You could set up that kind of system where, you know, you basically start to build your code. You then want to say, okay, I'm going to have one agent that's going to be focused on, you know, the readability and maintainability of this code. And another agent that's going to be focused on maybe the performance and optimization of the code. And, you know, you could have both of those things kind of going at the same time based on really at the end of the day, in a sense, you kind of can create these things by virtue of just providing the prompt.

34:27You just say, oh, here, Copilot, I have a new issue. I want to optimize the performance for this particular page. Right. It's actually going to do it. It's actually going to do it. It's going to do it. I just think of these little functions you can call. Check this. Check that. Write tests here. That's right. That's really wild. And they do it. Yeah. And we also have, obviously, pull request reviews as part of Copilot as well. So we also apply it at that kind of large scale for basically every code change that we make inside of Microsoft or in our open source repos as well. We do kind of AI-based code reviews.

35:10Right. I know you're using the classical data science form of adversarial there, but I kind of had a moment where I was like, it would be fun to just pit these agents against each other. I was too. Listen, okay, this agent's not very good at their job, and they always get things wrong. Now, your job is to watch them. You know, keep an eye on this. At least known to hallucinate. You don't like them very much, you know? I was thinking that too. Like, could they either, when will they get upset, and will they compete? You know, can you compete them? You both have the same job. The one who does it better gets the task.

35:39You know, their job is to do the task and be excited about getting it right. And so they compete with the person or the other. Well, I mean, I think that actually there's something to that. And, you know, I think one of the things that for folks who are working on different machine learning models for the application to coding, we have benchmarks, right? Just like in the old days when I was working on the JavaScript engine, we had performance benchmarks that we had to work on. nowadays we have benchmarks for these SWE agent kinds of of models that are coming up and so part of what we there's different kinds of techniques that you go through in terms of kind of getting the performance of the benchmark to be better because you can optimize for different things you can optimize for token consumption so like what's the cheapest way to accomplish it you could optimize for performance how can I complete the job more quickly You could optimize for accuracy, right?

36:38And so like in a lot of senses, what you're saying is actually not wrong. And I do think that over time, when we think about different competing agents that could actually go and fulfill your job, you could have ones that are experts in different types of tasks. Fascinating potential world. You mentioned every line of code or a lot of the codes that we do here at Microsoft, that got me thinking about your own products. Yeah. And Satya mentioned code modernization. Of course, a huge opportunity, right, for these agents to do. I was just thinking about Anders and the Teams port over to go. Yeah.

37:22And how tedious that could be unless you have some agents doing the work for you. I'm curious about your old software projects. I'm thinking Visual Studio is pretty old at this point. Yeah, we have 20-year code bases, 25-year code bases. Are you harnessing these things to modernize things like Visual Studio? Can I say I'm glad you asked? You can say that, sure. Well, actually, one of the things that we introduced today is allowing GitHub Copilot to help you modernize your.NET and Java code. So if you have a dependency on.NET 6 and you need to move to.NET 9, or you have a dependency on Java 8 and you need to move to Java 21, then you can actually use GitHub Copilot to help you do that.

38:05And this is like a big deal because, you know, it used to be that those kinds of jobs, like that's the thankless job that as a developer, you, you, you hate that. Didn't somebody spend like 10 years doing that stuff? Yeah. We just heard the story. That moment when like your boss comes in and it's like, we need to modernize the code base and I need you to work for six months on, on doing this port. Like, oh my God, that's crushing. Right. Because you don't get to do anything that's like exciting. It's just tedious. You know, it's kind of tedious. And, you know, from our customers who are using it, they're telling us it takes care of 70 % of the code migration, at least.

38:40So that's pretty incredible. We have, like, success rates in the 90s of just upgrading your code base. So I think that's one dimension of technical debt that this kind of stuff can take care of. Another is, like, security vulnerabilities, right? And that we're applying this internally at Microsoft very, very broadly. you can basically go look for CVEs. And once the CVEs are found, then we can actually go and file a PR to get it automatically fixed. And then all you have to do is review the code change. So my hope, I think that the industry is still saddled with incredible amounts of technical debt.

39:19And if we can actually go and erase a bunch of that technical debt, just imagine how much more innovation could happen. I got to thinking about this idea of like the state of human velocity you know like we are now doing things that we wouldn't normally do not because we can't do them because you're just so time consuming yeah like porting a code base to something else like we were spending a decade to do something like that and now I think we we have access to a tool that lets us think bigger not because it does the work but because we can get past the hard things easier and sooner so the speed of humanity essentially is it's kind of like maybe the inflection point of speed for humanity because like we've been going pretty slow yeah and like since the 1900s you got cars and industry change and at the end of the 1900s you have the explosion of computers and the internet and then the 2000s it's social media and all the things and now it's like ai is here to help us all go to a new plateau faster yeah i mean i think in a lot of senses like we've been struggle that I wouldn't say struggling I would say limited by the available developer talent in the world we still have like a shortage of developers in my opinion right a significant shortage of developers across the world and especially developers who have higher level systems thinking and reasoning capabilities right and so I think that in a lot of senses like what the opportunity what this all represents is an opportunity to kind of spread that that knowledge a bit more broadly.

40:54And like, think about all of the apps that your organizations wanted you to write, but you never got to because your backlog was so long, right? I think there's huge amounts of demand and need in the industry overall that is just not getting addressed today because developers are settled with like technical debt and what they already have on their plate is significant enough to occupy them, right? And so if we can actually erase a bunch of that, And I think that's going to make a huge difference overall. But I think the other thing that's super important in all of this is there are aspects of the developer job that are not awesome, right?

41:34Technical debt being one of them. Another thankless task is like being on call and responding to live site incidents, right? In the middle of the night. I know that a lot of our developers do not relish that aspect of their job, right? And I think that a lot of the new capabilities in AI allow us to offload at least the less complex cases of site reliability engineering response to agents. So one of the things that we talked about today is we introduced a new site reliability engineer SRE agent that can actually deal with, like, if my app suddenly starts to be unhealthy, it can actually go and do a profile and understand if it's a memory issue and even start to auto-scale your infrastructure to be able to respond and mitigate the issue.

42:29It may not be the permanent right repair item or fix. That might come a little bit later, but it can do that first line of response. And for us inside Microsoft, we've actually been applying it internally significantly and have dealt with a ton of hundreds, I think we're probably at thousands now, of incidents that have been managed in this way, such that developers never needed to get involved. and then they just review the repair items from the recommendations from this autonomous SRE agent. So I think that's pretty cool because there's aspects of the developer job that's all about creation.

43:12You love that moment when you get to write new code, you get to scaffold out new... I always loved scaffolding out new class libraries and frameworks and just doing the first rough-in of the application. That was always my favorite part, right? But this means that developers, they don't have to get woken up in the middle of the night and their job doesn't have to be awful. It's like self-healing. And I imagine that, like you said, the fix may not be a permanent one. It's more focused on uptime. Yeah, exactly. My goal is this autonomous agent is not the best long-term fix. It's keeping the application up.

43:50So, yeah. I mean, SRE agents, SREs in general are always focused on application uptime and like meantime to mitigation, right? So like if there is an incident, how long, how long does it take for them to actually respond to it? And then, you know, they also are concerned about things like costs and operations over time. And, you know, I think they can much more meaningfully contribute to how to build healthy, large scale systems that, that operate well. So are these agents actually applying the fixes and the person doesn't have to come in and hit that button that says, yeah, let's go ahead and do this?

44:34Did I hear that right? Correct. Yeah. I mean, it's all within policy, right? So you can decide what limits you want it to have. but you you know if you need to scale your infrastructure up to be able to handle more memory for example it could deal with that automatically in the middle of the night without having to ping you and wake you up and then you come in in the morning and and it says hey we had this incident we had this out of memory exception that happened here you know and then you can go investigate it in the morning and go figure out what's the long-term fix you could almost have it do the fix and another agent to check the fix.

45:08That's right. You alluded to the policy. The policy essentially is an augmentation of potentially an agent that has different parameters. You're trying to take us out of the job, aren't you? I'm just saying, that's just where it's going. I don't think any of this is... Like I said... That's what you can do, though. You can have the thing all the time. You can have an agent that just checks it to confirm based on policy. With these bounds, you have agency to do this thing. Without all those bounds, it is a no. Yeah. I think that's a lot. When we talk about what are the skill sets that developers are going to need to have for the future, it's still the same complex systems reasoning, right?

45:55When you think about if I have multiple policies that I am applying to how to manage infrastructure during a live site incident, right? That in and of itself, that set of policy roles, that is a complex system. And you have to think through, well, what happens when this role conflicts with that role? How is the system going to respond? So I think that's where a lot of our brain time is going to start going, is thinking about how these different kinds of systems and agents that are somewhat autonomous are going to interact.

46:39Well, friends, it's time to build the future of multi-agent software, and you can do so with Agency. That's A-G-N-T-C-Y. The Agency is an open source collective building the internet of agents. It's a collaboration layer where AI agents can discover, connect, and work across frameworks. For developers, this means standardized agent discovery tools, seamless protocols for interagent communication, and modular components to compose and scale multi-agent workflows. You can join Crew, LineChain, Lambda Index, BrowserBase, Cisco, and dozens more. The agency is dropping code, specs, and services with no strings attached.

47:22Build with other engineers who care about high-quality multi-agent software, Or visit agency.org. That's A-G-N-T-C-Y dot org. And add your support once again. Agency.org. A-G-N-T-C-Y dot org.

47:42Are you thinking about how these agents manifest as a visible layer to this agentic internet and web that was alluded to? Because I'm thinking like there's this idea of like agents available. And so why recreate the wheel? I was really just thinking about the idea of a secret agent. Why were you doing that, Adam? I was just like, that's a really cool name for an agent that like doles out secrets maybe or just deals with authentication and authorization kind of thing. Like if there was an agent, there was a secret agent. That's cute. And I would want to discover that secret agent. That's cute. Okay.

48:18Anyways. Well, a couple of things I would say about that. First of all, yes, I think in terms of like thinking about the common way that you can go interact with all of these different agents. Like, yes, I do think that that ultimately our goal is that GitHub Copilot can become that common substrate. It's almost like the omnipresent agentic command center that allows you to interface no matter if you're talking about your infrastructure or your code or your test or even, you know, tasks that I have to do to go work through the bureaucratic layers of our ops team or whatever it is. Like, I think a lot of that can start to become interfaced through working with GitHub Copilot.

49:03So, yes, on that point. I think what you're bringing up around secrets is a great question, right? Sure. I was just wanting to call it a secret agent. No, no, but here's the thing. That's still a great question. Here's the thing, though. Here's the thing. Inside Microsoft, one of, I have kind of two jobs at Microsoft. One is I run, I'm head of product for our developer division, and the other job is I'm basically the GM for our platform engineering team. And so that means that, like, basically we build all of the tools and all of the policies for all of the internal engineering teams at Microsoft.

49:35So we kind of take all of our third-party products and we host them and administer them and extend them and incubate in them for our first-party engineers. One of the big things that we've been trying to focus on is expunging secrets from our code bases. Because secrets are dangerous, right? Very dangerous. And, you know, if you have them in your code bases, then, you know, if you have malicious actors, they can go in and try to exfiltrate your code and get your secrets and then get access to your infrastructure. So generally, we are trying to move towards a system where we do not have secrets checked into our code bases.

50:10That said, like that's a great application of the kind of policy that can be applied at your organizational level to say, look, if I have any code that looks like a secret, I want you to flag it. I want you to file an issue because I want that to be manually checked. And we also have in GitHub Advanced Security detection of those kinds of secrets as well. so that we can actually make sure that you never push it into your code base. Well, then I propose that you make that a product. The secret agent? Done, sir. And you call it secret agent, and you credit Adam Stachowiak as the idea. Just on the fine print at the bottom.

50:50I just like that. It's so cool to have that. Make that a thing. Make that a thing. Now you have three jobs at Microsoft. The third one is to get that big name secret agent. I'm working on secret agent. It's catchy. I think it's called GitHub Advanced Security. Okay. Oh, there you go. Less, I mean, it's a cool name. It's a cool name, but, you know, it's not a brand. Secret agent. Yeah, if you whisper it, it sounds even cooler. That's right. Oh, my. So do you think about cascading effects, especially I'm just back on the SRE side of things, and thinking about turning over so much to. Control. Yeah.

51:31to software agents, which again are, what did Nathan Subo call it? A genius golden retriever on acid. Yes, which maybe those are the models he's working with. But, you know, a thing that you don't ultimately know what it's going to do. Now you can train and fine tune and guard and watch agents watching agents all you want. However, we've seen at scale the Internet operating, distributed systems at scale, things go wrong in ways that are sometimes very quick, very catastrophic, and compounding and cascading. One thing that I think about is some of these stock market trades, when you have quick corrections or crashes, is because you have software making margin calls and trading with software programs.

52:21And eventually what happens is the New York Stock Exchange actually just stops everything and is like, let's chill out here. Yeah. And I think there's a potential of that kind of thing with agent RSREs, you know, changing the memory on your VM, and then this happens. Like a race condition amongst agents or something like that. Just, you know, I'm wondering like what kind of, I know you all think about security a lot, and what kind of stuff is out there for just making sure that maybe there's a pull the plug moment or a way that you can get back in the loop and say, okay, let's just chill out here, guys.

52:53That's a fantastic question. Call it guys. Well, just a team. So I think generally what our approach is is that we want to make sure that every agentic workflow is completely auditable so that we can see what the agent is actually executing, look over it in history, that we do have controls over it to be able to say these are the resources that you have access to. And we also have to think about things like ways of testing the models themselves, whether it's a model that we build or it's a model that you build and for your software. And that's part of what we build with the AI Foundry that allows you to actually evaluate the models against all different kinds of checks, whether that's safety and security checks, whether that's responsible AI kinds of harassment kinds of scenarios or language that's inappropriate.

53:47A lot of that is really what has to get built as a part of kind of building and evaluating models themselves. And then we also want to have this common agentic control layer across all of the software that uses agents so that we can see what those agents are actually actively doing, what resources they have access to, and restrict what they have access to if they start to go astray. Right. And we'll be showing a demo of that tomorrow. Oh, cool. Yeah. Yeah, it's really just a big orchestration problem at the end of the day. And then underneath it, you have your, what do you guys call them? Not the frontier, but the founder.

54:25Yeah, the models themselves. And I think it's really cool how much choice is available at the model level. Because I've even, in my personal use and in my coding use, have appreciated the ability just to swap these different ones, especially as they leapfrog each other in capabilities. Yeah. And I think it's really cool how many different models are there. I mean, that's one of the things that I think has been really great about kind of bringing GitHub models into, to bring the AI Foundry model catalog into GitHub models is it allows developers to be able to go kick the tires on all the different models that are out there.

55:01And they all have different kind of strengths and weaknesses. And in some senses, I think about it as a search space of different model characteristics that have a certain price and a certain performance. And you just need to kind of go find what's the right one for your particular use case. And I think that the fact that we've integrated GitHub models, sorry, AI Foundry model catalog into GitHub models really does allow developers right in GitHub to go test these different models in a playground. And then further, because we have in VS Code the ability to select models as a part of your chat experience, we also find a lot of developers using that chat experience as a way to go test which model is meeting their particular needs for their use case, that they then go right into the application that they're building.

55:54That's awesome. No further questions. I don't have any questions about that. I just think it's cool. Yeah. And you're not the only one who's doing that. A lot of people are, and I think it's great. I love just giving developers choice versus saying, no, you're going to use this. It's the best one. Trust us. Always. No. Don't do that to me. That being said, which one's the best one?

56:18Well, I'm waiting for.agent to become a TLD. Oh. Oh, yeah. That'd be a good one. I mean, AI is cool, but.agent. Because then you have the secret.agent. Yeah. That's all for this one thing. Domain registered. Yeah. Yeah. That would be good TLD because I think there's going to be, you know, they're going to be selling agents like you're selling apps at this point. Don't you think? Well, yeah. If there's a company well positioned to sponsor in some way, shape, or form, because we just learned about DNS with Anthony Eden and how TLD has come into play. Right. You got lots of money to host a TLD. Yeah, there is a whole namespace question, right?

56:53How do you find all these different agents? Right. How do you figure out which one you want to deploy for this particular problem? And I think that's one of the big next things, both agents and tools. You know, there's going to be a catalog. Just like there's a catalog for models, there's going to be catalogs for agents and for tools. And the best way to catalog them is.agent. It really is. I mean, if you're building the agentic web, this open agent web that's happening,.agent. Okay. I'll take it to the top. Two more missions. Hopefully you don't mind. All right. And just, you know, just come back to me for any final sign-off on these ideas and stuff.

57:30Love it. I can give you more. Love it. Love it. So the advancements every year are interesting. It's moving very fast. Here we are 25. If it were up to you, 26, the three of us sit down. You don't have to unveil any secret roadmaps or anything. But what would be going on next year this time if you were excited about it? What would be the next step? We're at agents. Where are we next year? Well, first of all, I think the agents, we've seen with agents just how powerful they are. So we've seen a lot of promise. I think there's also a lot of peril in there as well. Yes. And what's going to start happening is that, you know, basically a lot of folks are using them without real security controls.

58:16And so I think we're going to need to see more ways, to your point earlier, around how do I audit and control all of these agents working throughout my enterprise or my team. So I think that's one thing. We're going to start seeing a lot more controls in that sense. The other thing is part of what we're seeing, and this has really only accelerated over the last three, four months as we've started to have capabilities like agent mode and VS Code, is the capabilities of the software development team are also changing, right? Developers now can do better designs. They can make things not just prettier but more easily usable without having to have designers involved.

59:01Designers can code. Product managers can now code. So what does that mean for how we think about the evolution of the software development team? And what canvases do we think we need to do collaboration? I think of it like giving somebody who the whole team or the whole group of people you just mentioned, they all speak a language. Let's just say it's English, for just lack of better terms for this analogy. I think of it like these folks have a limited vocabulary. These folks have a limited vocabulary, and they're all specialized. And now they have a more shared language spectrum. Exactly. Because you have the words, we have the words, we can share the words.

59:39That's called speaking, of course, as you know. But I feel like that's what it does. You now give them, they all spoke English already, because they all understood some of the code, some of the design, some of these different features. But now they can all speak a certain language. I completely agree with you. You know what I mean? But I think that part of what's going to happen is that everyone is going to start contributing to the code base more easily, right? Which is better for the product. I mean, and the user, obviously. But I think we're already starting to see designers contribute code, right?

1:00:10In terms of like, rather than handing a design over the wall and say, engineer, go implement it. No, the designer can actually go. And if they want rounded corners, they can get rounded corners to happen, right? Or if a PM has an idea around a new feature that they want to experiment with, maybe they can go build an initial prototype with that without having to go bother the engineers to go get that done. And I think that starts to kind of raise interesting questions around how do you think about architecting different kinds of systems. I think maybe one of the things that might happen is that there's a difference between solutions that are more sitting at that SaaS level versus services that are more at the systems level.

1:00:57I think that that SaaS level is going to start to be something that is more easily extended. you know today when we think about something like a microsoft office or m365 or we think about something like github itself it's essentially a end user experience a sass that is being provided and it has extensibility points and those extensibility points are painstakingly crafted because every time that you expose a new api that allows you to customize the environment Right. It both empowers your users to go build other things, but it also represents kind of a boat anchor that like you're stuck with the back compatibility for that contract.

1:01:41Right. But I think that that what this is now kind of enabling is for you to start to build other systems, other automation on top of other systems much more easily, even without the API, to be frank, because now it can just like traverse the DOM or whatever it needs to do. and I think that means that like a lot more software becomes a lot more extensible and I think that that means also that the way that you build software itself is going to end up changing over time the other thing that I think is super interesting is like we also spend a huge amount of time right now on on the the view creating the view sure right like if an MVC kind of model I think in the future, it might just be that you focus on the model.

1:02:28And the view, you actually go and specify with a design system. Well, I saw a t-shirt downstairs. It had a bunch of things crossed off. I think developer was one of them and something else. And it just said builder. Yeah. And so I feel like I've been ahead of the times basically with, I think, people becoming builders rather than just developer or just designer. And the word just, not pejoratively, if that's even a way to say it. But more so builder. Everybody's a builder and everybody can contribute. Yeah. Love it. I have a question that I think is maybe would have been way better back in the VS Code part.

1:03:01But as we wrap up. Yeah. I don't know if it's spicy or not. But I'm curious. We were kind of debating, you know, VS Code's foothold and is it a strategic advantage and this and that. And the open sourcing of that and what it's been a good thing for Microsoft. What we've seen recently in the Vibe coding space is VS Code forks. Uh-huh. And these forks come up fast and furious, and they're getting huge valuations. They sell for billions. Right. They sell for billions. They're getting large user bases very quickly, at least it seems like they are. And in a sense, that's a little bit of a backfire, right?

1:03:35Because now you're providing VS Code, this platform, which is just forkable. And now you're giving competitors an opportunity to just catch up real quick and compete with Copilot in weeks. I mean, they could vibe code their way to a$3 billion valuation. Does that bother you? Is that, do you even see it? Are these just like the cockroaches that you just say, get out of here, cockroach? How do you guys view it? How do you view it? Kelsey, I tell her that one. I love you, Kelsey. I think that there's real innovation that's happening in the industry and a level of competition that we haven't seen for a long time.

1:04:13So, like, I have a tremendous amount of respect for, you know, the competition that we're seeing right now. in the code editing space. I will say, yes, I think that there is a lot that has been built on top of the open source code base of VS Code, and I think that is creating a foothold that allows others to kind of go and create additional features or differentiation on top of it. But that's, I think, one of the reasons why we've decided to actually open source the GitHub Copilot extension for VS Code and build it directly into the VS Code code base is we really do think that the AI experience is now table stakes for any code editor.

1:04:53And in the same way that VS Code has been open from the get-go, we think that now the AI capabilities in VS Code also need to be part of the open source code base. And I think that we certainly believe, and whether it's VS Code or TypeScript or anything that we do in the Azure SDKs or.NET, all of that's open source. So like half of what my team works on is done in the open and open source. You know, we certainly see that when, especially when you're trying to build a community around a technology, an ecosystem around the technology, building in the open actually creates better products. You know, it allows more people to contribute, whether they're contributing pull requests and code contributions, or if they're just logging issues and just, you know, they care enough to actually follow through with really great issue descriptions.

1:05:43that's an important way to contribute to the code base. And we see that across all of our open source code bases. And I think what we hope to see now is there's a tremendous amount of innovation that's been happening in AI-based coding. What we hope to see is more of the community contributing back to the VS Code code base to really advance the state of the art for everybody. I'm not sure I would call them competitors, though. You don't think Winsurf is a competitor? of Copilot? I would say... I'm going to use one or the other, aren't I? I guess so. But is that your customer, for lack of better terms?

1:06:23Oh, they want all the customers, don't you? I don't think so. I think... Let her answer. Well, this is what I assumed you were thinking. And you said a lot of things, but you didn't say this. But if I read between the lines and I think, if I were you, I wouldn't see it as competitors because you are focused on developers using VS Code, and I don't think they're not developers, but if you're vibe coding, it's not a developer action, it's a different way to get the end result. A developer writes code and cares about the code, whereas the other way is not so much less about the code, it's a different way to get there.

1:07:00That's how I'd look at it. I think there's kind of two pivots to that. First of all, I would say, I think that code editors, generally, if your primary task is to write code, then I would say any of the popular code editors are competitors in a sense. But to the point earlier that we were talking about, we believe that we live or die by day-to-day product truth. And we have to basically win every developer based on their usage and experience with our products. And we strive to make the best products we possibly can. I think to your point around vibe coding and how does that relate, I see vibe coding as a really interesting evolution, right?

1:07:44It's not quite... I'm throwing zero stones at that. I'm an agnostic when it comes to all innovation. Whatever gets us to the next place, we all love it. That's what I'm for, right? And if vibe coding is one of the ways we get there or it invites more people in to build software, cool. I think vibe coding invites a lot of people in to go build more software. I think that it's not your typical pro-dev software developer. But I think that what Vibe Coding has kind of started to create is more of this pattern of what I would call natural language-driven development, which starts with maybe a Vibe initial prompt.

1:08:22But then it evolves into a full spec. And the spec is still written in natural language. It's not written in C Sharp or TypeScript or JavaScript or anything like that. It's written in a natural language, English in my case, but could be written in whatever. But then you take that spec and then you use that spec as the prompt. Right. And that allows you to then iterate to this level that you can get to a much more sophisticated first implementation of the code that you're aiming to implement. And then you continue to iterate and you may even modify the spec as opposed to modifying the code. And so I think that's starting to change things.

1:09:05And so from there, then it's like, okay, well, now the PM can contribute even a spec for a feature or they could contribute a spec for the initial product. The active testing could also be, in some senses, a large prompt. The designer could contribute a design system into the code base. And so I think what we start to see is that over time, the code base is not just everything that builds. It's all of the prompts for all of the systems and all of the different phases that you go through of the software development lifecycle. I think that's really insightful. And one of the things that I've noticed as an experienced developer trying to adapt and adopt the tools is that software isn't built in a chat scenario.

1:09:55scenario. Like we don't chat your way to a software system because there's just like so much chatting that goes up. You know, you, you design specifications and yeah, you may have conversations that lead to that design decision that you make. Once you make that, you don't want that to be like one moment in a conversation that was way up here. You got to, you know, tell your coding agent to scroll back and remember what I said back then, like you want to actually have tangible outputs. I expect that gets created through whether it's a vibe session or just a peer programming session. Now I have this written document that evolves and it'd be so cool to be able to take that spec and be like, all right, here's a different model.

1:10:34You know, start fresh. We don't need to use the code. We have the spec. Yeah. And like you write the same, you can take the same spec, six different models, write the program, you know, may take the best one on each or whatever it is, have something that you could like start from. So you're actually building out and architecture. Yeah. Is that formalized at all? Yeah, it is. I mean, we now are starting to do more spec-driven development. We have.prd files that would be the description of the spec. And those kinds of things are starting to get checked into the code bases. But I think also there was a nugget in what you were talking about in terms of design decisions that are made throughout the process.

1:11:14Sometimes it's not just the spec that you actually use. It's the why. Well, it's the conversation. Like if you think about you were having a conversation with your designer or another engineer on the team in terms of how something should work, maybe over time the history of that conversation should actually be something that's persisted into the code base in some senses. Yeah, and hopefully in a summarized fashion. Yeah. You know, so it's actually grokkable. Yeah, exactly. I know there's some people that keep actual, I can't remember what's called a Y document, but it's basically around their decisions.

1:11:46not the decision we made, but why we made the decision. Right. And so you can go back to that and be like, no, here's why there's this fence here. Exactly. You see a fence, you're like, why is the fence there? It doesn't need to be there. It's like, well, there was a reason. And none of us know why it's lost to history. Right. But now you could go back to that chat or that context and at least link it somehow, whether it's summarized or linkable or whatever it is, to be like, here's our spec. And then this part of the spec here, why is it like that? Well, here's the why. Yeah. Maybe in that world, developers don't have to write documentation.

1:12:19Now you're selling me. Oh, my gosh. Or they write one. They write one, the initial spec. That's right. Yeah, I was thinking about that, too. All right. Awesome. This has been a blast. Yeah, thanks for having me, guys. Thanks so much for sitting down with us, Amanda. Very fun. Thank you.

1:12:39okay on location at microsoft build is always a treat big thank you to our friends at microsoft for making sure we're there richard you're awesome and the rest of the team man so cool always good to be in seattle always good to have that awesome pacific northwest weather and to our friends over at five iron it was fun swinging with you okay so what's next big things happening around AI. It's always moving. It's not hype. It is real. This is not science fiction. This is science reality, and it's here to stay, and the adventure has just begun. A big thank you to our friends over at Retool. Retool Agents looks so cool.

1:13:17I'm using it in a couple of different scenarios, and I just can't believe it was possible. Seriously, I just can't even believe it was possible. Our friends over at Heroku are launching the next gen of heroku big things coming if you love heroku you're gonna love what's next and to our friends and our partners at fly those robots those humans everyone loves the fly.io platform it is the best that is the home of changelog.com learn more at fly.io and to the beat freak in residence break master cylinder he'll be mixing some beats live we are going live by the way if you didn't know this changelog.com slash live we're in denver launching pipely launching our next gen cdn what's happening around our platform gerhard me jared bmc jason others i mean it's it's not to be missed you are invited learn more changelog.com slash live we want you there check it out tell a friend okay that's it this show's done we'll see you on friday

1:14:33Thank you.

1:14:54Game on!