Naval Ravikant e tre fondatori che costruiscono infrastrutture, aerei e interfacce neurali descrivono un cambio di epoca: il software non si misura più in righe, ma in giudizio, riuso e velocità di esecuzione.
Quando un fondatore dice che oggi bisogna “buttare via token per risparmiare tempo”, sta già spostando il baricentro del mestiere. La conversazione con Naval Ravikant, Guido Roush di Vercel, Blake Scholl di Boom Supersonic e Max Hodak parte da lì: dall’idea che l’unità di misura non sia più la riga di codice, ma la capacità di far lavorare insieme modelli, componenti e giudizio umano. Il punto non è solo che gli strumenti sono migliorati. È che stanno cambiando ciò che vale come competenza, e perfino ciò che resta difendibile come vantaggio competitivo.
Ravikant apre con una tesi netta: l’ingegnere non viene più valutato per l’output diretto, ma per la capacità di costruire una fabbrica che moltiplica output futuri. In questo schema, il vecchio dibattito sui programmatori da 10x appare quasi timido, perché per lui il divario reale nelle aree digitali è già di 100x o 1000x.
Stiamo passando da una logica in cui misuravi quanto bene una persona spediva il prodotto, a una in cui misuri quanto bene costruisce la fabbrica che produrrà risultati da B a Z».
1:34
Quando lavori in domini digitali e intellettuali, non è nemmeno 10x, è 100x o 1000x. È sempre stato così».
2:07
Scholl e Hodak non contestano il quadro generale, ma lo spostano sul terreno più concreto della collaborazione con i modelli. Il tema non è se esistano persone molto più efficaci di altre, ma quanto i modelli amplifichino la differenza tra chi sa dirigere bene e chi no.
I modelli sono incredibilmente capaci, ma il feedback che dai sporadicamente sembra essere incredibilmente importante».
3:03
La qualità del reprompting, credo, è estremamente importante».
3:31
Qui il lessico conta. Ravikant parla di taste and judgment, gusto e giudizio, come nuove competenze centrali. Non basta chiedere bene, bisogna sapere cosa chiedere, quando insistere e quando correggere la direzione dell’agente.
La discussione sui costi si capovolge presto. Ravikant dice di aver smesso di trattare i token come una metrica da ottimizzare, perché il confronto sensato, a suo avviso, non è tra token e token ma tra token e tempo umano. Se il modello non produce abbastanza bene al primo giro, si può sempre ripassare sul lavoro e spendere altri token.
Li uso in modo goffo. Mi frustro con loro e poi continuo a buttare token per risparmiare tempo».
4:19
Anche se sembrano costosi, restano molto più economici di un essere umano».
4:43
Ravikant spinge ancora oltre: se il risultato iniziale è scadente, il problema non è aver usato il modello, ma non averci passato abbastanza iterazioni. In questa visione, la produzione software diventa un processo elastico, dove la qualità arriva in una fase successiva e quasi automatica.
Quando arriva il momento di mandarlo in produzione, ci butto sopra altri token: ricontrolla tutto, riscrivilo».
4:58
Non guardo i token come input o output. Guardo il mio tempo e il risultato finale».
4:28
Il passaggio decisivo, per Scholl, è che i modelli non si limitano più a eseguire istruzioni. Ora propongono percorsi, confrontano trade-off e tornano indietro con una diagnosi del problema, come farebbe un collega più esperto. Questa mutazione cambia il tono della relazione: non più strumento passivo, ma interlocutore tecnico.
Adesso i modelli fanno una specie di pianificazione intuitiva. Tornano da te e dicono: guarda, per quello che mi chiedi ci sono tre strade, e questo è il compromesso di ciascuna».
6:11
Sono passato a rispettarli molto di più, quasi come un pari con cui faccio avanti e indietro intellettualmente».
6:29
Scholl però non si lascia andare all’entusiasmo puro. Dice che gli errori restano frequenti, che le previsioni temporali dei modelli sono spesso pessime e che il vantaggio maggiore resta nelle mani di chi sa architettare bene il problema. Il modello aiuta, ma non sostituisce chi ha già una grammatica tecnica solida.
Se sei davvero bravo, estrai ancora più succo».
6:32
Un junior non ottiene junior back, ottiene conoscenze più avanzate che non avrebbe mai scritto da solo».
6:53
La domanda che attraversa tutta la conversazione è brutale: il software puro è ancora difendibile? Ravikant la formula senza giri di parole, chiedendosi se programmare classico sia diventato obsoleto, come parlare inglese in un mondo in cui i modelli lo parlano già. Se i modelli possono ricevere istruzioni in linguaggio naturale, dove resta il fossato competitivo?
Il software puro è morto? Il software puro è obsoleto?».
8:52
I modelli ora parlano inglese. Abbiamo dovuto imparare il codice per parlare con loro, adesso parlano inglese loro».
9:19
La sua risposta parziale è che il vantaggio si sposta verso i blocchi riusabili, l’infrastruttura, i componenti che gli agenti possono combinare senza reinventare tutto da zero. Scholl richiama qui la logica dei building blocks: un agente non dovrebbe dover riscrivere ogni volta l’equivalente di una coda, un database o un sistema di messaggistica.
Quello che serve agli agenti adesso sono blocchi di costruzione riutilizzabili, molto potenti».
10:04
Non vuoi che il tuo agente reinventi ogni volta un sistema di infrastruttura per mandare una mail».
10:21
Ravikant insiste che la vera rendita è nella cooperazione su larga scala, non nella micro-ottimizzazione individuale. Se tutti dipendono da PostgreSQL o da un altro stack comune, sostiene, si risparmia la fatica di ricostruire continuamente la civiltà tecnica da capo.
La parte più concreta arriva quando Scholl racconta il proprio rapporto con il codice. Dice di aver imparato a programmare da piccolo, di aver passato anni immerso nei linguaggi e di non scrivere più una riga a mano da molto tempo. Il suo lavoro, sostiene, si è spostato verso la capacità di mettere insieme pezzi e farli parlare tra loro.
Non ho scritto una singola riga di codice da parecchio tempo».
12:14
Da dicembre ho costruito una quantità enorme di software che uso ogni giorno, e non ho scritto niente di tutto questo».
12:26
Hodak rilancia con un’osservazione simile: capire come funziona un’API, come fluisce il dato, come si misura la performance è più utile, ormai, che macinare sintassi. Ravikant traduce questa intuizione in una teoria del management: gran parte del buon engineering leadership è sempre stata una forma di vibe coding mediata da persone, prima ancora che da agenti.
Chi capisce che cos’è un’API e come scorrono i dati, input e output, è sempre stato più utile che scrivere codice».
12:47
Stavamo già facendo vibe coding attraverso persone su Slack e nei one-on-one».
13:02
Il limite, però, non è sparito. Ravikant nota che il computer continua a essere un partner disordinato, capace di restare bloccato in punti in cui un umano impazzirebbe. Ma la differenza, dice Scholl, è che oggi il blocco dura molto meno, e questo cambia il rapporto psicologico con la programmazione.
Con gli agenti non resti più bloccato».
14:04
Perché Ravikant dice di “buttare via token”?
Lo dice perché considera i token più economici del tempo umano. Se un modello produce un risultato mediocre, secondo lui conviene iterare ancora invece di fermarsi al primo tentativo.
Cosa cambia per un programmatore junior?
Secondo Scholl, un junior ottiene comunque molto più di prima, perché il modello gli restituisce conoscenze che da solo non avrebbe scritto. Però il vantaggio maggiore resta per chi sa scegliere tecnologie e dare feedback buoni.
Il software puro è davvero finito?
Naval Ravikant lo mette in dubbio, ma non offre una risposta definitiva. La sua ipotesi è che il valore si sposti verso infrastruttura, componenti riusabili e sistemi che gli agenti possono combinare.
Perché gli agenti hanno bisogno di blocchi riusabili?
Perché non ha senso ricreare ogni volta database, code o strumenti di comunicazione. Scholl e Ravikant sostengono che gli agenti funzionano meglio quando partono da pezzi già collaudati.
Sintesi assistita dall'AI del podcast di Naval, verificata sulla trascrizione originale.