Come facciamo a tenere il passo con le revisioni delle PR nell'era dell'AI?

1. Limita ogni PR a una sola cosa

Il modo più veloce per uccidere il ritmo della revisione è una PR che fa tre cose insieme. I reviewer non dovrebbero dover districare mentalmente quali modifiche appartengono al bug fix e quali al refactor infilato di nascosto.

• Un bug fix, un campo, una funzionalità, non tutte e tre nella stessa PR.

• Una PR mirata di circa 1.000 righe che risolve un problema chiaro va bene. Una PR di 300 righe con tre questioni no. Se superi di molto le 1.000 righe, è un forte segnale che va divisa.

• Usa PR impilate per le modifiche più grandi.

• Fai un controllo rapido prima di aprire: qualcuno può rivederla tutta in una sola seduta? Fa esattamente una cosa? La mergereesti?

2. Non chiedere la revisione finché non è davvero pronta

Le bozze esistono per un motivo. Togliere una PR dalla bozza è un segnale al team che hai fatto le verifiche dovute e che vale il tempo di qualcun altro. Se quel segnale non è affidabile, l'intero sistema di revisione si rompe.

Toglila dalla bozza solo se puoi rispondere sì a tutto questo:

• Hai fatto una self-review

• Tutti i test passano, inclusi gli e2e

• Zero commenti irrisolti (compresi quelli di Devin)

• L'hai testata localmente per modifiche di UI/UX

• Per le modifiche che possono essere coperte da test automatizzati, hai verificato che la copertura sia al 100%

• Tutti i job CI sono verdi (a parte le fastidiose preview di Vercel)

Se anche solo uno è no, lasciala come bozza. Le bozze che chiedono revisione inquinano la coda e ritardano le PR che sono davvero pronte.

3. Limita a 5 le tue PR aperte (le bozze contano)

Le PR aperte sono inventario. Portano con sé costo di cambio contesto, rischio di conflitti di merge e debito di revisione. Se ne hai più di cinque aperte contemporaneamente, i conti non tornano. Stai producendo più velocemente di quanto il team possa assorbire.

Se hai 5 PR aperte, tra bozze e non bozze, non iniziare nulla di nuovo. Vai invece a rivedere le PR dei tuoi compagni di team oppure porta avanti il lavoro più vecchio.

4. Metti una voce umana nella descrizione della tua PR

La descrizione non deve essere scritta interamente da te. L'AI va bene per creare una struttura e riassumere il diff. Il problema che vediamo ora sono le descrizioni massicce generate dall'AI che sembrano una checklist generica con cui nessuno ha davvero interagito. Manca l'elemento umano di cui un reviewer ha davvero bisogno.

• Una nota dell'autore in una frase sul compromesso che hai scelto, o sul perché questa correzione conta adesso, vale più di un lungo blocco "Key Review Points" / "Human Review Checklist".

• Se stai distribuendo codice che non viene ancora usato da nessuna parte, dillo.

• Se l'AI ha scritto la descrizione, tagliala e aggiungi il contesto che solo tu hai.

5. Dimostra che la correzione funziona

Una PR che dice "risolve il bug X" senza prove chiede al reviewer di fidarsi sulla parola. Non farglielo fare.

• Screenshot, registrazioni dello schermo, dashboard prima/dopo, qualsiasi cosa mostri che il bug è sparito e che non c'è nessuna regressione altrove.

• La QA funzionale è obbligatoria per le modifiche UX/UI, non facoltativa.

6. Le modifiche SQL e di performance richiedono una vera validazione

La code review da sola non può confermare che una riscrittura di query regga sotto il carico di produzione. Leggere un diff di una query e dire "sembra giusto" non è validazione. Per le PR che toccano i percorsi delle query o le riscritture:

• EXPLAIN ANALYZE su un dataset simile a quello di produzione

• Numeri di latenza prima/dopo o screenshot delle dashboard

• Rollout con feature flag per le modifiche rischiose

7. L'AI è un acceleratore, non un cervello

L'AI può generare codice velocemente. Non può decidere se quel codice debba esistere. Il ragionamento deve comunque venire da te.

• Prima il design. Abbozza l'approccio, valuta i casi limite, scrivi una nota veloce, poi fai il prompt.

• Dopo che l'agente ha generato, leggilo davvero. La self-review intercetta chiamate Prisma nel posto sbagliato, linee guida dell'agente ignorate, struttura fragile, ecc.

• Prima di aprire, chiediti: cosa tocca? C'è impatto sugli utenti? Implicazioni di performance o sicurezza? Qual è il raggio d'impatto se è sbagliato?

8. Valida le PR di sicurezza prima di aprirle

Conferma che la vulnerabilità si applichi davvero al modo in cui usiamo il codice. Le PR "fix vulnerability X" che toccano percorsi sensibili possono introdurre più rischio del report originale.

9. Inoltra le PR al reviewer giusto

Il reviewer sbagliato spreca il tempo di due persone: quello del reviewer che non può dare un feedback utile e quello dell'autore che deve aspettare un secondo giro con la persona giusta.

• Le PR molto legate a un dominio specifico (routing di Salesforce/CRM, migrazioni dei profili team, ecc.) vanno al responsabile di quel dominio, non a Foundation che mette un timbro su una suite di test generata dall'AI.

• Le modifiche ai percorsi core/foundation (query infra, hasTeamAccess, ecc.) meritano un rapido allineamento con il team proprietario prima di aprire la PR.

10. Le conversazioni sull'architettura accadono presto

Rattoppare la stessa area tre volte è un segnale, non una coincidenza. Se stai aggirando di nuovo lo stesso limite, la mossa giusta è una conversazione e un'eventuale riscrittura, non un altro patch.

Parla con Foundation/Head of Engineering prima di implementare. È così che si sono formati i moduli infra, e la coerenza si moltiplica.

11. Percorso più leggero per le correzioni banali

Non tutto ha bisogno della revisione di Foundation. Dovremmo spendere banda di revisione dove conta di più.

Le piccole modifiche al toast, il dimensionamento dei pulsanti, le ridenominazioni meccaniche, i cambi di copy, le funzionalità della mainline - queste possono passare attraverso la revisione AI e/o le revisioni a livello di team. Riserva la revisione di Foundation alle modifiche che ne hanno davvero bisogno.

12. Non aprire PR per conto di altri

Se l'Engineer X sta facendo il lavoro, è l'Engineer X ad aprire la PR. Altrimenti i commenti finiscono alla persona sbagliata, le domande restano senza risposta e la PR si blocca.