You may have noticed my growing enthusiasm for GitHub Copilot. Over the past three weeks, I’ve delved into various aspects, from introduction to database scripting and Entity Framework. In the upcoming parts of this series, we’ll explore implementing the Repository pattern, leveraging data structures, and ultimately crafting the UI for the application we’re developing on this journey.
Pause from the Series
Allow me to pause our discussion on the MVP series and instead delve into a key discovery I’ve made regarding code generation. I’ll explore one crucial factor that significantly impacts the relevance of the responses.
When discussing GenAI, particularly GitHub Copilot, the second point you’re likely to encounter is the necessity of prompt engineering techniques to excel with it. (The first, often erroneously, being its purported ability to replace developers.) However, there’s a crucial aspect missing from this narrative: context. Let’s take a moment to delve into both prompt engineering and context, briefly.
Prompt
A prompt serves as the input you provide to GitHub Copilot, typically consisting of a few words or a sentence. GitHub Copilot then analyzes this prompt to generate the corresponding response, whether it’s code, documentation, and so on. The prompt reflects the developer’s input based on their experience and can vary widely in specificity, detail, granularity, and clarity.
Crafting an effective prompt requires experience and training, which is where prompt engineering comes into play. It equips developers with the skills to construct well-formed prompts. I’ll offer a comprehensive guide on prompt engineering in the near future.
Context*
Context on the other hand, is not something that the developers would type in every time. but all the reference code, documentation that is fed to the GitHub copilot using the commands, files, or any other way for GitHub copilot to generate the code.
If you refer back to the Part 2 and Part 3 of the series, you will notice I begin the coding session by first generating the ‘Standards’ file, which is then referred to generate the code. In this case, the standards file becomes part of the context for GitHub copilot. There are other sources of context for GitHub Copilot.
- Files open in the IDE
- If you want GitHub Copilot to refer any existing code from your project as a context, easiest way is to open the file(s) in your IDE and then request a prompt.
- Description on top of the code file
- You can include details such as purpose of this class or model, who is going to call, what other modules this class may invoke – you can add them as comments on top, which then acts as a context for GitHub Copilot.
- Inline comments in the code
- Any comments in the code file will also act as Context, add inline comments to make the context specific.
- Previous prompts in the session
- By default, GitHub Copilot remembers previous prompts in the session and generates response, in my posts you will notice in some places I just say, “Can you repeat previous prompts” and refer new class name to generate.
Conclusion
In summary, when utilizing GitHub Copilot, it’s essential to craft detailed and specific prompts while also providing adequate context. This approach ensures that the generated results are not only accurate but also minimizes the additional work required to finalize the code. Consequently, it boosts productivity by saving valuable time and effort.
