6.1.1. Code Generation, Refactoring, and Documentation
💡 First Principle: These three are the same act at different moments — Copilot proposes a transformation of code or intent into more code or prose, and you accept, adapt, or reject. Generation starts from intent; refactoring starts from existing code; documentation describes code that exists.
Practical uses the exam expects you to recognize:
- Generation — turning a comment, function signature, or description into an implementation; scaffolding boilerplate (CRUD handlers, config, repetitive structures).
- Refactoring — restructuring existing code: extracting functions, renaming for clarity, simplifying logic, applying a pattern consistently. Edit and Agent modes (Phase 2) shine here for multi-file changes.
- Documentation — generating docstrings, comments, README sections, and inline explanations from the code itself.
A scenario: a developer faces a tedious refactor — rename a concept across a dozen files and update the docs. Copilot (via Edit or Agent Mode) proposes the changes, and the developer reviews the diffs. The win is the avoided manual slog, not a guarantee the refactor is flawless.
✅ Best Practice: Use generated documentation as a strong first draft, then verify it matches what the code actually does — generated docs can describe intended behavior rather than real behavior.
⚠️ Exam Trap: Generation, refactoring, and documentation outputs are all drafts subject to validation. A question implying Copilot's refactor or docs are automatically correct ignores the Phase 3 discipline.
Reflection Question: How are generation, refactoring, and documentation variations of one underlying activity, and what review does each still require?
