GitHub Copilot in Visual Studio: Agents That Debug, Profile, and Test | BRK207

Key Takeaways

Hello everybody. All right, welcome to this second-to-last episode of of this room here at least at Build. So, thank you for being here. My name is Mats. >> I'm Nick. >> And we're here from the Visual Studio team to talk about Visual Studio and Copilot in Visual Studio specifically. Now, we could talk about all sorts of things uh Visual Studio and uh features in Visual Studio, what's coming, and all that type of stuff. But, this is specifically about the Copilot pieces. Um and we have some cool demos, and we're going to talk about uh roadmap, what to expect, what's coming down the pipe here over the summer. And um just to frame this a little bit for everybody here. When we're talking about Visual Studio, because we get this question all the time. We got it at the booth here through the conference as well. Um how does Visual Studio fit into this new agentic world? And um it works great. So, if we look at what Visual Studio is and how we see it and how we see its positioning, it is the tool for professional C# and C++ developers on Windows. That's what it is. So, if you're doing that, this is the premier place for you to do your development today and tomorrow. Right? Whether you're coding all day long or you're doing a bunch of agents do the work for you or whatever it might be, this is for you, okay? Now, we have a bunch of other tools. So, if you're doing Python or Node.js and stuff, we have a bunch of other tools for that. VS Code is fantastic. Um and so are other tools, you know, whatever makes you happy. But, if you're using C# and um C++ as a professional developer, Visual Studio is for you. Because there's certain things that makes Visual Studio really, really good for professional developers. Because a professional developer does things a a bit differently often. Um we have to think about quality gates. What does the code look like? Like security, accessibility, there's also such a compliance and governance. There's administration like IT admins that may have a say on what uh the role of Visual Studio across their fleet uh is supposed to behave, group policy, and so on. So, this is something that's specific to pro developers and it's something that Visual Studio is really, really good at. And it will continue to be a high priority for us. And there's something to say about code quality. Uh especially in this new world of agentic development where you don't always write the code, but you definitely review it, right? So, you might have an agent do some of your work writing the code, but then how do you maintain that code quality, coding standards, and so on? And sometimes that matters, and sometimes it doesn't. The way we see it when we talk about this distinction is is code an asset? Is the code something you have to maintain for years to come? Maybe a whole team is working on it. Coding standards matter, formatting, and quality, all sorts of things because code itself is an asset. Versus the other one where it's okay, I'm I'm writing some proof of concepts or internal tools where the code is an artifact. It's it's the thing I'm producing and I don't really need to read it that carefully or, you know, in order to maintain it. I'm fine with just the agent doing that. Um, that's when we say that the code is an artifact. And from Visual Studio's point of view, if you see code as an asset, then Visual Studio is for you. Okay? This is where we are like very, very uh serious and where we are seeing our investment go for professional developers that see code as an asset. And And have some cool demos. Nick, you brought some some really fancy stuff that I'm really excited for you guys to see. And so um let's cut over to the demo. Cool. >> There we are. >> Uh so when Mads talked to me about coming in for this talk, he said, "You know, we got to show something for the professional developer. We got to show, you know, what is actually real, what are people going to encounter every day." And so I thought what more fun could we have than to actually work on Visual Studio inside Visual Studio? And so this solution that I have opened is the Diagnostics Hub solution, and this is the code name for the Visual Studio profiler itself. This thing gets built, packaged into Visual Studio, and this is what gives you access to all of those profiling tools that you enjoy in Visual Studio. And this solution, this component is written in C++, it's written in C#, it's written in JavaScript, it's written It's got some assembly and some IL. If you look really deep down, there is a lot to it. And so we need professional tools to actually be able to work on this. And so what better way to demo the power of Visual Studio than to do use this? And so I want to walk through an actual bug that came across my plate uh couple of months ago. Uh and this was an internal telemetry bug that got filed on us where we have this index out of range in hybrid dictionary enum keys iterator. Uh we actually worked on a new feature on the profiler. We added it in, and then when some of our internal dog fooders started using it, we started getting a couple of crash hits. And this bug was filed, and it was sent over to me. Uh and I went and I had to go fix it. And normally I would, you know, look at the stack trace, I would start digging in and I would try and figure out like hey, how is this happening? Why is this happening? But now with a lot of the new agentic powers that are in Visual Studio, I can use that to help me be more efficient in actually working through this. And so I copied that link real quick and I'm going to hop over to the Copilot chat and one of my favorite new tools in Copilot is access to the MCP servers. >> Oh, yeah. >> They're great. Um I can basically I have this tool that's super powerful and I can use these MCP servers to tie into all these different endpoints and one of my favorites is this new ADO one. And so with this I can say, "Hey, we are getting a crash um noted by this bug." And the nice part is I can just copy and paste the bug link in and then I can say, you know, write me a unit test that demonstrates this bug. And now Copilot's going to go ahead, it's going to go and access that. And right away you can see it tries to use the MCP servers again. Matt was talking a little bit about that governance. I can't just turn it on autopilot YOLO mode. Like I have to be in control of what's actually happening on my system. It's using my credentials to access these things. >> Well, hang on. You could put it in autopilot, right? >> I could. >> Uh-huh. >> I could. I like to be in the loop. I like to understand kind of what's happening. >> Yep. >> And so you can see it's trying to do this uh get work item. I'm going to go ahead and I'm going to confirm that and I'm going to say, "Hey, that's fine." And so it's going to go, it's going to fetch that work item. Uh you can see it just grabbed an off token. Uh we'll go ahead and close that. We'll flip back, and it's already seeing like, "Hey, look at the hybrid dictionary source, and let's look at the existing test structure." So, it already picked up on the stack trace that was in there. It noted that there's problems in hybrid dictionary, and then says, "Let me find the tests for it, and let me try and go and write those tests." And so, it's continuing to dig through. It's just gathering more context, and you can see it's already implemented a test for me. Now, the interesting thing is this bug came with a new feature. We didn't actually have any tests for this hybrid dictionary, uh and these code paths where this is starting to crash, it was in code that was never used, and this new feature made use of that code, and that's why it started to crash. And that's why it was never caught in code review. >> We all have code like that. >> Yeah. >> Hanging out, yep. >> So, I'm going to go ahead. I'm going to keep all these changes. These look great, uh and it gave me two new test methods, one to enumerate the keys, and one to enumerate the values. Uh and then, I'm going to flip back over to my solution. I'm going to link over to where it is. It found my data warehouse managed suites um test project. This hybrid dictionary was in our data warehouse component. I'm going to go ahead. I'm going to say build. >> So, this is the actual code that's in Visual Studio. It's one of the many packages that make up >> Yeah. >> all the different features of Visual Studio. >> Yep. Exactly. And looks like there was a build issue. Maybe. Try this one more time. >> One failed. >> One failed. Oh, hey, look at this. The type string must be non-nullable value type. Uh it looks like what's happening is this is supposed to be using um some sort of struct for the key. Uh so, that was nice and fast. I can just tell Copilot, "Hey, those don't compile. It looks like it's the wrong key type." And I can kind of continue to have that conversation with it. Hopefully, it's going to go ahead and fix it. Uh it's going to look into what key constraints exist. >> But what I really like about this the your approach here is that you're writing the test first. >> Yes. >> To reproduce the issue. >> Mhm. >> Why do you do that? >> So, I never actually believed in test-driven development until Copilot came along. Like it just felt awkward. Like I wanted to write the code and then afterwards I might write in a couple of tests to see um you know, what can I do to protect myself from code failing in the future. Uh now I look at this more so in terms of I can write these tests to kind of create this nice test harness and then I can let Copilot actually help me write and author the code that's going to fix those tests. >> Yeah, it gives you like the safety of having the harness the guardrail in place when you let loose the agent to work on your code. >> Exactly. Exactly. And the nice part is you get this like durable artifact that goes with your repository. So, then in the future you start doing more refactoring with Copilot or you're changing out different dependencies, you have this nice test bed that you can then fall back onto. >> Mhm. >> And now looks like our build succeeded, which is awesome. Uh so, now let's go ahead and let's find uh this in our test explorer. So, I'm going to say um I'm just going to copy this. So, I have my test here. I'm going to run it and hopefully with any luck this test is going to fail and it's going to reproduce the crash. >> It's running. So, this is the challenge of working on large enterprise software. There are hundreds of projects and stuff isn't always instantaneous. >> There we go. >> We can see it's running now. The build succeeded and sure enough it failed. >> is a success. >> This is a success. >> Yes, this is what we wanted. >> But actually, this is really interesting cuz the test detail summary, if I look at that, my original bug was it should throw an index out of range exception, right? >> Uh-huh. >> And it's not throwing that. Instead, it's saying it's failing in a cert. And so, this is not what I would expect. So, I'm just going to go back to Copilot and say it's not throwing the exception. It is failing with >> This is very real world type of stuff, right? You go and you try to create a test to reproduce and you discover other things that >> Yep. Would be problematic. >> This is literally what my day-to-day looks like. >> Uh-huh. >> It looks like it says it needs an extra element. Would you like me to go ahead and apply the fix? Yes. >> That's nice. All right. Yep. >> Actually, when I said yes, >> it's fixing the test itself. >> No, it's fixing the code. [laughter] >> Okay. >> So, I'm going to say >> to fix the code yet. >> Not supposed to fix the code yet. >> Yeah. >> Um fix the test so it fails with index out of range. >> Mhm. This is the thing when you So, you actually practice the But because this is AI, you kind of never know. >> Yeah. No, it's >> get different different runs every time. >> Yeah. >> That's the fun of it. Mhm. The working in the non-deterministic >> Right, but >> probabilistic >> It's a really good um It's a really good uh way of looking at this because you were able to see what was going on and so your skills, your expertise is what helped you guide the agent to do the things that you know that it needs to do. So, the the better you are at your job as a developer, you the better you are at managing your agent, too. >> So, now it's gone ahead, it's updated those tests. Uh so, let's run those tests one last time. And with any luck, hey, we're failing with our index out of range, which is awesome. Um actually, I think that's first time I said it's awesome that our tests are failing, uh but in this case, I'm actually happy, right? And so, now I can start to lean into even more of the Copilot features of it. So, I have this nice uh guardrail, I have this nice test harness in place, and this is really where I can let the agent cook. I can say like, "Hey, this is the problem, go ahead and fix it." Uh and we got to doing this so often in um Visual Studio that we're like, "Hey, go optimize this benchmark. Hey, go fix this test that Hey, let's just go put a nice shiny button for people to click, and let's just make it nice and easy." So, I'm going to do my clicky clicky in the UI, and I'm going to say, "Hey, debug this test with Copilot." >> just right-click the test and say, "Debug this test >> Exactly. >> with Copilot." >> Yep. Yep, exactly. And so, now it switched over into our new debugger agent. Uh and so, we've gone from the regular agent mode, we're now in this debugger agent, and the debugger agent knows how to use the debugger. It can uh set breakpoints, it can hit those breakpoints, evaluate expressions, it can um look at memory, and really start to understand the code. In here, it gave its hypothesis, and it said, "Hey, the bug is clear." Turns out we had an off-by-one error, and it it it's very specific on the number of elements that are in that collection. Uh and so, it went ahead and fixed it, but then it went and it reran that unit test. It ran it under the debugger, so if a problem did occur, it could catch it. Uh but after it applied the fix, it noticed that the test passed. We're good to go. >> Nice. >> And so, this was legit a problem that we had. It came out I think I want to say it was the 18.5 range. Uh and we caught it internally before it started affecting customers. >> 18.5 was Was that the April update? >> I believe it was the April update. That sounds about right. And so, we caught it before it started affecting users. Uh it was in affecting our internal users. We're able to use Copilot to author that fix and push out that fix. >> Nice. >> So. >> And so, this is So, anyone you like before you could also go in and right click and say, "I want to debug." Mhm? The test, right? And you could set your own breakpoints, you could do your own debugging. But you said, "Hey, instead of me doing that manually, I'm going to let Copilot do that." And one you know, off-by-one errors, I mean, we've all been there. Sometimes they take forever to find even though they're simple in nature. Uh and so, something like this can really speed up even the simplest things, right? >> Exactly. Exactly. And so, the the second demo I want to kind of show is uh our new uh profiler agent experience. So, one of the awesome packages we recently added was our VS Test Performance Collector. And so, what this is is a NuGet package. Um you can add this to your test runs. We added this onto our Azure DevOps test runs. And so, every time our unit tests run, it automatically collects a prof- uh profiling trace for us, adds it to the test attachment. >> a profiling trace? >> So, profiling trace uh when that test is running, it it'll start saying like, "Hey, I'm about to execute the tests." We will turn on the profiler, and it's going to start collecting information about where your program is periodically throughout its run. And then at the end, it'll say, "Okay, I'm all done." It'll save all of that data it's collected along with auxiliary data like uh debugger symbols, uh metadata from .NET, uh and then it can take all of that and it can present a report to you that basically says like, "Here's where your program spent the most amount of time." >> Uh so, like CPU cycles, memory allocations, object allocations, that type of information? >> Exactly, exactly. So, we can capture CPU data, like you said, we can capture allocation data, um and we're going to demo this in uh Visual Studio uh where we're going to use actual instrumentation and we're going to use dynamic instrumentation. Um so, actually what's going to happen is that unit test will start up. It's going to then hook into the profiler and the profiler is going to instrument your code with start and stops between all your method calls. So, we can get exact performance information that we can use to then determine where we should apply fixes. And so, I was saying we recently added this to our Azure DevOps uh PR runs and we noticed that we had this um express decode large file. Yeah. code file Uh we had this decode large file unit test uh or verify my large file uh which basically compares how quickly we can uh compress and decompress a diagsession that has one of these ETL files in it. Diagsession is um the format of that trace file that the profiler collects. >> So, whenever you open up a profiler trace in Visual Studio, like it's reading that file? >> Exactly. >> Into memory? >> Exactly. And so, when we started running those uh unit test trace, it said, "Hey, you're spending most of your time in here." And so, I want to go ahead and I want to make that faster um in the profiler. So, I'm just going to again, I'm going to right click and I'm going to say profile with Copilot uh cuz again, I could specify like, "Hey, at profiler, I want to go ahead and I want to run this unit test and I want to make it faster." We're doing that over and over and over. And so, let's make some clicky buttons that I can click on stuff and I can get into my scenario. >> Okay, and but so you said co- profile with Copilot, but you can also just have said profile. So, if you want to do all this yourself and dig into the data and you know, get your hands dirty, you can totally do the same thing? >> Totally do the same thing. In fact, we technically don't have to show the UI here. Copilot doesn't necessarily care that the UI pops up and that you can browse through it. We present it because we want you to be able to dig into the UI if you want. >> And you can actually help steer the conversation with Copilot. >> Super important. And so, you you under- you get to understand what's going on as well. >> Exactly. Exactly. And one of my favorite things that you can do with Copilot after it's done one of the optimizations, you can ask it why. Why is this faster? And you can learn as a software engineer like, "Oh, hey, I've learned so many tricks about the jit, the GC, um just asking Copilot like, why is this suddenly so much faster if I do it this other >> Right, because it it because it knows all the low-level uh stuff. Like, I don't I know how to write C# but I don't know unsafe C# right? I don't necessarily know why one type of list or dictionary is faster than another type. >> Yep. >> And so, that it explains that to me is is super helpful. >> Yeah. Yeah. So, uh we we ran the trace and Copilot did a initial analysis uh with the findings. I can kind of look at the trace myself. I can see, "Hey, this took exactly 3.88 seconds to actually run the um the unit test itself. It was doing some Express stream test stuff. It was doing some hashing. Uh and you can see where it's reading bytes. Uh and then in the key findings, it's saying like, "Hey, the the hot path is dominated by this frame, this Express Uh and it's hitting this check read enough bits function all the time. And I'll be honest, I was the one who wrote this code, and I can tell you I profiled this code a ton. I was the dev lead for the profiler. I had to use it all the time. And even though I've profiled it in over and over and over over the years, there's still optimizations to find in it. And so, Copilot's gone ahead and it's given me helpful suggestions here. It says, "Hey, I can optimize this Express stream read block to buffer reads and reduce the binary reader overhead." I'm going to just click that and say, "Yep, go for it." Mhm. And so, it's going to go off, it's going to read the context on that, it's going to try and find like, "Hey, where is the source code?" It's going to look at the line information, match it up with the uh profiling report, and it's going to know exactly what it needs to go and optimize. >> Yeah, so the the what's really nice here is like it doesn't guess from the code. Like, it doesn't just look at the code and say, "Oh, this looks like it could run faster if you do these other things." It looks at it's actually executing code >> Yep. >> to figure out what the issue was, which is much stronger scientific case for the optimization, right? >> Exactly. It's using actual data. So, one of my uh favorite sayings is, "If you're not using data, you're not actually profiling or improving performance, you're just refactoring." >> Yeah. Right. >> So, it's gone ahead, it's implementing some changes in Express stream. You can see, looks like it's creating this new byte buffer. It's updating some Huffman table uh read table. So, some really low-level compression code that's used to compress these big die accession files. It's adding that and then with any luck, it'll go ahead, it'll build stuff, it's going to run the test again to make sure that it doesn't fail, and then it's going to re-profile it again to validate that it improved. >> So, with success, Visual Studio will be faster after you commit this code change. >> Exactly. We've actually >> We all get to benefit from this. >> We do. We do. I think um since we've added this new test collector, I think we've had six or seven different PRs into this diag session reader. We've over doubled the performance of reading these files in the latest versions of Visual Studio. >> Yeah, I do remember back when I when I started using the profiler, it's something you do after you do your code, and it can take minutes to run, and even just to open that file takes minutes, and so it's something that becomes an afterthought. It's not part of your inner loop, uh you know, dev test, you know, build run cycle. It's something you may do after the fact if you remember. But, because it's so fast now, I can do it as part of my inner loop. I can just start a new session and see whether I had any regressions. >> Yeah. >> And like I would know like a minute later. It wouldn't be like this long process, right? [laughter] >> And it's always, like you said, it's one of those afterthoughts. Like, people are interested in, you know, how do I get new features out? How do I fix bugs that are crashing? And then we we start to kind of let the code degrade over time cuz I can I just going to add more and more to it, and people aren't screaming at me yet for performance. And it takes time, and it it's a lot of data to try and understand. And now that you have kind of a partner to help you dig through that and help you understand what it is that you're looking at and suggest different optimizations is just great. >> So, that NuGet package you were talking about that you add to your project that you that helps you run your CI runs to give you the benchmarks. >> Yep. >> You get the diag sessions, so you have data like on your CI runs. You can now see if anything slowed down, you're having any regressions. >> Exactly. >> And you can then take that file >> Yep. >> and you can just open it in Visual Studio and see exactly what the problem was. >> And so I could download that file and I could see it. >> Yep. >> I could also use those ADO.NET CP tools that I showed in the first demo >> Uh-huh. >> to have it automatically go out, find that file for me in this test run. Like I can say like here's the URL for the test run or here's the URL for my pipeline. Go find any diagnostic sessions you can find, go analyze it in the profiler and tell me what I can do to optimize my code. >> Oh, wow. That's amazing. Amazing stuff. And this is something everybody can just go ahead and do. And we were talking about this. We've never heard of anyone that like on their own, if you go and improve the performance of your app, like it's one of the few activities we can do as developers without having to ask permission first, right? It does We don't need to have a ticket, a Jira ticket, or a GitHub ticket to go improve the performance. It's like Good job. >> Yep. >> Thank you. Thank you for improving [laughter] the performance, right? It's always a good thing. >> So it's going through another build of the solution. Again, this is the challenge of big enterprise code. Um >> You could have used the solution filter for this one, maybe, Nick. >> I was thinking about it. It's something that we recently added. The thing is is like I like showing that there's 160 different projects and this is is real as it gets, you know, it's C++ code, it's C#, JavaScript. So. >> 160 projects and it's only the profiler and diagnostic hub? >> Yeah, it's the profiler and it's the diagnostic uh tools window that pops up when you do debugging, you know, the pretty graphs and >> So if we combine that with all the other parts of Visual Studio, we have a lot of projects. >> I think when we first did the conversion over from TFS to Git, it was like 400 gig worth of data inside of it. It was just a massive amount. >> Wow. So it's running the build. >> It's running the build. I'm hoping this is going to work and pass. While we're waiting for that, we can kind of review some of the changes that it did. Uh so, it looks like it did a pretty extensive amount of changes. And the interesting thing here is we were reading from this input stream using a byte reader. And that's really fast. Like, it's the fastest way to access a byte stream in .NET. And it's still like, "Hey, that it it thinks it can do better." And so, what it ended up doing is it read it into this new byte array that it then just can directly read from. And it actually reduces the cost of the um calls into the byte reader. >> That's amazing. That's like stuff that you would probably never think of yourself, right? >> Yep. >> You would just see the profiling trace and be like, "Oh, yeah, but it's already optimized. It's using that reader and it's super optimized as it is. There's nothing for me to do." >> Okay. So, the build succeeded. There were some errors from unrelated projects. Again, as real as it gets. It's now running the tests. Uh and so, it's actually profiling it again. >> So, it's profiling again? >> Yes. So, that's one of the biggest thing. I always say, "Optimize twice or measure twice, optimize once." You measure to establish a baseline, then you go and you make some changes to your code, and then you measure again because you want to see the impact of the changes that you're making. >> Okay. And so, it was the one that now executed the unit test again with profiling attached or to create the diag session? >> Exactly. >> So, it's just one seamless flow, basically. >> Cuz it knows that you need to you need to in order to do a good scientific performance optimization, you have to do that measure before and after. You need to see the impact of the changes that you're doing. >> Yep. Yeah, 160 projects. It sometimes it takes a while, huh? >> I know. >> [laughter] >> Think test explorer also kicked off a build, unfortunately. >> Oh, [laughter] okay. Yeah, that's how it goes sometimes. It's just how it is. I like the way we're approaching this. We're You know, remember back in the day with HTML5 it came out, you had this idea of progressive enhancement. Yep. So, you would have you create your website, it would be basic, you would have be able to like click the links, it would change to a new URL, and it would load everything. And then Ajax came along and all of a sudden we could partially load pages, and then, you know, React and Angular and more and more stuff came on top. And if your browser was able at the time browsers weren't very able to do anything, but as they become it became better you could take advantage of all these features on top of the basic layer. Yep. And that's kind of what we're doing here, I feel like, with some of these Copilot stuff where we come in and you can be the driver, you can do everything manually if you want to. You can completely be in control of everything just like you have so far. But, you can take that extra step atop that with Copilot to really push the limits. >> Yep. >> I I really, really enjoy that. So, you can sometimes you may want to have the Copilot experience, and sometimes you don't. And you can decide. >> Okay, so uh it just ran the three tests. So, here's the interesting part. Uh it ran the tests ahead of time because it wanted to make sure it didn't regress any of the behavior. And then it's profiling again. So, again, you get these really nice guardrails with it. So, you can really let it go and cook, if you will. >> Right. >> And with this, it looks like we're getting another profiling trace out, and >> going to give us a new chart. That looks different. It's more green now. >> It is more green now. Uh time is shifted in there, and we're at 2 seconds for running that performance test. When previously we're at 3.8, so we almost doubled the performance of running that test, which is decoding one of these large files here on stage. >> Awesome. That is fantastic. So, this is something everybody can do. You can go home and do this, right? On any code base. .NET, C++, >> Yep. Whole thing. >> .NET, C++, whatever you have. >> That's awesome. >> So. >> Wonderful. This is great stuff. So, yeah, I encourage everyone to go try this if you haven't already. It's really, really powerful stuff. All right, let's switch on back to the slides. So, Nick, you ran this. You told us you you've run this now on the Visual Studio code base, but you run it on other things, too, right? We ran it on the Visual Studio itself, like profiler. You were telling me about the Was it the startup? You found like 80,000 allocations recently or something? >> 800,000 allocations in startup due to an Azure DevOps cache file when it's loading the version control library. The profiler agent actually found it in VS startup. I kind of I set up a rough loop and told it, "Hey, run devenv, allocation profile it, see what you can do." And there was this XML deserialization of this cache file. Trimmed 50 megabytes off of our initial heap, 800,000 allocations, way less for the GC to do. >> That's amazing. Um we turned it on to the Azure app service. Like, instead of just doing Visual Studio, what other parts of of Microsoft products can we look at? So, an Azure app service reduced the cost, basically, of running Azure app services, right? >> Yeah. >> Yeah. By optimizing the performance there. Roslyn, what did you do with Roslyn, the compiler? >> We literally just did the Roslyn compiler, I want to say two, maybe three weeks ago. Uh Roslyn compiler has tons of benchmarks. People have been optimizing this thing for the longest time. We found an optimization in switch case evaluation. Uh it was a SD2 on the team who was like, "Oh, I just want to I'm going to download Roslyn. It's got some tests. I'm going to run through it and I'm going to let the profiler try and chew on it." Sure enough, found it and got his first contribution out to Roslyn. >> That's amazing. So this works on a wide variety of different uh types of applications and libraries and whatnot, whether it's UI or APIs or or um you know, DLLs or whatever it might be. Uh across the board. So that's that's pretty fantastic. Uh Now uh We've got a bunch of stuff coming. >> We do. >> And we can talk about a bunch of the cool stuff we got for like uh What have we got coming? We've got work tree support coming uh next week, I think it is. We have full support for Git submodules coming next week in Visual Studio. Sounds nice. But we're not going to talk about that. >> Yeah. >> Yes, finally. But we're not going to talk about that. We're going to talk about some of the cool things we have for Copilot in Visual Studio. Um so a lot of us have to maintain old code, right? Whether it's old you know, WinForms apps or web forms of web applications. And there's fewer of us left that are able to maintain that kind of code because it's old. You might have old web forms code that runs on .NET 3.0 or something. Uh and who's going to maintain that and move that forward? Um it's really hard to go and tell and ask your manager or whatever to say, "Hey, can I get 6 months to convert this old uh web forms app to Blazor or something .NET 10?" Uh Probably no is the answer. Uh and we get that feedback all the time. So what's really cool is that we've had some really nice breakthroughs recently in our app modernization stories that now allow us to convert web forms including uh you know, user controls, server controls, components into Blazor. So you can take those old apps and modernize them completely onto a modern stack. You can put uh Aspire on them as well all through this app modernization. You can even upscale them to be something that can run in the cloud if you want to and it's all handled by the modernization agent. So, those are some really nice uh time-saving things that are coming for for particular this cohort and a lot of enterprises out there have a lot of these old uh apps. Another thing we're looking at are agent skills. Now, the thing about agent skills is that they really make your agent workflows a lot more powerful. It makes them more useful, the agents themselves when they work on your code base. The problem is how do you find skills? These are just markdown files that live in like some plugin repositories or marketplace repositories scattered around the web. But, how do you know that when you work on WinForms or some .NET scenario or whatever, what skills to use? That is a real big problem that kind of everybody's having. And what we're doing in Visual Studio is that we're automatically going to figure out like, "Hey, what is it that you're doing? What type of project are you working on?" And we have a bunch of skills that the individual teams have created like the Azure team, the WinForms team, and so on. So, if you're working on a WinForms project, we're automatically going to include into the context a bunch of these skills making your agent way more powerful. Actually, so powerful because it's it's written by the WinForms team themselves. They're the absolute experts in the technology you're using. And that's going to be applied automatically. So, all these skills are really fantastic. They're out there. They're open source. We actually take a bunch of contributions from the community as well. Uh and so, they're skills you can trust and we're going to automatically apply them. So, very, very helpful to have this as well. Um build speed. So, one of the things that we do in when we run um anything in agents is that the agent will sometimes have to do a build, right? It happens quite frequently. What's problematic sometimes is that it will we can look at the error list and we see oh there's a couple of errors there but it still tries to run a build and that can take like two minutes to run before it hits that error and it's like oh build failed. Like yeah, I could have told you that. I saw that error before you started building. So we're doing a bunch of optimizations around all of it but one of the first ones coming here is the build speed where it does something as simple as hey let's just look at the error list and other indicators to see whether or not we should kick off a build now or if we need to do a little bit of more work first. So that's really nice that that will come. That's going to speed up our experience. That is just one out of a lot of different performance optimizations here you're going to see around the chat window and all that. This is one of my favorites. So merge conflicts. How many people here love merge conflicts? Okay, there was hand up. Okay. Good for you. >> [laughter] >> So when we talk to a lot of developers they tell us that they actually get a fear and there's a anxiety and a frustration when you have to commit code and you realize oops I'm behind head and I have to do a pull first and you're like almost shaking when you move the mouse up to that pull button, right? Oh oh, can I do a clean pull with my changes or what, right? So there's there's a whole frustration there. And I get it. I get it. We all experience this from time to time. So what we're going to launch here very soon is a way to click a button and have the AI go and look and help us with our merge conflict resolution. This is a huge huge thing I think for me and others that are maybe except for that handful of people that love this situation. But [laughter] it has that ability to figure this out and when we run the test against what would a human do when you're when you're faced with a conflict merge conflict, what would a human do? How would a human solve that conflict? And when we look at how would an agent do it? It's almost the same. Like the agent is very very capable, and if it can't do it, you can always do the thing in that situation. You might have a several merge conflicts, and only one of them is the one that require your input. Maybe none of them, right? So, it's a it really takes the kind of the heartache away, which is very exciting. All right. These are getting meteor and meteor these uh these features here that we're going to roll out. Uh have you ever thought about this as being a problem that why is it that Visual Studio seem to be getting Copilot features later than everybody else? Uh at least without You don't have to put your hands up. I kind of know the answer to this question. Uh you do, right? And we do as well. And it's kind of frustrating sometimes. There's a lot of reasons for it, but one of them is that we have our own implementation of Copilot. Like we talk to the Copilot that Visual Studio talks to the Copilot API them- ourselves, and we have to like make it work with the profiler and the debugger agent and app modernization and all these different aspects of Visual Studio that a lot of other tools don't have. So, that's one aspect. But another one is that, you know, we have our own implementation of the back end. Like we talk to the Copilot service ourselves. So, what's really nice, what's going to roll out starting next week on the uh Visual Studio Insiders, is that we're finally going to make that move onto the Copilot CLI SDK, the GitHub Copilot CLI SDK. And what's really fantastic about this is that Visual Studio, VS Code, the CLI, like all going to be using the exact same base, the same SDK. We're going to have the features at the same time. Uh they're going going implemented differently, right? Because in Visual Studio, we can kick off a When you kick When the agent kicks off a build, it uses Visual Studio to do the build, which makes a lot of sense because MS Build is already warm, Roslyn is already doing its thing, and so that is actually executing faster than if we ran the build on the command line. So, Visual Studio will still do its Visual Studio thing, even though it's on the shared component and SDK. So, this is very, very exciting. Uh I'm very excited to see what you think about this. I've been running it for about a month full-time, and I absolutely love this experience. So, can't wait for you to get your hands on that. We have one more. One more. So, we have a list of different models you can use in Visual Studio. All right, we got the Opus and the Sonnets and the GPTs, and we allow you to add other models. Like, you can add, you know, XAI and a few others. Got Gemini in there and so on. You can bring your own key. So, if you have a subscription to some of these uh providers from a list that we've said that you can use, then uh you can do so. But, you still need to sign in with your Copilot GitHub Copilot credentials in order to do this. And so, I'm very happy to announce that starting very soon, you can start using any model in Visual Studio. Whether it's running local, whether it's on a cloud anywhere. Yeah. >> [laughter] >> Yes, thank you. There were some There were some claps over there. I'll take it. I'll take it. Thank you. Um so, this is a huge um thing especially for enterprises that have like very strict security uh requirements and so on. They maybe they can't run something that's in the cloud, for instance. Well, now you can run it local, whether it's on your machine, it's on prem somewhere, your own server room. However, you you want to do this. Um like there's not going to be restrictions there. But, what The thing that makes Visual Studio Visual Studio, as I was telling you in the beginning, is because we are so focused on the professional developer segment. We know that there are like trust boundaries and things that are important to enterprises. So, of course, we're going to have a kind of a security layer there so you can lock it down for your organization to say, "Hey, only these models are we mandated to use this and that model, for instance." And so, you only use the local model or you only use this cloud provider or whatever it might be, right? So, you have that management layer on top. So, hopefully you'll start checking this out again next week in the Insiders build of Visual Studio 2026. And uh I think we can I think we can take a question or maybe two. So, if you have any questions, there are some mics up here. Come on up. We're almost out of time, but we do have We do have a little bit here in case you're curious about something. No? All right. It was the back room that was having but okay, let's call it here. Thank you so much, everybody. I hope um you're excited about what's coming over the summer. Make sure to get the Insiders next week. Uh you won't regret it. It's a lot of future new things. So, thank you very much. >> [applause]