Quando l'IA deve filmare la propria revisione

Quando viene aperta una pull request, la mia o quella di un collega che mi hanno chiesto di revisionare, queste sono le righe che incollo all'agente:

Ora revisioniamo questa: [aggiungi il link GitHub della PR]

Però voglio che tu la esegua in locale E2E e veda se va tutto bene, e che ne faccia delle registrazioni con Playwright. Voglio anche che tu la attacchi, che provi a romperla E che la testi a fondo [aggiungi qui altro contesto se serve, per esempio sia nello scope personale sia in quello dell'organizzazione].

Poi lo lascio lavorare: esegue la modifica sulla mia macchina, da un capo all'altro, mentre Playwright registra il browser man mano che procede. Playwright è una libreria di automazione del browser che l'agente può pilotare, e sa filmare le pagine che apre. Quello che torna indietro è un resoconto scritto, con accanto le registrazioni e gli screenshot dei momenti a cui rimanda.

Molte cose sono cambiate da quando a luglio ho scritto di revisionare a colpo d'occhio il codice dell'IA, compreso il modo in cui revisiono le pull request. Ultimamente questo modo di revisionare mi ha colpito, e credo che la maggior parte degli sviluppatori resterebbe sorpresa da quanto sia migliorato.

Cosa dicevo a luglio, e cosa è cambiato

Allora sostenevo che, quando l'agente esegue il codice al posto tuo, la revisione non sparisce. Si sposta sulla prova, e il rimedio che proponevo era aprire tu stesso i log e trovarci quello che l'agente diceva ci fosse.

Quel rimedio funziona ancora, ma la maggior parte delle volte non mi serve più. A luglio dicevo anche che la revisione lenta consiste nell'eseguire la modifica, tracciarla e provare a romperla, e nel far mostrare all'agente il suo lavoro. La novità è un modo per chiedere tutto questo in un solo messaggio e riavere il lavoro in una forma che posso controllare senza rifarlo. L'esecuzione la fa l'agente, e le registrazioni mi mostrano cosa è successo sullo schermo.

I modelli tendono alla risposta più rapida. Se gli chiedi se una modifica funziona, preferiscono dire di sì piuttosto che andare a verificarlo, e a volte ne ho visto uno descrivere log che non esistevano. Una risposta che suona conclusa è la strada più breve per arrivare alla fine del turno.

Non è solo una mia esperienza. La system card che Anthropic ha pubblicato per Claude Opus 4.8 elenca degli errori emersi dall'uso interno dell'azienda stessa, e uno di questi rientra quasi esattamente nel mio scenario. Il modello sosteneva di tenere d'occhio le pull request di un ricercatore, e non era vero. Nella stessa lista compare anche un caso in cui affermava di aver eseguito una verifica che non aveva fatto.

Dire a un modello di stare più attento è una richiesta, e una richiesta è proprio ciò che salta quando ha fretta. Una registrazione cambia ciò che il modello deve consegnare.

Perché una registrazione è più difficile da falsificare

Una frase su ciò che è successo si può scrivere senza che succeda niente. Una registrazione ha bisogno che qualcosa sia stato eseguito davvero, e tutto ciò che è stato eseguito è lì sullo schermo, perché io lo giudichi.

Quando l'agente deve filmarsi mentre esegue la modifica, il modo più economico di soddisfare la richiesta è farlo davvero. Per tutto ciò che finisce in video, non c'è più spazio perché un paragrafo sicuro di sé prenda il posto del lavoro. Da solo, un resoconto è l'unica versione dei fatti, e non riesco a distinguere un test da una frase su un test se non rifacendolo io stesso. La registrazione separa la frase dall'evento. Se l'agente dice di aver testato il form vuoto, il form vuoto o è nel video o non c'è. Tutto ciò che il resoconto dice e che non è mai arrivato davanti alla telecamera torna a essere un'affermazione.

Il filmato mostra cosa ha provato l'agente, e ciò che lascia fuori segna ciò di cui non ho prove: la schermata che non ha mai aperto, il form che non ha mai inviato con input non validi, il secondo account in cui non è mai entrato.

C'è un secondo effetto, e conta altrettanto. Davanti alla telecamera, fingere che un problema non ci sia stato, o inventarne uno, smette di essere una scorciatoia sicura per l'agente, perché il video è lì per essere controllato. Così, quando ne trova uno, me lo segnala invece di seppellirlo nel riassunto.

Perché tutto questo funzioni, raramente devo guardare un video intero. Gran parte dell'effetto si produce prima che io apra qualsiasi cosa, perché è la richiesta del filmato a far sì che l'agente esegua la modifica. Quello che guardo, invece, sono gli screenshot dei momenti che contano, e tra questi ci sono anche i successi. Mi piace vedere il flusso arrivare in fondo come deve, in ciascuno degli scope che ho indicato, tanto quanto l'errore sullo schermo o una pagina che si è aperta per un account che non avrebbe mai dovuto arrivarci. Il video resta lì dietro, per quando uno screenshot fa sorgere una domanda.

Il resoconto diventa un indice delle prove, e per un riassunto è un compito migliore che fare le veci delle prove. Continuo a chiedermi "è vero?", ma ora a rispondere è uno screenshot, o nel peggiore dei casi un breve spezzone di video, e una parte più grande del mio tempo va a "ha importanza?".

Quando conta cosa ha risposto il server, vale la pena chiedere, insieme al video, anche il trace di Playwright. Il video sono i pixel. Un trace conserva, per ogni azione, un'istantanea della pagina prima e dopo, con le richieste di rete, il corpo delle risposte e la console del browser. Se l'agente dice che il server ha risposto con un 403, nel trace c'è la risposta.

Il Playwright MCP di Microsoft, uno degli strumenti che permettono a un agente di pilotare un browser, lavora sull'albero di accessibilità della pagina, una sua rappresentazione testuale strutturata, invece che sui pixel. Il filmato è per me, ed è per questo che è utile: l'agente agisce su una vista testuale della pagina, e il filmato mi mostra i pixel che lui non guardava, senza nessun suo commento sovrapposto. L'agente può comunque scegliere quale ripresa consegnarmi, o continuare a eseguire un flusso finché non diventa verde, quindi vale la pena chiedere ogni registrazione che ha fatto, comprese le riprese fallite.

Attaccala, e testala

Il prompt chiede due cose che tirano in direzioni diverse, di proposito.

Un modello a cui chiedi una conferma tende a confermare. Quel "veda se va tutto bene" lo invita a cercare le cose che vanno bene, quindi percorre la strada per cui la funzionalità è stata costruita, vede la schermata prevista e riferisce che è andato tutto bene. Vale la pena avere quell'esecuzione in video, perché un esito positivo senza prove alle spalle è esattamente l'affermazione da cui mettevo in guardia a luglio. Ma copre solo il caso che l'autore aveva già in mente.

Chiedigli di romperla e dovrà andare a cercare altrove: un campo obbligatorio lasciato vuoto, il pulsante di invio cliccato due volte, la stessa pagina aperta in due schede, l'ID nella barra degli indirizzi sostituito con uno che appartiene a qualcun altro, il tasto indietro premuto a metà di un flusso. È in posti come questi che i bug tendono a nascondersi.

Un agente a cui dici solo di rompere le cose ha il problema opposto. Può passare l'intera sessione su un unico caso limite ingegnoso e non confermare mai che il flusso normale, quello da cui passa ogni utente, funzioni ancora da un capo all'altro. Voglio, nella stessa esecuzione, sia la visita guidata del flusso normale sia l'assalto al flusso stesso, ed è per questo che la E è maiuscola.

Le due istruzioni, poi, funzionano meglio in video che in un resoconto scritto. Una frase come "ho provato a romperla e non ci sono riuscito" non mi dice nulla su quanto ci abbia provato, mentre la registrazione dei tentativi mi dice molto. Vedo se ha messo sotto pressione il form una volta e poi è passato oltre, o se ci è tornato con un altro account o con un altro ordine dei passaggi. Gli attacchi falliti fanno parte delle prove che la modifica regge.

La riga che solo io posso scrivere

L'ultima parte del prompt è un segnaposto che cambia a ogni pull request. È lì che dico all'agente dove sta il rischio.

Il mio esempio è "sia nello scope personale sia in quello dell'organizzazione". Quando una funzionalità deve comportarsi correttamente sia in un account personale sia dentro un'organizzazione, la maggior parte di ciò che può andare storto sta al confine tra i due: qualcosa che appartiene a uno scope e compare nell'altro, o una pagina che funziona per il proprietario e fallisce per un membro. L'agente può leggere il diff e provare a indovinarlo. Non sa quali percorsi seguano davvero gli utenti, né quale errore sarebbe imbarazzante e quale grave. Io sì, perché conosco il prodotto e so cosa voglio che faccia.

Quella parentesi quadra è la mia parte della revisione. Sposta l'agente da ciò che suggerisce il diff a ciò che so che si può danneggiare, e la registrazione mi mostra se ci è andato davvero.

Ciò che il filmato non mostra

Il filmato ha i suoi confini.

È l'agente a scegliere cosa filmare: i percorsi che segue e, a seconda degli strumenti, quando la registrazione parte e si ferma. Se lo scope dell'organizzazione che avevo chiesto non è nella registrazione, non ho prove che sia stato testato, qualunque cosa dica il resoconto.

Tutto ciò che Playwright registra succede nel browser. I log del server, le righe nel database e il job in background che parte un minuto dopo non sono né nel video né nel trace. Una schermata può diventare tutta verde mentre, sotto, una riga viene scritta sull'account sbagliato. Un controllo di autorizzazione può mancare sul server mentre l'interfaccia nasconde il pulsante alla perfezione in video, e l'API dietro accetterebbe comunque la richiesta da chiunque la inviasse direttamente.

È qui che la metà del prompt dedicata all'attacco si ripaga. Un filmato del caso positivo non tocca mai quel controllo, mentre lo tocca un filmato dell'agente che apre un record appartenente a un altro account, o che invia la richiesta con il pulsante nascosto. Per tutto ciò che riguarda gli accessi, vale la pena nominare quell'attacco nella riga di contesto. Quando la modifica arriva al database o al server, le query e i log della stessa esecuzione vanno messi accanto alla registrazione, salvati dove il resoconto possa indicarli.

Una registrazione può anche sembrare giusta per il motivo sbagliato. Se l'agente ha sostituito il backend con uno stub per far caricare la pagina, la registrazione è la registrazione dello stub. Il prompt chiede un'esecuzione in locale ed end to end, e conta sapere con che cosa stesse davvero parlando l'app, prima ancora di qualunque cosa abbia mostrato. A questo rispondono le richieste di rete nel trace.

Una nota pratica: un video di Playwright viene scritto su disco solo quando il contesto del browser si chiude. Se l'agente dice di aver registrato l'esecuzione e il file manca o è vuoto, anche quella è una prova.

Dentro questi confini, il filmato è la revisione lenta di luglio, con l'agente che si occupa di eseguire e il giudizio lasciato a me.

L'ultima parola resta mia

I modelli sono migliorati molto da quando ho scritto il pezzo di luglio, e la mia prova sono le mie stesse revisioni. Quello che noto è che quando l'agente deve eseguire la cosa e filmarla, e qualcosa si rompe, lo dice, e io posso vederlo con i miei occhi. Anche sul miglioramento, non gli credo sulla parola.

Gli sviluppatori che hanno conosciuto la revisione fatta dall'IA solo come un bot che lascia commenti su un diff ne hanno visto la versione più piccola. Questo somiglia di più a un tester seduto al mio computer che prenderebbe delle scorciatoie se glielo lasciassi fare: usa la modifica come farebbe un utente, prova a romperla e lascia la registrazione perché io possa vedere quali scorciatoie ha preso.

Leggere il codice conta ancora, e la registrazione copre ciò a cui la lettura non arriva, il comportamento della cosa quando gira. Non è gratis. Un'esecuzione richiede più tempo di una lettura, l'app ha bisogno di dati su cui valga la pena fare i test, e qualcuno deve comunque guardare cosa torna indietro.

Niente di tutto questo fa dell'agente il revisore. Fa il lavoro materiale. Alla fine sono ancora io a decidere cosa è giusto e cosa voglio. Quando la registrazione mostra un flusso che funziona ma non è quello che il prodotto dovrebbe fare, l'agente non può saperlo, e quando segnala come bug un comportamento voluto, sono io a dire che non lo è.

Il pezzo di luglio si chiudeva sulla linea tra il diff che hai capito e il diff che hai soltanto visto. Le registrazioni rendono meno costoso passare dalla parte del diff capito. Non ho bisogno di guardare ogni esecuzione dall'inizio alla fine, mi basta vedere i momenti che contano e sapere quali percorsi copre la registrazione. Quello che è cambiato è che ora faccio filmare alla macchina il suo lavoro, così la mia attenzione va meno a se ha fatto quello che diceva e più a se ha guardato nei posti giusti. Posso giudicarlo solo perché so a cosa serve il prodotto, e quando guarda nei posti sbagliati, mando una riga di contesto in più e lo faccio ripartire.