The Agent Awakens: Collaborative Development with GitHub Copilot | BRK113

Key Takeaways

All right, good afternoon everyone. Uh, I think there's a few folks still looking for seats. So, if anyone has a free seat next to you, can you raise your hand and make sure that folks Okay, folks coming in, if you want to go to where one of the folks are wonderful, getting a last few folks in. Great to see a full room for this session. We are incredibly excited to be here today uh to share with you a little bit about some of the recent uh things we're doing with agents inside the GitHub platform. My name is Luke Hoben. I'm leading some of the engineering teams working on uh agentic coding inside GitHub and I'm joined by my colleague Tim Rogers who's leading uh product uh for these features. So today we're going to kind of give a bit of a background on where we've been with GitHub Copilot over the last five years uh from chat to uh from completions to chat to agents and then we'll do a really deep dive on some of the new work uh that we're doing uh inside GitHub with GitHub copilot. I think folks probably saw that this morning in the keynote uh Satia announced a really new feature an exciting feature in the GitHub copilot platform uh which is GitHub copilot coding agent. So coding agent is available now. Uh it is our latest feature for agentic coding within the GitHub platform. GitHub Copilot uh coding agent is available in GitHub Copiot Pro Plus and enterprise for anyone to use today. I'm going to do a raise your hands. Has anyone already tried it? A few folks. There we go. Great. Okay. So lots of folks already trying it out. We'd love to see that. Today we're going to do a deep dive on what we've done with coding agent and the technology behind it with GitHub copot coding agent uh copilot is now a member of your team. Uh so you can bring it in and assign it issues you can work on it collaborative work with it collaboratively on uh PRs in your uh repo and in many ways it's bringing agentic coding to where you are to a natural collaborative part of the GitHub fabric. I like to think of this as sort of one of the most natural and integrated ways that we're sort of bringing agents into information work across all of our different platforms uh in at Microsoft today. And so we're really excited to show this to you uh today. So before we dive deep into coding agent, I wanted to give a little bit of a background on kind of the evolution of GitHub copilot over the last five years. So I'm sure everyone here is familiar with uh GitHub copilot completions which were the first feature that we launched as part of GitHub copilot back five years ago. These really started the sort of modern wave of everything that we've done to bring uh AI into the developer experience. And when these started, you know, they were at the scope of just a few lines of code, right? So you'd be typing and you get ghost text that was maybe the fa the completion of that line or the next couple of lines. They were an interaction which sort of checked back with the user every, you know, less than a second, hundreds of milliseconds, very frequent check-ins, very small amount of uh net new work. And these were really focused on helping individual developers to be more productive within their IDE. So they were about one developer working on their machine, you know, kind of being more productive every day. Last year we introduced sort of the next big step which was chat. And so chat gave us the ability to not just take where you I am in my context in my editor and give me the rest of that line but sort of solve kind of problems for me. I could describe something I wanted and it would suggest a set of changes initially a set of changes in one file and then over time we expanded that into a set of changes that might happen across multiple files. This was still obviously focused on individual developers in the ID. The thing that really changed over the last year though uh was sort of the improvements we've seen in models and in sort of aentic capabilities within those models. And so one measure of that is Swebench uh which is a benchmark that sort of tests for real open- source repositories. It takes some of the issues that were open in those repositories. It takes the real PR that some developer merged to fix that and it goes and says hey can the AI recreate a PR which matches the tests for that PR uh perfectly. And so a year ago when we launched chat uh you'll see that you know SweetBench verified this this particular benchmark the state-of-the-art was 25%. So of all those issues in that benchmark only 25% of them could um the state-of-the-art uh AI models and agents solve. But now where we're at today, we're over 70%. And we're continuing to see this grow every week uh every few weeks. We're seeing kind of this increase both because of improvements in models and because of improvements uh in the agentic technology that we're building. And so this fundamentally changes the nature of the products that we can build. Right? Instead of, you know, us being able to get a correct answer 25% of the time, we can get a correct answer 75% of the time. Now we can give you a lot more capability in the agentic tools that we provide. And so this brought us to VS Code agent mode. And so with agent mode inside VS Code and then also now in Visual Studio and our other idees that we support, we're really expanding the capabilities of what our agentic tooling can do to take on complete tasks. It's no longer just, you know, give me some some code. It's go solve a problem on my behalf. And now it's going to be the agent taking maybe minutes to go solve that on my behalf to do a big piece of work uh while I'm sitting there watching it. still very focused on the inner loop and still focused on VS Code. And so I'm sure everyone here is familiar with agent mode, but I'll just quickly go through it here. So, you know, you can set the selector to agent uh inside VS Code chat. You can pick the model you want to work with. You can give it any task you'd like to solve. And VS Code will go off and work on this. And of course, it will work on it both by reading files and proposing some changes, but then most importantly, it'll also go and actually make those changes. So it'll go and edit the files in line. It'll go and run some tools like my npm run lint, my npm run test. It'll see the results of those tools. If they fail, it'll recognize that and figure out what to do to change its path and its trajectory on the work it's doing. And if they succeed, it'll move on and say, "Okay, I've completed the task you gave me." So this example just took you know 30 40 seconds but you can imagine this in many cases can take you know you know many minutes or even in sometimes I'm sitting there working with iterating for tens of minutes on a problem with it and this of course is what leads us to GitHub copot coding agent. So with coding agent we're bringing that same kind of experience of agentic coding where we're bringing it kind of into the outer loop. We're allowing it to work for longer periods of time to take on even larger chunks of work. Tasks that may be an entire GitHub issue uh and tasks that may take up to tens of minutes for the agent to solve on my behalf. By pushing that into the outer loop, we're allowing it to be asynchronous and autonomous to work on my behalf while I'm doing other things and to help me solve problems that I can then come back to and review its work and iterate with it. And we're also bringing it now into GitHub. So instead of it just being something that lives as part of my individual developer productivity on my machine, we're bringing into something that helps my team's productivity on GitHub and that I can collaborate with. But enough talking. Let's bring up Tim to walk us through a demo of this in action. Thank you, Luke. Let's switch over. Great. Well, you should be able to see on the screen the website of our airline, Copilot Airways. You might have seen this before at GitHub Universe, our conference last year. And it's also what you would have seen in some of the videos that Luke just showed. This is a moderately complex application. It's built in Nex.js and uses Tailwind CSS as well. It's got about 40,000 lines of code, so it's not like incredibly simple, but it's also not incredibly complex. So, it's a nice kind of test case for these kind of agents. On this website, I can search for flights, I can make a booking, and I can even manage bookings. Now, obviously, this website, this app is going to be the next big thing. And like any project in my issue tracker on GitHub, I've got a bunch of work to do of all all kinds of different things. I've got new features I want to add. I've got bugs to fix. I've got refactors I want to do. The same stuff you've got in your issue tracker as well. Obviously, I could work through these things, but there's a there's a lot here. So, what if Copilot could jump in and help us? So, what I'm going to do is I'm going to pick a bunch of these issues from this list. going to pick three as it happens. Going to click the assign button and then I'm going to pick copilot or actually I picked some that already. So just so we can see it properly, I'll pick these three which are not assigned to co-pilot and then we can assign those. And there we go. So we're not even just limited to giving one issue to copilot to work on in the background. We can give it one or two or three or five or whatever number we want to do. Right away copilot is going to give a quick reaction to those issues. So, we've got the um interesting maybe it's because it's closed. Well, in general, we assign the issue to copilot and copilot is going to react and open a draft PR and then we can start working from there. So, let's jump to this issue that I created a bit earlier on and assigned to C-pilot. So, this issue is a is a feature request. It's something we want to add to the app. So, this is an airline. We've got a travel guide that suggests destinations that the traveler can go to and we want to add user reviews to those destinations which would be a really nice new feature that you'd see on a lot of travel websites. Now the product manager for this work has actually written the description of what they want to do in notion. That makes things a little bit hard for Copilot because it can't just you know can't just um read data from GitHub. It's got to go somewhere else to get that. So let's see how it handles that. So this issue was assigned to copilot earlier on and copilot opened up a pull request. So when we get started copilot opens a draft pull request which it uses the kind as the kind of canvas the scratch pad for its work and as copilot works it gradually updates the pull requests body and title to kind of update us on its progress. So when the pull request was first open we have this like thanks for assigning the issue to me. Then as it works, it adds a plan like this. And then it gradually starts to kind of tick off that plan and check items as it completes them. And then when it's done, we get a nice title that describes what the pull request is and the kind of pull request body that you would love to see from the developers on your team that really like describes what's been implemented, how it's been done, and even seen some cases where it explains how to test it. So you get a really good PR title and PR body at the end. And as C-pilot works, it progressively pushes commits. And you can see here it's actually broken up this work into a bunch of commits which is again what you would want the ideal in your developer on your team to do probably. And when it's done it requests a review from you as the person that assigned the work. So you can you can jump in and you can give feedback. While co-pilot's working or at the end we can click this nice new view session button to understand what's going on under the hood. So in here we get kind of copilot's logs. we can see how it thinks and the different tools that the agent uses to explore the repository, understand the problem, that kind of stuff. And if you've used agent mode in your IDE, this will be very familiar. This idea of like a a train of thought, like the consciousness of the model. So let's have a look at some of the stuff that it does. So in here we can see co-pilot like running bash commands to look through the repository and understand what's there. It looks at the code as it is right now. Um, and it also tries to understand the problem that it's solving. So we saw when we looked at the issue there was a link to notion where a lot of the context was. And actually here copilot has been able to use the notion MCP server to go and grab that information. So it can gather context and understand the problem. And then after it's kind of looked at the code and understood the problem, we then get this thought step which is where Copilot kind of gathers its thoughts and and fleshes out a plan of what it needs to do next. So this is kind of it saying okay here's what I've learned and this is what I'm going to do next. Then moving forward we start to see copilot actually making changes. So we've got these create blocks here where copilot creates files and these edit blocks where copilot changes the existing files. So you can see as we scroll through these logs we get a really good idea of how copilot's approaching the problem where it's looking to understand the current state and then it makes changes to the state of the code. A really important step that we'll see a bit further down is where copilot actually kind of you know begins to validate its work which is going to be really crucial because we want to get a PR that's green at the end. So you can see here copilot running bash and particularly using mpm run test. So this agent effectively has its own computer where it can run your tests run your llinter and if it sees that things are good then it can push and you can review. But if during this process it finds problems, so there are tests that are failing or you've got lint limp rules that aren't passing, it can see those errors and fix them before it pushes. So rather than you getting a pull request that's red and having to say, "Hey co-pilot, can you fix this for me?" It's immediately getting ahead of you and figuring out what to do next, and getting a PR that's ready to go. This is actually a really nice example of the kind of asynchronous nature of this agent. So you can see here at the top that this session took 18 minutes for it to create this new feature. These sessions can obviously range a bunch in how long they take. At the bottom end, you see sessions that take like two or three minutes. If it's, you know, a simple couple of lines change and we currently have a time limit cap of 59 minutes. Reason we do that is because we've just seen that when the agent goes beyond a certain amount of time, it's very likely to be lost and confused. So we kind of limit that to, you know, not keep running if it's going to spend a bunch of actions minutes and use a bunch of LM requests, but not actually produce a useful result at the end. So we've seen here this these logs. Let's go back to the pull request now. So copilot requested review for me and I can jump into the files change tab just like I would do with a human developer to see what it's done. And scrolling through here I can see that it's written code. It's updated tests. So it's done a it's done a really thorough job here. This isn't a super simple PR. You know it's got 500 lines of changes. This isn't you know a one minute piece of work or a five minute piece of work. It's a meaningful thing to build. And of course we can choose what to do. Now I as a developer can choose to check out this branch locally and work on it myself if I want to. So I can say like copilot you're done now like I'm going to take this from here or I can actually use pull request reviews just like again I would do with a human developer to ask copilot to make changes. So if we just scroll down here a bit like maybe I can say here you know we've got quite a lot of like JSX here. Maybe I can say like can you refactor this part into a separate component. I just leave that comment for copilot and then just like when I assign the issue to copilot it's going to see that jump in and start working again. One more thing I want to show you before I kind of head out of the demo and back into some slides. One thing you might notice at the bottom here is that we've got this message that says two workflows awaiting approval. As we're building these agents at GitHub, we're thinking really carefully about how do we enable you to get these this new productivity and this new functionality, but also at the same time, how do you like maintain your security posture and the way you're working and the guardrails you have within your teams? And one ways, one of the ways that we've done that is by making sure that GitHub actions workflows don't run before the code has been reviewed. That's really important because GitHub actions workflows can have access to sensitive code or access to secrets and things like that. So you want to review that code and make sure it's safe before it it goes into that environment. If you've you might have seen this button before on an open source project. So if you've got an open source project and an outside contributor makes a PR to your to your project, you will get this same button. And effectively we're treating the agent as a kind of semi untrusted outside collaborator whose work you have to review before it gets run or gets anywhere gets anywhere dangerous. So that's the demo part. Let me switch back over to the slides now and we can talk through some more stuff. So let's recap what we've seen here is that I can hand copilot a task to work on in the background. Then copilot opens up a draft pull request where I can see its progress and understand what it's doing. I can see that high level through the PR title and PR body and the commits. And I can also really zoom into that looking at the logs to see in detail exactly what Copilot is doing. And then finally, Copilot requests review from me and I can check out that branch and work on it independently or I can leave a review for Copilot and let C-pilot pick up that work. In terms of how I give Copilot tasks, there are actually a bunch of different ways that I can do that. What I've shown you here in the demo so far is assigning an issue to C-pilot on github.com. Well, there are actually other places where you can assign issues to Copilot as well. Just as a few examples, on the GitHub mobile app, you can assign an issue and you can also do it through the GitHub CLI. Here's a quick video showing the kind of issue assignment process through the GitHub mobile app. So just like I can do on github.com, I can find an issue. I can open up the assignees menu and I can pick copilot. That's then going to follow exactly the same process that we've seen on github.com. So copilot's going to open a draft pull request. I can go into that pull request and I can watch from there, jump into the logs and get pinged for review when it's done. This might seem like a kind of fun cute thing, but I I genuinely think this is really really valuable. I've actually had situations in the last few weeks where I've, you know, spotted a bug or something I want to implement while I'm like on the bus or making a coffee. I can quickly write an issue from my phone and assign it to co-pilot and then when I come back from my lunch break, I've got a PR that's ready for review. Like that's a real thing that I'm doing and other people in the team are doing. So it's it's cool to be able to do that. So that's the issues side of things, but you don't actually have to create a GitHub issue to be able to give work to this agent. We also have the ability to kind of assign it tasks ad hoc through copilot chat which is really cool and also fits into developer workflows in an interesting way. So let's jump back to my laptop and we can see the s code here. So while I'm writing code I'm I'm working on a task. You know I'm trying to build a feature. I'm trying to fix a bug. But at least for me as a developer I'm often scrolling through code and I'll think like oh I can see another bug here or we should refactor this or this comment doesn't look right or lots of things like that. When I see those things in my code, I kind of have three options. Option one is that I start working on that now and I get distracted from the task that I'm working on. Option number two is that I create an issue and put it in my backlog to be picked up later. And realistically, that will probably never get picked up and that thing will never get fixed. Or option number three is that I just forget about it. And realistically, option number three is the most likely thing to happen. But with Copilot coding agent, I've got another option, which is that I can stay focused on the thing that I'm doing and I can ask C-pilot to fix this thing that I've spotted in the background. So, if we scroll down here, I've got this. And this is just the code for Copilot Airways. And we've got this like part of the UI where it says, "Oh, I'm searching for the best flights." And again, we've got quite a heavy amount of JSX here. And it might be nice to refactor this into its own component. So, I'm going to highlight that code. Just going to make co-pilot chat a bit wider. And I'm going to ask Copilot create a PR to refactor this into its own component. And just like I can do by creating an issue and assigning it to C-pilot, I can just ad hoc ask C-Pilot to make a change here, it's going to open a pull request and follow that same process that we've already seen. This is another really nice entry point for interacting with this agent. And you can see here it's literally given me the URL of the pull request and I'm going to get an email and notification when it's done and I can jump back in. And that doesn't have to distract me in a meaningful way from the work that I'm doing. Like I can send that message quickly and move on and do something else. So that's how we can give work to co-pilot. So how does this all work under the hood? If you asked a developer to work in your project but didn't give them a computer and didn't give them their dev environment, that probably wouldn't end very well. You know, they would write code that doesn't work. The tests don't pass, the linting steps all fail. And the same thing applies to an AI agent. If your AI agent doesn't have a development environment, it's not going to do a great job of solving problems. We use GitHub actions as that development environment, which was a really natural choice for us at GitHub, given that's such a battle tested, high-scale form of compute that developers are already using every day. This compute environment allows the agent to verify and validate its work as it does it without the long cycles of CI/CD. What I will add is that I still think CI/CD is really important. You want to have that like canonical step that checks the code and make sure that makes sure that everything passes. And the agent isn't going to be able to run probably your entire test suite the same way as a human developer wouldn't run the entire test suite. But we can have this nice balance where copilot runs the test in the llinter for the code that matters or the code that it's changing and then we defer to GitHub actions to review the rest. Why have we chosen GitHub actions for the compute? Well, it gives us this kind of safe, secure, and ephemeral environment that just can be spun up and torn down quickly for the agent, which is really, really nice. And the other nice thing about leaning on GitHub actions is that you can customize the agents development environment and do it in a way and using a language that you're already familiar with. So given the agent has bash, it can run it can run aptgate install, it can run npm install, it can run whatever you want. But if it has to do that every time it starts up working on your project, that takes a bunch of time and it might make mistakes. So I can write a GitHub actions workflow for my project that will set up the agent's state and get everything ready and pre-installed. So when the agent runs npm run test, everything is already there. The dependencies are ready to go and it can get straight into the work that it's trying to do. So we've talked about how a how a developer needs a development environment. The other thing that developers need to be successful is context. If you just told a developer like do this thing and didn't show them any of the code or any of the past issues or any other pull requests that have been worked on, that probably wouldn't end very well. And again, the same applies to our AI agents. The more we can give them the data and the context on the project and on the needs and on the requirements, the better job they're going to be able to do. So in the case of GitHub, you want to give them access to code, the issues, the pull requests, that kind of stuff. So out the box, our agent has access to GitHub code search which it uses to explore the repository and find the code that needs to be changed. So it can kind of rather than like you know cding around the entire project and trying to find what to f what to change, it can run a quick search and identify the right places right away. And we also have the GitHub MCP server enabled for the agent by default. And that also means that the agent can explore issues and pull requests and things like that. I've seen a bunch of real use cases of that in the past few weeks. So it's quite common in a GitHub issue to like have this complex web of other issues that you link to. You know, you say this issue is related to this one and then that issue is related to this one. Well, because of the MCP server, Copilot can actually follow all of those links and find all that context and understand the whole scope of the problem. Another really nice example that I've seen is Copilot finding other pull requests that are similar for inspiration. Again, the sort of thing you'd hope that a human developer would do. If you're trying to make a change, it's a great idea to find a similar change in the past and copilot can do that as well. But of course, not all the context that you need to be successful is necessarily going to live in GitHub. There are a bunch of other tools that teams are going to use and it's really valuable to have those connected into the agent as well. So it can have access to the same data that a developer can have. And we're doing that using model context protocol or MCP which you've already heard about, I'm sure, a bunch of times today and you're going to hear about even more in the rest of the conference, I'm sure. MCP servers allow you to give the access the agent access to extra context and extra tools. At the moment, this is limited to local servers, but we'll be looking at support for remote servers in the future. Let me just give a few examples of how this actually works in practice. So, in my demo, we saw using the notion MCP server to go to like a product requirements document that is stored in notion. Another really nice example that we've seen is the Terraform MCP server, which can be used to supplement the agent's knowledge of Terraform. So the models that we're using for these agents were trained in the past. They don't have information right up to the current second. But the projects we work in, you know, we might be working in a language like Ruby or a runtime like Node.js or a project like Terraform. And those projects are changing constantly. MCP servers can provide that kind of mainline to the current documentation, the current state. So the agent can have the latest information, know exactly how that thing works right now, so it can make good decisions and implement what you want to implement. A third nice example is the Playright MCP server, which can be used to give the agent the ability to browse the internet. That could be useful for following URLs that might be included in an issue description or even testing an application once it's been built, making sure that it does the thing that it's meant to do. We care a lot about helping you to get these AI agents into your team to help you to be more productive, but we also want to do that safely, as I said earlier. So, as we've been building Copilot Coding Agent, we've really designed it from the ground up to try to keep your data safe and ensure that your normal development processes are being followed safely and securely. There's a few examples of that on this slide. First off, Copilot only has read access to GitHub. So, it can't, you know, make changes that you're not expecting with one exception, which is it has the ability to push to a specific branch that's been created for it. That means that we guarantee at a platform level that copilot can't push changes to main or you know create releases or any of those kind of things. It's very limited and it's very scoped. We think readon is generally going to be safe but when there's writing we want to be really really controlled about that and make sure that it's only doing things that we approve. A second thing that we do is make sure the agent only has limited network access. That's important from a data exfiltration perspective. The agent could make a mistake and leak your code to the internet for example or a malicious user could give it a prompt that caused it to do something like that. We have limited internet access for the agent so that it's its internet access is limited to certain whitelisted locations. And of course you have the ability to to customize that. So if there are particular destinations that you want the agent to be able to use, you have the freedom to do that. But we start with a sensible sensible firewall configuration that helps to keep you safe. Thirdly, as I showed you, we make sure that actions workflows don't run in response to the agents pushes without your approval. And finally, we make sure that the person who gave co-pilot a job to do can't then approve that code. That's really important because most teams have requirements that say that an independent person has to review every pull request. If I could come in and tell Copilot to do something and then review that, that would clearly undermine that requirement. So, we've made it so that an independent person has to do that review. And again, we enforce that at the platform level, so you can't bypass that. So that's a quick rundown of kind of seeing the agent and how it works. Let's talk a bit about how we've been using this at GitHub and what we've learned in the process. We've had GitHub copilot co coding agent in use within GitHub for about two and a half months now. It's been used by about 400 people within the company in about 300 repos. We've actually merged almost a thousand pull requests into the main branch that have been created by Copilot. And the reason I'm telling you this is like as we're building these products, we really are testing them internally because we want to make sure that when we release something, it really works and it's actually genuinely valuable. If developers at GitHub didn't like this product, then probably you and your developers wouldn't like it either. And we want to make sure that doesn't happen. So that dog fooding processor is really, really important to us. We've had an active Slack channel where we've been kind of working on this as a company with hundreds of messages a week. And we've been really trying to keep up the momentum internally with change logs and videos and tips to get people excited and get people using this for real work. Of course, the first thing you want to do is start this testing close to home. And that's why we've actually been using Copilot coding agent to build copilot coding agent or padawan as we used to call it. It turns out that actually copilot is the number five contributor to our to our own project. So this is, you know, re real evidence that this is something we're actually using to build this product. If if it's good enough for us, we hope it's good enough for you. Let me just share a few examples. One that I really liked was adding a new feature where we wanted commits that Copilot makes to your project to be co-authored by the person that told it to do the work because that creates this kind of link where you can see where where did this idea come from? Who is the human responsible for this work? We wrote a quick issue to describe that feature, assign it to C-pilot, and it was able to surgically find the right files to edit and add the right test coverage, and we ship that to production the same day, making the experience a lot better. We've also been using this a lot to pay down technical debt, which when you're working on a kind of fast-paced project to ship for build, you take on quite a lot of technical debt, unsurprisingly. So, we've been using C-pilot for things like removing feature flags, tidying up old code, and refactoring the stuff that we've already got. Copilot is therefore kind of taking care of work that otherwise might be forgotten or dep prioritized. We can stay focused on kind of shipping new features and fixing bugs. And we can let Copilot take care of some of that other stuff in the background. So move fast and ship stuff, but also maintain hygiene and keep the technical debt manageable. But it isn't just our team. This has actually been used a lot across all of GitHub. A few examples that I like. So this is one I like from our billing platform team. They had a bug in their application where if the database was down or timing out or erroring out, it would completely fail. The application would just error if even if there was cache data available. Copilot was able to put together a relatively complex 400 line PR to fix that and make it resilient to database downtime. And they got approved that right away. There were no comments, no reviews. The first version was great. They shipped it done. Another example that I really like is from our copilot API team who have been using this to manage configuration. We have this copilot API project within GitHub which is kind of the API that powers all of the copilot experiences that you use that has a lot of customers now and they're constantly wanting to make changes to their configuration changing their rate limits changing the models they have access to changing context windows and that was taking meaningful amounts of time every day to update those configs. Now, Copilot is doing most of that work, which frees up engineers to actually write code rather than update config files. I'm going to hand back to Luke now, who's going to talk through some tips and best practices that we found as working on this and building with it. [Applause] I always love all those examples of the internal uh things we've done with it. And that's just a small sampling. As Tim mentioned, there's hundreds more of those that we've seen. And every day we're seeing these exciting examples of how folks are using this to actually improve their productivity and their team's productivity. So let me talk a little bit here about some of the tips for how we can sort of effect most effectively use copilot inside our projects. So, one of the things that I always think about, you know, folks always ask, well, what what kind of problems is coding agent good at, right? And it's a really hard question, right? Because it's sort of like what kind of problems is a new hire on my team going to be good at, right? And there's not a simple answer to that. Everyone builds up an intuition over time about their code base and the person's skills and how they're going to fit. And I think one of the things that that we like to think about here is imagine that you're onboarding uh someone to your team. what are the things you need to do to help make them productive uh within uh your project. And so there's a few things that sort of really apply uh with coding agent. The first thing is sort of giving really clear and well scoped issues to to coding agent. So the more details and the more context you provide in that issue, the more uh sure coding agent is going to be about the work it's doing. Oftentimes when we give work to other engineers on our team, we might be assuming a whole bunch of context that's out of band of that issue, right? that we've talked about this thing in the past and they happen to know that when I say these certain words I actually mean something a lot more detailed. That isn't obviously going to be true with coding agent. It doesn't necessarily know those things unless you tell it. And so providing it the the context, providing it links to related issues, providing it links to um docs like the PRDS and notion, these are all going to be even more important here than they might be for another developer on your team. Similarly, kind of providing uh context with co uh custom instructions. So, if you've used VS Code agent mode, you may be familiar with Copilot instructions.mmd, which is a file where you can provide sort of instructions to copilot that it should keep in in mind every time it's operating within your repository. And these are just some markdown text that's going to be injected into every prompt that is run through uh through through agent mode. We support that as well in uh coding agent. And so, this means that every time coding agent takes on a task, it will read in that file and include it in its context. So anything you want uh co-pilot coding agent to know you can just put in that markdown file. It'll know it every time it does its work. And then the third uh is the dev environment. And Tim kind of talked about this. We're using actions as that development environment. And so because we're using actions as that development environment, it means that all of the stuff you do to configure your CI/CD environment to run your builds and your tests and all these things, you can bring all that information over and use it to set up C-pilot's uh working environment. And so that means all that stuff you've done, pretty much every one of you who's using GitHub has written a bunch of uh you know YAML to set up your environment for your CI. Well, now you already have everything you need to get copilot set up for its dev environment. And the very last step, uh Tim talked about MCP as well. Uh this is such an important tool and we've seen this you know the reason you heard it so much in the keynotes today you're going to keep hearing it um going forward is this has really enabled a huge ecosystem to very quickly appear around tons and tons and tons of tools that are available uh for these agents. And of course the really important thing with an agent like uh like Copilot coding agent is it's got a computer it can use and it has a built-in sort of file editor and bash command but the more tools you can give it the richer it's going to be. the more capable it's going to be, the more context it's going to be able to have. And so giving it access to all the tools it needs to be successful is one of the one of the things you can do to really enable it to be even more uh powerful for you. So here's a quick video of some of this in action. So we'll start with kind of an issue uh that was opened here. And notice in this case the issue is really fleshed out with a lot of details, right? We're giving it kind of what are all the steps we wanted to take? What does the implementation look like? What is what does success look like? The more detail we give it, the more uh success it can have. We also here add a fairly detailed co-pilot instructions to that MD, right? We talk about the style guidelines we want it to fulfill. We talk we give it an upfront understanding of the codebase structure. We give it all the information that a new developer might need to be productive in this environment. And then we give it some copilot setup steps. So a little bit of YAML to describe what version of node we want and to run npmci before it gets started. So that environment is set up and ready to go for it to be a productive developer right away. And here you can see, you know, you can even go and look at the raw actions logs of what happened behind the scenes when Copilot was running. And you can see what it did. And then finally in our repository level co-pilot uh coding agent settings, you see we can configure our MCP servers just like we would within VS Code. Uh configure with an MCP JSON file. We can bring that file over and configure it for our repository. So an enormous number of tools that we have available to give copilot much richer capabilities within the platform. All right. So with that I'll just recap on a few of the sort of core things we saw here. So the first thing really is we're taking kind of agentic coding from being a pair programmer sitting kind of beside you on your developer machine helping you to be productive as an individual to making this really a peer programmer member of your team someone you can assign work to and collaborate with as part of the work that you do. We're bringing the metaphor of assigning issues and giving it sort of a first class meaning within the platform. Letting Copilot become that member of your team that that collaborates on your terms with in inside issues, inside pull requests. You can iterate with it, give comments. Um very natural interaction model. Copilot coding agent sits on top of all the sort of foundations we have inside GitHub. It sits on top of issues and pull requests and actions and copilot. All these pieces that we have that you're familiar with and use every day. now you can use along with the agent. And most importantly, we're just getting started. One of the things I often sort of tell folks on the team is the amazing thing about this is that we're clearly just 1% of where we can be in terms of the impact that this can have over time. And it's going to be amazing to see what we can build on top of this as we go. So there you go. You can assign issues to copot your newest team member. Thank you. All right. So, we have some time for Q&A if anyone has them. I think there's a mic uh around. So, if anyone has questions, feel free to raise your hand and we'll try to get a mic over to you. Actually don't know where the mic is. So, folks yell out, I'll uh I'll replay back the question before we move on. Uh there's one over here. Uh the question was will this be available for GitHub enterprise on primint? At the moment the answer to that is no. We don't have any plans to bring these kind of like I guess github.com integrated experiences for GitHub enterprise server. But you know never say never I think is the answer but at the moment we don't have any plans to do that. All right. We have a mic set up in the middle if anyone wants to uh use that. There we go. Can agent cross repos? Uh so the question was uh can an agent cross repo? So today we do limit it to a single repository. Uh so you know we saw things like the ability for it to assign an issue and it open a pull request that will always today be in the same repository and also by default when we give it access to the GitHub MCP server we give it an access token that only has access to read only within the same repository. This is because today kind of a lot of GitHub's access controls are obviously defined at the repo boundary, right? That's a natural sort of container unit for access control. We we know that for a lot of organizations, in fact, this is even more true internally inside GitHub, we really have highly dependent sort of cross repository working things where issues in one repository are frequently solved within another one. And so we know this is something we want to do to open it up to be able to work across repositories and for you to be able to delegate access to if I'm working on an issue in this repository, you should have access to these other repositories for opening pull requests. Um but for right now it is limited to one uh one repository with the ability to uh Tim showed the ability to sort of kick off a task where you don't have to assign the issue. You can just sort of uh you know say at GitHub open a PR that would allow you then to go sort of open a PR in another repository and just bring in context the issue within chat. Um but that's something that we're going to be working on over time here. Hi. Um so I have two questions actually. One is uh does this mean there's a different plan uh than the VS code copilot which has its own premium request kod and things like that. And the second one is can I just rather than using this default uh copilot agent just build my own through all the amazing VS code stuff that you have provided and deploy that one instead of using this one. I'll take uh I'll take that and then Tim can add if he has anything else. Um so on the first one about uh about sort of I think it's about the billing and the premium requests. Um so this is plugged into the exact same model as uh GitHub copilot agent mode and so it'll use the same sort of premium requests uh model as that. So today I think every every tool call that it's doing effectively is going to be one uh request against the model and so uh you know you'll see that as part of your GitHub pro plus or enterprise this will use up those same premium requests as part of your allowance and so you can use them either in agent mode or here in uh in copot coding agent. So to that, so we right now have developer individuals have their own beamer requests. Um will this have its own or is it like a pool of requests that it will just drop from? This will use against the the developer who assigned the issue. Um and so that person who is the co-author on that will sort of will use their uh their thing. So you can kind of use this in the examples Tim had where he was kind of working in VS Code and then assigning work off. You can think about both of those as sort of you know kind of drawing down against the same model. So very integrated. We expect to continue to evolve that model, but these are really all part of a continuum, all something that you get access to natively as part of uh the co-pilot offering. One thing to add to that as well is that we kind of when you use this, there are like two different ways that you pay. You pay for the copilot usage and you also pay for the GitHub actions usage. Um and the really nice thing about the GitHub actions usage being separate is that you can choose to use larger runners if you want to. So if your project requires more resources to like build and run tests and all those kind of things, you can choose to upgrade to a to a to a machine with more RAM or more CPU or more advanced networking so that you can have the requirements that you need. And then the second question was about sort of can you kind of build this yourself, right? Um so there's sort of two answers to that. Um one is obviously kind of what we showed today is a very integrated experience into GitHub and we don't today have the ability for folks to build all of that themselves. Um, so you can build obviously your own sort of coding agents today. Um, and lots of folks are building really uh interesting and valuable coding agents that live in all sorts of places. Today the challenge is oftentimes you you build that coding agent and then you have to get the code into GitHub, right? Because that's where you know that's where the sort of code becomes meaningful as part of your project is as part of a PR as part of your main branch. And so we're trying to build a really integrated experience for this within GitHub today. Uh I'd say one of the things we're we're looking at in the future is sort of taking a lot of those building blocks we've built to enable uh coding agent and bringing them into the platform so that you can build your own agents using those same building blocks. So reusing some of the actions infrastructure we've built for this reusing some of that agentic identity we've built for this and so over time I think you'll see us bring more of that in the platform and enable you to build sort of richer integrations of your own into that. Um but today a number of those pieces that we showed are specific to coding agent. I just have one last comment to that. Uh the reason why I asked you that is because um my team has already built this uh and it works. We built via programmers that works exactly like this in VS Code because of all the abilities and just the stuff that you guys have amazingly pushed out which is amazing. Now when I look at it I just look at it like okay the same thing is being done on GitHub. Y right um but we have worked really hard to optimize it such that we're not even using the kod that that's been given to us. cutting it down, bringing it down the cost, stuff like that, right? So, I would want to use my own agent because it will bring my cost down. That's the only reason I asked you that. Yeah. No, I think I think we're really excited going forward to bring as much of this as possible into the platform. Let as many other sort of uh folks building, you know, GitHub has traditionally had a really open marketplace for applications, for actions, for all these things. We want to do the same thing for agents is sort of the next phase of this work. So, definitely interested. Thank you. Appreciate it. Hello. Okay, I work in a very large monolithic repository more toward the million lines of code. Uh, but the reality of situation is any given dev is only really working in this like 40,000 world. Uh, do you see or do you have some intuition that the way that I should be scoping that is with the instructions marked file or should I be like building MCPs that are like reflecting on my own codebase which I