GitHub Copilot Tips and Tricks: What Actually Works Now

If you’re still using GitHub Copilot like it’s an autocomplete engine that occasionally finishes your for-loops, you’re leaving most of it on the table. The old advice — “write clear comments,” “break tasks into small steps,” “review every suggestion” — isn’t wrong, but it was written for a tool that could only see the current file and suggest the next few lines. That tool doesn’t really exist anymore. Copilot now has an agent mode that edits across your whole repo, a cloud agent that opens its own pull requests, real MCP server support, and a model picker with a dozen-plus options. None of that shows up if you’re still prompting it like it’s 2023.

Agent Mode for Multi-File Changes

Agent mode (available in VS Code and JetBrains via the mode dropdown in Copilot Chat) doesn’t wait for you to open the right file. Give it a task — “extract this validation logic into a shared utility and update all callers” — and it will search the workspace, decide which files need to change, make the edits, run your build or test command, read the output, and fix what it broke. You approve or reject the overall plan, not each individual keystroke.

The practical shift: stop scoping your prompts to a single file. If you’re still saying “in this file, change X,” you’re using agent mode like chat mode. Describe the outcome across the codebase instead, and let it figure out the file boundaries. It’s also worth knowing there’s a second, separate agent — the cloud (coding) agent — that runs asynchronously in a GitHub Actions environment, works off an assigned issue or a Copilot Chat prompt, and hands you back a pull request instead of local diffs. Use agent mode for “I’m at my desk and want this done in the next few minutes”; use the cloud agent for “go do this while I work on something else.”

Custom Instructions: Steering Copilot’s Defaults

Repeating the same context in every prompt — your test framework, your naming conventions, “don’t use default exports” — is a sign you haven’t set up custom instructions yet. GitHub Copilot reads several layers of these automatically, no flag required:

  • Repo-wide: a single file at .github/copilot-instructions.md. Plain Markdown, applies to every Copilot request made against that repository.
  • Path-specific: files under .github/instructions/*.instructions.md, each with YAML frontmatter declaring an applyTo glob (e.g. applyTo: "app/models/**/*.rb"). Useful when your backend and frontend conventions genuinely conflict and a single repo-wide file can’t hold both.
  • Agent-specific: AGENTS.md files, which can live at multiple levels of the directory tree — the nearest one to the file being edited wins. These are read by agent mode and the cloud agent specifically, not by plain chat.
  • User-level: a personal instructions file in your profile directory, layered on top of whatever the repo defines.
---
applyTo: "**/*.test.ts"
---

Use Vitest, not Jest. Mock network calls with msw.
Prefer `it.each` for table-driven tests over copy-pasted blocks.

These instructions don’t show up in the chat transcript, which trips people up — to confirm they’re actually being applied, check the References list under a Copilot response; the instructions file should be listed there.

MCP Servers: Giving Copilot Real Context

This is the change most worth paying attention to if you’ve already set up MCP elsewhere: Copilot now supports Model Context Protocol servers directly, in agent mode, the Copilot CLI, and the cloud agent. The GitHub MCP server and a Playwright MCP server are wired in by default for the cloud agent, which is why it can already read issues, inspect PRs, and interact with rendered web pages without extra setup. If you haven’t worked with MCP before, our guide to Model Context Protocol covers how it actually works.

Where this actually pays off is connecting Copilot to systems it has no native visibility into — your internal ticketing system, a design tool, an infra API — so it can act on live state instead of guessing from static code. A repo admin configures servers once, as JSON (stdio for local processes, HTTP/SSE for remote ones), and from the CLI you can browse and install servers straight from the GitHub MCP Registry with /mcp search instead of hand-writing config — see our look at the MCP registry by the numbers for how fast that ecosystem is actually growing.

Practical tip: don’t wire up every MCP server you can find. Agent mode’s context budget is finite, and a pile of unused tool definitions competes with your actual code for that budget. Add the two or three servers a given task genuinely needs, not your entire toolbox.

Choosing the Right Model for the Task

Copilot’s model picker isn’t cosmetic anymore — it spans multiple vendors (OpenAI, Anthropic, Google, xAI, and others), and the right choice depends on the job, not brand loyalty. As a rule of thumb: faster, cheaper models are fine for mechanical work — renaming, boilerplate, simple test scaffolding. Save the larger, more expensive models for multi-file refactors, anything touching concurrency or security logic, or tasks where you’d want a second opinion from a senior engineer anyway. Some models also expose configurable reasoning levels and much larger context windows, at the cost of more AI credits — worth it occasionally, wasteful as a default.

Don’t memorize a specific model name as “the good one.” The lineup changes often enough that whatever’s listed in this paragraph would be stale within a quarter — check the live picker in Copilot Chat and treat model choice as a per-task decision, not a one-time setting.

Copilot CLI: Agent Mode in the Terminal

If your work happens more in a terminal than an IDE, Copilot CLI is now a fully agentic tool, not a command-lookup helper. It has a plan mode (shows you the steps before touching anything) and an autopilot mode (executes and iterates without per-step approval), supports the same multi-model picker, and is extensible with the same MCP servers and custom instructions as the IDE experience. It also keeps session memory, so a second CLI session on the same repo doesn’t start from zero context. For scripting-heavy or infra work where you’re not going to open an editor anyway, this is worth adopting instead of bouncing between chat and a shell.

What Actually Survived from the Old Advice

A few pre-agent-mode habits are still worth keeping, because they were never really about Copilot’s limitations — they’re just good practice:

  • Specific comments still steer inline suggestions. “// validate using the project’s Zod schema, not ad hoc checks” produces a better single-line suggestion than a vague one, even in plain autocomplete.
  • Review the diff, not just the summary. Agent mode’s plan-level summary (“updated 4 files to add retry logic”) can hide an unwanted change buried in file 3. Read the actual diff before approving.
  • Small, well-scoped asks still outperform one giant one. Agent mode can handle broad tasks, but “migrate the auth module to the new session format” produces a more reviewable result than “modernize the codebase.”

Frequently Asked Questions

Is GitHub Copilot Workspace still a thing?

No — Copilot Workspace was sunset in 2025. Its ideas (issue-to-PR automation, sub-agent task breakdown) were folded into the Copilot cloud agent, which is now a GA product rather than a separate preview tool.

Does GitHub Copilot support MCP servers?

Yes. MCP support is current and spans agent mode in the IDE, the cloud agent, Copilot code review, and Copilot CLI — not a preview feature limited to one surface.

What’s the difference between agent mode and the cloud agent?

Agent mode runs locally in your IDE in real time, editing files in your working copy with you watching. The cloud agent runs asynchronously in a hosted GitHub Actions environment against an assigned issue or prompt and delivers a pull request — you’re not present while it works.

Where do I put custom instructions for GitHub Copilot?

Repo-wide: .github/copilot-instructions.md. For rules scoped to specific paths, use .github/instructions/*.instructions.md files with an applyTo glob. For agent-specific guidance, use AGENTS.md, which can be nested at multiple directory levels.

Can I choose which AI model Copilot uses?

Yes — the model picker in Copilot Chat (and the CLI) supports multiple vendors, with trade-offs between speed, cost, reasoning depth, and context window size depending on which model you select.

Quick Summary

  • Agent mode now does autonomous multi-file edits with terminal access, in both VS Code and JetBrains — stop scoping prompts to one file at a time.
  • The cloud agent is a separate, asynchronous product: assign it an issue, get back a PR, no local session required.
  • Set up layered custom instructions (.github/copilot-instructions.md, path-scoped *.instructions.md, AGENTS.md) instead of repeating context in every prompt.
  • MCP server support is real and current — connect Copilot to the systems it can’t see natively, but keep the server list short to protect context budget.
  • Treat the model picker as a per-task decision: cheap/fast models for mechanical work, larger/slower ones for anything that actually matters.
  • Copilot CLI is now a full agentic tool with plan/autopilot modes — worth using directly if your work lives mostly in a terminal.
  • Copilot Workspace is gone; its capabilities live on inside the cloud agent.