Anti-pattern: incollare l’intera repo in chat

Sembra logico: più contesto = più qualità. Falso, oltre una certa soglia. Modelli con finestra ampia (200K-1M token) non garantiscono qualità migliore con input enorme: garantiscono solo costo maggiore, latenza maggiore, e attenzione dispersa. Il contesto giusto non è il massimo: è il minimo che basta.

Perché questa lezione conta

Chi inizia ha l’impulso di “dare tutto al modello” per essere sicuro. Risultato: rumore, costi, attesa, e risposte peggiori di quelle che avresti ottenuto con 5 file selezionati. Saper scegliere quali file dare è uno skill fondamentale del vibe coder: vale per chat, IDE AI, agenti CLI.

Obiettivo operativo

Alla fine devi saper:

1. spiegare perché più contesto può peggiorare l’output;
2. selezionare il set minimo di file per un task specifico;
3. usare strategie alternative quando non sai quali file servono.

Nucleo della lezione

1. Perché troppo contesto fa male

Quattro effetti negativi:

Rumore: il modello deve filtrare informazione irrilevante. Più rumore = più probabilità che si focalizzi su dettagli sbagliati. Un file di 500 righe in cui solo 30 sono pertinenti = 470 righe di distrazione.

Costo: input lungo costa di più. Modelli tariffano per token. 200K token in input = ordine di grandezza in più di 20K token. Sui workflow ripetuti, la differenza è significativa.

Latenza: tempo first-token cresce con dimensione input. Output lento = workflow rotto. Un agente che ci mette 30s per partire perché legge 500 file genera frustrazione.

Lost in the middle: anche dentro la finestra, attenzione del modello non è uniforme. Dettagli a metà di un input lungo vengono ignorati. Iniziando dal materiale più rilevante, perdi qualità su quello.

Inoltre: input enorme mascherà problemi di prompt. “Non funziona perché non ha capito” → in realtà aveva contesto sufficiente, ma il prompt era debole. Più contesto = meno feedback su qualità del prompt.

2. Come selezionare file

Strategia in 4 livelli, in ordine di preferenza:

Livello 1 — Entry point + tipi condivisi: file di ingresso (main, app, route principale) + tipi globali. Dà al modello la mappa minima.

Livello 2 — File del componente coinvolto + suoi import diretti: il file che modificherai + i moduli da cui importa. Per task localizzati, questo è quasi sempre sufficiente.

Livello 3 — Test correlati + eventuale errore: test del modulo + log/errore preciso. Aiuta a definire il “fatto” e a riprodurre il bug.

Livello 4 — Configurazione rilevante: solo se il task la coinvolge. tsconfig, package.json, framework config. Non per ogni task.

Ciò che NON metti, salvo casi specifici:

• node_modules/ (mai);
• file generati (build, dist);
• asset (immagini, font);
• file di testi/contenuti (a meno che il task riguardi il contenuto);
• file di log;
• altri moduli non collegati al task.

Regola pratica: se prima di mandare il prompt non hai dovuto scegliere cosa includere, hai incluso troppo.

3. Strategie quando non sai quali file servono

Tre approcci:

Chiedere prima quali file servono: prompt iniziale “ho il task X, struttura repo è [tree], dimmi quali file vorresti vedere prima di scrivere codice”. Il modello propone, tu confermi e mandi solo quelli.

Usare tree sintetico: invece di file completi, dai struttura cartelle (tree -L 3) + nomi file. Il modello capisce la mappa, chiede file specifici se servono.

Riassumi moduli: invece di codice intero, dai una sintesi: “modulo X esporta funzioni Y, Z, W; tipi A, B; usa lib K”. Il modello ha context senza dettagli inutili.

Allega diff invece di file completi: per task di modifica, spesso il diff (cosa è cambiato) è più informativo del file completo.

IDE AI / agente CLI: lascia che leggano file selettivamente via tool. Tu dai obiettivo + scope (file ammessi), strumento legge solo ciò che serve. Spesso più efficiente del fornire tutto a priori.

Procedura pratica

Prima di mandare prompt importante:

1. Scrivi il task specifico.
2. Lista file rilevanti secondo i 4 livelli.
3. Domanda di controllo: ognuno di questi file cambia cosa il modello farebbe? Se no, toglilo.
4. Verifica dimensione: stima token (1 KB ≈ 250-500 token). Se sopra 50K token e il task è specifico, probabilmente troppo.
5. Manda prompt.
6. Osserva: se il modello chiede file aggiuntivi, dagliene; se sembra avere abbastanza, vai.

Laboratorio guidato

Task: “in un’app web con frontend React + backend Node, aggiungi rate limiting all’endpoint POST /api/comments”.

Approccio sbagliato: incollare intera struttura cartelle e tutti i file. 2000 righe.

Approccio mirato:

• File obbligatori: src/server/routes/comments.ts (l’endpoint) + src/server/middleware/index.ts (per vedere middleware esistenti).
• Configurazione: package.json per vedere se libreria di rate limiting già esiste.
• Tipi condivisi: src/types/api.ts se contiene tipi di response.
• AGENTS.md: per convenzioni del progetto.

Totale: 4 file, ~300 righe. Sufficiente per il task. Se manca info, il modello chiederà.

Pratica: per il prossimo task tuo, fai lo stesso esercizio. Conta riduzione di righe portate al modello rispetto a “incollare tutto”.

Output atteso

Una checklist personale di selezione contesto:

• task: __
• file ovvi (4 livelli): __
• file da includere: __ (max 5-7 di solito)
• file deliberatamente esclusi: __
• approccio fallback se mi accorgo che manca info: chiedere al modello.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: evitare il sovraccarico di contesto e imparare a fornire all’AI solo ciò che serve per il task. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Perché troppo contesto può peggiorare la risposta: rumore, costi, latenza, attenzione dispersa.
• Come selezionare file: entry point, tipi condivisi, componente coinvolto, test, errore, configurazione rilevante.
• Strategie alternative: chiedere prima quali file servono, usare tree sintetici, riassumere moduli, allegare diff.

3. Applicazione: svolgi il laboratorio: partire da una struttura repo e scegliere il set minimo di file per correggere un bug specifico. L’output da ottenere è: una checklist di selezione contesto per richieste in chat o in IDE AI.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• so spiegare 4 ragioni per cui troppo contesto fa male;
• ho una strategia di selezione in 4 livelli;
• non incollo mai più di 5-7 file in un prompt iniziale (poi aggiungo se serve);
• quando non so cosa serve, chiedo al modello prima di scrivere codice.

Errori comuni

“Più contesto = più qualità”. Falso oltre soglia. Modelli con finestra grande non sono “memoria infinita”.

Incollare tree completo e tutti i file. Modello disperde attenzione. Risposta peggiore di selezione mirata.

Asset inclusi senza ragione. Immagini, file binari, dati di seed. Inutili e costosi.

Configurazione sempre allegata. tsconfig, package.json non servono in ogni prompt.

Mai fornire AGENTS.md. Convenzioni dimenticate, modello inventa stile incompatibile.

Tagliare troppo. Uno solo file della funzione che modifichi senza i suoi import = modello inventa la firma di quelle funzioni.

Prompt di lavoro

Task: [descrizione]

Struttura repo (tree, livello 3 max):
[output di `tree -L 3 -I 'node_modules|dist'`]

Prima di mandarti file, dimmi:

1. Quali file vorresti vedere per primi? (max 5)
2. Per ognuno, perché ti serve.
3. Cosa NON ti serve (così non lo invio).

Aspetta la mia conferma e i file. Solo dopo, proponi piano del task.

Esercizio finale

Riguarda tre prompt complessi che hai mandato di recente. Per ognuno, conta:

• file inclusi totali;
• righe di codice totali;
• file effettivamente toccati nella risposta;
• file menzionati ma non utilizzati nel ragionamento.

Quasi sempre il rapporto “incluso vs usato” è 3-5x. Quel surplus è rumore. La prossima volta puoi tagliarlo. Tempo recuperato + qualità migliorata.