GitHub Copilot works better when the repository, prompts, comments, and instructions provide clear context.
2
Copilot coding agent can work from a GitHub issue, run tasks in an isolated GitHub Actions environment, and create a draft pull request for review.
3
MCP servers give Copilot access to external data and operations, but they require explicit configuration, credentials, and security review.
Summary
Christopher Harrison and Jon Peck run a hands-on lab about using GitHub Copilot as a peer programmer. Harrison starts with context: readable code, clear names, comments, project structure, and detailed intent all help Copilot understand a task. He then explains the progression from completions and chat to multi-file edits, IDE agent mode, and coding agent on github.com. Coding agent takes a GitHub issue, works in an ephemeral GitHub Actions environment, creates a branch, and opens a draft pull request. The agent has no internet access by default and cannot modify the main repository directly. Harrison also covers Copilot instructions files, dot-instructions files, and MCP servers. Instructions can describe coding standards, repository structure, and file patterns. MCP servers expose external tools and information, but users must configure access and review the servers. AI does not remove code review, testing, linting, or security checks from the development process.
Copilot needs repository context as well as a good prompt
Harrison describes Copilot as an AI pair programmer that reads the code much like a new human teammate would. Prompt writing matters, but readable code matters too. Good function and variable names, clear structure, comments, and a navigable project layout give Copilot information it can use. Single-letter variables and unexplained abbreviations make the code harder for Copilot to follow. Comments can explain what the code is doing and how it should work, even when the comments do not affect the application. Harrison calls this good code practice in general, with a direct benefit for Copilot's ability to understand a project.
Clear intent and specific instructions produce better agent work
Harrison asks developers to state what they want Copilot to do and to specify important constraints. He warns against terse prompts written as if Copilot were an old command-line chatbot. His advice is not to be passive-aggressive with Copilot: if a requirement matters, tell Copilot directly instead of assuming it will infer the requirement. He uses a detailed GitHub issue as an example. The issue describes a feature for submitting games and lists its requirements. For a larger task, he says he might also provide a workflow for the agent to follow while it builds the project.
Harrison distinguishes several Copilot workloads. Code completions suggest the next line, function, or class while a developer is typing. Chat began as a single-response interaction, such as generating one file. Edits extend this to changes across multiple files, which is useful for a web page involving HTML, JavaScript, and CSS. Agent mode works inside the IDE, where Copilot can navigate the project, decide what needs to change, build code, run external tasks such as unit tests, and respond to detected errors. Coding agent runs on github.com from an assigned issue, works in the background, runs scripts, self-heals, and eventually creates a pull request for review.
Coding agent works in a constrained and reviewable environment
Coding agent runs in GitHub Actions and receives an ephemeral environment for its assigned issue. By default, a firewall prevents access to the internet, including the ability to install frameworks and libraries. Teams can open firewall access, or install the required dependencies as part of the setup. The agent cannot write to the repository generally; it can modify the branch it creates. Its pull request remains in draft form until someone approves it, and workflow checks such as security scans and tests cannot run until the workflow runs are approved. Harrison also explains that the person who assigns the issue cannot review the agent's work in the current version, so another person must review it.
Developers can correct an agent through comments or a fresh assignment
If coding agent misunderstands a task, the developer can add a comment with a clarification. Harrison demonstrates extending the request with an endpoint for searching games by name, after which Copilot starts a new session using the existing work. If the result is completely wrong, the developer can unassign Copilot, change the issue, and assign it again so work starts from scratch. Harrison says the first diagnosis should be context. The agent may have misunderstood the request or the environment. Developers can also check out the generated branch and make changes manually when that is more suitable.
Instructions files store project-specific guidance
Harrison presents Copilot-instructions.md as a repository artifact read by coding agent and by Copilot chat requests in the IDE. His example includes an application overview, code standards, requirements before committing, global language guidance, project-specific rules, and the repository structure. He recommends keeping the file current as the project changes. He also describes dot-instructions files for repeated patterns, such as creating Flask endpoints, React components, tests, or Svelte files. These files can point to prototype files and can apply automatically based on a path or filename pattern, such as files in a server test folder that start with test_.
Instruction sources are considered together, so teams should avoid contradictions
Harrison says he did not need to repeat information from an instruction file in a GitHub issue, but repeating an important requirement can reinforce it. He explains that Copilot does not use a simple hierarchy in which one source always wins. It considers the available context and makes a decision. This makes consistency important. If repository instructions, dot-instructions files, and issue text send mixed messages, Copilot can become confused in the same way a human teammate would. When a task repeatedly needs the same correction, updating the instruction file can improve future results.
MCP servers extend Copilot while adding access and security decisions
An MCP server exposes commands that Copilot can use to access external information or perform operations. Harrison explains that an MCP server can help with data outside the model's training set and can improve search and reasoning over a large repository. Coding agent may need firewall access when an MCP server reaches external resources. MCP servers can be configured at the organization or repository level, and an MCP JSON file can list servers. Users still provide their own credentials because actions happen on their behalf. Tokens can have expiration dates, and Copilot can ask for approval before carrying out an operation. Harrison advises vetting MCP servers like any other system with access to external information or the ability to act for the user.
AI leaves the existing development safeguards in place
Harrison argues that AI does not change the DevOps flow. Before AI, code still needed review, linting, security scans, unit tests, and other checks before entering the codebase. Those safeguards remain necessary when Copilot writes the code. He also warns that Copilot is probabilistic and may change more than the requested file, especially in agent mode. Developers who need tight control can use edit mode or ask mode in the IDE. Coding agent's branch can be reviewed, modified manually, or used as the starting point for another branch.
"I really can't overstate the importance of instructions file."48:45
Who should watch
You are deciding where Copilot completions, chat, IDE agent mode, or coding agent fit into an existing development process.
Your team wants agents to work on GitHub issues while keeping branches, pull requests, tests, security checks, and review under control.
You need Copilot to follow repository conventions or use external tools through MCP, and you want practical guidance on supplying that context safely.
