Anthropic afferma che Claude Code scrive ormai circa il 90% del proprio codice e che il team sta cambiando il modo in cui lo revisiona. In un post, Addy Osmani, Morgan Westlee Lunt e Qing Wang descrivono l’obiettivo: integrare la maggior parte delle pull request con al massimo una persona coinvolta, che può anche essere l’autore della modifica, senza aumentare i rollback o gli incidenti.
Il team sostiene che i revisori non debbano avere un quadro mentale completo di Claude Code. Chiedono invece a Claude di spiegare la parte del codice che devono comprendere. Questo approccio è stato criticato in una discussione su Hacker News: alcuni commentatori si sono chiesti se affidarsi alle spiegazioni dell’IA lasci qualcuno in grado di individuare la causa di un guasto quando il modello ha capito male.
Come funzionano i livelli di revisione
Un classificatore assegna a ogni modifica un livello di rischio in base alla modifica stessa, non al suo autore. Tra quelle a basso rischio ci sono la documentazione, i testi e le aggiunte protette da un flag di funzionalità: possono essere approvate senza il via libera di una persona. Le modifiche a rischio medio, tra cui gli interventi sulla cache, sull’aggiornamento automatico e sui prompt di sistema, richiedono una persona. L’approvazione di un agente non vale come approvazione umana, ma la persona che ha richiesto una modifica può essere il revisore necessario.
Anche il processo di revisione può fallire: gli agenti intervengono su osservazioni che una persona potrebbe ignorare. Anthropic racconta di una pull request sottoposta a più di 50 cicli di revisione e correzioni nel corso della notte, prima che l’autore la fermasse. Il team afferma di aver fissato un limite al numero di cicli dopo aver scoperto che semplicemente aumentare le revisioni peggiorava le cose. Ha anche rilevato che circa il 59% del codice segnalato nei cicli successivi era già presente al primo esame del revisore.
Cosa resta incerto
Un altro esempio tratto dal repository pubblico di Claude Code mostra i limiti delle spiegazioni generate. Ad agosto, una risposta generata da Claude affermava che alcune segnalazioni erano state chiuse per inattività perché mancavano le informazioni necessarie a riprodurre il problema. Le regole del repository, però, consentono di chiudere le segnalazioni dopo 14 giorni con stato “stale” e altri 14 giorni, con un’eccezione per quelle che hanno almeno 10 voti positivi. Uno sviluppatore ha contato più di 6.000 segnalazioni etichettate come contenenti passaggi per riprodurre il problema che risultavano comunque chiuse come inattive. Anche il suggerimento della risposta di lasciare un commento per riaprire una segnalazione si è scontrato con un flusso di lavoro che blocca le segnalazioni chiuse dopo sette giorni.
Anthropic afferma di non avere ancora interruttori di emergenza che rendano più stringenti i requisiti di approvazione se le metriche delle revisioni peggiorano. Il prodotto Code Review è generalmente disponibile nei piani Team ed Enterprise. L’azione GitHub per la revisione della sicurezza è open source, ma il suo README avverte che non è protetta dagli attacchi di prompt injection e dovrebbe essere usata solo per revisionare pull request attendibili.
Perché conta
Per i team che valutano la revisione del codice guidata dall’IA, il processo di Anthropic mostra che le modifiche a basso rischio possono essere integrate senza approvazione umana, mentre quelle a rischio medio richiedono ancora l’intervento di una persona. L’azienda afferma di non aver introdotto interruttori di emergenza per rendere più stringenti le approvazioni quando le metriche di revisione peggiorano: il post, quindi, non chiarisce come reagirebbe il processo se le sue protezioni iniziassero a non funzionare.
