Dal prompt al suggerimento: cosa succede davvero

GitHub Copilot non “conosce” il tuo codice: a ogni battuta l’editor costruisce un prompt e lo invia a un Large Language Model (LLM), che risponde con una completion. Capire come viene assemblato quel prompt e come il modello lo elabora è la chiave per usare Copilot in modo efficace — ed è materia d’esame GH-300.

Un LLM è un modello di linguaggio addestrato a predire il token successivo più probabile data una sequenza di token in ingresso. Il codice, per il modello, è testo: partendo dal contesto ricevuto, calcola una distribuzione di probabilità sui possibili token seguenti e genera la sequenza più plausibile. Non esegue il codice, non lo compila e non consulta una base dati di risposte corrette: produce statisticamente ciò che, dato quel contesto, tende a comparire. Per questo la qualità del contesto determina la qualità del suggerimento.

Come Copilot costruisce il contesto

Nelle inline completions (i suggerimenti “grigi” nel file) l’estensione non manda solo la riga corrente. Il prompt include tipicamente:

  • Il contenuto del file aperto, in particolare il codice prima del cursore (prefix) e spesso una porzione dopo il cursore (suffix), sfruttando la tecnica fill-in-the-middle.
  • Neighboring tabs: frammenti dai file aperti in altre schede, che Copilot usa come indizi su tipi, funzioni e stile del progetto.
  • Simboli e segnali dal file: nomi di funzioni e variabili, commenti, docstring, import e signature. Un commento descrittivo o una firma di funzione ben scritta orientano fortemente la predizione.
  • Metadati come il linguaggio del file (dall’estensione) e il percorso.

Da qui una regola pratica: per ottenere completions migliori, apri i file rilevanti, scrivi nomi espliciti e aggiungi un commento che dichiari l’intento. Stai letteralmente arricchendo il prompt.

La finestra di contesto (context window)

Il modello ha una context window finita: un numero massimo di token che può considerare in un singolo passaggio. Non tutto il repository entra nel prompt — l’estensione deve selezionare e ordinare i frammenti più pertinenti stando entro quel limite. Ecco perché file enormi o codice lontano dal cursore possono essere troncati o esclusi: se un’informazione cruciale resta fuori dalla finestra, il modello non può usarla.

Diverso è Copilot Chat, dove il contesto è più ampio e in parte esplicito: puoi allegare file, usare workspace context (@workspace / la modalità che indicizza il progetto) o referenziare simboli con #. Chat può inoltre operare in loop con strumenti (agent mode), mentre le inline completions restano un flusso prompt → completamento rapido e locale.

Selezione del modello

Copilot non è legato a un solo LLM. In Chat e nella configurazione dell’organizzazione è possibile la model selection: modelli diversi hanno context window, latenza e capacità di ragionamento differenti. La scelta è un trade-off:

  • Modelli più leggeri → completions inline a bassa latenza, dove la velocità conta.
  • Modelli più capaci → task complessi in Chat (refactoring esteso, spiegazioni, ragionamento multi-file), dove si accetta più latenza per qualità.

L’amministratore governa quali modelli sono disponibili tramite le policy di Copilot a livello enterprise/organization.

Determinismo e limiti

Poiché la generazione è probabilistica, lo stesso prompt può produrre suggerimenti leggermente diversi, e un output plausibile non è garantito corretto: può inventare API o introdurre bug. Il modello riflette il proprio addestramento più il contesto fornito; non “sa” cosa è cambiato nel tuo codice cinque minuti fa se quell’informazione non è nel prompt. La validazione resta responsabilità dello sviluppatore.

Trappole tipiche d’esame

  • Scenario: un suggerimento cita una libreria uscita ieri. “Copilot ha cercato online?” → No. Le inline completions non eseguono ricerche web in tempo reale: generano dal contesto del prompt e dai pesi del modello. Nessuna query a Internet.
  • Scenario: una funzione in un file non aperto non viene suggerita correttamente. → Il codice non era nel contesto. Apri i file rilevanti (neighboring tabs) o usalo in Chat con contesto esplicito.
  • Scenario: progetto molto grande, suggerimenti che ignorano codice lontano. → Colpa della context window finita: non tutto il repo entra nel prompt; conta prossimità e pertinenza, non l’intero codebase.
  • Scenario: serve massima qualità su un refactoring complesso. → Non è un problema di inline completions ma di model selection in Chat: scegli un modello più capace, accettando più latenza.
  • Scenario: stesso prompt, output diverso. → È il comportamento probabilistico dell’LLM (predizione del token successivo), non un malfunzionamento.