Il costo marginale della correttezza

Il costo marginale della correttezza tende a zero. È necessario comprendere appieno cosa ciò comporti per il modo in cui si pratica l'ingegneria del software. Bisogna essere ossessionati dal fare le cose nel modo giusto.

Un panorama in evoluzione

In passato, un ingegnere poteva distinguersi grazie al proprio talento tecnico puro: pensiero algoritmico efficiente, sistemi distribuiti scalabili, analisi meticolosa dei breakpoint nel debugger. Questo sta diventando sempre meno vero a un ritmo sempre più rapido. Gli agenti stanno consentendo a chiunque di scrivere codice corretto.

La capacità più importante che devi sviluppare per distinguerti oggi è il fiuto: la capacità di fiutare ciò che non va e la forza di volontà per sistemare le cose.

Individuare un'API lenta

Stiamo addestrando un nuovo modello a Pangram (non credo di svelare troppo ammettendolo) – sarà più grande, più intelligente e anche *più veloce* rispetto ai nostri modelli precedenti. Quest’ultimo superlativo non sarebbe stato possibile senza l’ossessione di fare le cose per bene, semplicemente per il gusto di farlo. Perché possiamo farlo. Perché siamo orgogliosi del nostro lavoro. Perché un giorno, mentre stavo testando la nostra API, ho pensato: «Dovrebbe decisamente essere più veloce di così».

All’epoca non avevo modo di sapere in che modo, esattamente, addentrarmi in quella "tana del coniglio" avrebbe dato i suoi frutti. Ero semplicemente animato dalla convinzione che dovessimo fare le cose per bene e dalla fiducia che, con Fable al mio fianco, tutto fosse possibile.

Ne siamo usciti vincitori solo un paio di giorni dopo, avendo avuto la meglio sulla latenza che aveva afflitto il mio dogfooding. Con Fable sono riuscito a creare un ambiente di test interamente locale per il nostro complesso orchestratore di API distribuite. Abbiamo generato ipotesi per tutti i punti critici del nostro codice e testato le correzioni per ciascuno di essi. Abbiamo messo in pipeline operazioni Redis complesse e verificato il mantenimento del comportamento. Abbiamo eseguito simulazioni di diversi modelli di carico basati sul traffico di produzione e stimato l’infrastruttura necessaria.

Senza gli agenti, questo sarebbe stato un progetto insostenibile e irrealizzabile, che avrebbe richiesto settimane o mesi di lavoro di ingegneria. Invece, è stato un progetto secondario che ho portato avanti mentre la mia sessione di addestramento si concludeva in sottofondo.

I nostri sforzi sono stati ricompensati con un aumento di circa 5 volte dell’utilizzo della GPU – dal 20% (ahi!) al 98% – e una velocità di elaborazione pari a quella dei nostri nodi bare metal. Ci è costato pochissimo. Ci ha fatto guadagnare tutto. Ha trasformato l’hosting del nostro nuovo modello da un’operazione dal costo proibitivo a un vero e proprio affare.

Affinare il proprio fiuto

Purtroppo non esiste un unico semplice trucco per affinare il proprio fiuto, ma è una capacità che si può sviluppare. Ecco cosa ha funzionato per me (credo):

Hai una bassa tolleranza al dolore

Tutto ciò che ti infastidisce probabilmente infastidisce anche i tuoi utenti: non limitarti a stringere i denti. Devi entrare in sintonia con te stesso: nota cosa ti provoca un leggero disagio durante la giornata, quali parti del codice tendi inconsciamente a evitare o quali attività ti rendono un po’ troppo irrequieto. È proprio qui che si possono ottenere risultati positivi. È proprio questo che ha dato il via al mio approfondimento sull’ottimizzazione delle API.

Mi piace dire che “le cose semplici dovrebbero essere semplici”. Questo vale sia per il vostro codice (ad esempio, eseguire una semplice ablazione di addestramento non dovrebbe richiedere alcuno sforzo mentale) sia per il vostro prodotto (ad esempio, una singola chiamata API dovrebbe essere appena più lenta del passaggio in avanti stesso). Quando vi ritrovate a pensare “non dovrebbe essere così difficile”, risolvete il problema! Ora avete gli agenti! Avviate un worktree e lanciate Codex /obiettivo Allora, cosa hai da perdere?

Metti tutto in discussione partendo dai principi fondamentali

Gli agenti rendono tutto questo semplicissimo. “Quanto tempo dovrebbe richiedere questa operazione, date le dimensioni del nostro batch, le specifiche della GPU e il numero di parametri?”. “Quanto dovremmo spendere per questo fornitore, dato il nostro volume di dati e di query?”. Quando sai come dovrebbe essere il risultato corretto, è molto più facile individuare ciò che non lo è.

Lo faccio per ogni topologia modello/nodo/forma di richiesta che supportiamo: è così che ottimizzo la nostra configurazione vLLM per assicurarmi che ci avviciniamo al limite teorico. È così che ho scoperto che c'era un divario tra il throughput della nostra API e i risultati ottenuti su un nodo bare metal.

Questo principio vale anche per il tuo codice. Se un'astrazione ti sembra strana, non accontentarti della risposta “è sempre stato così”. Ripensa al contratto partendo dai principi fondamentali: come dovrebbe essere, alla luce di ciò che sappiamo ora? Il tuo compito è capire dove indirizzare l’agente. L’agente può occuparsi del refactoring e verificare la correttezza nel giro di una notte.

Sii curioso, leggi molto

Una delle ottimizzazioni che preferisco, che ho implementato durante la mia prima settimana in Pangram, è stata ispirata dal meccanismo di attenzione sparsa ibrida di DeepSeek V4.

La mia ottimizzazione non aveva nulla a che fare con l'architettura neurale, e tanto meno con l'attenzione in particolare. Si trattava di un miglioramento dell'algoritmo che utilizziamo per individuare i confini tra il testo scritto da esseri umani e quello generato dall'intelligenza artificiale, che in precedenza richiedeva un secondo ciclo di inferenza illimitato.

Assorbi il maggior numero possibile di idee interessanti da quante più persone brillanti riesci a trovare. Il tuo compito ora è quello di essere infinitamente curioso, di creare collegamenti e di chiederti “e se…”. Ricorda: il costo marginale di scoprire qualcosa tende a zero.

Usa i tuoi gettoni

Ogni domenica ho un rituale in cui mi limito a impostare Codex su un valore casuale /obiettivo per cercare di utilizzare i miei gettoni settimanali prima del reset. Il più delle volte finisco per buttare via il codice oppure questo rimane a prendere polvere in una bozza di PR dimenticata. A volte ne vale la pena. Quasi sempre imparo qualcosa da questo esercizio. In ogni caso non mi costa nulla. Alcuni lo definiscono “giocare alle slot machine”, ma io dico che non si può vincere se non si gioca