GitHub Copilot: the developer side.

Microsoft 365 Copilot and GitHub Copilot share a name but are different products. If you write code — even occasionally — GitHub Copilot changes your workflow. Four modes matter: code completion, IDE chat, agent mode, and pull-request summaries.

You'll learn the discipline that keeps it a help not a hazard, then call the right mode for each task. About 14 minutes.

A pair programmer, not a replacement

The trap most developers fall into: accepting suggestions blindly and ending up owning code they didn't write and don't understand. The whole skill is staying in the driver's seat.

What pattern keeps GitHub Copilot a help, not a hazard?

Write a clear function name and a comment; Copilot suggests the next lines as you type. Tab to accept — after you read it. ~30–50% fewer keystrokes on routine code.

Highlight code and ask: "why doesn't this compile?", "refactor to async/await," "explain this line by line," "write tests for the edge cases." It replaces most Stack Overflow trips.

You ask Chat to refactor a function and it returns a confident but wrong answer. Likely fix?

Agent mode (VS Code, Visual Studio, JetBrains) takes a goal and works across many files autonomously, proposing changes you review. Good for migrations, library upgrades, and repetitive multi-file edits.

Agent mode finished a 15-file refactor and local tests pass. Before you merge:

Open a PR → "Copilot: Generate description" → it drafts a summary of the changes, files, and rationale. Beats the lazy "fixes #123" — reviewers actually understand what they're looking at.

Which mode reaches for this?

Four tasks. Pick the GitHub Copilot mode you'd use for each.

Four modes, one discipline: let Copilot do the typing, but stay the engineer who reads, runs, and reviews.