Domain 5: Improve Developer Productivity

What this domain tests

#

Domain 5 is the practical productivity domain: can you use Copilot to generate code, refactor safely, document what matters, learn unfamiliar code faster, create realistic tests, and ask for security and performance improvements without treating AI output as automatically correct? The official weight is 10–15%.

The exam answer is never "Copilot wrote it, so ship it." The developer is the author of record and remains accountable for every committed line.

Use the right Copilot surface

#

Inline suggestions are best when you are already editing code: completing a function body, generating repetitive branches, filling a mapper, or turning a precise comment into code. Copilot Chat is better for explanation, planning, comparison, larger generated sections, or iteration. GitHub’s best-practices page separates inline suggestions for snippets, repetitive code, comments-to-code, and TDD from Chat for questions, larger generation, task-specific keywords, and persona-style review prompts. GitHub Docs — Best practices for using GitHub Copilot

Use Ask to understand code, Plan to inspect the codebase and propose a path before edits, and Agent to make coordinated changes, run commands, and iterate. Even in Agent mode, review diffs, commands, test output, and assumptions before committing. GitHub Docs — Asking GitHub Copilot questions in your IDE

Generate code from comments and signatures

#

A high-signal comment plus a function signature is often better than a vague instruction. GitHub’s IDE-suggestions documentation shows that Copilot can suggest code from natural-language comments and partial function signatures, and that you can accept, reject, or cycle alternatives. The exam workflow is: provide intent, types, constraints, examples, and nearby context, then inspect the generated code. GitHub Docs — Getting code suggestions in your IDE

// Return the net invoice total in cents.
// Rules: reject negative line amounts, apply percentage discount before tax,
// round half away from zero, and return a detailed calculation object.
export function calculateInvoiceTotal(
  lines: Array<{ description: string; amountCents: number }>,
  discountPercent: number,
  taxPercent: number,
): InvoiceTotal {
  // Copilot inline suggestion starts here, but the developer verifies rounding,
  // validation, overflow behavior, and tests before accepting.
}

A better Chat prompt would be: Implement calculateInvoiceTotal in #file:invoice.ts. Preserve the exported type names, throw RangeError for negative cents or percentages outside 0..100, and include examples for rounding behavior. That prompt names the file, the contract, the error behavior, and the edge cases. In VS Code, use #file, #selection, #function, and #project for context. GitHub Docs — Copilot Chat cheat sheet for VS Code

Refactor without changing behavior

#

Copilot is useful for refactoring because it can propose smaller functions, better names, guard clauses, pattern replacements, and data-structure changes. The Cookbook includes recipes for improving readability and maintainability, avoiding long conditional chains, reducing nested logic, and splitting large methods. GitHub Docs — Improving code readability and maintainability

function shippingCost(order) {
  if (order.customer) {
    if (order.items && order.items.length > 0) {
      if (order.address && order.address.country === 'US') {
        return order.items.reduce((sum, item) => sum + item.weightOz, 0) * 7;
      }
      return 2500;
    }
    return 0;
  }
  throw new Error('Missing customer');
}

A safe refactoring prompt is: Refactor this function for readability using guard clauses. Do not change return values or error behavior. After refactoring, list behavior-preserving tests I should run. The important exam behavior is asking Copilot to preserve behavior, then checking it with tests and review. If the refactor changes error type, rounding, null handling, or external calls, it is not a safe productivity win.

Document code without inventing commands

#

Copilot can help generate docstrings, JSDoc comments, README sections, ADRs, migration notes, and diagrams. The Cookbook includes documenting legacy code, explaining legacy code, explaining complex algorithms, and syncing documentation with code changes. GitHub Docs — Documenting legacy code

/**
 * Creates a short-lived password reset token and stores only its SHA-256 digest.
 * The raw token is returned once so the caller can send it to the verified user.
 */
export async function createPasswordResetToken(userId: string): Promise<string> {
  // Implementation intentionally omitted.
}

For ADRs, ask for the decision, context, alternatives, consequences, and links to relevant files; then verify the output against actual code and team decisions. Copilot can draft structure, but it cannot know undocumented operational truth unless you provide it.

Learn faster and reduce context switching

#

Copilot can explain unfamiliar code in the IDE, reducing context switching because you do not leave the editor for every library, pattern, or syntax feature. The IDE Chat documentation supports general development questions and project-code questions, and the legacy-code recipe shows explanations from another developer background. GitHub Docs — Explaining legacy code

Good onboarding prompts include: Explain #file:billingRules.ts as if I am new to this repository, Show the request flow for #function createOrder, Which files should I read before changing refunds? Use #project, and Summarize this test failure and point to the likely source file. The productivity gain comes from staying in context while Copilot uses open files, selected code, project context, terminal context, and GitHub-specific skills where available. Human verification still matters: ask for references, open the files, and confirm the explanation matches the code.

Generate sample data and seed data

#

Copilot can generate realistic synthetic examples when you specify schema, constraints, privacy requirements, and edge cases. Use it for demos, local development, tests, and documentation; never use real customer data.

CREATE TABLE accounts (
  id TEXT PRIMARY KEY,
  plan TEXT CHECK (plan IN ('free', 'team', 'enterprise')),
  seats INTEGER NOT NULL CHECK (seats >= 0),
  renewal_date DATE NOT NULL
);

Prompt: Generate 20 synthetic seed rows for this schema. Include all plans, zero-seat trials, month-end and leap-year renewal dates, and no real company names. Then check validity, privacy, duplicates, and scenario coverage.

Modernize legacy code iteratively

#

GitHub’s modernization tutorial shows a realistic workflow: understand legacy code, chart data flow, generate a test plan, convert to a modern stack, create unit and integration tests, run them, and refine. The example modernizes COBOL to Node.js and warns that conversion is iterative and must be validated. GitHub Docs — Modernizing legacy code with GitHub Copilot

For a language migration, use a sequence like this: first ask Ask mode to explain the legacy module; next use Plan mode to produce a migration plan with risks and unanswered questions; then use Agent mode only after approving the plan. For a single-file translation, GitHub also documents translating code to another language, such as Perl to TypeScript. GitHub Docs — Translating code to a different programming language

Modernization is not only language migration. You can ask Copilot to update deprecated framework APIs, propose dependency updates, replace callback-style code with async/await, add type annotations, or separate business logic from UI. The exam-safe answer always includes a regression test plan, dependency review, security scan, human code review, and staged rollout.

Generate unit and integration tests

#

Testing is covered in this domain. GitHub’s testing tutorial covers using Copilot to generate unit and integration tests, asking for edge cases, running the tests, and improving coverage. The /tests slash command in VS Code generates unit tests for selected code, but GitHub warns that generated tests may not cover every scenario and should be reviewed and extended. GitHub Docs — Writing tests with GitHub Copilot

class BankAccount:
    def __init__(self, initial_balance=0, notification_system=None):
        if initial_balance < 0:
            raise ValueError("Initial balance cannot be negative.")
        self.balance = initial_balance
        self.notification_system = notification_system

    def deposit(self, amount):
        if amount <= 0:
            raise ValueError("Deposit amount must be positive.")
        self.balance += amount
        if self.notification_system:
            self.notification_system.notify(f"Deposited {amount}, new balance: {self.balance}")

Unit-test prompt: Generate pytest unit tests for BankAccount.deposit. Cover valid deposits, zero, negative, initial negative balance, and exact exception messages. Integration-test prompt: Write integration tests using a mock notification_system. Verify notify is called once after a valid deposit and not called when deposit raises. The second prompt matters because integration tests verify collaboration between components, not just isolated return values.

Edge cases, assertions, and the tautological-test trap

#

Copilot can enumerate edge cases: nulls, empty strings, overflows, time zones, leap years, concurrency, retries, authorization boundaries, duplicate inputs, Unicode, API failure, and partial writes. Ask directly: List edge cases this function does not appear to handle. Group them by input validation, state, external dependency, security, and performance. Then turn the relevant cases into tests with meaningful assertions.

Also watch for generated tests that only assert “does not throw,” duplicate the same case under different names, mock away the behavior being tested, or snapshot huge outputs without checking business meaning. Copilot can accelerate test writing, but the developer decides what correctness means.

Security and performance improvements

#

Copilot can help spot common vulnerabilities and suggest fixes, but GitHub’s vulnerability recipe is explicit: do not rely on Copilot for comprehensive security analysis; use code scanning too. GitHub Docs — Finding existing vulnerabilities in code

function displayName(name) {
  const element = document.getElementById('name-display');
  element.innerHTML = `Showing results for "${name}"`; // ask Copilot to review this
}

A useful prompt is: Analyze #selection for common security vulnerabilities. Explain exploitability, suggest a safer fix, and list tests or scanners I should run. A good fix would use textContent instead of innerHTML for this display case, but you still verify the UI requirement, encoding behavior, and code scanning results. For dependencies, Copilot can help draft Dependabot configuration, but repository settings and generated YAML still require review. GitHub Docs — Managing dependency updates

For performance, the Cookbook shows Copilot suggesting algorithmic improvements, such as replacing a naive prime search with a sieve. Ask for measurable changes: Optimize this function for performance, explain the complexity before and after, preserve behavior, and suggest benchmarks. Then run benchmarks and tests. GitHub Docs — Refactoring for performance optimization

Code review and pull request summaries

#

Copilot code review can review pull requests, identify issues, and suggest fixes, including bugs, security vulnerabilities, and style inconsistencies. It can be requested on a pull request, but it always leaves a comment review, not an approval or request-changes review, so it does not replace required human approval. GitHub Docs — About GitHub Copilot code review GitHub Docs — Using GitHub Copilot code review

Copilot can also generate a pull request summary in the description or a comment so reviewers quickly understand the pull request scope, but GitHub notes that it does not take existing PR-description content into account, so start with a blank description for best results and then add missing context manually. GitHub Docs — Creating a pull request summary with GitHub Copilot

Check yourself

#