Improve developer productivity with GitHub Copilot
Copilot proposes; a baseline decides
A test suite that appears in seconds, a refactor that compiles first time, a security review that finds nothing: each looks finished, and none of them has proved anything yet. Every task in this domain runs one loop. You give GitHub Copilot context and a specific target, Copilot returns a proposal (code, text, a test or a review finding), and you check that proposal against the task's baseline, which is this guide's term (not GitHub terminology) for whatever defines a correct result, such as your stated requirements, the code's existing behavior, the code's contract (the inputs, outputs and errors it promises), or a measurement. The exam trap is an answer that treats the proposal as the result because it compiles, looks plausible, or drew no complaints from Copilot; GitHub's review guidance is to run automated tests and static analysis tools first (static analysis: checking source code without running it; GitHub's code scanning, described below, is one such check) and then review the code yourself.
The domain unfolds in two halves: improving the code, then checking it
The first half, improving the code, is covered on Enhance Productivity and Code Quality: code generation, refactoring, documentation, explanations of unfamiliar code, debugging a known error, sample data, and legacy modernization, each with its own baseline. The second half, checking the code, is covered on Support Testing and Security: unit, integration and end-to-end tests, edge cases and assertions, and security and performance reviews, used when the question is whether existing code is correct, secure or fast enough. There the proposal is a check (a test or a review finding) or, for performance, a suggested optimization, so the loop gains two steps (that page calls it the check loop): run or measure what Copilot returned, then ask Copilot what is still missing and judge its answer yourself. Debugging is not checking, but a known slow path still is: with an error in hand, you ask Copilot how to fix it, while slow code may function correctly but be inefficient. Prompt structure is taught in Craft Effective Prompts, and the duty to validate AI output in Validate and Operate AI Tools; this domain applies both.
When two answers both work, pick specific, small and verified
The answer the exam rewards gives Copilot specific context (the selected code, an error message, a schema, the existing tests) and a named target, splits large work into small steps you can review one at a time, and ends with a check a person runs, such as tests, code scanning (GitHub's feature that analyzes repository code for security vulnerabilities and coding errors), secret scanning (GitHub's scan for hard-coded credentials such as API keys), a timing comparison, or your own careful review of Copilot's suggestions. GitHub's prompting guidance states the middle part directly: break the task into multiple simple, small tasks. The tempting wrong answers each drop one of the three: converting a whole legacy system in one prompt, asking Copilot to make the entire repository faster, or accepting a clean Copilot review as a security sign-off, even though GitHub says you should not rely on Copilot for a comprehensive security analysis.
Two halves, one loop: what Copilot proposes and which baseline decides
| Half of the domain | Tasks | What Copilot proposes | Baseline that decides | Drill into |
|---|---|---|---|---|
| Improving the code | Code generation, refactoring, documentation, explanation, debugging a known error, sample data, modernization | New or changed code, documentation, sample data, or an explanation | Set per task, for example your stated requirements, the existing behavior, or the current implementation; the drill-in page gives every task's baseline | Enhance Productivity and Code Quality |
| Checking the code | Unit, integration and end-to-end tests; edge cases and assertions; security and performance reviews | Tests, review findings, and suggested performance optimizations | The code's contract, checked by running the tests; no exploitable weakness in input, access or data, checked by code scanning, secret scanning and human review; the original output and timing, checked by running the optimized code and comparing its output and timing | Support Testing and Security |