Se usi GitHub Copilot ogni giorno, c’è una possibilità concreta che tu stia prendendo decisioni tecniche basate su un contesto che Copilot non sta più vedendo. Non perché stia sbagliando in modo evidente, ma perché ha smesso di capire senza dirtelo.

Copilot non fallisce come i sistemi tradizionali. Non va in crash, non alza eccezioni, non interrompe il flusso con un messaggio scomodo. Semplicemente continua. Oppure tace. E proprio questo silenzio è il punto critico, perché induce fiducia dove dovrebbe scattare il sospetto.

Questo non è un articolo contro l’uso dell’AI nello sviluppo. È l’analisi di un edge case reale, documentato e riproducibile, che emerge in Visual Studio Code quando Copilot incontra codice vero. Non esempi didattici, non progetti puliti, ma file grandi, stratificati, cresciuti nel tempo. Quelli che nessuno ha mai davvero rifattorizzato.

Negli ultimi mesi è stato osservato un comportamento preciso nell’estensione ufficiale di Copilot: superata una certa dimensione del file, indicativamente tra le millequattrocento e le duemila linee, la generazione del codice inizia a degradare. A volte si interrompe a metà funzione, a volte non parte affatto. In altri casi Copilot continua a suggerire codice, ma lo fa come se stesse guardando solo una parte della realtà.

La cosa più pericolosa è che non succede nulla di visibile. Copilot risulta attivo, l’autenticazione è valida, l’IDE non segnala problemi. Dal punto di vista dello sviluppatore non c’è alcun motivo evidente per dubitare dello strumento. Eppure il contesto su cui il modello sta lavorando non è più completo.

Il motivo è strutturale. Copilot non analizza l’intero file né l’intero progetto. Costruisce una finestra di contesto basata su porzioni di codice, file aperti, informazioni locali. Quando questa finestra diventa troppo grande, viene ridotta. Non in modo esplicito, non dichiarato, ma attraverso un taglio silenzioso. Il modello continua a funzionare, semplicemente con meno informazioni di quelle che tu stai dando per scontate.

Ed è qui che il problema cambia natura. Non stai più valutando un suggerimento generato su una visione completa del sistema, ma uno costruito su una rappresentazione parziale. Il codice può sembrare corretto, elegante, coerente con ciò che vede. Ma ciò che non vede non lascia traccia.

Il limite in sé non è il vero problema. Ogni sistema complesso ha dei limiti. Il problema è che Copilot non cambia comportamento in modo riconoscibile quando li raggiunge. Non avvisa, non degrada in modo esplicito, non chiede conferma. Continua a comportarsi come se nulla fosse successo, e questo crea una falsa percezione di affidabilità.

Molti sviluppatori interpretano l’assenza di suggerimenti come una scelta “intelligente” del modello. In realtà può essere semplicemente un segnale di saturazione del contesto. Altri accettano suggerimenti plausibili senza chiedersi cosa Copilot potrebbe non aver visto. In entrambi i casi, il rischio non è l’errore immediato, ma l’erosione progressiva della qualità decisionale.

Questo pattern non è isolato. Comportamenti simili emergono anche in altri scenari documentati: editor che vanno in freeze ciclici risolti solo disabilitando Copilot, suggerimenti che si interrompono a metà riga in presenza di latenza di rete, token validi che non producono output, conflitti silenziosi con altre estensioni di completamento. In tutti questi casi il denominatore comune è lo stesso: mancanza di segnali chiari quando qualcosa smette di funzionare correttamente.

C’è poi un aspetto ancora più insidioso. Non tutti i modelli si comportano allo stesso modo. Parlare di Copilot come se fosse un’entità unica è un errore. È un sistema che combina modello linguistico, gestione del contesto e integrazione con l’IDE. Cambi uno di questi elementi e cambia il modo in cui fallisce.

I modelli più piccoli o meno recenti tendono a fallire in modo visibile. Il suggerimento si interrompe, Copilot smette di rispondere, il problema è evidente. Paradossalmente è il caso meno pericoloso, perché costringe lo sviluppatore a fermarsi.

I modelli più avanzati, invece, riescono a reggere contesti più ampi e mantengono una buona coerenza locale anche quando il limite viene superato. Il fallimento non è rumoroso. È silenzioso. Il codice continua a sembrare sensato, ma è costruito su una visione incompleta del sistema. I modelli migliori non eliminano il limite, lo nascondono meglio.

A complicare ulteriormente le cose c’è l’integrazione con l’IDE. Anche a parità di modello, il comportamento può cambiare in base a quanti file sono aperti, a come è configurato il workspace, alle estensioni installate. Due sviluppatori sullo stesso progetto possono osservare risultati diversi senza aver cambiato una riga di codice. Questo significa che il comportamento non è deterministico, e che la fiducia cieca nello strumento è mal riposta.

Questo edge case non colpisce chi lavora su progetti dimostrativi. Colpisce chi lavora su monoliti legacy, su sistemi cresciuti per stratificazione, su configurazioni complesse che nessuno ha mai ridisegnato da zero. Esattamente i contesti in cui un assistente dovrebbe essere più utile.

In questi scenari Copilot può smettere di aiutare senza dirlo, oppure continuare a suggerire codice basato su una comprensione parziale. In entrambi i casi, il rischio è lo stesso: prendere decisioni tecniche pensando di avere un alleato che in realtà sta lavorando alla cieca.

Non esistono soluzioni definitive oggi. Esistono solo contromisure culturali e operative. Ridurre deliberatamente il contesto, non interpretare il silenzio come intelligenza, non accettare suggerimenti senza chiedersi cosa potrebbe essere rimasto fuori. Se non sai rispondere a questa domanda, quel codice non dovrebbe entrare nel progetto.

Copilot non è un compilatore. Non è un analizzatore statico. Non è un sistema deterministico. È un assistente probabilistico che può continuare a parlare anche quando non capisce più tutto.

Il rischio non è che sbagli.
Il rischio è che tu non te ne accorga.

La domanda giusta non è se Copilot ti sta aiutando.
La domanda giusta è se sapresti riconoscere il momento esatto in cui ha smesso.

Se la risposta è no, il problema non è Copilot.
È il modo in cui lo stai usando.