Rivedere quello che ha fatto
Chi ha fatto il lavoro non è la persona giusta per giudicarlo. Vale per il codice, vale per un report, vale per una proposta commerciale. Qui vale in modo particolarmente concreto.
Alla fine di questo capitolo
- Sapete perché un resoconto veritiero può non bastare
- Sapete cosa cercare guardando le modifiche vere
- Sapete come chiedere un secondo parere e cosa farne dei rilievi
Il problema, in una frase
Quando Claude finisce un lavoro vi consegna un resoconto conciso: cosa ha fatto e dove. Sotto ci sono i file toccati, dalle modifiche minime a quelle importanti. Il resoconto di solito è vero. Ed è esattamente per questo che è pericoloso.
L'esercizio che vale tutto il capitolo
La lezione propone un caso semplice: aggiungere la validazione a un modulo di iscrizione. Formato dell'indirizzo, password di almeno otto caratteri, messaggi di errore sotto ogni campo.
Il resoconto di Claude
Aggiunta la validazione degli input al modulo di iscrizione.
- Formato email e lunghezza password controllati prima dell'invio
- I messaggi di errore compaiono sotto ciascun campo
- Tutti i test passano
Otto file modificati. Ogni riga del resoconto è vera. E dentro quegli otto file ci sono comunque tre cose che meritano un secondo sguardo: un file di test che perde otto righe, un file di configurazione toccato senza che nessuno l'avesse chiesto, e una dipendenza nuova comparsa per una funzione sola.
Il punto dell'esercizio è tutto qui: un riassunto può essere interamente vero e nascondere lo stesso i problemi. Non perché qualcuno vi stia ingannando, ma perché un riassunto racconta quello che è stato fatto, non quello che è stato toccato per strada.
Guardare la modifica, non il racconto
Il comando /diff apre il confronto fra prima e dopo, file per file: le righe tolte e le righe aggiunte. Si naviga con le frecce, si entra in un file con Invio, e si può vedere anche cosa ha cambiato ogni singolo passaggio.
Modifiche non richieste
Un valore di configurazione cambiato di passaggio, un metodo riscritto senza che ne aveste parlato.
Test indeboliti
Test disattivati, cancellati, o allentati quel tanto che basta per farli passare. È il segnale più serio.
Pacchetti e valori a mano
Una dipendenza aggiunta per una funzione sola, un indirizzo o una chiave scritti direttamente nel codice.
Se è tutto da buttare
Il comando /rewind, o due volte Esc su una richiesta vuota, permette di tornare al punto prima di quel lavoro, ripristinando codice e conversazione. Un limite da conoscere: i file modificati dai comandi eseguiti da Claude non tornano indietro. Se ha installato un pacchetto, quel pacchetto resta installato.
Chiedere un secondo parere
Una sessione lunga contiene tutto quello che è stato letto e deciso strada facendo. È proprio la cronologia che non volete addosso a chi deve rivedere: sa già perché ogni scelta sembrava sensata.
Il comando /code-review è quel secondo revisore. Guarda le modifiche in un contesto pulito e riferisce quello che trova. Non cambia niente finché non glielo chiedete voi. Gira in sottofondo, da pochi secondi a qualche minuto, e conta come qualsiasi altro lavoro: si tiene per le modifiche che lo meritano.
Che farsene di ogni rilievo
Ogni cosa segnalata finisce in una di tre caselle. La più interessante è quella di mezzo, perché è la sola che tiene aperta la possibilità che il revisore si sbagli.
Come si contesta un rilievo
Non si ignora e non si accetta: si cita il fatto e si chiede di ricontrollare. Anche un revisore che legge senza contesto può prendere un abbaglio.
Due richieste che conviene tenere pronte
Hai segnalato che la funzione non ripulisce gli spazi,
ma alla riga 4 c'è già la chiamata che li toglie.
Ricontrolla e dimmi se la tua conclusione regge.Correggi il primo problema: non disattivare il test
e rimetti il controllo originale.
Poi esegui i test e mostrami l'esito.
La seconda contiene la regola più importante di tutte: ogni volta che chiedete una correzione, chiedete anche la prova. Se la correzione si allarga fino a diventare una modifica sostanziale, si rifà la revisione da capo.
Quanto verificare, e quando
Una modifica di una riga si guarda e via. Servono sia il vostro occhio sia una revisione quando ricorre una di queste tre condizioni, e sono trasferibili di peso fuori dal codice.
Le tre soglie
- La modifica è troppo grande per tenerla tutta in testa
- Tocca qualcosa di delicato, o ha un effetto che non si annulla
- State per passare il lavoro a qualcun altro
Quando lo stesso rilievo torna sempre
Se una revisione dopo l'altra segnala la stessa cosa, il problema non è quella modifica: è che manca una regola scritta. Va messa dove Claude la legge all'inizio di ogni sessione, ed è il capitolo che comincia adesso.
Vuoi portarlo dentro la tua azienda?
Leggere una guida e cambiare il modo in cui si lavora sono due cose diverse. Negli Ethos Lab AI si parte dai vostri processi e si finisce con qualcosa che funziona il lunedì dopo.