This is an offshoot not only of the jukebox project, but some little things I’ve been automating at work as of late. Nothing here is groundbreaking, but it wasn’t obvious to me when I started using copilot. During my first attempts, I just added copilot my normal process of knocking something together: Jump in and start experimenting with things, write some comments and notes and gradually build up a working thing piece by piece. Copilot was helpful, but kept running ahead of me, doing things I didn’t ask it to do, which was annoying.
I really started to see more benefits once I started working in a slightly different, and possibly more obvious, way. In brief:
- Start by writein brief requirements
- Use Copilot instructions files
- Use new chats from time to time
- Try different models
Keep reading for the longer version…
Most people already know that AI is all about the prompt generation. It’s so important that there are prompt engineering courses to be taken if you like. I was prompting the hell out of things, but what really changed my workflow was postponing the first part of my normal process, the “jump in and start experimenting” bit. To be clear, the things I’m experimenting with are well-trodden territory, it’s going to work fine so long as I get the configuration and syntax correct. Instead, I now take a few minutes to write requirements, even for short utility type scripts. These aren’t long documents, just a some bulleted or numbered list of points that spell out what and sometimes how things should be done. Then, the prompts are pretty simple, basically just telling copilot to implement the requirements.
If it’s something more involved, I might ask copilot to tell me if there is anything ambiguous or missing from the requirements first. As things get implemented and features are added, I’ll add them to the requirements, or clarify existing requirements rather than overloading the chat window.
As I add and modify functionality, I update the requirements rather than putting those modifications in the prompt. With a numbered list, I can just refer to the number of the requirement that was added or changed. This makes for short and fewer prompts.
I keep the requirements with the rest of the project files (in a git repository on Codeberg). A bonus of this method is having those requirements for future reference. Usually, I just put the requirements in the README file if they are short. For more complicated project, a separate file or files might be in order.
Copilot instructions are a big help too. They are a great place to put overarching requirements that apply to everything so you don’t need to repeat yourself. Want to establish co-pilot’s role or enforce a certain communication or coding style? The instructions file is a great place to do that.
Lastly, starting new chats from time to time, or when working on different things is helpful. This is a recommendation I’d seen in many places and ignored for a while. For new tasks, I would always start a new chat but I was just letting it ride as I worked on the same thing. However, the recommendations do seem to degrade over time. A new chat solves this.
Bonus tip: Experiment with the different models to see which works best for what you are trying to do. Claude Sonnet worked better for me while working on Python than Chat GPT.