Here's How I Use GitHub Copilot To Build Features

All right, folks. We're going to look at building a feature out with some AI tools today. And I am not role playing as a pirate. My eyes a little messed up. So maybe my editor will make me look like a pirate briefly. And then we'll cut over to all the fun stuff. So we're going to be looking at a Tumblr API today. So on my screen right now, I have the Tumblr API pulled up. And this is all stemming from the fact that I had a user request come in for Brand Ghost. And someone said, "Hey, Nick, I would love to be able to post content across my different Tumblr blogs, but it looks like your platform only supports one." And I'm not totally familiar with Tumblr. I've used Tumblr before. I am not actively on there. Like I think platforms like Twitter or LinkedIn or I think lots of us use Instagram, Tik Tok, blah blah blah. Tumblr seems like it's a little bit more removed. So I spend time on other platforms less on Tumblr. And I didn't realize that I guess you can have multiple blogs on Tumblr. That's my fault. So I said, I'm gonna go to the Tumblr docs. And very conveniently, the Tumblr documentation, if I just do a little scroll here, you can see the scroll bar on the right side of my screen. Look how tiny that is. There's all of the docs for the entire API on one page. That's lovely. And the reason that's lovely is because we're going to help or get help from AI today to help us try to build out this feature. Now, what I've noticed when trying to put some AI videos together is that if I structure them all and I have this dependency on the LLM doing the exact right thing, I'm setting myself up for failure because it's not totally deterministic. So, in this video, we're going to get AI to put together as much as possible a GitHub issue for us that we can go assign to an agent to go carry out the work. Hopefully, if that comes together nicely, what I will do is make a follow-up video where we're going to review that code. We're gonna step through it, give the feedback. It's just that that video, I think, will stand on its own and we'll have some heavier editing there because the back and forth process is going to be a pain in the butt. So hopefully we can get it nailed down right using this approach where we're going to go over to GitHub spaces. Before I do that though, the first thing that I did and it's more natural for me to do this is I said, "Okay, I have this whole Tumblr API. I just like going over to chat GPT." So, I'm going to jump over just going to show you this conversation I had with Chad GBT. And this is I'm not making this up. This is literally how I started doing this. And I said I should record a video to show people. This is my approach for building out some of these things. So, I said based on the Tumblr API docs and then gave it the link, how does one programmatically determine if someone has a main blog page and side blogs under the same account? Now, is this the right terminology? I'm not totally sure. I don't know what you call uh the alternative blogs. I don't know if that's even a concept. If every blog that you can have on Tumblr is sort of like a first class, first level type of blog. I just don't know enough about the platform. I figured here's the entire set of documentation for the API and hopefully it can find something there. The reason I gave it the API to start with instead of just asking this is that I didn't want to get some answers about the platform itself that are not going to be available through querying the API because for the platform I'm building if it's not available on the API I am not sort of in a position where it makes sense to offer that as a service if it's going to be violating terms of service and how we use a platform. So if it's not on the public API I'm not touching it. So that's why this is a requirement [laughter] needs to be available there. They go on to say or they as in chatbt says Tumblr's API does not provide a single is this the main blog flag. I read this initially and I was like oh crap well that's going to make this really interesting and then it said that there is an API to get the blogs which is user info endpoint. I'm already using this by the way. Um, we have this in Brand Ghost right now, but there's an interesting part, right? So, it says here's the API and I'm like, okay, I know we call that, but it literally does give us a list of blogs and it said it doesn't have a flag. Uh, but like it it kind of does, right? Like it says is primary true and then all the other ones are false. Okay, I did a quick check in the code at this point because I was like, hold on, like, do I do I already have this functionality enabled? Turns out I have this API call. Turns out I am literally looking through the code specifically uh to go pull out the blog where primary is true already, but I need to be able to support having multiple blogs being referenced from someone's uh API call here. What that means, just for a little bit of context, is that when someone says, "I would like to connect my Tumblr," instead of it doing a onetoone mapping of your Tumblr login to a Tumblr blog that you'd have access to in Brando, the way that this would work is you would authenticate once and it's like a one to n mapping. N is probably one most of the time, but if you have uh different blogs that you have connected to your Tumblr account, this is one to N where N is more than one. And that's exactly what this user who made this request, that's their exact situation. They have more than one blog. So they want the ability to not only post to say this one, but they also want to post to this one. We have this concept in Brando where you can connect an account and it sort of fans out to um connecting to or we register them as multiple accounts on Brand Ghost. Really good example of this is LinkedIn. If you connect a LinkedIn account on Brandos, what will happen? So say you connect your personal account. If you have business pages, all of those business pages will also be connected as long as you have admin rights to go post to those business pages. Another example is when it's this one's less of a good example, but if you connect meta, right? So you have your Instagram, your Facebook pages, threads is for some reason separate because meta, I don't know. Um, but those ones will also connect multiple accounts. LinkedIn is the best example here because the way that the APIs work is that you acknowledge one account and then we get references to the rest almost exactly like this. The other interesting thing to note is that your authentication is tied to not each of these individually, right? So it's not like you have a separate login for this blog and a separate one for this one. You have authentication once and then all of these connected to it. That means on our platform on brand ghost if you are making a post to one of these and we determine that you've lost authentication for whatever reason the Tumblr API comes back and says nope like invalid token or you know you've uh that's expired whatever it is if it's a lost o reason that means that we also have to lose off on all of these if you change your Tumblr password right what will happen is that it will invalidate all of these if you try on brand goes to refresh refresh your account for Tumblr. It needs to refresh all of these. So, we have again this concept already exists in Brand Ghost, but I'm telling you all of this because that's going to feed into this conversation that we are going to have in GitHub copilot spaces. So, if you're not familiar with this, I don't think this is specifically unique to GitHub. I think I haven't used it, but I think Codeex from Open AI is something like this. I think that in cursor I accomplish this by having my code clone down locally and I can see it. But I have multiple repositories for brand ghost. So we have our front end and our back end. But I like this entire interaction because when I really want to work in my code, it has full context. I for some reason find chat GPT just jumping back. I find working in chat GBT is the the lightest way most natural way for me to kind of have this highlevel back and forth like hey tell me some information about stuff. I don't know why but I feel like it does a much better job of like looking up information for me from the internet especially if I'm over in in this for example I find that it's less it's more tuned for looking at my code and less like it's going to reach out to the internet. What we're going to do is prompt this to see if we can get it to set up a GitHub issue. I'm going to walk you through like my approach for doing that effectively. Obviously, still a work in progress. All of these things can be refined. But to start things off, instructions. So, these are instructions that I have set up in this space. Do I think that this is the best way to do it? Nope. Um, but I literally refined these before doing some of my uh conversations earlier today. And this is one of the reasons I was like, I think this would be helpful for a video. I just originally had this up at the top. I dropped something in here as um as instructions. What the heck was that? Grammarly. Um something in here for some instructions so that it had some context for the code base. But everything else after this block is new. So everything like starting here. So I had just mentioned to you that I feel like this tool doesn't do a great job of searching the internet. I stole this from some other prompt I saw online to try and get chat GBT specifically to go check the internet and like assume you're always out of date for knowledge. So, I'm trying this out. I'm still kind of TBD on whether this works. But these two things definitely made a huge difference today and I just wanted to explain them. I have found and you've probably noticed this too if you're talking with AI and it's almost like if you ask it a question that it's like it sides with you aggressively. So, for example, it codes something and you're like, "Hey, does it make sense to do X?" It's like, "Oh, you're totally right. We shouldn't do X." And it's like, "No, I I'm not saying that. I just I wanted to know. I just wanted to know. I wanted to understand it." I don't know if this is mostly because of uh how we speak or if this is mostly just because of how LLMs are. Maybe a bit of both. But it almost seems like when we ask things to be curious, LLMs seem to often interpret that as a suggestion that you're telling it to do something else. Maybe it's cuz it has a bias for action. Maybe it's because it has a bias for trying to um, you know, to please you. I don't really know. But I added this in here. Again, I'm not I'm not sitting here to try and claim like I'm some prompt sorcerer, like I'm not the best prompter in the world, but I do think that this helped a lot. And my goal with like basically all of this, this is mostly about planning down here, but this one's more about analysis. Now that I have this dropped in place, I can tell and we'll probably see it in the chat. It literally every time it responds, it's doing a mini pros and cons analysis, which is super cool. I have not yet proven if it is staying more unbiased. So, if I ask it something and I'm curious, I haven't proven that it's like it's not going to jump right into like, oh, you're you're right. But so far the the pros and cons part is is absolutely working. And then the other part on planning this did a pretty good job. I think the thing that I noticed is that it was catching itself like in some of its response is it was saying like I need to be articulate. This is unambiguous, right? Like whether or not it's doing the best job of that again still TBD, but it's really cool because now it seems pretty front and center. So moral of the story here is not copy my prompt. It's perfect. Definitely not. My my message here is like play around with this and iterate. Try your conversations out. See how they're going. I already know that one of the things I realized that I have to tune with this is that when it's creating the plan, it did a really good job of laying things out. But I don't actually think that the first example I saw with this translated into the agent doing the work effectively. Just something to think about. It was a plan. I thought it was pretty straightforward. Did that translate into an agent executing it effectively? Maybe not. Maybe bad example. We'll have to see. So, play around with this. These instructions seem to have a pretty big impact. So, what we want to do here, the goal with this is to create a GitHub issue and we're going to assign it to Copilot and have it go do that work for us and see if we can basically have this feature integrated for us almost all through AI. We already have Tumblr authentication. We already have examples of this pattern, but I'm going to walk you through how I would literally approach this. Okay? So, I'm going to take a little bit more opportunity to pause and explain things because I want to explain what I'm doing, but otherwise, this is mostly what I would be doing to build out this feature. Okay? And I'm doing this a lot with brand ghost development and some of my side projects. The reason that I'm doing a lot more of this is because I'm finding it lets me do more things altogether. What do I mean by that? I'm not just doing one thing, getting it to 100%, doing the next thing, getting it to 100%. I might have like more work in progress, like five or so things going on at once, and I can kind of jump between them. A more recent example is I had some AI generated code. I saw the output of it, and I was like, this will work, but it's not designed the way I want, and I don't know how to suggest otherwise yet. I need to park that. So, I can think about this. So, that's paused now. But in the meantime, I can go have these other, you know, trains of thought going off and having agents do stuff. So, this works well for me. I'm going to record with my voice so I you're not watching me type here. Um, and that way I don't have to type it and then explain it after. In Brand Ghost, we currently have the ability to connect a Tumblr account and the existing code will map one Tumblr account to a single blog associated with that Tumblr account. We have other examples in the codebase like LinkedIn. When we authenticate with LinkedIn, we are able to get multiple LinkedIn accounts including personal and business pages. I would like for us to be able to support multiple blogs for Tumblr in the same way that we support multiple accounts for some platforms like LinkedIn. I notice that there are flags on the Tumblr API when we get the user info that indicate a primary blog, but we also have the ability to get other blogs that are not primary. These are the ones that I would like to make sure we include as individual social account IDs when we are authorizing Tumblr. We'll start with this. This is a prompt that I do not think is going to result in it putting together a perfect work item or anything like that. This is me starting a conversation. I'm going to be using GPT5. Are there better models for this? Sure. By the time you're watching this, I'm sure there's going to be a whole new set of models. [laughter] So, I think this one will work for me. I didn't go with a mini model. Um, sometimes the mini ones are nice when you're going back and forth pretty quick because they're faster. But sometimes when I'm doing a bigger prompt like this and trying to get more creative just to let's get things rolling. I like doing a model that is not mini so it will take more time seems to do more reasoning and then we have a kickoff point. You can see it's already starting by analysis. I think this is part of uh my instructions that I added originally or when we walked through originally here blows an architectural analysis and proposed implementation plan. So it's already jumping to a plan but let's see what it says. One of the reasons I love this is because it has full reference to my codebase and it's online right. So if I can do this in cursor usually it's because my multiple repositories are available on my computer but this code's in GitHub so it's nice that it's able to see it. Tumblr social account off Tumblr. This is a database table. Stores one row per social account ID. It knows that these method calls assume a onetoone social account to blog. So it can see that from the code. I said this, but it found the methods. I didn't say these methods in my original prompt. Posting expects a social account ID whose off resolves uniquely to a blog ID. So that's interesting, right? So social account ID must be mapped to a blog ID. And that means if we want to post to other ones, we need to essentially have a dedicated social account ID. That's what I would actually expect. No enumeration of multiple blogs after OOTH. Okay, so far so good. That makes sense. I asked it about LinkedIn because I said it's comparatively has functionality like what we might expect. So it says LinkedIn social o handler enumerates personal and organization accounts after authentication. It creates or updates multiple social o records. uses, this is a special point here, uses a pair ID concept to logically group related o entries. I did not say this to co-pilot here. I know this. I didn't say it to you either, but I walked around this a little bit. I said that when we authenticate and we lose authentication, these things need to be grouped together somehow. That's what this pair ID is. I never said pair ID in my prompt, though. So, it found it and understood this from my codebase. So to logically group related O entries for coordinated refresh or update pattern process accounts async loops through accounts and calls try add off as sync or update flows. So again just some method names you might not know the details. That's totally cool. Tumblr API behavior. So this says returns primary blog plus additional blogs each with a name. Um so that's that's what this API does. How we're currently using it does not do that though. All blogs will be addressable via this with the same access token if user has rights. So here's the goal and let's see how close it got. Enumerate all blogs available to the authenticated Tumblr user. Yes. Create separate social account entries each representing a distinct blog. Also yes. Persist per blog O entries similar to how LinkedIn stores personal and organization accounts. That is what I would hope. What's interesting is this is a very high level statement. How does it plan to do that? We don't know yet. Support refresh flows that keep all blog entries tokens synchronized to avoid drift in expired rows. So yes, again we don't see how it's planning to do that. Preserve backward compatibility with existing single blog entries. Okay. So yes, and I'm also curious how it's planning to do that. So option A, reuse the current table, insert multiple rows, same tokens, different blog ID, distinct social account ID. So far that is quite similar to what I would expect. Pros, minimal schema change. I don't even think it is a schema change but okay cons token refresh becomes fragmented. Rows can fall out of sync. Ah okay. Right. So this is not what we want because of this because of this con token refresh becomes fragmented. If I wouldn't have updated my instructions file before doing this it might not have put these options in front of us and I'd have to tease them out of it. So, it's not impossible that it would have got there, but they kind of did it up front for us. Option B, add pair ID like LinkedIn to group all Tumblr blog off rows. This is what I would want. So, a combination of like, you know, one row per social account in the database plus a pair ID column. Pros enable coordinated refresh update. Yes, that's what I want. Requires schema migration. Okay, so require schema migration. Add that and indices uh added logic and refresh routines. This is I think a necessary evil though the migration uh is actually pretty simple because we don't have multiple databases that we have to go update. It's one table backwards compatibility is if this and it doesn't it hasn't said this but this is how LinkedIn works that pair ID can be null if there is no pair ID it's fine so it doesn't matter that's not going to break existing Tumblr so that's cool option C split token storage user level token have a Tumblr blog accounts I don't want it um this is already more work yeah cons larger refactor more code impact high migration no thanks like not what I want this so far right here option B was exactly what I was uh kind of thinking and then option D is a hybrid. Add pair now. Defer full normalization. No, I don't like I don't think I need that. I think option B is what I want. Recommendation is option D. Add pair now. Defer full normalization. No, I don't think I want that at all. So, I disagree with this recommendation, but I'm glad that it had pros and cons to put in front of us. Alter table. So, yes, that's exactly it. So, pair ID. I use snowflake ID. So, they're in 64. That's why it's big int here. Add an index on it. Pay ID is generated once that and also notice that it's allowed to be null as I said. So that means that in terms of existing records, we're fine. So now it's calling out some code. Again, these are things that you might not know, but I also didn't say this in my prompt, right? So what I'm trying to do in this video is call out the things that it's identifying and letting you know like, hey, look, this it found this. This is relevant or it's not. The reason is like it's not to you it's not actually important what these classes are. Who who gives a crap, right? I give a crap. You might not. But what's important, I think, is that you're seeing how I'm working through this because I'm trying to demonstrate to you. I'm not doing anything magic here. I'm just having a conversation with AI, seeing what's sticking, what's not, and how we steer it. Tumblr social o handler is a class I have. It's patterned on the same thing. So all the social media platforms have a similar style. It wants to generate a single pair ID for the batch. Yes, that's right. So Tumblr rest client. It says add method. Try get user info async returning this. I I might have to start doing a bit of an update to this uh in the chat. So I don't want to add a method. I already have one and I want to modify the existing one because I don't have a need for that existing one to stay the way that it is. It was only getting the main blog name. I just need it to be updated to give me the list of blogs back. It knows it has to go basically update another class just to sort of pass more data along. Add method to refresh all authors by pair ID. This is exactly how LinkedIn works. So, it's good that it sees that. Tumblr author repository. I don't know off the top of my head if this is right. So this is where when we go to create this work item and we assign it to co-pilot afterwards to go work on what might happen and this is again very common in a lot of the development I'm doing with AI is that on the surface this doesn't seem wrong to me but I actually don't know. I could go spend time upfront and go confirm all of this but genuinely I'm reading this and I'm like this doesn't seem wrong. If I go spent some time up front and went through the code and I went looking, I might be able to confirm these or say actually just to give you an example like we actually don't need this one or we don't need this one, right? Try get all by owner user ID and pair ID. Maybe we just update the existing method that's close to this, right? Maybe that's good enough. But instead, what I'm just going to do, cuz this is more realistic for what I normally do, is that I would just let it go do this. And then when I review the code, I would go, "Oh, actually, that feels kind of silly." Is that something that I could get better at? I think so. I just generally work that way and I refine that kind of thing later in the code review. Posting a metrics likely unchanged. Any code assumes Tumblr account per user audit. I'm just going to scroll through very briefly. Yeah, I think for the most part, I'm going to address a couple things. So, I would prefer this. So, let's do that. I'm just gonna Oops. Trying to copy it, but I only got one eye. So, I let me talk to it. I'd like to refine some of your suggestions based on the following points. So, I'm going to say let's use option B for migration of the data. We can make the schema change in the existing schema script that we have. We don't need to add a new one. We will just modify the schema to have the pair ID column as you described. But we don't need to create a new migration. I will migrate the database manually. Okay. And then I think the last thing I want to say is this code change is explicitly focused on the backend changes. So in terms of the UX comments that you had, let's just make sure that we're referring to the blog concepts. the exact same way that we were previously. That means if we were using the blog name, let's stick with the blog name. Okay, I'm just going to send that over and see what it's going to do. I think we're getting very close to being able to ask it to make a GitHub issue. So, we'll get it to do that. You'll see that when it takes some of this conversation to put it into a GitHub issue, we'll probably run into another weird problem, which is like as I was talking through all of this with Copilot and kind of repeating it out to you. I feel like I'm pretty aligned with it. When it goes and makes the issue, I'm assuming it will do some things like it'll make statements that say like, you know, step one, you might need to go do whatever. It's like I don't want it to have you might or if I want it to say you must go do X. Like this is the time up front to go ask and answer these questions and the issue that it makes. I want it to be very much like directly go do these things. What's helpful about seeing it put that issue together is that we have the opportunity to catch that stuff up front. At least I've learned so far that if I have GitHub issues that I assign to Copilot with open questions, I'm sort of expecting that I should be a little bit disappointed. And sometimes that's okay. Like I wanted to explore some things, but other times not so much. Okay, this is kind of ridiculous for screen real estate. Okay, so it's putting a bunch of code together. I don't know if I want to go review all the code. Talking about test changes, so that's good. This needs to be mocked. I don't have a lot of um mocked code in my tests, but this is definitely an example of this is hitting a REST API. I'm not going to go hit a real REST API in my test. I think that's good. Refresh behavior backwards compatibility, right? So, we need to make sure that we can support just a single one. But see, it says if you decide to leave, this is a good example. If it puts something like this into the GitHub issue, that won't be right because I don't want it to tell the agent going to do the work if you decide. No, like we have decided up front. So, I will say we leave the pair ID. I'm just going to copy that to my clipboard so I don't lose it, but we are going to leave it null. Uh, next steps. Confirm you're satisfied. That's fine. Implement schema. Let's do this. I would like you to make the following assumption more concrete when we go to make the GitHub issue. and then I will put it here. So yes, we will leave pair ID null for legacy rows. Now that we've clarified this, open up a GitHub issue with distinct stepbystep tasks for an agent to execute in order to implement this feature. Ensure that you have added coverage for the tests that needed to be updated and added for the new behavior that we expect. Do not leave anything ambiguous or open for interpretation by the agent as all questions must be answered before the agent can execute the GitHub issue. I'm going to send this over and just going to call out that one of the things that I need to figure out how to improve is that I am pretty sure this part do not leave anything ambiguous or open for interpretation by the agent. I suspect what's going to happen cuz I've seen this happen a few times now is it's going to leave this as a step in the issue. Instead of going, "Oh, I need to figure this out before I make the issue." It goes, "No problem. I'm making the issue and this is one of the things I have to put into the issue. Maybe it's how I'm saying it. Maybe I need to update the instructions, but uh I have a a feeling that one of the last steps we'll see in the issue is to go ask clarification. So, let's go see what it does. All right, it looks like we have our GitHub issue created. Let's have a little read through. Um okay, so it has a clear goal at the top. Update Tumblr integration to support connecting and managing multiple blog per Tumblr account. Yes. And then it also has analogous how LinkedIn handles multiple organizations. I like this kind of thing. I am hopeful that that gives some guidance to the agent that will execute this when it's looking for common patterns like it should. Then it will go check out some LinkedIn code. So it has some things to refer to in the codebase. Use a pair ID to feel. So that's right. That's exactly what I wanted. Performing a bulk refresh only group updates row sharing the same pair ID. Exactly. For legacy rows, leave pair ID as null and ensure all logic gracefully handles the state. Good. And then it has step by step. So this is cool. The uh ones I made earlier didn't have like the checkbox style. I don't know, but I'm hopeful that having this checkbox style actually helps in terms of having an agent like go step by step. I saw one earlier where it was numbered steps and then it just had a too much text in each section and it kind of just seemed like it gave up part way and was ignoring the steps. But we'll see. It's talking about the schema changes. Do not auto migrate old rules. Legacy Heroes must keep this. No unique index. So, we'll see. I don't know if it's going to add it to a a new migration script. It says don't automigrate. We'll see. It might still make a new migration script, but I don't know. It doesn't explicitly say not to. So, I can't be disappointed. I can change it. Maybe I should right now. So, when it says do not use the Whoa, what happened? I started typing and it jumped me to the end. Use the existing SQL file. Okay, it's the preview button. There we go. Okay, now that's out of the way. Create strongly typed uh pair ID. Exactly. So, I use strongly typed IDs everywhere. So, that's good. We'll be back by long. Do not share this strct across other features. Very good. I didn't tell it to do that, but it knows. This is probably based on some of my coding conventions that I have in my C-pilot instructions and my architectural docs. I'm assuming that's where that's coming from. Update the data models. So, this is right to include a pair ID. Uh just Dapper. That's what I use instead of entity framework. So, for the pair ID, that makes sense. Repository. So, this is just like the CRUD stuff that we have at the the database layer. That's all fine. It's suggesting adding in these methods. Like I said, I don't know if these are right, and that's okay cuz they don't seem wrong to me. I will see when it goes and implements it. If I'm like, "Oh crap, that's really off." Then we'll change it. That's fine. But I'm willing to accept that risk of it being wrong right now. Extend this class. This is where a lot of the logic is. When updating or refreshing, it must take the pair ID into account. Maintain all previous userfacing naming conventions for blogs. Do not alter existing naming logic. So there's a couple of spots where we will give a name to uh an account automatically. So I'm just telling it to use the same. I'm feeling pretty good about this. Ensure all code checks for null pair ID where logic expects groups of Os gracefully handle single row null pair ID case. Yeah. And then test coverage. Okay. So this is one that I wanted to see some detail on. Update all existing Tumblr off at tests cuz we have new scenarios, right? multiple blogs to get distinct social account ids. This is giving us that one one to end mapping versus one one. So we need tests for it and we still need to assert that we have a single blog example maintained. So that's good. And then bulk refresh. So I like all of these add negative and regression test for edge cases. I don't this is kind of like it's not wrong to suggest this. I think it's good but mixing legacy and grouped rows. I don't know what that means. So, this is interesting because this is an example of something that's a little bit ambiguous. So, add negative and regression test for edge cases. I think that's a great point to make. What are those edge cases? If I were spending more time like working with the agent on this and not recording this video, either I would read this now and I would go to edit this and just add in what I think those edge cases are, or I would go back to the chat and say, "Hey, you mentioned negative and regression tests. What are those? Let's let's let's inventory them. Let's put them in so that the agent doing this work isn't guessing." I'm okay with that for now. This is interesting. And I don't want this. call out migration legacy guidance. This is one of the things that drives me nuts about um some of the AI stuff is like I don't need if I put this dock in my codebase, it would not serve a purpose ever. And that's because it's literally trying to document the migration that it's doing. It's very temporary. I don't need that in my codebase. And then you can see the very last part. Do not begin agent work unless every step above is specified. I kind of said that before we started reading through this, but I said do not leave anything ambiguous or open for interpretation. It did put it in right at the end. So, a couple quick changes I just want to make at the end. This is kind of silly cuz that supposed to be answered before. This is what I want to have. Document document um document the public API for the role and expected. Yeah. And I want to say more clearly because I don't want it to write a doc file like an a markdown file document the public API with XML doc comments. That way my IntelliSense will show it. I don't always do this but sometimes like if I'm going back and touching up code that already exists. It's kind of nice just to like add it and then it makes the code a little bit easier to work with with IntelliSense. And then I do want to say do not add any markdown file. Literally, I want to call out [laughter] to not do this. Yes, thank you, Grammarly. Okay, I think this is what I would like to do. I'm going to make this issue. I'm going to assign it to Copilot and then [music] when the next video is ready, you can check it out right up here and we'll go see what it was like to navigate poll request. Thanks so much for watching. I will see you in the next one. Take care.