Uno sviluppatore ha imposto l'apertura del browser per considerare una UI davvero "fatta"

L’agente scrive “Implemented and verified”, ma nessuno ha aperto il frontend in un browser. È successo abbastanza volte da far cambiare processo a chi lo usava¹.

La routine era sempre quella. L’agente modificava il codice. Eseguiva formatter, type checker e test. Tutto verde. Poi dichiarava il lavoro verificato. Verificato come, esattamente¹?

Una suite di test che passa è un buon segnale. Non sostituisce l’atto di aprire l’app e usare la funzione appena cambiata. L’autore racconta che il codice spesso “aveva senso” e i test passavano, ma l’interfaccia mostrava difetti che un umano notava in pochi secondi¹.

Gli esempi sono concreti. Un controllo che si sovrappone a un altro. Uno stato selezionato presente nello store ma non evidenziato sullo schermo. Un reset che funziona in un percorso ma non in un altro. Un filtro che aggiorna lo stato ma lascia i dati vecchi in pagina. Un salvataggio che sembra a posto finché non ricarichi. Un layer di mappa disegnato nell’ordine sbagliato. Una modale che si apre, ma non entra nello schermo¹.

In questi casi, l’agente aveva testato il codice. Nessuno aveva testato l’applicazione. Da qui la decisione: rendere la revisione in browser parte della “definition of done” per ogni modifica visibile agli utenti¹. Non più “fatto” finché qualcuno non guarda davvero la pagina e ci interagisce.

Dopo alcune settimane, quella abitudine è diventata uno strumento. L’autore dice che ci arriverà, ma prima chiarisce il problema: la verifica non può fermarsi ai test che passano, deve includere l’uso dell’app in un browser vero¹.

Il punto è pratico. Le anomalie citate emergono solo quando l’interfaccia si compone davanti agli occhi. Non bastano formatter, type checker e test a individuare un layer che appare nell’ordine sbagliato, o uno stato che il negozio di dati registra ma lo schermo non riflette. Questi problemi vivono nella resa visiva e nell’interazione. Li intercetti aprendo l’app e provandola, non solo guardando l’esito “verde” degli strumenti automatici¹.

Questo tipo di controllo alza la soglia per dichiarare “verificato”. Cambia anche la forma della prova. Una verifica significativa, per il lavoro rivolto all’utente, deve stare dove sta l’utente: nel browser. Per l’autore, farlo diventare parte della “definition of done” ha chiuso il buco tra “test passati” e “esperienza che funziona”, almeno per le parti dell’app che una persona tocca direttamente¹.

La scelta ha una conseguenza operativa: quando l’agente conclude che ha finito, la conferma non arriva solo da strumenti che misurano il codice. Arriva dall’uso reale dell’interfaccia. È una richiesta minima, ma cambia l’esito. Scopre problemi che i test non vedono e impedisce che “Implemented and verified” significhi “nessuno ha aperto il frontend”¹.