Review delle pull request con l'IA: qualità del codice e crescita di chi si forma.
Una pull request confusa costringe a iterare più volte prima di essere approvata, e con i coding agent il codice da rivedere aumenta. Una review fatta con l'IA può aiutare a controllare la qualità e a seguire chi è in formazione: deve però restare uno strumento di supporto, non un giudice.
Vale anche per chi lavora senza IA: tenere traccia delle pull request e di come evolvono, giro dopo giro e nel tempo, serve comunque. I coding agent rendono il bisogno più evidente, non lo creano.
Da dove nasce, e cosa non ho ancora fatto
Il problema delle pull request confuse è emerso spesso nei confronti con colleghi, in occasioni diverse.
Il metodo che descrivo nasce da lì e dalla mia esperienza di senior e team lead, che da sempre comprende formare e seguire i profili junior.
Non l'ho ancora applicato in un progetto. Per metterlo davvero alla prova serve un team reale: più sviluppatori, compiti di complessità diversa, un periodo abbastanza lungo da vedere un andamento. Fa parte di una harness condivisa dal team, che, come scrivo in Qualità e coding agent, non ho ancora costruito. Quello che segue è quindi una proposta di metodo.
Due obiettivi
- Garantire la qualità del codice che arriva nel prodotto.
- Seguire adeguatamente chi è in formazione, e capire se sta crescendo davvero, anche quando il codice lo scrive con l'aiuto dell'IA.
La qualità del codice: una soglia uguale per tutti
La soglia per approvare una pull request sarebbe la stessa per chiunque: sicurezza, correttezza e regole importanti del progetto bloccano l'approvazione indipendentemente da chi ha scritto il codice. L'IA farebbe una prima review sulle linee guida del team; l'ultima parola resterebbe a una persona.
Autore e revisore andrebbero tenuti separati: chi rivede il codice non deve essere la stessa sessione che l'ha scritto. La review è tanto buona quanto sono chiare le regole scritte del progetto.
Seguire chi si forma: cambia il percorso, non la soglia
Cambia invece il modo di arrivare all'approvazione. A un junior i commenti spiegano il perché e rimandano alla regola, e i problemi minori, come nomi o stile, sono segnalati ma non bloccano; a un senior bastano commenti brevi. Per ogni problema bloccante, chi ha scritto il codice spiega in poche righe cosa ha cambiato e perché; se non è d'accordo con un commento può contestarlo, e una contestazione motivata è un buon segno.
Dentro una singola pull request fisserei un limite di giri: superato quello, è meglio sedersi con un senior che continuare a iterare.
Il rischio da evitare è uno sviluppatore che passa la review senza capire. Uno studio controllato di Anthropic su 52 sviluppatori, quasi tutti junior, ha trovato risultati più bassi nel test di comprensione per chi imparava una libreria nuova con l'assistente (50% contro 67%), senza un guadagno di tempo significativo. Chi usava l'IA per farsi spiegare i concetti otteneva risultati simili a chi lavorava senza. Lo studio è piccolo e preliminare, ma indica cosa guardare: non se lo sviluppatore usa l'IA, ma come la usa.
Quando un affiancamento è normale e quando è un segnale
Con il passare delle pull request, o dei mesi, ci si aspetta che chi entra in un progetto arrivi all'approvazione più rapidamente. All'inizio può essere normale che serva l'affiancamento di un senior: dipende dal progetto, da quanto è complesso e da quanto è documentato. Se dopo cinque o sei pull request la situazione si ripete ancora, c'è qualcosa da capire. Le cifre sono indicative.
Non è detto che il problema sia la persona: possono pesare i compiti assegnati, una parte del codice poco documentata o una regola poco chiara.
Perché raccogliere i dati delle review
Con più sviluppatori in inserimento è difficile seguire a memoria il percorso di ciascuno. Un registro delle review, con i problemi segnalati, l'area del programma e i giri necessari, mostra se gli stessi errori tornano o scompaiono, e in quanto tempo si arriva all'autonomia sui diversi tipi di compito.
Letto per area del programma, lo stesso registro dice anche altro: se più junior incontrano lo stesso problema nella stessa parte del codice, il punto debole probabilmente non sono loro ma la harness, cioè la documentazione, le regole o i controlli di quella parte. È anche il modo per capire nel tempo se la harness funziona.
Gli strumenti di review in commercio raccolgono già questi dati: la documentazione di CodeRabbit, per esempio, descrive metriche filtrabili per singolo sviluppatore. La questione quindi non è se i dati esistono, ma come si usano.
Preparare il lavoro: pull request più chiare e meno spesa
Una pull request confusa nasce spesso da un compito vago. Preparare il lavoro prima di assegnarlo serve a due cose: lo sviluppatore sa cosa deve consegnare e come verificarlo, e l'agente lavora su richieste precise invece di esplorare il codice a vuoto, consumando meno. Conta sempre di più, perché molte aziende stanno mettendo limiti alla spesa per l'IA.
Chi valuta
Lo strumento non valuta le persone. Fornisce dati tecnici sulle pull request: problemi, giri, errori ricorrenti, difetti emersi dopo l'approvazione con la loro causa. Questi dati entrano nei percorsi di valutazione della crescita che l'azienda già prevede, dove il giudizio resta di una persona.
Alcune condizioni le considero necessarie:
- lo sviluppatore vede tutto ciò che vede il responsabile su di lui, e può rispondere;
- niente classifiche tra persone né punteggi complessivi;
- si raccolgono solo dati sul contenuto tecnico delle pull request, non gli orari di lavoro né le conversazioni con l'IA, e i dati esclusi vanno scritti;
- i dati si conservano per un periodo definito.
Cosa verificare prima di partire
Un sistema che segue nel tempo il lavoro dei singoli sviluppatori va verificato con un legale prima di avviarlo. Il fatto che non decida da solo non toglie gli obblighi: la normativa europea sull'IA considera ad alto rischio anche i sistemi che monitorano e valutano le prestazioni dei lavoratori. I punti da verificare sono almeno questi:
- lo Statuto dei lavoratori (art. 4);
- il GDPR;
- la legge italiana sull'IA (L. 132/2025, art. 11), che richiama gli obblighi di informazione ai lavoratori;
- l'AI Act, i cui obblighi per questi sistemi, dopo il rinvio deciso nel 2026, si applicano dal 2 dicembre 2027.
Non è una consulenza legale.
Fonti a supporto
Il metodo è una proposta ricavata da esperienza e confronti con colleghi; le fonti sostengono singoli punti, non il metodo nel suo insieme.
- Anthropic — How AI assistance impacts the formation of coding skills (si apre in una nuova scheda): studio controllato su 52 sviluppatori, gennaio 2026; campione piccolo e risultati preliminari, misurati subito dopo il compito.
- Claude Code — Manage costs effectively (si apre in una nuova scheda): le richieste vaghe fanno esplorare il codice e consumano di più; pianificare e dare obiettivi di verifica evita rilavorazioni.
- CodeRabbit — Dashboard (si apre in una nuova scheda): metriche delle review filtrabili per singolo sviluppatore; documentazione del fornitore, strumento che non ho usato.
- TechCrunch — The token bill comes due (si apre in una nuova scheda): aziende che hanno messo limiti alla spesa per l'IA, giugno 2026.
- Regolamento (UE) 2024/1689 (AI Act) (si apre in una nuova scheda): allegato III, punto 4, lettera b), sistemi per monitorare e valutare le prestazioni dei lavoratori.
- Consiglio dell'UE — approvazione definitiva delle modifiche all'AI Act (si apre in una nuova scheda): comunicato del 30 giugno 2026, nuove date per i sistemi ad alto rischio.
- Legge 23 settembre 2025, n. 132 (si apre in una nuova scheda): art. 11, uso dell'intelligenza artificiale in materia di lavoro.