Mainlane è un ingegnere con un team di agenti IA. Viene spontanea una domanda: chi controlla il codice scritto da un’IA? La nostra risposta è un’altra IA — una che non l’ha scritto — seguita da una persona che decide se rilasciarlo.
Il ciclo
- Una sessione di Claude prende un’attività e apre una pull request.
- Un revisore separato parte da una sessione pulita. Non ha mai visto come è stato scritto il codice, quindi legge il diff come farebbe un collega: senza i presupposti dell’autore.
- Il revisore lascia osservazioni su tre livelli: 🔴 da correggere, 🟡 meglio correggere, 🟢 sarebbe utile.
- La sessione autrice le corregge e risponde punto per punto, chiudendo con una sezione «Verifica»: i comandi eseguiti e il loro output.
- Il revisore controlla il nuovo head. Il ciclo si ripete finché non resta nessuna osservazione, nemmeno 🟢.
Due regole lo mantengono onesto. Un’osservazione si può contestare solo con una misura — un numero, l’output di un comando, un mutante che un test non intercetta — e non con un «va bene così». E dopo cinque giri il ciclo si ferma e chiede a una persona, così non gira mai all’infinito.
La parte umana
Nessun agente fa il merge. Quando la revisione è pulita e la CI è verde esattamente sul commit visto dal revisore, la sessione scrive «pronto per il merge» e aspetta. Il merge avviene solo dopo il via libera di una persona, e solo per quello stesso commit.
Cosa intercetta
Alcuni esempi reali dal repository di questo sito:
- Nella pull request che aggiungeva i controlli Lighthouse alla CI, il revisore ha notato che un’impostazione della build CSS puntava alla cartella sbagliata, così gli stili di layout sparivano silenziosamente dal sito. Né Lighthouse né il controllo di accessibilità lo avevano segnalato. Ha anche individuato un banner della lingua fisso che poteva coprire l’elemento con il focus per chi naviga da tastiera.
- Nel controllo di ripristino dei backup del database, il test giornaliero confrontava i dati ripristinati con sé stessi invece che con l’export: non si sarebbe mai accorto di righe mancanti. La stessa revisione ha trovato un messaggio di errore che poteva scrivere nei log l’email di un lead.
- Nell’introduzione della Content Security Policy, le segnalazioni delle estensioni del browser avrebbero impedito di raggiungere l’obiettivo «una settimana senza violazioni», e le immagini esterne nei post del blog si sarebbero rotte una volta applicata la policy.
Niente di esotico. Era il genere di cose che una persona stanca si lascia sfuggire il venerdì sera.
In numeri
A fine ottobre 2026 il ciclo gira su otto repository, con 385 pull request unite e 1.069 revisioni. Gran parte del costo è il lavoro stesso: nell’ultima settimana di ottobre circa tre quarti dei token vanno all’implementazione e meno di un decimo alla revisione.
Limiti
Il revisore è lo stesso tipo di modello dell’autore, quindi può condividerne i punti ciechi. Non sostituisce la revisione umana delle modifiche importanti, e il testo di una pull request viene trattato come dato, mai come istruzione. Ciò che sostituisce è il passaggio che quasi tutti gli sviluppatori che lavorano da soli saltano: un secondo paio d’occhi su ogni singola modifica.
Se vuole lo stesso processo nel Suo team, è uno dei nostri servizi: ci contatti.