Tackling tech debt with the GitHub Copilot Cloud Agent

Key Takeaways

Hello, thank you so much. Hi, my name is Britney Ellik. I am a senior software engineer at GitHub and I have what I think is one of the coolest jobs in the world. I get to work at GitHub, which is a fantastic place if you're interested in working on DevTools and I get to test all of the things that we create at GitHub and use them in my workflow dayto-day. So, I've been using GitHub Copilot for well over a year at this point. Um, in particular, I'm going to talk today about using the coding agent with GitHub Copilot and how that has really transformed my workflow and the way that I think about tech debt. So, let's get into it. Uh, so here's what we're going to talk about. Uh, we're going to go over the problems with tech debt management. We're going to talk about your tech debt elimination accelerator. And we're going to talk about building a sustainable tech debt strategy. So, some of the problems with tech debt management. This is a backlog that I've seen at a lot of different companies that I've worked on. I usually refer to this as the tech debt graveyard. So, these are the issues that I have created and lovingly put in the backlog to make my application better, but I rarely have the time to ever actually get to them. Sometimes they pile up, sometimes for over a year. Um, and that's because in the tugof-war in developer time between feature work and tech debt, features almost always win. It's a bummer, but it's the case. And it makes sense because those features are your competitive advantage. That's what sets your application apart. That's why people actually use it day-to-day. So, it's important that developers spend more time working on features. But that means that a lot of those improvements that we would all really love to see happen don't ever get prioritized. These things tend to pile up over time. So it starts with a slowdown in the way that things work. Something that you originally think is going to take only 2 days ends up taking 2 weeks. Velocity on the overall team slows down. Your code becomes more fragile as this problem snowballs over time. that developers become afraid of touching old code. There are outages and customer trust erodess as they can't rely on your application. And then finally, a lot of the time we end up at this cliff where somebody says, "We need to rewrite this whole application from scratch because there's just too much to work around. That means a multi-month or quarter or year project where you're just rebuilding the same application. That is a bummer." But I've seen this time and time again and I think that there is a solution now in this world of AI. How do we get around mount tech debt? That brings me to your tech debt elimination accelerator. This is GitHub copilot. Like I said, specifically I want to talk about the coding agent. So that is the ability to assign GitHub issues to the agent and have it complete it and bring them back to you. It's very, very cool. And like I've said, I've been using it a ton in the last year. And it has completely changed the way that I look at these smaller tasks. So, it's always available. It's never tired. It's eager to tackle a lot of the boring tasks that quite frankly I want to see done, but don't always want to do them myself. It allows your team to be your team, but better. So your team is currently balancing spinning a lot of these plates where it has things like security updates and bug fixes. These small changes to update text or improved test coverage. A lot of these things can actually be handled by the co- coding agent from GitHub copilot while your team and you get to focus on the strategic planning and the larger things that actually make your application better over time so that you don't end up in these situations where you have to completely rewrite your software. That brings me to a demo. So what is this thing that I'm actually talking about? I have let's see here. There it is. I have two great loves in this life. One is building software and the other is crocheting. This last year I learned that I can actually create a type of afghan called a graph gan, which means that you basically put pixels together and turn it into a an actual blanket, which I thought was incredibly cool. And I was thinking, you know what? I know of a a graph that I really like to see. So, I decided to put together this Sorry, my thing zoomed in there. I decided to put together this commit graph gan pattern generator. So now this is my commit graph from GitHub that I have now turned into a pattern. I'm currently making it and I've been posting updates online. It is very very fun to work on. You can see here where I took some parental leave and had uh had my kids. So this was really cool. I vibe coded this app um and brought this thing to life that I probably never would have brought to life before the age of AI. But now that I have some people using it, I realized that I kind of want to make it better. Um, and I don't really have a ton of time dayto-day to work on these sorts of fun things. So, I wanted to show you how I've decided to sort of harden this application over time to using the coding agent so that I can make changes in the future and not have to worry so much about them. So here I have an issue that I've created to create unit tests for the year selector component. I when I created this no tests were created and I want to make sure that there are tests so that you know in the future I can make a change with the coding agent as well and make sure that it's not going to break anything. So all I got to do is assign this issue to co-pilot and boom that's about it. I can add some extra context in that box if I want to but I don't necessarily have to. So you can see co-pilot's taking a look and it's going to start creating a pull request for these changes. Um it starts out as just a little work in progress where it'll go add unit tests and you can actually take a look. I'm going to approve these workflows to run so that it's not running up on my actions without me saying that I uh actually want it to do so. And it's going to start looking at this task and doing the work which is incredibly cool. We'll see if uh there we go. The session just popped up. You can take a look if you really want to watch this thing work and see what it's thinking about and installing over time, which is very cool. You can even go in and steer it while you're working on it. So, if you're like, I don't really like the direction it's going, I can go in and do this. When I'm doing some of these tech tasks, I usually just fire off a bunch of tasks at once and then come back to them later. So, I don't spend a ton of time doing this personally, but it is really cool if you do want to keep an eye on those things. Now, in the interest of time, I am going to pull up a poll request that was already created by Copilot to show you what this looks like. So, this is the poll request that it came up with with the same exact prompt um a couple weeks ago. I think it took like 10 minutes to do. Um we don't all want to sit here and watch it for 10 minutes. So, uh this is what it came up with. So you can go through and review it just like any other pull request you might review at GitHub. You can see it looks like it added um this user event uh testing library. That's cool because there's probably some user events that are worth testing. Um you can go in and see how it's what it decided to test. So it tests that the component renders looks good. Um that it's handling different types of props and different user interactions. Okay. So when a user is clicking on the button, that's why it needed that library. That makes sense. Um, so you can review this just like any other pull request. You can go back and forth and add comments to say, "Hey, can you update this? I don't actually think that this test is necessary." And then just merge it like you would with any other any other pull request on GitHub, which is incredibly cool. Going to take us back now to the presentation. Hate to do that. I'm so sorry. Here we are. All right. Uh, so that brings me back to building a sustainable tech debt strategy. So now that we have this tool, we want to actually do something with this um that will make it so that you can make this part of your workflow. And so in the spirit of the season, I am going to give you all a gift and I'm going to tell you how to wrap up your backlog. This is a little acronym that I put together that is has been useful for me when I'm trying to figure out how to uh how to you know employ this and use it within my application. So we're going to start here with write effective issues as the first one. Now you might see an issue like this uh refactor to use async8 use async8 for API methods. For the average engineer on your team, this might be enough if they have enough context to know that this is, you know, they know they can take this and do something with it. But for AI tools, they need a little bit more help to know and direction to know exactly what it is you want to actually do. So, I recommend trying to write a more effective issue for these things. So, first you want to use a descriptive title. I typically when I write an issue for the GitHub copilot coding agent, I will mention where I want the change to actually take place. So update authentication middleware for example to try and pinpoint where the changes to use the async8 pattern. Next, I'll add plenty of context. My guideline there is I like to think of what would I need to tell somebody who was newer to the team [snorts] to make sure that they had enough information that they could pick up this issue. um and work from here with it. It doesn't have to be, you know, tons and tons of paragraphs long, but it needs to be enough information that it can work from that. And then finally, include examples. So, if there is something like this where you want to use a specific pattern, you can include an example of what that pattern should actually look like. That will result in much better results from the coding agent. Next, I want to talk about refining your instructions. That is the R of wrap. So there are a couple of different ways that you can create instructions for GitHub copilot. I apologize. I know that this is a lot of very small text, but I have links to all of this in the repo for this talk. Uh and it just links to the repository custom instructions for GitHub copilot. These are instructions that you can put in your repo for anything that is relative to your application. So for example, I you write a lot of Go and there are specific ways that I like tests to look in Go. I like to use tabled driven unit tests typically. So that's something that I put in my repository custom instructions so that every time GitHub copilot is doing something with that repo, it refers to them and make sure to use those. There are a couple of other ways that you can write custom instructions. So for example, if you have an organization that has specific needs, saying, you know, I want every single change within this organization to include unit tests, that's a great thing to put in your organization custom instructions. So refining your instructions is another thing that will lead to better results over time. Next, atomic tasks. Basically, breaking large work into chunks. You might be looking at this and thinking, "All right, sounds like this is fine for small tasks, but we have really big problems that we want to solve." Well, you can do that, but it might be a little bit easier if you take these large problems and break them into a much smaller problem. For example, you wouldn't want to rewrite your entire application that has, you know, three million lines of code from Java to Go in one go. You'd probably do that a little bit at a time. So for this example, we have implementing an edit widget button. And that might be too large of a task. And it would probably do fine on a task this large, but you could break it into smaller problems um like add an edit button or uh create the edit API method or add last updated field to the database. Um adding metrics. So, breaking those into smaller chunks helps you not only with the changes that you need to make, but also uh it makes it easier to review the pull requests as well, which is nice. And then finally, pairing with the coding agent. So, knowing what you're good at versus what the coding agent is good at is going to be a really good guideline for which tasks to give to the coding agent and which ones you can tackle. For example, I'm really good at understanding the why behind a lot of problems. And so I can give a task to the coding agent and see if it actually addresses the why. Why do we need to make this change? Uh that is something that the AI tools are are occasionally a little bit less good at doing. Um and so it's, you know, helpful to keep that context to know where I excel and where those other tools excel. I'm also really good at cross-system thinking. So for example, thinking about how one change in this repository is going to impact another repository. um that is something that a lot of the AI tools don't do as much yet. Who knows what the future is going to bring um but it's something that I'm really good at and so that's something that I try to keep in my realm of things that I do. But the coding agent is good at other things. So for example, expan expanding upon existing patterns. So if you do make a small change, a proof of concept change to update a pattern in your application and you want to see, you know, what this looks like across the rest of the repository, that is a great thing to give to a coding agent so that it can make those changes and you don't have to sit there and make those changes in each file. It's really great at tireless execution. Like I said, I like to fire off, you know, 5 to 10 tasks in the morning and then come back to them later and see what happened. Um, it's also really good for exploring possibilities. So if you want to, you know, do a PC between two different ways to solve a problem, you can assign them both to the coding agent and see what it comes up with and see what it actually looks like, which is very, very nice for not spending a bunch of time doing that. And I've noticed that this has really changed the way that I develop software over time. So my development flow looks a little bit more like this, where I h break time up into different chunks to work with the coding agent. So I might spend a half an hour triaging issues to co-pilot or reviewing those PRs or merging those issues. I also still have a lot of development time. So I still reserve a lot of that time for the big more ambiguous problems that I don't quite know how to solve for myself. Um and I found that having this time blocking schedule has been really helpful. This is a really great time to turn those tech debt mountains into a more managed terrain. We have the power now to not have tech debt anymore. And that is incredibly exciting and a great thing to uh to change the way that we build software. And I'm looking forward to hearing how it impacts you as well. So, thank you so much.