Che cosa conta come successo, prima di guardare i numeri

Un criterio di valutazione non è una metrica: è una frase che scrivi prima di lanciare l’agente. Sul Copilot cloud agent questa frase vive nella issue o nel prompt del task, e la documentazione è esplicita su cosa deve contenere: una descrizione chiara del problema o del lavoro richiesto, i criteri di accettazione su come si presenta una buona soluzione — per esempio se servano o no unit test — e un’indicazione dei file da toccare. Vale anche il rovescio: i task che la doc consiglia di non assegnare sono esattamente quelli privi di criteri, cioè requisiti ambigui e obiettivi aperti, insieme alle issue critiche per la produzione e agli interventi su sicurezza, dati personali e autenticazione.

I vincoli operativi invece non stanno nel testo del compito: stanno nella superficie che esegue, e qui confondere le quattro è l’errore più costoso. Il cloud agent è già impedito dal push sul default branch e dal merge, e resta soggetto ai ruleset come qualunque persona. Nella Copilot CLI il vincolo sono i permessi sui tool e il local sandboxing: in autopilot l’agente procede senza chiedere conferma a ogni passo, ma qualsiasi azione che debba uscire dalla sandbox viene negata, e --max-autopilot-continues mette un tetto alle continuazioni. Nei GitHub Agentic Workflows i vincoli si dichiarano nel frontmatter del file Markdown, che gh aw compile traduce in un workflow .lock.yml di Actions; le scritture sono ammesse solo attraverso i safe-outputs dichiarati. Nel Copilot SDK e nei custom agent li esprimi con chiavi come tools e model.

---
on: ...              # quando parte
permissions: ...     # in lettura per default
tools: ...           # che toolset ha a disposizione
safe-outputs: ...    # le uniche scritture consentite
engine: ...          # quale agente esegue
max-ai-credits: ...  # tetto di spesa per run
---

Un vincolo che non compare in uno di questi posti non è un vincolo: è una speranza.

Segnali quantitativi, e chi li accende

I segnali numerici più diretti li conosci già: il codice compila, tutti i test passano, non compaiono nuovi warning o errori. A questi si aggiungono i risultati dei controlli di CI e gli esiti di code scanning e GitHub Code Quality, che un ruleset può pretendere come condizione per il merge nei repository dove operano gli agenti.

C’è però un dettaglio che l’esame ama, perché rompe l’automatismo mentale: i workflow di GitHub Actions non partono automaticamente quando il cloud agent fa push sulla pull request. Qualcuno con i permessi giusti deve premere Approve and run workflows nel merge box. Finché non lo fa, la pull request dell’agente non produce alcun segnale di CI — non perché sia sbagliata, ma perché non è stata eseguita. Nella stessa logica, la tua approvazione di una pull request creata da Copilot non conta ai fini delle review obbligatorie.

Altri segnali quantitativi arrivano dalle superfici di osservazione. Il session log di una sessione dell’agente mostra progresso, token usage e durata, e ogni commit porta un link al log, così da poter ricostruire in review o in audit perché una modifica è stata fatta. A livello di organizzazione, l’impact dashboard collega l’adozione all’andamento del ciclo di vita delle pull request, il code generation dashboard espone le Lines of Code metrics come misura direzionale dell’output, e gli stessi dati sono raggiungibili via API. Da qui ricavi la domanda che interessa davvero: quante pull request dell’agente vengono accettate senza modifiche.

Segnali qualitativi e allineamento con l’intento

Nessuno dei numeri sopra risponde alla domanda che la doc mette al centro della revisione del codice generato dall’IA: questo codice risolve il problema giusto? Un agente che fa passare tutti i test può avere risolto il problema sbagliato, e può averlo fatto in un modo che i test non rilevano. Il caso limite è indicato in modo esplicito: attenzione ai test cancellati o messi in skip invece di corretti. È il classico verde ottenuto spegnendo il misuratore.

I segnali qualitativi sono quindi la revisione umana e il giudizio su leggibilità, manutenibilità, nomi chiari e aderenza alle convenzioni del progetto, insieme alla domanda su quali assunzioni l’agente abbia fatto su logica di business, preferenze di design e comportamento degli utenti. Copilot code review aiuta a raccoglierli su scala, ma non li sostituisce: la documentazione chiede di validarne sempre i commenti e di integrarli con una revisione umana, e avverte che non è garantito che individui tutti i problemi.

L’allineamento fra criteri e intento si costruisce a monte, non in fase di giudizio: le custom instructions in .github/copilot-instructions.md e nei file *.instructions.md fanno sì che le regole con cui valuti siano le stesse che l’agente ha ricevuto. Per le automations sulle issue esistono poi rationale e confidence: ogni azione supportata registra la ragione per cui è stata applicata o proposta, e il livello di automazione del repository decide quale confidence basta per applicare invece di suggerire.

La scansione automatica come misura di qualità

L’ultimo sotto-obiettivo chiede di generare segnali, non solo di leggerli. Code scanning, secret scanning con push protection, gli alert di Dependabot e GitHub Code Quality producono giudizi ripetibili su ogni branch che l’agente apre, coverage inclusa. Il salto concettuale che l’esame verifica è di prospettiva: qui non stai usando questi strumenti come controllo di sicurezza, stai usando il loro output come metrica della qualità di ciò che l’agente produce. Un alert aperto da codice generato dice qualcosa sul prompt, sulle istruzioni e sui vincoli che hai dato, non solo su quella riga. Se ricorre, il difetto sta nella configurazione dell’agente. Sulla CLI puoi anticipare il segnale con /security-review prima di aprire la pull request; a livello di repository puoi renderlo bloccante con la regola che richiede i risultati di code scanning e proteggere con CODEOWNERS i file di configurazione di Copilot e dei server MCP, così che i criteri non vengano riscritti da chi viene valutato.