4.2.1. The Code Suggestion Lifecycle

💡 First Principle: Trace one suggestion from keystroke to ghost text and you've mapped the entire architecture. Each numbered step is a place where context is added, screened, or transformed — and a place an exam question can land.

End to end, an inline suggestion travels like this:

Two things to internalize from the diagram. First, the proxy bookends the model — screening on the way in and the way out — which is why it's the home of Copilot's safety controls. Second, the loop closes at your accept/dismiss: that telemetry is the primary signal GitHub uses to judge suggestion quality, which is why your interaction is part of the system, not just its endpoint.

💡 Key Point: If you can place the proxy (steps 3-4 and 6) and the feedback loop (step 8), you can answer most architecture questions on the exam.

⚠️ Exam Trap: Filtering is not a single step. Screening happens inbound (before the model) and post-processing happens outbound (after). A question that puts all filtering in one place, or omits one direction, is describing it incompletely.

Reflection Question: Walk the lifecycle from your keystroke to ghost text. At which two points does the proxy act, and why does that placement matter for safety?