Prompt per GitHub Copilot: commenti, contesto e chat

Uno sviluppatore scrive // calcola il totale sopra una funzione vuota. Copilot propone dieci righe che sommano i prezzi, senza l'IVA, senza lo sconto fedeltà, con dei float dove il progetto usa centesimi interi. Il codice compila ed è sbagliato, perché il commento era l'unica informazione data.

GitHub Copilot si guida in tre modi: ciò che scrivi nel file, ciò che gli chiedi nella chat e le regole che fissi per tutto il repository. Ognuno ha i suoi riflessi.

I suggerimenti in linea: il commento è il tuo prompt

Quando Copilot completa il tuo codice mentre digiti, si basa su ciò che circonda il cursore: il nome della funzione, i file aperti, i commenti. Un nome esplicito e un commento che descrive il comportamento valgono più di un lungo preambolo.

Confronta questi due inizi di funzione.

// calcola il totale
function totale(articoli) {

// Totale di un carrello in centesimi (interi).
// Applica lo sconto fedeltà del 5 % se cliente.fedele è vero,
// poi aggiunge l'IVA al 20 %. Arrotondamento al centesimo inferiore.
// Carrello vuoto: restituisce 0.
function totaleCarrello(articoli, cliente) {

Il secondo dice l'unità, l'ordine delle operazioni, l'arrotondamento e il caso limite. Copilot non deve più indovinare. Se non sei sicuro della regola di gestione, non chiedere al codice di indovinarla al posto tuo: scrivila prima.

Aiutano anche due abitudini. Tieni aperti i file che mostrano come il progetto fa le cose (un modulo vicino, un test esistente), perché fanno da esempi. E rileggi ogni suggerimento prima di accettarlo, soprattutto i più lunghi: accettare in un colpo solo dieci righe che non hai letto significa scrivere codice che nessuno capisce.

La chat: scegli cosa vede

Nella chat, la qualità della risposta dipende da ciò che Copilot ha sotto gli occhi. A seconda del tuo editor, può vedere il file aperto, il codice che hai selezionato e i file che aggiungi esplicitamente al contesto (in Visual Studio Code, per esempio, nominandoli con #). Guarda cosa propone la tua interfaccia, perché le opzioni cambiano da un editor all'altro.

Il riflesso utile è selezionare il codice interessato prima di fare la domanda. Un esempio di richiesta per correggere un bug:

La funzione selezionata restituisce 0 per un carrello di due articoli quando il cliente è fedele. Senza sconto dà il totale giusto.

Cerca la causa, spiegala in due frasi, poi proponi la correzione più piccola possibile. Non riscrivere il resto della funzione e non cambiare la sua firma.

«La più piccola possibile» protegge la tua cronologia di commit. Senza questo limite, lo strumento riorganizza volentieri tutto il file, e la revisione del codice diventa un incubo.

Per i compiti comuni, comandi come /explain, /fix o /tests esistono nella chat di diversi editor. Evitano di riscrivere la stessa richiesta, ma completali con una frase di vincoli. Per esempio, dopo /tests:

Scrivi i test della funzione selezionata con il framework già usato nella cartella tests/. Copri il carrello vuoto, il cliente fedele, un prezzo a zero, un arrotondamento che cade tra due centesimi. Un test per caso, con un nome che descriva il caso.

Lancia poi i test. Un test scritto da Copilot può passare perché verifica ciò che il codice fa, e non ciò che dovrebbe fare. Rileggi i valori attesi uno per uno.

Le regole del progetto: un file di istruzioni

Sei stufo di ripetere «usiamo centesimi interi» e «nessuna nuova dipendenza senza parlarne»? GitHub permette di depositare nel repository un file .github/copilot-instructions.md, scritto in Markdown e in linguaggio naturale. Copilot lo legge per le richieste che riguardano quel repository. Il suo supporto varia a seconda dell'editor e della funzionalità, quindi guarda la documentazione di GitHub per il tuo caso.

# Regole del progetto

- Gli importi sono interi in centesimi. Mai float per il denaro.
- Test con Vitest, nella cartella tests/, un file per modulo.
- Non aggiungere dipendenze senza segnalarmelo nella risposta.
- I messaggi di errore destinati all'utente sono in italiano, i nomi nel codice in inglese.

Tieni questo file breve e verificabile. Dieci regole precise valgono più di tre pagine di principi, e una regola che non rileggi mai finisce per contraddire il codice. Lo stesso ragionamento vale per le istruzioni di sistema e per le istruzioni degli agenti: scrivi ciò che un nuovo collega dovrebbe sapere il primo giorno.

Cosa Copilot non sa

Non conosce le tue decisioni di architettura, la tua storia di bug né le regole che sono nella testa del team. Può anche proporre una funzione di una libreria che non esiste o una sintassi di una vecchia versione. Se un suggerimento usa una chiamata che non riconosci, apri la documentazione della libreria prima di proseguire.

Pensa anche al contenuto del tuo codice: chiavi di accesso, password, dati dei clienti. Non metterli in un commento né nella chat, e leggi le condizioni della tua offerta e le regole del tuo datore di lavoro sull'invio di codice a un servizio esterno. Le basi della rilettura e del debug con un'IA sono nel nostro articolo sui prompt per sviluppatori.

Da provare oggi

Prendi la prossima funzione che stai per scrivere. Prima di digitare la prima riga, scrivi nel commento il suo comportamento completo: ingressi, uscite, un caso limite. Guarda cosa propone Copilot, poi correggi il commento, non il codice, se il suggerimento si allontana da ciò che volevi.