Jev: il modello progettato per essere chiamato dal codice, non dagli umani
Diogo Almeida, ex OpenAI, spiega perché ha creato una nuova classe di modelli "system one" — e perché rifiuta i benchmark pubblici, i rifiuti e il pre-training.
In breve
In un'intervista di oltre due ore allo studio Latent Space, il fondatore di TypeSafe illustra la tesi dietro Jev: un modello il cui consumatore è il codice, ottimizzato per l'"intelligenza per dollaro", senza catena di ragionamento né rifiuti. Smonta anche l'RLHF, i benchmark pubblici e il dibattito sul "pacing" del frontier, e racconta perché ha lasciato OpenAI dopo aver spinto InstructGPT.
🍺 Versione da bancone
Da tre anni tutti ti spiegano che l'IA sarà il tuo collega d'ufficio. Lui pensa che sia un errore di casting: l'IA non è uno stagista, è un database un po' dotato che chiami un milione di volte al giorno da un loop. Da qui un modello che non chiacchiera, non rifiuta nulla, non ragiona ad alta voce, e restituisce solo tre cose: un booleano sfumato, un punteggio, una scelta. Se funziona, la rivoluzione IA non arriverà sotto forma di un chatbot geniale ma di un software banale che, all'improvviso, prende finalmente le decisioni giuste da solo.
Da ricordare
- 1
Jev appartiene a una classe di modelli che TypeSafe chiama "system one", "machine native" o "large programmable": il consumatore dell'output è codice, non un umano.
- 2
Solo tre primitive — nule (derivato da Bernoulli), score e choice — che corrispondono a un if, a un ordinamento o soglia, e a uno switch su enum.
- 3
Il modello è ottimizzato per l'"intelligenza per dollaro" (da cui il nome, in riferimento al paradosso di Jevons), non per la velocità né per le classifiche.
- 4
Almeida si dichiara "estremamente anti-benchmark pubblici": troppo facilmente aggirabili, dovrebbero cedere il posto alle valutazioni interne degli sviluppatori sui propri workflow.
- 5
Nessun rifiuto nell'API: "refusal is obviously a type error" — un rifiuto casuale in una dipendenza che gira in background rompe il software.
- 6
I dati sono interamente sintetici e l'azienda rifiuta di addestrarsi su quelli degli utenti, per non sovradattarsi al presente.
- 7
Cifre citate: oltre 1.000 miliardi di token al giorno processati, notte compresa, 100.000 persone su Discord, e quasi nessun ricavo prima del lancio.
Capitoli
Cold open: l'enigma dell'automazione
Come mai un'IA capace di problemi matematici di alto livello non automatizza ancora i compiti più basilari? Il motore dell'automazione esiste, mancano le prese.
Settimana di lancio: "never been worse"
Stato d'animo del fondatore dopo un lancio che ha saturato la timeline, e scelta di dare priorità ai town hall Discord rispetto agli incontri con gli investitori.
Cos'è Jev?
Definizione della nuova classe di modelli: system one, machine native, large programmable, con il codice come consumatore e l'intelligenza per dollaro come metrica.
RLHF, mode collapse e la slide di LeCun
Il mode dropping dell'RLHF spiega perché l'accumulo di errori previsto da LeCun non si verifica — al prezzo di una calibrazione distrutta.
Perché Jev non rifiuta mai
Il rifiuto come errore di tipo in un'API; distinzione tra allineamento di capacità e allineamento di sicurezza; l'intelligenza come database piuttosto che collega.
Anti-benchmark pubblici
Perché i benchmark pubblici sono ingestibili e aggirabili, e cosa dovrebbe sostituirli: vibes, fiducia, poi valutazione nel workflow reale.
La "bitterest lesson": i dati prima di tutto
Il dato conta più del compute, RLCD come nuova north star, e l'ossessione del reclutamento di "data people".
Determinismo contro robustezza
Niente seed per ora: la proprietà giusta sarebbe la robustezza, testata iniettando UUID nei prompt.
Versioni dei modelli e LTS
Impegno a non modificare un modello distribuito, assenza di promessa di supporto a lungo termine, e ipotesi di un LTS su Jev 1.13.0.
Design dell'API: nule, score, choice
Origine dei nomi, rifiuto dei tipi esistenti, e corrispondenza con if, soglia e switch su enum.
Come strutturare le proprie richieste
Scomporre fino all'unità semantica minima, passare JSON strutturato invece di template, porre molte domande in parallelo.
System 1 contro system 2
Perché gli LLM pre-addestrati sono fondamentalmente pensatori system one, e cosa ha portato l'RLVR — con la sua fragilità frattale.
Prima del lancio: più della metà non capiva
Ritorno su una fase di validazione deludente, l'assenza di ricavi e la messa in discussione della nozione di product-market fit.
Famiglie di utilizzo e coding agent
Dark data, tempo reale, verifica, smart software — e la critica della "tirannia della KV cache" negli agenti di codice.
Il dibattito sul rallentamento del frontier
La dichiarazione comune dei laboratori presuppone secondo lui che serva sempre più RLVR; un'ipotesi che giudica non universale.
Da InstructGPT all'addio a OpenAI
La battaglia per il deployment di InstructGPT, il documento inviato a Sam Altman, e la creazione di TypeSafe con Eric e poi Sasha.
I cantieri che offre agli altri
Videogiochi intelligenti e ripensamento dei coding agent liberati dalla KV cache: due direzioni che vorrebbe vedere esplorate da altri.
Una nuova classe di modelli: il codice come cliente
Il punto di partenza è un'opposizione di compiti. Il pre-training ottimizza l'autocompletamento di Internet, l'RLHF ottimizza la risposta a un umano, l'RLVR ottimizza output verificabili. TypeSafe rivendica un quarto obiettivo, battezzato RLCD: produrre output direttamente consumati da codice. Da qui il nome dell'azienda, TypeSafe.
Concretamente, Jev non scrive testo libero. Espone tre primitive: nule (derivato dalla probabilità di Bernoulli, un booleano continuo), score, e choice. Almeida le descrive come tipi volutamente nuovi, che non vanno confusi con un bool, un int o una function call.
La corrispondenza con il codice è esplicita: un nule alimenta un if, uno score un ordinamento o una soglia, una choice uno switch su enum. "Ci saranno altri tipi, e corrisponderanno a primitive di programmazione", annuncia.
Il nome Jev viene dal paradosso di Jevons. Il branding interno è chiaro: Jev designa la famiglia di modelli che resta sulla frontiera dell'intelligenza per dollaro. Non la più intelligente in assoluto — la più intelligente a prezzo dato.
Il processo all'RLHF: mode collapse e calibrazione
È la parte più tecnica dell'intervista, e viene da qualcuno che ha lavorato su InstructGPT. Secondo Almeida, nessuno ha guardato agli effetti collaterali dell'RLHF, in particolare il mode dropping: il modello abbandona i modi minoritari della distribuzione per produrre solo ciò che è più sicuro.
Se ne serve per spiegare un paradosso noto. La famosa slide di Yann LeCun sull'accumulo di errori con la lunghezza della sequenza è, dice, "matematicamente ovvia ma manifestamente falsa" empiricamente. Motivo invocato: per non deragliare su catene lunghe, i modelli RLHF diventano ultra-conservativi e perdono la loro calibrazione.
Questa calibrazione rotta è, per lui, "un veleno" nelle distribuzioni di probabilità sulle stringhe di caratteri — e la ragione per cui si prendono decisioni sbagliate sovraccaricando i modelli di testo.
Considera LeCun uno dei commentatori più corretti del settore, pur rifiutando di sbilanciarsi su JEPA: "ottima ricerca precoce", ma non ancora pragmatica ai suoi occhi.
Né rifiuti, né benchmark: la dottrina della piattaforma
Sulla sicurezza, la posizione è netta. Almeida non si oppone alla sicurezza come principio, ma ritiene che il safety alignment sia disallineato rispetto agli utenti di un'API. Un rifiuto è "un type error": accettabile in un prodotto consumer, insensato in una dipendenza che gira in background.
La sua analogia ritorna più volte: "l'intelligenza somiglierà più a un database che a un collega". E non spetta al motore di database giudicare l'uso a valle. Sull'uso militare, ammette una preferenza personale, ma rifiuta di inscriverla nello strato tecnologico, motivando che ogni sovradattamento "frattura l'intelligenza".
Stessa logica per i benchmark pubblici. Ricorda che ogni laboratorio aveva un tempo un team dedicato a raccogliere dati simili a MMLU. La sua conclusione: "a lungo termine servono vibes e fiducia", poi una valutazione nel workflow reale. Internamente le eval esistono — la disciplina consiste nel non aggirarle.
Il costo di questa posizione è stato reale: durante il round precedente, nessuno gli credeva per mancanza di numeri da mostrare. Dice di esservisi attenuto per principio. Si dichiara anche "anti-demo", incluse le demo lusinghiere della sua community.
Affidabilità, versioni, GPU: le promesse fatte agli sviluppatori
Niente seed, niente determinismo per ora. Ritiene il determinismo interessante per i test unitari, ma stima che la vera proprietà desiderabile sia la robustezza: input semanticamente identici, output simili. Il loro test casalingo consiste nell'iniettare UUID nei prompt e verificare la stabilità delle risposte.
Sulle versioni, l'impegno è netto: "non modificheremo i nostri modelli dopo il deployment". In compenso, nessuna promessa di supporto a lungo termine — contano di iterare molto più velocemente dei fornitori abituali, con l'ipotesi di un LTS temporaneo sulla versione molto usata, Jev 1.13.0.
Il contesto è quello di una carenza duratura di GPU. È anche l'argomento economico del loro posizionamento: meno intelligenza per dollaro significa più GPU per lo stesso risultato. L'obiettivo dichiarato non è onboardare grandi clienti ma mettere lo strumento in più mani possibili.
Il fine-tuning non è escluso, ma non è previsto: teme l'effetto fucile a pallettoni e preferisce puntare sulla calibrazione e su cascate di modelli di dimensioni diverse.
Come usarlo, secondo il suo autore
Il suo consiglio principale sta in una parola: scomporre. Porre molte piccole domande indipendenti invece di una grande, fino all'unità semantica più fine. L'esempio che dà: non chiedere "devo rifiutare qui?", ma interrogare separatamente ogni possibile situazione di rifiuto.
Il vantaggio è di ordine ingegneristico. Ogni domanda diventa misurabile, ogni bug si corregge aggiungendo una domanda o regolando una soglia, e il caso diventa un test permanente, al riparo dal context rot. Riassume: "è machine learning senza il machine learning".
Secondo consiglio: smettere di mettere tutto in stringhe di caratteri. State, istruzioni e criteri accettano JSON strutturato. I system message sono descritti come "orribili variabili globali" dove si accumula tutto sperando che ogni istruzione passi.
Sul fronte degli usi, classifica quattro grandi famiglie: i dark data che le aziende non osavano passare a un LLM per motivi di costo, i coding agent, il tempo reale e gli assistenti, e la verifica sistematica delle chiamate LLM. Il computer use, invece, è arrivato per sorpresa.
OpenAI, l'inverno dell'IA e il dibattito sul "pacing"
La parte biografica illumina il resto. Almeida racconta di essersi battuto per il deployment di InstructGPT, con di mezzo un algoritmo non pubblicato scritto da lui, per poi constatare che il risultato serviva soprattutto al copywriting. Da qui la sua domanda: cosa manca tra "molto intelligente" e "crea valore"?
La sua risposta: in una rivoluzione economica guidata dall'IA, la stragrande maggioranza delle chiamate verrà dal codice, non dagli umani — e tutta l'ottimizzazione andava verso gli umani. Dice di aver scritto un documento, di averne parlato con Sam Altman che gli ha consigliato di andare avanti, aver supposto che Anthropic lo stesse già facendo, per poi finire per fondare TypeSafe con Eric e poi Sasha.
Il suo motore dichiarato è la paura di un inverno dell'IA di cui si sentirebbe personalmente responsabile, sia per la direzione RLHF sia per non aver puntato tutto su di essa. Il suo obiettivo non è un punteggio ma una cifra macro: 3% di crescita della produttività totale dei fattori in cinque anni.
Sulla dichiarazione comune dei laboratori a favore di un rallentamento, parla di un gioco di prestigio: presuppone che tutti debbano fare sempre più RLVR lasciando i modelli agire liberamente. Per la sua forma di modello, "zero è la quantità ottimale". L'host aggiunge un'altra lettura, più prosaica: posizionamento politico in vista del 2028.
“Refusal is just like obviously a type error.”
“I think intelligence will be more like a database than a coworker.”
“If you gave me a billion dollars I wouldn't pre-train.”
Perché conta
Da tre anni il consenso di prodotto sull'IA sta in una parola: l'agente, o il collega digitale. Almeida propone l'esatto opposto — un'intelligenza banalizzata, invisibile, chiamata da programmi, fatturata come una richiesta di database e giudicata sulla sua affidabilità piuttosto che sulla sua intelligenza grezza. È una tesi coerente, argomentata tecnicamente, e ha il merito di spiegare un fatto scomodo: il software del 2026 assomiglia ancora a quello del 2019, con in più una chatbox laterale. Resta una tensione da non cancellare. Rifiutare i benchmark pubblici, le demo e il determinismo in nome della purezza ingegneristica significa anche rendere le rivendicazioni dell'azienda non verificabili dall'esterno, proprio nel momento in cui "intelligenza per dollaro" diventa un argomento commerciale. La promessa di non modificare mai un modello distribuito, invece, è impegnativa: è lì che bisognerà mantenerla.
Da leggere anche
99% o 0%: quattro esperti scommettono sulla fine del mondo
Steven Bartlett fa scrivere a quattro esperti la loro probabilità di estinzione su una busta. Le risposte vanno dal 99% allo zero, e il dibattito che segue è il più utile che abbiamo sentito sull'argomento.
Fonte · The Diary Of A CEO · AI Emergency: The AI Labs Are Lying To Everyone, He Says 99% Chance Of Extinction | Roman Yampolskiy
#data centerOggiCalifornia regola i data center: sette leggi in un colpo solo
Rendicontazione obbligatoria su acqua ed elettricità, fine delle scorciatoie ambientali: Sacramento vuole che l'industria dell'IA paghi le proprie bollette di rete.
Fonte · Governor of California (gov.ca.gov) · Governor Newsom signs most comprehensive data center laws in the nation, providing communities more control on water, electricity, and land use
#ricercaOggiOpenAI annuncia la risoluzione di Navier–Stokes e crea un comitato di matematici
In un solo post: un modello interno che dichiara di aver chiuso oltre 100 problemi aperti, e un gruppo di esperti indipendente per gestire l'onda d'urto.
Fonte · OpenAI · Advisory Group on Mathematics and Artificial Intelligence