Coding with Copilot 2025-11-24 by hkon
In my daily work as a developer, my workflow has shifted greatly the last year. I have gone from coding mostly myself, using ChatGPT as a source of inspiration, to mostly having Copilot in agent mode write code for me. Better or worse, I don't know yet. But here is my current workflow.
Having watched the Copilot writing out code time and time again that was "good enough", I decided it was time to let up on the chains a little bit and enable agent mode.
So far, agent mode, the mode in which Copilot actively works on your files, has proven successful in producing results. And I am fairly certain it has made me more productive in producing features for users.
Where it really shines is in filling in gaps in my knowledge, where I would normally have to look up that one thing I remember I used to solve that one problem in the past. I can give Copilot a few instructions and it just writes out what I wanted, but fairly often, it also writes out "the rest" without me having to ask for it. It knows what comes next. It's the nature of the technology after all.
Plan
First of all, know what you are going to do. If there are some parts or product you are working on that is unfamiliar to you, ask Copilot to summarize how that part works in Ask-mode, how the interaction between the major structures are, what does the data look like, what is the interaction with the user, etc. It can, in my experience, explain both correct and succinctly all these points, which gives you a good idea of how things work today and how your issue or feature might be fixed or implemented.
Secondly, still in Ask-mode, I explore some solutions with Copilot. Once I have decided the high-level approach we want to take, I put Copilot in agent mode and start writing prompts. At the moment of writing (Nov-25), I am using Copilot with Claude. It's the superior AI at this point in time.
Implement
Thirdly, we start with implementation prompts. I usually write on a semi high level what I want done and Claude is able to "reason" and implement the changes. Sometimes I must help it along the way with some keywords and references to central code pieces, etc., but it mostly "reasons" correctly about such things.
Fourthly, we start to read, test, and commit. Having written one successful prompt, the next one can easily, very easily mess up something that worked and you were happy with. So the first thing I started to do was committing to Git after each successful prompt. The measure of success being: I liked what it made and it worked. I also find it easier to review changes with my regular diff tools rather than the built-in "compare and accept" mode that Copilot offers as default. The compare and accept gives another layer in between, which is also useful for rollbacks. Then staging before committing also gives yet another point of comparison. I can't really have enough points of comparison, it seems.
But easy rollbacks without losing progress have become a very important part of my use of Copilot. Having a granular Git history also allows you to take a step back if you have gotten stuck, which happens.
I have Copilot write tests for the code it produces. It's a good way to verify that the code it has written works, but you must keep an eye on the changes at this point. Sometimes it wants to change the production code to suit the test, and that is often the wrong solution, but nothing a few prompts won't solve.
Review
At some points, things are getting to a point where we can consider it implemented. But we're not done. At this stage I do a git diff master > diffs1.txt and have Copilot review the changes that have been made. It can give a very good summary of what has been changed and how it can be improved. After a couple of rounds of reviews, we get the stamp of approval and we make a pull request, which is probably also reviewed by Claude before it's approved. That's how I do it.