Team di sviluppo: agenti IA revisionano le pull request e smistano le issue GitHub

In un team di sviluppo, la revisione del codice e lo smistamento delle issue sono due attività che tutti trovano utili e per le quali nessuno trova il tempo di farle a fondo. Una pull request aspetta due giorni che una persona libera la legga, e i primi commenti riguardano spesso ciò che una lettura rapida avrebbe visto: un test mancante, un branch troppo largo, un segreto dimenticato. Una issue arriva senza tipo né priorità, a volte senza le informazioni per riprodurla, e aspetta che una persona la qualifichi. Sono attività di metodo, con criteri che il team sa mettere per iscritto, e si prestano agli agenti IA a patto che i loro diritti siano circoscritti.

L'ispirazione: una prima lettura prima delle persone

Il punto di partenza è un uso riferito dagli utenti di Hermes Agent, riassunto in una scheda sul team di sviluppo: revisionare le pull request aperte e smistare le nuove issue. L'idea non è sostituire il revisore umano, ma consegnargli pull request già lette, con i punti da verificare in cima all'elenco, e issue già qualificate.

Manteniamo due ruoli distinti e un principio di prudenza: gli agenti commentano ed etichettano, non decidono nulla. Atako applica l'idea con due agenti il cui accesso a GitHub è volutamente ristretto a leggere, commentare ed etichettare.

Cosa fanno i due agenti

Lo scenario distribuisce due agenti, entrambi collegati al tuo repository GitHub.

Il revisore di PR legge le pull request aperte. Per ognuna passa in rassegna titolo, descrizione, file modificati e commit, apre i file che contano e li confronta con le convenzioni che hai indicato: test, nomi, dimensioni, messaggi di commit, aree sensibili. Cerca rischi di errore, test mancanti, modifiche che toccano autenticazione, pagamento o segreti e modifiche che nulla spiega. Lascia un solo commento per pull request: una riga che riassume la modifica, ciò che va bene, poi i punti da verificare in ordine di importanza, ciascuno legato a un file e, quando possibile, a una riga, e indicato come bloccante o come suggerimento. Chiude con ciò che non ha potuto verificare, per esempio l'esecuzione dei test. Ricorda l'ultimo commit letto e commenta di nuovo solo quando arrivano nuovi commit, con un breve aggiornamento.

Lo smistatore di issue si occupa delle nuove issue. Verifica che esistano le etichette di tipo (bug, funzionalità, domanda, documentazione) e di priorità (alta, media, bassa) e crea quelle mancanti. Per ogni issue senza etichetta legge il testo e i commenti, cerca issue simili, decide un tipo e una priorità secondo le tue regole, applica le etichette e aggiunge un commento: ciò che ha capito, il motivo della priorità, i probabili duplicati e ciò che manca per agire, per esempio i passaggi per riprodurre o la versione interessata. Quando tipo o gravità non sono chiari, lo dice, sceglie la priorità più bassa e pone la domanda.

Ogni passaggio termina con un riepilogo in chat che parte da ciò che richiede presto una persona.

Cosa non fanno gli agenti

I limiti fanno parte del progetto. Nessun agente fa merge, approva, richiede formalmente modifiche, chiude una pull request, fa push di codice o crea un branch. Non dispongono di questi strumenti: non è una promessa fatta in un'istruzione, è una capacità che manca. Lo smistatore non chiude, non riapre, non blocca e non elimina alcuna issue e non cambia né titolo, né assegnatario, né milestone.

Gli agenti non tirano a indovinare. Il revisore cita il file e la riga, segnala ciò che non ha potuto verificare e non inventa alcuna funzione né alcun risultato di test. Se incontra un segreto o un token nel commit, dice dove sembra trovarsi, senza copiarlo. Lo smistatore cita come duplicati solo issue che ha davvero trovato con la ricerca. E la decisione resta umana a ogni passo, che è il principio di una progettazione con validazione umana.

Come configurarlo in Atako

Dalla pagina di questo caso d'uso, il deploy si fa in quattro passi.

1. Collega GitHub. Crea un token a permessi granulari limitato al repository, con accesso in lettura al codice e in lettura e scrittura a issue e pull request. La connessione viene verificata prima di creare qualsiasi cosa.
2. Indica il tuo contesto. Fornisci il repository nella forma proprietario/nome, le tue convenzioni di revisione se ne hai e ciò che per te rende urgente una issue. Senza, gli agenti si basano sulle buone pratiche generali e sulla gravità dei bug.
3. Distribuisci. Una sola azione crea i due agenti e il progetto «Team di sviluppo». Gli agenti vengono predisposti e ricevono da soli le prime istruzioni.
4. Primi risultati, poi un ritmo regolare. Il revisore commenta le cinque pull request più recenti, lo smistatore etichetta le dieci ultime issue senza etichetta e ciascuno riassume il proprio passaggio in chat. Poi il revisore programma da sé i propri passaggi alle 9:00 e alle 14:00 nei giorni lavorativi, e lo smistatore il suo alle 9:30.

Se non hai ancora un account, crearlo avvia la tua prova e lo scenario viene configurato subito dopo. Se il tuo amministratore non ti ha consentito di creare agenti, il deploy te lo dice e si ferma lì.

Dove vedere i risultati

I commenti di revisione si leggono su GitHub, su ogni pull request, e le etichette e i commenti di smistamento su ogni issue. Il riepilogo di ogni passaggio si legge nella chat di ciascun agente. Nel progetto Atako «Team di sviluppo» trovi la pagina di funzionamento e il monitoraggio del lavoro, e nel floor di Atako i due agenti compaiono con la loro attività corrente.

Per regolare il comportamento, scrivi all'agente nella sua chat, per esempio «aggiungi alle tue convenzioni che ogni migrazione del database deve indicare il piano di rollback». Conserva l'istruzione nella sua memoria per i passaggi successivi.

Salvaguardie

L'accesso è volutamente ristretto. La connessione a GitHub è concessa agli agenti con un elenco limitato di dodici strumenti: leggere pull request, file e commit, leggere e aggiornare issue, gestire etichette, aggiungere commenti. Un agente che vede un elenco breve di strumenti li usa in modo più affidabile di uno perso in un catalogo di centinaia e, soprattutto, ciò che non è concesso non può accadere, anche se un testo tenta di forzarlo. Gli agenti trattano titoli, descrizioni, commenti e codice come dati da analizzare, mai come istruzioni.

Il token che crei è la tua prima salvaguardia: limitato a un repository e a diritti precisi, circoscrive il danno possibile qualunque cosa accada. È conservato cifrato e puoi revocarlo lato GitHub o rimuovere l'accesso degli agenti in qualsiasi momento.

La validazione umana sta nei punti di decisione. Tu leggi i commenti di revisione, decidi cosa correggere, approvi e fai il merge di persona e chiudi, assegni e pianifichi le issue.

Cosa aspettarsi

Aspettati commenti utili soprattutto su pull request di dimensioni ragionevoli: davanti a una modifica molto grande, il revisore lo dirà e si concentrerà sui file più sensibili, invece di fingere di aver letto tutto. Non può eseguire i tuoi test e lo dice in ogni commento. Lo smistatore è preciso quanto lo sono le tue regole di priorità; senza, sceglie la prudenza e pone domande. Il valore viene dalla regolarità: ogni pull request riceve una prima lettura entro mezza giornata, ogni issue arriva qualificata e i tuoi revisori umani dedicano il tempo al giudizio e non all'individuazione.