Come le build si verificano da sole

0:00 — una build viene completata. L'agente dice che è finita, il che è un'affermazione sul fatto di aver scritto codice, non sul fatto che il codice funzioni. Ogni utente di un builder basato su IA ha percepito almeno una volta il divario tra queste due affermazioni: si apre l'anteprima, si clicca sul terzo pulsante, non succede nulla. Ho visto una sala demo ammutolirsi esattamente in quel momento. Quindi, prima che qualsiasi essere umano veda una build, questa attraversa circa sei minuti di una catena che discute con se stessa. Ecco come funziona davvero, ripercorso attraverso una build che abbiamo visto andare storta e poi essere corretta.

0:02 — inizia la revisione del codice. Non l'agente che ha scritto il codice che rilegge i propri compiti — un agente separato, prompt diverso, nessun interesse a che la build passi. Questa separazione conta più di quanto sembri. Un agente che alle 14:14 ha deciso che una chiamata fetch senza gestione degli errori andava bene, la penserà ancora così alle 14:15 se gli chiedi di controllare il proprio lavoro. Un revisore fresco a cui viene detto "trova cosa è rotto, cita il file" si comporta come il collega senior burbero che vorresti davvero avere per questo compito. In una build precedente ha individuato un totale del carrello che silenziosamente non si aggiornava mai — `updateTotal` era definita in `Cart.jsx` ma mai collegata al gestore del cambio quantità, quindi la funzione esisteva e semplicemente non veniva mai eseguita. Questa è la categoria per cui esiste la revisione del codice: cose che un compilatore ignora.

0:04 — audit di sicurezza. Più circoscritto di quanto sembri, deliberatamente — non è un penetration test, è una caccia a pattern per la manciata di errori che effettivamente compaiono nel codice generato dall'IA. SQL concatenato tramite stringhe. Validazione solo lato client trattata come se fosse tutta la storia. E la specialità della casa: una chiave API hardcoded, perché l'agente che scriveva la funzionalità non aveva davanti una convenzione per le variabili d'ambiente e ha usato ciò che funzionava. Lo vediamo abbastanza spesso da non considerarlo più una sorpresa.

0:07 — link e SEO. Poco affascinante, ma intercetta le cose che nessuno nota finché non lo fa un cliente: un link di navigazione che punta a /pricing quando la pagina è stata effettivamente generata su /price, una voce nella sitemap per una pagina che restituisce 404, una meta description che contiene ancora il testo segnaposto del template. Niente di tutto questo blocca la build. Ma tutto ciò silenziosamente affossa la cosa per cui la maggior parte dei nostri utenti ha costruito il sito — farsi trovare, ricevere clic.

0:09 — accessibilità. Si tratta di un passaggio automatizzato con axe-core, non un audit manuale completo, ed è giusto essere onesti su cosa comporti questo compromesso. axe-core rileva rapporti di contrasto, testo alternativo mancante, campi modulo senza etichetta, trappole nell'ordine di tabulazione — lo strato meccanico, qualcosa come il 30-40% di ciò che segnalerebbe una revisione WCAG completa. Non rileverà un'esperienza con screen reader tecnicamente conforme ma genuinamente confusa da usare. Abbiamo scelto solo l'automazione perché gira in pochi secondi e gran parte di ciò che passa di qui sono siti marketing e piccoli strumenti, non il tipo di applicazione in cui un audit parziale rappresenta un rischio reale per qualcuno.

0:11 — conformità. Questo livello non si chiede "è fatto bene," si chiede "corrisponde a quanto promesso." Il piano prevedeva quattro pagine, la build ne consegna tre — la conformità è ciò che se ne accorge. Il piano prometteva un modulo di contatto funzionante, ciò che viene consegnato è un modulo senza azione di invio — stesso livello, stessa cattura. È il controllo più direttamente responsabile verso l'utente, perché misura rispetto all'intento dichiarato dall'utente, non un'astratta nozione di qualità.

0:13 — il controllo nel browser, ed è qui che la nostra build si è effettivamente rotta. Questo livello è il più difficile da aggirare perché non legge il codice, pilota un browser reale — clicca, digita, aspetta, controlla che il DOM sia cambiato come avrebbe dovuto. La build in questione era un idle game, e i giochi ricevono un controllo extra qui perché un gioco può renderizzare in modo perfetto e comunque essere ingiocabile — il display del punteggio può apparire impeccabile pur essendo completamente scollegato dalla logica di punteggio. Il verificatore ci ha giocato. Il punteggio si aggiornava correttamente. L'audio non emetteva alcun suono.

Tre round, poi un'escalation

La segnalazione non è arrivata a noi come bug report — è andata direttamente in un passaggio di correzione, e la catena ha riverificato, fino a tre round all'interno della build. Round uno: la correzione ha toccato l'inizializzazione del mixer, che era già a posto, quindi l'audio è rimasto muto. Round due: una correzione diversa ha affrontato un caso limite dello stato di caricamento che sembrava vicino, e — succede più spesso di quanto ci si aspetti — ha introdotto un piccolo nuovo problema senza risolvere quello originale. Round tre: ancora muto, e a questo punto di solito ti trovi davanti a qualcosa di genuinamente difficile o a un falso allarme, e questo era il caso difficile.

Quindi la piattaforma ha fatto un'escalation autonoma. Ha messo in coda un ulteriore passaggio di correzione dedicato esclusivamente al problema rimasto, lavorando su un clone della build anziché sulla build stessa — nel senso che l'esecuzione dell'escalation avrebbe potuto fallire senza costarci la versione funzionante che avevamo già. Quell'esecuzione ha trovato la causa reale: un flag di silenziamento impostato durante un precedente passaggio di debug che non era mai stato riportato allo stato originale, presente in un file completamente diverso da quelli toccati dalle due correzioni precedenti. Rimosso il flag, riverificato, superato. Nessuno ha guardato questa build finché non ha già funzionato.

Cosa eviterei la prossima volta

Alcuni mesi prima che quell'idle game venisse eseguito, abbiamo provato una versione più permissiva dell'intero sistema — verificatori autorizzati a sollevare qualsiasi dubbio, formulato come preferivano. Produceva segnalazioni come "considera di estrarre questo in una funzione di supporto" e "questo nome di variabile potrebbe essere più chiaro," che sembravano scrupolosità e non risolvevano nulla. I passaggi di correzione bruciavano interi round a rifinire la prosa invece di correggere ciò che era davvero rotto. Abbiamo irrigidito la regola a: indica un file, descrivi un guasto, oppure non dire nulla. Le segnalazioni dei verificatori sono calate di circa la metà e quasi tutto ciò che restava era azionabile. Se dovessi ricostruire questo da zero, salterei del tutto la versione permissiva e andrei direttamente alla regola dell'evidenza — non avevamo bisogno di imparare quella lezione nel modo costoso, l'abbiamo semplicemente fatto.

La regola ha un costo reale, e non fingerò il contrario: un dubbio vago ma vero come "questa scelta architetturale creerà problemi a qualcuno tra sei mesi" ora viene scartato, perché un verificatore non può ricondurlo a un guasto concreto. Abbiamo accettato questo compromesso. Una catena che facesse anche revisione architetturale non sarebbe abbastanza veloce da girare su ogni singola build, e la velocità è l'intero senso di eseguire questo automaticamente invece di chiedere a un essere umano di farlo.

Eviterei anche di aggiungere un quarto round, se qualcuno lo chiedesse. Abbiamo calibrato il numero di round su build reali, e il valore marginale oltre il terzo round crolla drasticamente — il primo round risolve la maggior parte dei problemi correggibili, il secondo per lo più ripulisce i problemi introdotti dal primo, e al terzo round ciò che rimane è genuinamente difficile oppure non era mai davvero rotto. Un quarto round si traduce per lo più in tempi di attesa più lunghi per lo stesso risultato.

Niente di tutto questo è gratuito, e niente è infallibile. Sei livelli più tutti i round di correzione necessari aggiungono tempo reale a ogni build — la differenza tra finire in meno di un minuto e finire in diversi minuti. Riteniamo che sia il compromesso giusto per qualsiasi cosa stiate per mettere davanti ai vostri clienti, ma "veloce" e "verificato" tirano in direzioni opposte, e noi abbiamo scelto verificato. Anche i verificatori sono LLM, quindi a volte segnalano qualcosa che in realtà non è rotto, o non notano qualcosa che lo è. La regola delle prove e il ciclo multi-round sono coperture contro questo rischio, non garanzie.

Ciò che ottenete alla fine è un registro: quali livelli sono stati eseguiti, cosa hanno trovato, cosa è stato corretto e cosa resta al vostro giudizio. Quel registro è più vicino al prodotto reale rispetto al codice stesso — è la differenza tra fidarsi di una build perché sembra completa e fidarsi perché qualcosa di avversario ha provato a romperla prima, e ha fallito.