Capire il lavoro05 / 20
Verificare le prove
In questa pagina
Che un Agent dica “implementato” non basta. Ogni spiegazione arriva con le sue prove: il codice letto, i test eseguiti, le registrazioni delle esecuzioni e gli screenshot, a un clic da te per verificarli. Quando qualcuno chiede, puoi indicare il punto esatto.
Che cosa contengono le prove
Apri “Evidence” nella nota. I tipi di materiale più comuni sono:
| Materiale | Mostrato come | Quando lo clicchi |
|---|---|---|
| Un riferimento al codice | Un nome di funzione, o un chip “file:riga” | Il pannello del codice si apre a destra su quelle righe |
| L’output di un comando, per esempio un’esecuzione di test | Un chip | L’output completo si apre nella barra ausiliaria a destra |
| Un diff del codice | Un chip | Si apre nella barra ausiliaria a destra |
| Screenshot e altre immagini | Un’anteprima | Si apre ingrandita |
Output dei comandi, diff e screenshot provengono dalle registrazioni che l’Agent ha lasciato durante l’implementazione. Noea conserva per ogni turno quali comandi sono stati eseguiti e quali screenshot sono stati fatti, così una spiegazione può citarli direttamente.
Guarda un riferimento al codice
Un riferimento al codice a metà frase di solito appare come il nome di una funzione o di una variabile, per esempio openGrace; altrimenti appare come un chip “file:riga”, per esempio grace.ts:6-18. Se una spiegazione cita due file con lo stesso nome, il chip aggiunge la cartella superiore.
Ferma il puntatore su un nome o su un chip per vedere il percorso completo, l’intervallo di righe e il simbolo. Cliccalo e il pannello del codice si apre a destra su quel file, alle righe citate. Se il file è ancora come lo ha lasciato un turno di implementazione, le modifiche di quel turno sono sovrapposte all’intero file, così vedi quale turno le ha scritte. Il menu del tasto destro può aprire il file nell’app predefinita, mostrarlo nel Finder o copiarne il percorso.
Se nel frattempo il codice si è spostato, i numeri di riga del chip e il punto in cui ti porta seguono la sua posizione attuale. Se il codice citato è cambiato e se ne trova solo il nome, il chip è attenuato; se il file non c’è più o il codice non si trova più, il chip è attenuato e barrato, e passandoci sopra si legge il motivo. In entrambi i casi, la spiegazione molto probabilmente va indagata di nuovo.
Fin dove arrivano le prove
Quando guardi un materiale, per prima cosa capisci di che tipo è:
| Materiale | Che cosa può confermare | Che cosa tenere presente |
|---|---|---|
| Codice di implementazione o di test | Quale logica usa il codice e quali casi definiscono i test | Che il codice di test esista non significa che i test siano stati eseguiti o superati |
| Risultati di esecuzioni precedenti | Che cosa è stato eseguito allora e quale è stato il risultato allora | Se il codice è cambiato da allora, il risultato potrebbe non valere più |
| Verifica eseguita durante questa spiegazione | Il risultato nell’ambiente e nell’ambito di questa esecuzione | I casi che passano non dicono nulla su quelli non coperti |
Explain e Investigation si basano soprattutto sulla lettura del codice e del materiale esistente; non rieseguono ogni volta test, build o app. L’Agent verifica qualcosa solo quando leggere il codice non basta a stabilire un fatto da cui dipende la conclusione. Buone prove dicono che cosa non hanno verificato, per esempio “Non eseguito contro il vero provider di pagamento; i risultati degli addebiti provengono da un test double.” Quando le prove sono scarse, non si trova nessuna implementazione o l’intento è ambiguo, le prove e l’attenzione dovrebbero dirlo chiaramente invece di offrire una conclusione solo apparentemente certa.
Tieni presente anche che una spiegazione è un resoconto di indagine con prove, non un certificato. Far controllare a un Agent l’implementazione di un altro Agent non rende il risultato più certo di per sé. Il valore delle prove è che puoi aprirle e controllare, non che la spiegazione dica “confermato”.
Screenshot e interfaccia
Alcuni comportamenti non si possono stabilire dal solo codice, per esempio se un avviso compare davvero nell’interfaccia. Se l’Agent ha fatto uno screenshot durante l’implementazione, la spiegazione può elencarlo come prova, per esempio “Durante il periodo di grazia, un avviso compare in cima alla pagina impostazioni del team.”
Clicca l’anteprima per ingrandirla. Nota quale pagina mostra, in che stato e quale esecuzione l’ha lasciata: uno screenshot dimostra come appariva l’interfaccia allora; se il codice è cambiato da allora, può essere cambiata anche l’interfaccia.
Controlla voce per voce
Quando controlli le prove, chiediti per ogni voce:
- Questo riferimento punta a ciò di cui parla questa parte dell’intento?
- Quali casi coprono i test, e tra essi ci sono i casi limite?
- Il risultato sostiene davvero la conclusione della spiegazione?
- Le prove dicono che cosa non è stato verificato?
Per esempio, le prove sul periodo di grazia dicono “eseguiti i test del periodo di grazia: tutti i 6 passano”, mentre l’attenzione nota che “nessun test copre il caso in cui il terzo tentativo riesce.” Ora sai che quel percorso si regge sulla sola lettura del codice, senza un’esecuzione che lo dimostri.
Quando le prove non bastano
Se manca un caso chiave, passa il puntatore sul paragrafo, clicca “Ask about this” alla sua sinistra e chiedi all’Agent di verificarlo:
Aggiungi un test: il terzo tentativo riesce al giorno 6 del periodo di grazia, quindi l’abbonamento torna normale e non viene declassato. Dimmi il risultato quando è stato eseguito.
Quando l’Agent finisce, Noea spiega il turno da sé; se l’hai disattivato, clicca “Investigation” a sinistra del paragrafo. La nuova spiegazione elenca questa esecuzione come prova.
Se la conclusione della spiegazione non corrisponde alle sue prove, o pensi che l’Agent abbia frainteso il tuo intento, chiedilo anche qui, e non cambiare il tuo intento per adattarlo al codice. Vedi Scrivere nell’intento ciò che hai stabilito.