Transcription
Hi everyone, I'm Maxin Soniggov, a senior solution engineer at Microsoft focusing on AI developer tools and welcome to another episode of promptdriven development where we build and improve software by writing great prompts.
Today we are going to tackle something developers often put off until the very end or skip entirely: documentation. But instead of spending hours writing it ourselves, we'll use GitHub Copilot to generate it for us just by crafting the right prompt. We'll start with a quick look at our example project, an expense tracker app, and then use prompts to create a complete README file and generate documentation for the front end and API.
Along the way, I'll also show you "Bring Your Own Key," a feature that lets you connect your own AI model API keys, offering greater flexibility in how you use Copilot. Let's dive in and see how prompting can turn documentation from a chore into something fast, accurate, and fun.
And here's our project, personal expense tracker. I started it by gathering product requirements in a PRD (Product Requirements Document). Then I created another document, technical specification, where I listed all technologies I want to use. And then I implemented it, or at least partially implemented it, of course, with a huge help from GitHub Copilot agent mode. The application itself looks like that, definitely incomplete and fairly simple so far. And like many hobby projects, talking here for myself, it lacks documentation. Let's check if GitHub Copilot can help us.
For me, great projects start from great README files, where we explain to other developers and future ourselves what this project is about, how to run it, how to build it. For sure, we can ask GitHub Copilot to generate a README file for us. But instead of writing a prompt manually, because I really want to have a detailed README file, what if we use a ready-to-go prompt, "README Generator"? You can ask me where did I get this one from. And here's the answer: There is an amazing GitHub repository called "Awesome Copilot" that contains chat modes, instructions, prompts, and so on, created by community members. And this one is exactly from this repo, "README Generator" prompt. And I downloaded this markdown file. I put it into my folder, `github/prompts`. And if I follow conventions, naming conventions, this prompt is immediately available as a comment. So let's just run it. Perfect. Let's see how this README file looks. Let's open its preview. Amazing. Perfectly formatted, complete, and correct one. How do I know that it's correct? Because it asked me to run some commands along the way to make sure that it builds correctly. Great.
Now, we have an amazing README file. But let's don't stop here. I also want our API layer to be fully documented. And this is not part of the README file, not to these details. And let me open GitHub Copilot again and start a new session. My best recommendation for every new task: start a new session and try something different this time. Let's go for edit mode, because in this particular situation, I don't want GitHub Copilot to run any commands, just to create any some files for us. So let's ask it: "Create detailed API documentation following best practices." Perfect. Just a couple of minutes of work, and we have two new files. First is human-readable API documentation. Let's check how that looks. Open preview. Yeah, looks human-readable and 100% correct because it scanned our backend for these API points. And second is YAML documentation for OpenAPI, and it exactly follows what we asked: best practices. Perfect. Now our API layer is fully documented.
Before we move to the next step of our project documentation journey, let me demonstrate you another super important and useful feature of GitHub Copilot: that is "Bring Your Own Key." Let me open Copilot again. And if we check the model selector, we'll see that we can actually manage models here. That means that we can bring our own model or bring our own key. For example, if we have extra requirements on compliance, extra security measures, and of course, it gives us extra flexibility on managing costs. Let's imagine that we have an existing key for Gemini and we want to use exactly this one. So we can choose which model we want to have here. Let's pick both. And voila. Now, if we switch to this model consumption, and all interaction with the model will happen exactly through our API key. Just extra flexibility for us developers and organizations.
We now have a README file created for the project in general, and the backend layer or API layer documented in detail, both for humans and for serving via OpenAPI through YAML format. Let's do something now with our front end. And again, let's do it in a different way so I can demonstrate you different ways of using GitHub Copilot. Let's start from inline mode. And let's open some front-end component, transaction list, for example. And there is a fairly simple method. Let's document it. Let's hit Ctrl+I on our Windows machine and slash, and from the slash commands, we choose the one called "doc." And we don't need to write anything in addition. Voila, we have JSDoc formatted documentation or comment for this method. Yeah, we can accept it. And, um, yeah, maybe let's take the whole file and add the documentation to these methods that are here. Let's open our chat window, GitHub Copilot again, and we can type something like: "Add inline documentation to all methods in." And to be precise, we can even directly reference this particular file. You see, `/file dashboard.tsx`. And let's revert to our basic model. Let's give it a try. Perfect. Less than one minute of work, and we have all methods documented. Now our front end is even better because it's well documented.
Let's repeat some of the best practices we went through along the way. We started with a completely undocumented personal expense tracker application. Then, in the "Awesome Copilot" repo, we found a prompt called "README Generator" and used this in GitHub Copilot in agent mode. But before doing this, we actually made it as a part of our repository by just putting this into the `github/prompts` folder. Now we can run it as a command every time we need to create a new or updated README file. And the result was really good. It's complete. It's perfectly formatted. And what's more important, it's validated because we ran all the commands, all the key commands, while we created this file. Not we, but GitHub Copilot in agent mode.
Then we requested to document our backend layer, our API, and GitHub Copilot did it for us again, perfectly well. Created documentation, both human-readable in the form of a README file, also complete and correct, and also as YAML for OpenAPI. Then we switched to the front-end part and requested GitHub Copilot to create full documentation for some of the files. And also, we demonstrated how to use GitHub Copilot in inline mode. So in just a few steps, we converted our project from not documented to developer-friendly.
And that's it for this episode of promptdriven development. The key takeaway here is that Copilot is so much more than just an autocomplete tool. Among other features, it can be your documentation assistant, helping you ship clearer, better documented projects without the usual time consumption. I hope you'll try this approach on your own apps. Start small, refine your prompts, and watch how quickly you go from no docs to great docs. Thanks for watching, and see you in the next episode of promptdriven development. Happy prompting.