GitHub ha aggiornato Copilot code review l’11 settembre. Durante l’analisi il sistema può ora usare un insieme più ampio di strumenti shell: non soltanto leggere i file, ma anche eseguire build, test e comandi mirati quando il contesto lo consente. Nel livello Lite più agenti contribuiscono alla stessa review e il prodotto combina i rilievi. GitHub riporta miglioramenti nei propri esperimenti, ma quei numeri descrivono il campione dell’azienda e non prevedono il risultato sul vostro codice.
Perché è importante
- Dal 11 settembre Copilot code review può usare più strumenti shell per validare il codice e, nel livello Lite, combinare il lavoro di più agenti.
- Quando una modifica affronta un commento, la re-review può risolverlo automaticamente; i rilievi ancora pertinenti dovrebbero restare aperti.
- GitHub specifica che la review predefinita è un commento e non conta come approvazione richiesta: test, regole del repository e responsabilità umana restano separati.
Che cosa cambia nella review di Copilot
La parte più visibile arriva dopo la prima review. Se una nuova modifica affronta un commento di Copilot, la re-review può risolvere automaticamente quel thread; se il problema resta, il commento dovrebbe rimanere aperto. Quando si applica un suggerimento, GitHub può anche proporre un messaggio di commit coerente con il cambiamento. Sono riduzioni di lavoro amministrativo: non dimostrano, da sole, che la correzione sia completa.
La documentazione conserva un confine importante. Per impostazione predefinita Copilot invia una review di tipo Comment, non Approve o Request changes, quindi non soddisfa automaticamente le approvazioni richieste. Una organizzazione può configurare review automatiche e, in altri scenari autorizzati, anche approvazioni; la scelta va trattata come una modifica al processo di qualità, non come un interruttore di produttività da accendere senza una prova.
Passo 1 — Costruisci una pull request che possa davvero fallire
Crea un repository o un ramo di prova senza segreti e prepara una modifica piccola. Inserisci tre difetti conosciuti e diversi: una condizione al limite, una gestione incompleta dell’errore e un’incoerenza rispetto a una regola del progetto. Aggiungi un punto che sembra sospetto ma è intenzionale, spiegandolo nei test. Il campione deve avere una risposta nota prima della review; altrimenti ogni commento convincente sembrerà corretto.
Mantieni attivi lint, typecheck e test esistenti. Copilot può chiamare strumenti shell, ma non va usato per nascondere un controllo mancante nella CI. Registra quali comandi partono, quale versione del codice analizzano e se il risultato è riproducibile da una persona. Se un test fallisce per rete o dipendenze, separa il guasto dell’ambiente dal difetto della modifica.
Limita anche il perimetro. La documentazione consente istruzioni generali in `.github/copilot-instructions.md`, contesto in `AGENTS.md` e istruzioni specifiche per percorso. Scrivi poche regole osservabili: per esempio quali test devono passare, quali directory contengono dati sensibili e quali pattern sono intenzionali. Un testo lungo e vago aggiunge contesto, non necessariamente precisione.
Cosa puoi farci concretamente
- Preparare una pull request di prova con tre difetti noti, un falso allarme plausibile e test automatici già riproducibili.
- Aggiungere istruzioni di review brevi e verificabili, poi confrontare il risultato con e senza quel contesto.
- Misurare difetti trovati, falsi positivi, commenti riaperti e tempo umano prima di estendere la review automatica ad altri repository.
Passo 2 — Esegui review, correzione e re-review come un unico test
Richiedi la review manualmente sulla pull request di prova. Per ogni commento assegna una classe: difetto reale, suggerimento utile ma non bloccante, falso positivo o rilievo non verificabile. Non applicare subito tutte le correzioni. Apri il file, esegui il test collegato e controlla che la spiegazione descriva davvero la causa. Un suggerimento pronto da applicare resta codice da comprendere.
Correggi due difetti in due commit distinti e lascia volontariamente aperto il terzo. Richiedi una re-review, oppure abilita per il test la review dei nuovi push. Il risultato atteso è chiaro: i due thread affrontati devono chiudersi soltanto se il problema è risolto; il terzo deve restare visibile. Se un commento scompare mentre il test continua a fallire, la risoluzione automatica non è una prova sufficiente.
Esamina il messaggio di commit proposto come una sintesi, non come la motivazione del cambiamento. Deve dire che cosa è stato modificato senza attribuire una causa non dimostrata. Poi chiedi a una persona diversa di rivedere la pull request senza vedere prima la classificazione. Il confronto mostra sia ciò che Copilot ha trovato sia ciò che ha orientato in modo eccessivo l’attenzione del revisore.
Passo 3 — Misura il valore senza confondere velocità e copertura
Ripeti la prova su almeno dieci pull request rappresentative e registra quattro numeri: difetti noti trovati, falsi positivi, minuti umani per classificare i commenti e rilievi importanti scoperti soltanto dalla review umana o dalla CI. Aggiungi i commenti risolti e poi riaperti. Una riduzione dei thread aperti è utile soltanto se non riduce la visibilità dei problemi reali.
Per i repository con rischi maggiori conserva le protezioni esistenti: approvazione umana, branch protection, controlli di sicurezza e proprietari obbligatori sui percorsi critici. La review AI può diventare un primo passaggio continuo, soprattutto su errori ripetitivi e verifiche automatizzabili. Non deve diventare l’unico soggetto che propone, corregge e approva la stessa modifica.
Il verdetto pratico è favorevole ma condizionato. Auto-risoluzione e strumenti shell riducono attrito e possono aumentare la profondità della prima lettura. Il vantaggio emerge quando il team rende visibili comandi, istruzioni e casi mancati. Se l’unica metrica è il tempo fino al merge, l’automazione può sembrare migliore proprio quando ha smesso di fare domande.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
