Un agente di programmazione che termina un compito scrive spesso «Risolto». È qui che sta il pericolo. Se l'agente non ha ricevuto gli strumenti per verificare da sé il proprio lavoro, questa frase è spesso falsa. Porta a correzioni che non correggono nulla, e talvolta a incidenti gravi in produzione.
Esigiamo quindi che ogni agente alleghi la prova che ha ottenuto da sé. Senza, il compito non è concluso. Questa regola decide che cosa affidiamo all'IA, che cosa rivede il team e che cosa ricevete a ogni consegna.
Senza prova, niente «fatto»
Un modello linguistico scrive il seguito più probabile di un testo. Dopo una correzione, il seguito più probabile è «risolto», che la correzione funzioni o no. Solo l'osservazione del risultato decide. Un ingegnere di Cursor ne ha fatto un principio del suo metodo, 
pstack · Prove it works: «compila» non dimostra nulla, l'agente deve osservare il risultato reale.
Ogni agente allega quindi la prova di ciò che annuncia: il test che falliva e ora passa, le schermate della pagina su smartphone e computer. Quando non ha potuto verificare, scrive «non verificato».
Che cosa un agente deve poter verificare da solo
Esigere prove non serve a nulla se l'agente non può ottenerle. Gli diamo quindi i mezzi per controllare il proprio lavoro.
- La documentazione aggiornata degli strumenti che usa, per verificare che una funzione esista invece di ricordarla.
- Una mappa delle dipendenze del codice, per sapere che cosa una modifica può rompere prima di farla.
- Un browser e dei simulatori, per aprire ogni pagina su smartphone, tablet e computer.
- Test di percorso, in cui un agente segue un obiettivo come «passare all'offerta Pro» e una verifica esatta controlla il risultato mostrato.
Quando un agente segnala un difetto, deve riprodurlo con un test prima che ne teniamo conto. Il test resta poi nel prodotto e ripete lo scenario a ogni modifica.
Che cosa affidiamo a un agente
Il nostro criterio è una domanda. Si può verificare il risultato senza rileggere tutto il codice? Erik Schluntz, ingegnere di Anthropic, paragona un'applicazione a un albero nella conferenza 
Vibe coding in prod. Usiamo questa immagine per decidere dove va la revisione umana.
Dove va la revisione umana
Foglie
Una schermata di report, un'esportazione, una pagina di amministrazione.
Affidate a un agente, giudicate sui risultati testati.
Rami
Un percorso di prenotazione, un modulo condiviso.
Contratti testati. Ogni modifica a un contratto viene rivista.
Tronco
Dati, diritti di accesso, pagamenti.
Compreso e rivisto dal team a ogni modifica.
Le foglie sono le funzionalità da cui non dipende nulla. Quando input e output sono testati, il loro risultato basta a giudicarle. Il tronco regge i dati, i diritti di accesso e i pagamenti. Il team lo comprende e lo rivede, perché tutto il resto ne dipende e nessun test misura il debito tecnico.
Ogni test aggiunto rende verificabile una parte in più, e quindi affidabile a un agente. Per questo quasi un terzo del codice che scriviamo serve a verificare il resto.
Che cosa decide il team
L'agente esegue in fretta. Decidere che cosa eseguire, e come sapere che è giusto, resta il lavoro del team.
Le domande giuste, prima della prima riga di codice. Che cosa succede se un pagamento fallisce a metà? Chi può vedere i dati di un altro cliente? Che cosa fa l'app senza connessione? Un agente non si pone queste domande da solo. Saperle porre viene da progetti consegnati e da guasti risolti. Erik Schluntz lo sottolinea: senza le domande giuste, un agente non lo si guida, lo si subisce.
L'architettura. I confini tra i moduli, i dati condivisi e ciò che deve poter evolvere formano il tronco dell'applicazione. Un agente riproduce la struttura che trova, buona o cattiva. Spetta quindi al team disegnarla.
La definizione di «fatto». Prima di ogni compito, il team scrive che cosa deve essere vero perché sia concluso: i casi da coprire, i risultati attesi, le schermate da verificare. Un test può passare con un risultato sbagliato se il risultato atteso è sbagliato. L'importo di un rimborso, una regola di annullamento o i diritti di un utente si decidono quindi con voi, poi si scrivono nei test. L'agente scrive quindi il codice che li rispetta.
Codice pronto per la produzione
Ogni evoluzione arriva testata, verificata su smartphone e computer, con l'indirizzo della versione da approvare. Controllate il risultato voi stessi prima della messa in produzione.
Quattro domande da porre ai vostri sviluppatori
- Come dimostrano i vostri agenti ciò che annunciano?
- Quali parti del mio prodotto rivede una persona, e perché proprio quelle?
- Chi stabilisce i risultati attesi nei test?
- Che cosa riceverò per approvare un'evoluzione?
Volete riprendere un'applicazione esistente o costruirne una con questo metodo? Parliamone.
SaaS
Swiss Made Software