4.3. Reflection Checkpoint

Key Takeaways

• Copilot is an encrypted round trip: context is built into a prompt, sent to a GitHub-owned proxy on Azure, screened, completed by the model, screened again, and returned — with nothing retained for the real-time flow and (on paid plans) no training on your code.
• The model sees a constructed prompt, not your repo. Input processing assembles open files, tabs, selection, and metadata using FIM framing — which is why context (and context crafting) drives quality.
• The proxy is an active checkpoint, not a relay: inbound toxicity/relevance/jailbreak screening, outbound toxicity/security/public-code checks. Content exclusions (not the proxy) protect sensitive files from ever entering the prompt.
• Copilot's limitations are structural — knowledge cutoff, finite context, no true verification, non-determinism, no enforced SDLC — which is precisely why human validation and oversight are required.

Connecting Forward

Phase 4 showed that the model only ever sees the prompt you (and Copilot's input processing) construct. Phase 5 turns that into a skill: prompt engineering and context crafting. Once you know suggestion quality is a function of the constructed prompt, deliberately shaping that prompt becomes the highest-leverage thing you can do.

Self-Check Questions

• Trace the code suggestion lifecycle from keystroke to ghost text, naming the two points where the proxy acts and what the feedback loop measures.
• A colleague worries Copilot is "storing our private code and training on it." Using the data-flow facts, how would you accurately reassure them, and what caveat applies to the Free tier?
• Which structural limitation explains why Copilot suggested outdated API usage, and what's the right fix — distrust Copilot entirely, or change something about the context?