GitHub Copilot for Engineers: Getting Better Results

GitHub Copilot moved to usage-based billing in June 2026, dropping the flat subscription model that made monthly costs predictable. For teams using it heavily across multiple projects, that shift puts a premium on being deliberate: reaching for the right model, keeping prompts focused, and building a configuration that produces good results without a lot of back-and-forth iteration.

Many of us install the extension, start with the defaults, and only tune settings later. The defaults are a reasonable starting point, but they are not a full configuration. A small investment in setup changes how much you get out of every request on an ordinary working day, and that matters more now that each request has a cost attached.

This guide covers the full path: getting the tooling in place, choosing models with cost in mind, layering global and project-level rules, and building out instructions, agents, and skills that make Copilot predictable across different kinds of work.

Architecture overview

Before you start

Subscription and VS Code extension

You need an active GitHub Copilot subscription. Plans are available at individual, business, and enterprise tiers at github.com/features/copilot. Once active, all tools use your GitHub account credentials.

The GitHub Copilot extension for VS Code is the primary day-to-day interface. Install it from the Extensions panel or via the CLI:

1
code --install-extension GitHub.copilot

The extension provides inline completions as you type, Copilot Chat in the sidebar, inline chat on any selection via Cmd+I / Ctrl+I, agent mode for multi-step tasks, and multi-file edits with a single review step.

Defaults keep improving, so avoid cargo-culting old setting lists. Focus on non-default tweaks that improve signal quality and control usage:

Copilot CLI

The GitHub Copilot CLI is a standalone AI agent for the terminal.

Install via Homebrew:

1
brew install copilot-cli

Or via pnpm, if you prefer Node.js tooling:

1
pnpm add -g @github/copilot

On first launch, authenticate with your GitHub account by following the /login prompt. The CLI has two modes: an interactive session where you have a back-and-forth conversation while Copilot reads and modifies files in the current directory, and a programmatic mode where you pass a single prompt with -p and the CLI executes and exits.

1
# Start an interactive session
2
copilot
3

4
# One-shot task with explicit tool approval
5
copilot -p "Show me this week's commits and summarise them" --allow-tool='shell(git)'
6

7
# Open a PR with the changes
8
copilot -p "Refactor the auth module to use async/await and open a PR"

awesome-copilot

github.com/github/awesome-copilot is the official community-curated repository of Copilot instructions, agents, skills, and prompts. Before writing any configuration from scratch, check here first. It is far faster to adapt a battle-tested instruction file than to start from a blank page. The catalogue covers common engineering workflows: security review, frontend, documentation, and more.

Choose models by task

Model choice should match task shape. GitHub Copilot subscriptions give you access to a range of models. Here is how to map them to real work:

A practical pattern:

1. Start with your default model.
2. If the output is shallow, switch to a stronger reasoning model.
3. If the output is too slow for a simple task, switch back to a faster model.
4. Keep one model per agent role for consistency: engineering, security, UX, docs.

Agents (covered below) let you pin a model in their frontmatter, so the same task always runs with the same capability profile.

Layer global and project settings

The most reliable setup is layered: global defaults for how you work everywhere, project-level rules for what is unique to a specific repo.

Global settings

Global Copilot configuration lives under your home directory:

Managing these in a dotfiles repo and syncing them to $HOME on each machine gives you a consistent baseline without reconfiguring per project. Good candidates for global rules include workflow behaviour and tool preferences, secure coding defaults, code-commenting standards, and framework-specific instructions for React, TypeScript, and similar.

If you want a concrete reference, this is my setup: github.com/sourcier/dotfiles.

Project-level settings

For project-specific behaviour, add a .github/copilot-instructions.md to the repo root, or place .instructions.md files in .github/instructions/. VS Code picks these up automatically when you open the project.

Use project-level rules for naming conventions unique to this repo, folder architecture and module boundaries, test and QA requirements, and build and deployment constraints. Use global rules for communication style, security baseline, preferred CLIs, package manager choices, and repeatable personal workflow.

Instructions, agents, and skills

These three tools serve different purposes. Treating them as interchangeable leads to a setup that is noisy and hard to maintain.

Instructions: always-on policy

Instructions are Markdown files with YAML frontmatter that Copilot reads automatically whenever the applyTo glob matches the file you are working in. Use them for stable guardrails and standards that should apply silently in the background.

Two patterns work well: broad instructions with applyTo: '*' for universal rules, and targeted instructions with file-type globs for framework-specific rules.

Minimal template:

1
---
2
applyTo: '**/*.ts'
3
description: 'TypeScript service-layer standards'
4
---
5

6
# Service Standards
7
- Use strict typing
8
- Return typed errors
9
- Validate external input at boundaries

Agents: task-specific operators

Agents are .agent.md files that define a reusable persona with a pinned model, a tool budget, and a system prompt. Use them when the same class of work needs consistent behaviour every time.

An agent definition includes:

• name: shown in the VS Code agent picker
• description: used for routing; Copilot reads this to decide which agent fits a request
• model: pinned model for this workflow
• tools: explicit list of tools the agent is allowed to use

Good starting agents: a Software Engineer for general implementation and refactoring, a Security Reviewer for OWASP-focused code review, an Expert Frontend Engineer for React and TypeScript work, and a Tech Writer for documentation and READMEs.

Create a new agent when a task requires a distinct review lens, needs a stable model and tool profile, or when you want consistent output style for that workflow.

Skills: reusable playbooks

Skills are SKILL.md files that contain detailed step-by-step procedures for a specific domain. The agent reads the skill file at invocation time rather than keeping it in context permanently, which means skills can be as long and detailed as needed without bloating every conversation.

Good candidates: a premium frontend UI craftsmanship checklist, a workflow for creating AGENTS.md files for a new repo, or a Playwright website exploration procedure.

The rule of thumb:

• Instructions = default behaviour
• Agents = who does the work
• Skills = how specialised work gets executed

MCP servers

MCP (Model Context Protocol) extends Copilot with external capabilities: browsers, issue trackers, cloud providers, databases, and more. Servers are configured in ~/.copilot/mcp-config.json for global access, or .vscode/mcp.json for project scope.

Three common patterns:

1. Local command server: runs a pre-installed binary on your machine (preferred)
2. Remote HTTP server: connects to an external service over HTTPS
3. npx/uvx on-demand: package runner launches the server each time; avoid for servers you use regularly as the cold boot adds latency on every invocation

Installing common servers

Playwright MCP: browser automation and visual QA:

1
brew install playwright-mcp
2
# or via pnpm
3
pnpm add -g @playwright/mcp

Azure MCP Server: Azure resource inspection and management:

1
brew tap azure/azure-cli
2
brew install azmcp
3
# Authenticate before first use
4
az login

Example config

1
{
2
  "mcpServers": {
3
    "playwright": {
4
      "command": "playwright-mcp",
5
      "args": ["--headless"]
6
    },
7
    "atlassian/atlassian-mcp-server": {
8
      "type": "http",
9
      "url": "https://mcp.atlassian.com/v1/mcp/"
10
    },
11
    "Azure MCP Server": {
12
      "command": "azmcp",
13
      "args": ["server", "start"]
14
    }
15
  }
16
}

Prefer a globally installed binary via Homebrew or pnpm for any server you use regularly. Reserve npx for one-off evaluation of a new server before committing to a permanent install.

When to reach for MCP

Follow this order:

1. Native CLI first: git, gh, pnpm, docker, cloud CLIs.
2. Use MCP when no good CLI path exists or when MCP adds capability the CLI cannot.
3. Keep the MCP list minimal and intentional.

Security checklist

Before adding any MCP server:

• Never hardcode tokens in config files. Use environment variables or a secret store.
• Prefer least-privilege credentials.
• Use trusted hosts only for remote HTTP servers.
• Disable or remove servers you are not actively using.

Rolling it out

Individual setup

1. Install the VS Code extension and Copilot CLI.
2. Create ~/.copilot/instructions/ and add one global instruction file. Workflow preferences and a security baseline are the highest-value starting points.
3. Browse awesome-copilot and copy two or three instruction files relevant to your stack.
4. Add a .github/copilot-instructions.md to your primary repo with project-specific conventions.
5. Try agent mode for a non-trivial task to get a feel for how it behaves.

Team rollout

1. Define a shared baseline in a dotfiles or inner-source repo covering instructions, agents, skills, and MCP config.
2. Add two to four high-value project instructions per repo.
3. Create three core agents: engineering, security, and documentation review.
4. Add skills only for repeated, specialised workflows.
5. Review output quality every two weeks and refine rules and prompts based on what you observe.

Keeping it improving

Results degrade when instructions conflict, when prompts are vague, or when agents are used for everything regardless of fit. A simple quality loop prevents that drift:

1. Be explicit in prompts: goal, constraints, relevant files, and done criteria.
2. Keep instructions concise and non-conflicting.
3. Scope rules with applyTo so they trigger only where needed.
4. Use specialised agents for repeated high-value workflows.
5. Validate with tests and lint, and feed failures back into instructions.

Quick audit checklist

When the setup is in place, use this to evaluate it quickly:

• Model selection is intentional by task type.
• Global rules exist for workflow and security.
• Project rules exist for repo-specific conventions.
• Agent catalogue maps to real team workflows.
• Skills exist only for deep, repeated procedures.
• MCP servers are minimal, secure, and actively used.
• Prompts include explicit success criteria.

Further reading

• awesome-copilot: community instructions, agents, skills, and prompts
• GitHub Copilot documentation: official reference for all features
• Copilot CLI documentation: about the CLI, modes, and security considerations
• VS Code Copilot extension: extension page with changelog and settings reference

Wrap up

The model table in this guide covers the cloud providers available through a Copilot subscription. If you want to cut cloud costs further or keep sensitive work entirely on your machine, running models locally is worth exploring. My next post covers exactly that: installing and tuning Ollama on Apple Silicon, choosing models by use case, and wiring local inference into VS Code Copilot and the CLI. It goes live June 4.

If this guide helped, use it as a practical checklist this week: pick one primary model, tighten your instruction layers, and remove one source of prompt churn from your workflow. Then share what changed for you in the comments, or subscribe via the form at the end of this page to get the local AI follow-up as soon as it publishes.