Cosa è successo
GitHub ha aggiunto una valutazione di approvazione a ogni revisione del codice Copilot e ha introdotto un'impostazione opzionale che consente a Copilot di inviare un'approvazione formale di richiesta pull. La funzionalità è in anteprima pubblica ed è disattivata per impostazione predefinita.
Il registro delle modifiche del 1 settembre di GitHub afferma che ogni revisione del codice Copilot ora includerà una valutazione di approvazione nel commento di panoramica. La valutazione indica se Copilot considera una pull request pronta per l'approvazione, insieme ai commenti dettagliati prodotti durante la revisione. GitHub descrive questo come un segnale immediato del giudizio di Copilot, ma afferma che la valutazione di per sé non conta ai fini dei requisiti di fusione di un repository. Un essere umano può utilizzare il segnale per decidere cosa fare, senza concedere l'autorità di approvazione formale a Copilot.
La funzionalità di approvazioni separate consente agli amministratori di autorizzare Copilot a inviare un'approvazione su una richiesta pull. GitHub afferma che l'approvazione inviata può contare ai fini della regola delle approvazioni richieste di un repository. Si tratta quindi di una modifica del flusso di lavoro piuttosto che semplicemente di una nuova etichetta in un rapporto di revisione: Copilot può diventare uno dei revisori la cui approvazione soddisfa una condizione del repository configurata. Secondo il registro delle modifiche, la funzionalità è disponibile in anteprima pubblica per i piani GitHub Copilot Pro, Pro+, Max, Business ed Enterprise.
L'impostazione è disattivata per impostazione predefinita e può essere controllata a livello di azienda, organizzazione e repository. Gli amministratori aziendali possono mantenere le approvazioni disabilitate in tutta l'azienda o consentire alle organizzazioni di decidere. Gli amministratori dell'organizzazione possono abilitare la funzionalità in tutta l'organizzazione, delegare la scelta agli amministratori dei repository, abilitarla per repository selezionati o disabilitarla a livello di organizzazione. Gli amministratori del repository possono attivare o disattivare le approvazioni e selezionare quali percorsi di file Copilot può approvare. GitHub indirizza gli amministratori alla documentazione di revisione del codice Copilot per i dettagli di configurazione, ma la fonte non descrive ulteriormente questi passaggi.
GitHub afferma inoltre che l'approvazione di Copilot viene respinta se vengono inviati nuovi commit dopo l'approvazione, allo stesso modo dell'approvazione di un revisore umano. È quindi possibile richiedere una nuova revisione a Copilot per ottenere una nuova approvazione. L'annuncio non spiega come il sistema raggiunge la valutazione di approvazione, segnala i tassi di errore, identifica quali tipi di modifiche gestisce meglio o indica se l'anteprima viene implementata in modo uniforme su tutti i piani elencati.
Dettagli della fonte: github.blog ↗
Perché è importante
Ciò sposta Copilot dall'offrire giudizi di revisione alla partecipazione al flusso di lavoro di approvazione di un repository. Poiché la sua approvazione può contare ai fini delle approvazioni richieste, gli amministratori devono decidere dove e come un revisore dell'IA può esercitare tale autorità.
Il significato pratico è che ora un giudizio sull’intelligenza artificiale può essere collegato a un controllo di governance del software esistente. Molti repository utilizzano le approvazioni richieste come punto di controllo prima che le modifiche vengano unificate. L'annuncio di GitHub non dice che Copilot unisce automaticamente il codice, ma dice che un'approvazione Copilot abilitata può soddisfare la parte di approvazione di tale processo. Ciò offre alle organizzazioni la possibilità di incorporare la revisione dell’intelligenza artificiale nei flussi di lavoro stabiliti, preservando al contempo il controllo dell’amministratore sull’esistenza o meno di tale funzionalità.
La modifica crea anche una distinzione significativa tra assistenza e autorizzazione. Una valutazione di approvazione è informativa e non conta ai fini dei requisiti di fusione. Un'approvazione inviata è un'azione operativa con conseguenze a livello di repository. La decisione di GitHub di rendere le approvazioni attivabili e configurabili a diversi livelli amministrativi offre alle aziende un meccanismo per limitare l'adozione in base all'organizzazione, al repository o al percorso del file. Tali controlli possono essere particolarmente importanti per i repository contenenti modifiche che richiedono una revisione umana specializzata, sebbene la fonte non specifichi alcun caso d’uso particolare regolamentato o sensibile.
Il controllo a livello di percorso è notevole perché consente agli amministratori di definire dove Copilot può approvare anziché applicare una regola generale a ogni file in un repository. La fonte non spiega la sintassi del percorso disponibile, se le esclusioni sono supportate o come gli amministratori dovrebbero scegliere i limiti. Inoltre, non dice se le approvazioni Copilot sono visibilmente distinte dalle approvazioni umane in tutte le visualizzazioni del repository, quali record di audit vengono conservati o come viene assegnata la responsabilità quando un'approvazione AI viene accettata da un team.
La regola di licenziamento affronta un problema fondamentale di coerenza: un’approvazione non dovrebbe rimanere valida dopo le modifiche del codice rivisto. Considerando i nuovi commit come invalidanti l'approvazione di Copilot, GitHub allinea la funzionalità con il comportamento descritto per i revisori umani. Ciò non dimostra che la revisione sia completa o corretta; significa solo che l'approvazione viene rimossa dopo i commit successivi. La fonte non fornisce alcuna prova sul fatto che una nuova revisione rilevi tutte le modifiche sostanziali o quanta supervisione umana si aspetta GitHub durante l'anteprima.
Meccanismo interattivo: come funziona realmente
Esplora la tecnologia alla base di questo sviluppo in modo interattivo.
crm_get_transaction(id='4092').An agent must create a draft calendar event for Tuesday at 2 p.m. Which evidence would establish the requested result?
Cosa guardare dopo
Le domande chiave riguardano l’affidabilità con cui le valutazioni di Copilot identificano le modifiche pronte per la revisione, il modo in cui le organizzazioni configurano le restrizioni sul percorso dei file e il modo in cui i team gestiscono la responsabilità quando un’approvazione dell’IA contribuisce a una decisione di fusione. L’annuncio di GitHub non fornisce misurazioni di precisione, dettagli di audit o una data di disponibilità generale.
Il primo problema da tenere d'occhio sono le prestazioni nei repository reali. GitHub afferma che la valutazione dell'approvazione segnala se Copilot considera una richiesta pull pronta per l'approvazione, ma non fornisce parametri di riferimento, tasso di false approvazioni, ambito del test o confronto con revisori umani. Queste incognite sono importanti perché un’approvazione formale può influire sul rispetto dei requisiti configurati di un repository. Lo stato di anteprima pubblica significa anche che la funzionalità potrebbe cambiare man mano che GitHub raccoglie feedback, sebbene il registro delle modifiche non specifichi un calendario di test o traguardi pianificati.
La seconda questione riguarda la governance nella pratica. Gli amministratori dovranno decidere se Copilot può approvare tutte le modifiche, solo le modifiche nei repository selezionati o solo i percorsi di file specificati. L'annuncio descrive i livelli di controllo disponibili ma non specifica se GitHub raccomanda l'approvazione umana per particolari categorie di codice. Lascia inoltre aperte le domande sulla proprietà delle revisioni, sulla verificabilità, sulla notifica e su come i team distingueranno un'approvazione generata dall'intelligenza artificiale dal giudizio di una persona quando indagano su un difetto successivo.
Il terzo problema riguarda il modo in cui la funzionalità interagisce con altri requisiti di revisione. GitHub afferma che l'approvazione di Copilot può contare ai fini della regola di approvazione richiesta di un repository, ma non spiega come interagisce con le protezioni dei rami, le responsabilità in stile CODEOWNERS, le revisioni rifiutate o i repository che richiedono approvazioni da gruppi particolari. Inoltre, non dice se un’organizzazione può richiedere l’approvazione umana oltre a quella di Copilot. Questi dettagli potrebbero determinare se la funzionalità funziona come un limitato aiuto alla produttività o diventa una modifica significativa ai controlli di rilascio di un progetto.
Infine, i team dovrebbero osservare il confine tra una valutazione di approvazione e un'azione di approvazione. La valutazione è ora inclusa in ogni revisione Copilot, mentre l'approvazione formale rimane disabilitata a meno che un amministratore non la abiliti. I nuovi commit ignorano un'approvazione esistente e richiedono una nuova richiesta di revisione. GitHub non ha rivelato il modello o il processo di revisione alla base della valutazione, le prove utilizzate da Copilot o le garanzie che impediscono che un'approvazione venga trattata come una prova più forte di quanto non sia. Tali omissioni sono i principali limiti dell’annuncio.