Addy Osmani parte da un'osservazione: dare a un agente un modo per verificare il proprio lavoro migliora notevolmente la qualità di ciò che produce. Ciò che rendeva costoso il "buon codice" — test, benchmark, specifiche, percorsi end-to-end reali — può ora essere delegato all'agente. Il lavoro umano passa quindi dalla revisione riga per riga alla costruzione di loop che l'agente esegue autonomamente, e il gusto viene capitalizzato: ogni errore diventa una configurazione condivisa, un hook o un test. Un essere umano resta responsabile di ciò che viene rilasciato, ma esamina le evidenze piuttosto che i diff.

A suo avviso, i modelli sono ora sufficientemente buoni perché la verifica sia il collo di bottiglia. Un agente che non può controllarsi da solo indovina, e la correzione richiede allora un andirivieni umano lento, costoso e non scalabile. Un agente che si testa da solo scrive, controlla, legge il risultato e riprova prima che qualsiasi essere umano intervenga. I test cambiano ruolo: diventano il modo in cui l'agente percepisce il mondo e sa di aver finito.

I test end-to-end sono l'oracolo privilegiato: descrivono ciò che fa l'utente e sono difficili da ingannare, a differenza di un test unitario basato su mock, che può condividere lo stesso fraintendimento dell'agente. Devono indicare il passaggio che fallisce, trasformando un'istruzione vaga in un obiettivo. Lenti e instabili, devono restare pochi di numero.

I test basati su proprietà stabiliscono ciò che non deve mai accadere; strumenti come fast-check, Hypothesis o proptest generano migliaia di input e riducono i fallimenti a un caso minimo. Proprietà comuni: round-trip, invarianti, idempotenza, equivalenza con una versione semplice. Impediscono all'agente di scegliere esempi che si limitano a confermare la propria logica e fungono da specifica.

Per una riscrittura, i test differenziali trasformano il vecchio sistema nell'oracolo: input identici, casuali o tratti dal traffico reale, confronto degli output, normalizzazione di ciò che è insignificante e un elenco motivato dei cambiamenti previsti, finché il vecchio sistema non può essere ritirato.

Il loop deve essere rapido e deterministico: un agente alle prese con test lenti o instabili impara a riprovare piuttosto che correggere, oppure distanzia le proprie esecuzioni e perde traccia delle cause. Osmani raccomanda un loop centrale sotto il secondo, un'aleatorietà controllata, l'esclusione immediata dei test instabili, un output conciso e test più pesanti prima dell'integrazione. La sua conclusione: scrivere il controllo prima del codice.