Poi ho fatto loro una domanda a cui non hanno saputo rispondere: quanto è costato?

Che l'artefatto fosse all'altezza, quello lo sapevano. Se arrivarci avesse richiesto quaranta minuti o quattro ore, dodici dollari o duecento, nessuna idea. Un'approvazione pulita al primo colpo e un'esecuzione che taglia il traguardo strisciando, al decimo assalto contro lo stesso problema irrisolto, per loro erano la stessa cosa.

Non lo sono. Solo una delle due è un sistema che funziona.

Il limite che delimita la cosa sbagliata

Avevo limiti di iterazione: dieci giri per fase, non uno di più. Sembrava controllo. Non lo è. Un limite di iterazioni delimita quante volte gira il ciclo, non quanto costa ogni giro, e nella mia pipeline un solo round di revisione si apre a ventaglio su otto verificatori che corrono in parallelo. Quel passo, da solo, può costare più di tutte le fasi precedenti messe insieme, e non c'è limite che se ne accorga.

Così ho scritto un libro mastro. Budget dichiarato prima di cominciare. Si controlla quando si passa da una fase all'altra e a ogni ritorno indietro, mai a lavoro in corso. Se attraversi un arco quando sei già oltre il tetto, l'esecuzione si ferma con un verdetto esplicito, invece di arrivare in fondo zitta e passarti il conto.

Quello che avevo sottovalutato è l'analisi del percorso. Conta la spesa che non ha portato avanti l'esecuzione — tutto quello che si sono mangiati i tentativi finiti in un ritorno indietro — e segnala i motivi che si ripetono. È l'ultimo numero quello che brucia. Un'esecuzione che passa al decimo tentativo identico è un'esecuzione fallita con una medaglia in prestito, e nei miei vecchi report non compariva da nessuna parte.

Perché vale più di quanto sembri

C'è uno studio di marzo che mi ha costretto a ripensare cosa aggiungo a un agente, e perché.

A un agente di programmazione hanno dato una cosa sola in più: una mappa di quali test coprono quale codice, consegnata come file di testo semplice, da leggere e basta. Le regressioni — test che prima passavano e hanno smesso — sono scese dal 6,08% all'1,82%. Il 70% in meno con un file.

Lo stesso studio aveva un secondo ramo. Al posto della mappa, istruzioni di procedura: lavora prima sui test, attieniti a questa disciplina. Le regressioni sono salite al 9,94%. Peggio che non toccare niente.

Per lo stesso motivo il budget vive nel file di stato e non in un prompt che chiede all'agente di stare attento ai soldi. Nessuno sta attento a un numero che non vede.

Sono andato a cercarlo.

Nelle classifiche pubbliche ogni tanto compare lo stesso modello che gira sotto due harness diversi. La distanza va dai tre agli otto punti percentuali. Ora tieni fermo l'harness e cambia il modello sotto: il punteggio si sposta di venticinque.

Se ti fermi lì, la conclusione si scrive da sola: l'harness quasi non conta, compra un modello migliore, vai a casa.

Solo che non è questo a toglierci il sonno

Quei benchmark misurano un compito, dentro un container, che passa o non passa. In produzione nessuno dorme male per un compito dentro un container.

Si dorme male per altro. Un sistema che crolla ogni pochi giorni. Un risultato che martedì prossimo non viene più uguale. Un verdetto che poi non riesce a controllare nessuno. Un'esecuzione che dichiara successo, e il file che dice di aver modificato se l'è inventato.

Ecco, per tutto questo — stabilità, riproducibilità, verificabilità — non esiste nessun benchmark pubblico. Il tentativo più vicino che ho trovato ha tre settimane, e la sua stessa verifica preregistrata si è chiusa senza conclusione.

Dove invece le cifre ci sono, non sono piccole. Uno studio ha tagliato le regressioni del 70% dando all'agente un solo file di contesto. Un altro ha misurato il 9,5% di compiti falliti in meno mettendo un critico che controlla il piano prima dell'esecuzione. Sono entrambi cambiamenti di harness. Nessuno dei due finisce in classifica.

Per adesso, quindi, il lavoro tocca a te. Misura quello che ti interessa davvero — ogni quanto cade il sistema, quanto lavoro torna indietro da rifare, quante volte un verdetto regge la revisione — perché nessuno lo pubblicherà al posto tuo.

Il mio sito ha passato tre settimane a servire una versione indietro di due commit. E io, tranquillo.

Com'è andata, in ordine. Il 6 agosto ho pubblicato due modifiche a una sottopagina. Sono partiti tre deploy. Tutti e tre falliti. Ognuno ha registrato una durata di build di zero millisecondi e il messaggio «Page build failed.». Nessun dettaglio, nessuna notifica, niente in posta.

Zero millisecondi vuol dire che il build non è nemmeno partito, quindi il mio codice non c'entrava. Era caduto qualcosa più a monte.

E il sito? Il sito benissimo. HTTP 200, certificato in regola, tutto che carica. Continuava a essere servito l'ultimo build riuscito, identico al giorno prima. Il guasto non aveva nessuna superficie visibile. Da fuori, dal mio browser, da quello di chiunque altro: un sito sano.

L'ho scoperto perché stavo armeggiando con altro e ho guardato lo stato dei deploy per curiosità.

Il parallelo scomodo

È lo stesso modo di fallire contro cui alzo porte tutti i giorni. Solo che è arrivato da un lato che non avevo difeso.

L'agente dichiara successo. I test passano. Il diff sembra pulito. Tutto quello che affiora in superficie dice che il lavoro è fatto, e l'unico modo per sapere il contrario è controllare qualcosa che chi riferisce non governa: aprire l'applicazione vera, interrogare lo stato vero, confrontare con qualcosa che l'ottimizzatore non può toccare.

Quel riflesso, con gli agenti, ce l'avevo. Con la mia pipeline di deploy no. E intanto stava lì, ventun giorni a servire contenuto stantio senza fiatare.

La riparazione, tra l'altro, è consistita nel togliere, non nell'aggiungere. Il sito è HTML puro, eppure ogni deploy lo passava per un motore di template di cui non ha mai avuto bisogno: 165 secondi per pubblicare mezzo megabyte. Un file vuoto dopo, il deploy è una copia di file e dura 19 secondi. Nove decimi del tempo se ne andavano in un passaggio il cui unico contributo reale era poter fallire.