Capstone: Your AI-Native Development Workflow

The Tools You Now Have

By this point you have worked through every major surface of GitHub Copilot: inline completions, Chat in Ask/Edit/Agent modes, the async Coding Agent, custom instructions, MCP servers, the CLI, and code review. The challenge now is not learning any individual feature — it is knowing which one to reach for at each moment in your development workflow.

This final lesson builds a decision framework and walks through a complete example from blank file to merged PR using the full stack of Copilot tools in the right sequence.

A Decision Framework for Choosing the Right Tool

A Complete Workflow: Blank File to Merged PR

1. Set up the foundation first. Before you write any code, make sure .github/copilot-instructions.md captures your stack, conventions, and constraints. This shapes every Copilot interaction from this point forward. Treat it as a living document and update it as your team learns what instructions produce better suggestions.

2. Write with inline completions. Open the file and start typing. Let ghost text carry the routine implementation. Accept suggestions for boilerplate, reject them for anything that requires domain knowledge Copilot does not have. Use NES to follow related changes across lines. This is where most of your time-saving happens on familiar code.

3. Use Ask mode to orient yourself on unfamiliar code. When you hit code you do not understand — whether it is in your own project, an open-source dependency, or a file a colleague wrote — reach for @workspace and /explain before trying to trace it manually. Understanding code is a large part of writing code, and Ask mode compresses it.

4. Use Edit mode for targeted refactors. When you need to apply a consistent change across multiple files — updating an API interface, applying a new error handling pattern, migrating to a new library — describe it in Edit mode, review the diff file by file, and accept what fits. Do not use Agent mode for tasks where you know exactly what needs to change and which files it affects.

5. Use Agent mode for open-ended implementation. When you have a goal but are not sure what files will need to change, or when the task involves installing packages, running tests, and fixing the errors that result — switch to Agent mode. Provide a clear goal, a reference to existing patterns, and a verifiable outcome. Let the agent iterate.

6. Use the Coding Agent for well-scoped issues. When you have a ticket or issue that is well-defined enough that a capable developer could implement it from the description alone, assign it to the Coding Agent. This is especially valuable for tasks that run during time you would otherwise not be coding: overnight, during meetings, while blocked on another task. The draft PR gives you a solid starting point even if it needs revisions.

7. Use the CLI for terminal-heavy work. When you are in a terminal context — deploying, running migrations, setting up environments, scripting — bring in the Copilot CLI rather than switching to VS Code. The CLI agent has the same capabilities and reads the same custom instructions.

8. Configure automatic code review. Set up Copilot as an automatic reviewer on your repository so every PR gets a first pass before human reviewers see it. Write path-scoped instructions files for the areas of your codebase that have the highest standards or the most common mistakes. The review comments are a feedback loop on how well your instructions are tuned.

The Compounding Effect

Each of these tools is useful individually. They compound when combined. Custom instructions make inline completions more accurate. The Coding Agent performs better when your instructions file explains your architecture. Code review finds more relevant issues when your review instructions match your actual standards. Every investment in instructions pays off across every surface.

The developers who get the most out of GitHub Copilot are not the ones who use every feature all the time. They are the ones who have a clear mental model of what each tool is for — and switch between them fluidly as the nature of their work changes.

Try This

Pick a real feature or bug fix from your current backlog — something that would normally take you a full working day. Before you start, write a clear GitHub Issue with acceptance criteria. Then work through it using the full workflow above: start with custom instructions if they need updating, use inline completions and Agent mode as you build, and submit the PR with Copilot code review enabled. At the end of the day, compare how far you got versus a typical solo day. That comparison is the clearest measure of the workflow's value.