4.1.2. Input Processing and Prompt Building
💡 First Principle: The model never sees "your repo" — it sees a constructed prompt that Copilot assembles to look like a document the model can naturally continue. The quality of that constructed prompt, not raw access, is what drives suggestion quality.
Before anything is sent, Copilot's input processing builds a prompt from available context. It gathers signals — the code around your cursor, the active selection, neighboring open tabs, file path and language hints — and assembles them, often using a "fill in the middle" (FIM) framing so the model can complete code between existing code, not just append to it.
This is why two developers sending "the same" request get different results (Phase 1) and why context crafting matters so much (Phase 5): the prompt the model receives is a product of your editor state, not your literal keystroke alone.
A scenario: a developer is surprised Copilot "knows" about a helper function defined in another open file. That's input processing at work — neighboring tabs contributed to the constructed prompt. Close that tab, and the context (and suggestion quality) can change.
💡 Key Point: Copilot is fundamentally a document-completion model. Prompt building engineers your context to look like a document whose natural continuation is the code you want.
⚠️ Exam Trap: "Copilot only sends the current line" is false. Input processing draws on surrounding context — open files, neighboring tabs, selection, metadata — to build the prompt.
Reflection Question: How does "fill in the middle" prompt construction differ from simple autocomplete, and why does having relevant files open improve suggestions?
