Skip to main content

GitHub Copilot–When to choose what?

A few weeks ago, I did a webinar with a colleague where we talked about GitHub Copilot and the different ways you could use it. At that time, we demonstrated both the Chat mode and the Edits mode. With Microsoft 50-year anniversary the new Agent mode was made general available bringing the number of options to 3.

 


Remark: I didn’t succeed in letting Microsoft Designer generate a pathway splitting in 3 directions….

So now the question becomes:

When to choose what mode?

Great question!

When to choose what mode?

Choosing between GitHub Copilot Chat, Edits, and Agent mode depends on what you're trying to achieve:

  • Copilot Chat: Ideal for conversational interactions where you ask questions, seek explanations, or brainstorm ideas related to coding. It's like having an AI-powered teammate that responds to your queries in real time.

  • Copilot Edits: Best when you're actively modifying code. This mode allows you to start an edit session where Copilot suggests and applies changes directly to your code based on natural language prompts. It's great for refining specific segments without manually searching through the entire codebase.

  • Agent Mode: Designed for more proactive, task-oriented workflows. It goes beyond simple responses and edits, handling multi-step tasks autonomously. If you need Copilot to execute a more complex coding workflow without constant oversight, this is the mode to use.

I typically applied the following rules of thumb when choosing between modes:

  • I used Chat mostly when I need information about my code or guidance.

  • I used Edits when making targeted modifications to existing code.

  • I used Agent Mode when I wanted to setup new projects or build complete features and tests.

That being said I noticed that I used Agent Mode a lot more than the other 2 modes the last weeks. But it is too soon to tell if this is a general pattern or accidently related to the kind of work I’m focusing on the last weeks.

An example

Let’s take a common coding scenario: You’re refactoring an old JavaScript project and need to modernize some functions.

  1. Copilot Chat: You start by asking, "How can I optimize this function?" Copilot gives an explanation of best practices, performance improvements, or alternative methods.

  2. Copilot Edits: You decide on a refactor, highlight the function, and prompt Copilot with "Rewrite this using async/await." Copilot applies the edit directly in your code.

  3. Agent Mode: You need a deeper transformation, so you say "Upgrade this entire module to TypeScript." Copilot autonomously carries out the task across multiple files, making changes where necessary and resolving dependencies.

So, it depends on whether you want a quick explanation, a targeted edit, or a more comprehensive workflow execution.

I asked GitHub Copilot to transform this into a nice diagram and this is what I got back:

 

Hope that helps!

More information

Github Copilot Edits

GitHub Copilot Agent mode (Preview)

Mastering GitHub Copilot: When to use AI agent mode - The GitHub Blog

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

Azure DevOps/ GitHub emoji

I’m really bad at remembering emoji’s. So here is cheat sheet with all emoji’s that can be used in tools that support the github emoji markdown markup: All credits go to rcaviers who created this list.