Abbiamo usato gli LLM anche per lavori per cui non servivano. Poi è arrivato Jev.

Per gli ultimi anni abbiamo avuto una risposta quasi automatica a ogni problema che richiedeva un minimo di interpretazione: mettiamoci un LLM. Devi capire se un’email riguarda vendite o assistenza? LLM. Devi stabilire se un ticket è urgente? LLM. Devi decidere quale tool deve usare un agente? Ancora LLM.

E funziona. Il punto è un altro: forse abbiamo iniziato a usare modelli generativi anche per lavori che non avevano bisogno di generare niente. È un po’ come chiamare uno chef stellato ogni volta che qualcuno deve decidere se una porta debba essere aperta o chiusa.

Il 15 settembre TypeSafe AI ha presentato Jev, il suo primo System One Model: un modello progettato non per scrivere testi o sostenere conversazioni, ma per prendere decisioni strutturate dentro il software. La cosa interessante non è semplicemente che esista un nuovo modello. È l’assunzione che mette in discussione: per rendere un software intelligente, non è detto che ogni problema debba diventare una conversazione con un LLM.

EDITORIAL NOTE

“Forse il futuro dell’AI non è un cervello sempre più grande. Potrebbe essere un sistema che sa quale cervello usare.”

INAZUMA / EDITORIAL LENS”

Immagina che un cliente scriva: “È la terza volta che vi contatto. Il rimborso non è ancora arrivato e se non risolvete oggi cancello tutto.” Un LLM classico può leggere il messaggio, riassumerlo, spiegare il problema e scrivere una risposta. Ma il software spesso non ha bisogno di un paragrafo. Ha bisogno di sapere cosa deve succedere dopo.

• FACT 01INTENT → REFUND
• FACT 02URGENCY → HIGH
• FACT 03CHURN RISK → HIGH
• FACT 04ROUTE → RETENTION
• FACT 05HUMAN REVIEW → YES

Jev riceve uno stato — per esempio testo, dati del cliente e contesto del processo — e una serie di domande con uno spazio di risposta definito. Restituisce Choice, Boolean o Score, insieme a probabilità. In parole semplici: non deve trovare le parole giuste. Deve aiutare il software a scegliere.

Un LLM general purpose è straordinario quando il risultato deve essere aperto: scrivere una mail, programmare, spiegare un concetto, creare una proposta, riassumere documenti o ragionare su un problema ambiguo. Jev rinuncia volutamente a quella libertà.

Non gli chiedi “che cosa dovremmo fare?”. Gli chiedi qualcosa come “questa richiesta appartiene a SALES, BILLING o SUPPORT?”, “quanto è urgente da 0 a 10?” oppure “serve revisione umana?”. TypeSafe chiama questa famiglia System One Models, richiamando l’idea di un pensiero rapido: decisioni circoscritte, veloci e strutturate.

Sì. Ed è probabilmente la prima obiezione corretta di uno sviluppatore. Possiamo chiedere a GPT, Claude o Gemini uno structured output, validarlo con uno schema e ottenere department: sales, priority: high. Quindi il vantaggio non è semplicemente “Jev produce JSON”.

La differenza è nel lavoro per cui il modello è stato progettato. Un LLM rimane un modello generativo che stiamo guidando verso un output strutturato. Jev nasce direttamente intorno a decisioni tipizzate e probabilità. TypeSafe dichiara, nei propri benchmark di workflow, fino a circa 193,6 volte più velocità e 444,6 volte minor costo rispetto agli LLM confrontati. Sono benchmark del produttore, quindi vanno trattati come un segnale da verificare sul proprio caso, non come una garanzia universale.

Un’azienda non è composta soltanto da conversazioni. Ogni giorno qualcuno decide dove mandare una richiesta, se un caso è urgente, se un documento è completo, quale lead contattare per primo, quando coinvolgere una persona e quale processo deve partire. Molte di queste decisioni sono ripetitive, contestuali e abbastanza delimitate da poter essere modellate.

Ed è qui che Jev diventa interessante: non come “nuovo ChatGPT”, ma come possibile componente invisibile tra un input e la prossima azione del sistema.

Un OCR legge una fattura. Un modello o un parser estrae i dati. Poi arriva la parte meno spettacolare e più operativa: che documento è? Mancano campi? Sembra anomalo? Va registrato automaticamente o mandato in revisione? A quale coda appartiene?

• FACT 01TIPO DOCUMENTO → FATTURA
• FACT 02DATI MANCANTI → YES
• FACT 03ANOMALIA → MEDIUM
• FACT 04REVIEW UMANA → YES
• FACT 05CODA → ECCEZIONI

Jev non “fa la contabilità”. Può essere il nodo che decide cosa deve succedere al documento dopo che gli altri componenti lo hanno letto.

Un lead entra nel CRM con azienda, dimensione, settore, ruolo, attività recente e comportamento sul sito. Un decision model può valutare ICP fit, intent, priorità e routing. Poi un LLM può fare la parte in cui è fortissimo: ricerca, sintesi e messaggio personalizzato.

• FACT 01ICP FIT → HIGH
• FACT 02INTENT → HIGH
• FACT 03PRIORITY → 9/10
• FACT 04ROUTE → ACCOUNT EXECUTIVE
• FACT 05RESEARCH REQUIRED → YES

EDITORIAL NOTE

“Il decision model sceglie. Il generative model comunica.”

SYSTEM DESIGN”

“Sono tre giorni che aspetto e se non risolvete chiudo l’account.” Prima di scrivere la risposta, il sistema deve capire cosa sta succedendo: intent, urgenza, rischio di churn, necessità di escalation. Un decision model può occuparsi di quella valutazione; un LLM può poi generare la risposta; il CRM recupera il contesto; il codice verifica cosa il sistema è autorizzato a fare.

• FACT 01INTENT → REFUND
• FACT 02URGENCY → HIGH
• FACT 03CHURN RISK → HIGH
• FACT 04ESCALATE → TRUE

Questa separazione è importante: decidere che un rimborso sarebbe appropriato non significa avere il permesso di eseguirlo. Policy, permessi e transazioni certe devono restare nel codice e nei sistemi di controllo.

Le operations sono piene di happy path ed eccezioni. Una fattura normale attraversa il processo. Una fattura con un ordine mancante si blocca e qualcuno deve capire perché. Un decision model può classificare l’eccezione, assegnarle una severità e instradarla senza trasformare ogni caso in una lunga chiamata a un frontier model.

• FACT 01DUPLICATE → NO
• FACT 02PURCHASE ORDER MISSING → YES
• FACT 03SEVERITY → 6/10
• FACT 04ROUTE → PROCUREMENT
• FACT 05HUMAN REVIEW → YES

Il valore non è “avere Jev”. È togliere dal team centinaia di piccole classificazioni ripetitive mantenendo visibili le eccezioni.

CV e job description possono essere valutati lungo dimensioni definite: esperienza richiesta, dominio, competenze presenti, necessità di revisione. Ma qui il confine è importante: un punteggio non dovrebbe trasformarsi automaticamente in una decisione finale su una persona. Il modello può aiutare a organizzare e prioritizzare; governance, bias, normativa e supervisione umana diventano parte del sistema.

Nell’e-commerce può classificare recensioni, richieste di reso, motivazioni e priorità. In finance può distinguere tipi di eccezione, dati mancanti e livelli di rischio operativo. Nelle assicurazioni può aiutare a classificare una pratica, capire se manca documentazione o se il caso richiede revisione. In tutti questi esempi la distinzione è la stessa: classificare e instradare non significa delegare automaticamente la decisione finale.

Un agente AI lavora continuamente attraverso piccoli bivi: continuo o mi fermo? Uso il tool A o il tool B? Chiedo chiarimento all’utente? Devo escalare? Devo provare un’altra strategia? Oggi spesso è lo stesso LLM che ragiona, decide, scrive e controlla l’intero loop.

• FACT 01CONTINUE?
• FACT 02RETRY?
• FACT 03ASK USER?
• FACT 04USE TOOL A?
• FACT 05USE TOOL B?
• FACT 06ESCALATE?
• FACT 07STOP?

Un decision model può inserirsi proprio in questi nodi, lasciando ai reasoning model i casi complessi e ai generative model il linguaggio. Vercel cita tool routing, sub-agent routing, continuation e stopping tra i casi d’uso che sta esplorando con Jev.

Molte architetture AI sono ancora mentalmente semplici: INPUT → LLM → OUTPUT. Il modello legge, interpreta, classifica, decide, scrive, verifica e instrada. È comodo, ma concentra lavori molto diversi nello stesso componente.

Una possibile architettura più matura è: codice per ciò che sappiamo con certezza; decision model per classificare, valutare e instradare; reasoning model per i problemi complessi; generative model per scrivere e conversare; tool per agire; persone per approvazioni, eccezioni e decisioni sensibili. Non è una ricetta universale. È un modo migliore di fare la domanda.

Jev restituisce probabilità, e questo permette di progettare livelli diversi di automazione. Un caso ad altissima confidenza può proseguire automaticamente; uno intermedio può richiedere un controllo; uno incerto può essere passato a un modello più capace o a una persona. Le soglie però non sono universali.

Il costo di sbagliare una categoria di newsletter è quasi nullo. Il costo di sbagliare una decisione che muove denaro o impatta una persona può essere enorme. Le soglie devono essere validate sui propri dati e sul costo reale dell’errore.

Una PMI probabilmente non comprerà mai “Jev” e non dovrebbe interessarle il nome del modello. Le interessa che le richieste arrivino al reparto giusto, che i lead migliori vengano visti, che le eccezioni emergano prima, che il personale faccia meno classificazione manuale e che il sistema sappia quando fermarsi.

EDITORIAL NOTE

“Il valore non è “abbiamo integrato un System One Model”. Il valore è “il tuo team non deve più prendere 400 micro-decisioni ripetitive ogni giorno”.”

BUSINESS LENS”

Jev non è un sostituto di Claude, GPT o Gemini. È interessante proprio perché può stare accanto a loro. Se togliamo ai frontier model i compiti semplici e ripetitivi, possiamo usare i modelli più potenti dove servono davvero: ambiguità, ragionamento, linguaggio, sintesi e creatività.

Un buon sistema potrebbe usare contemporaneamente codice per ciò che è certo, Jev per decisioni circoscritte, Claude o GPT per ragionamento e linguaggio, database e API per lo stato reale, e persone per eccezioni e decisioni sensibili. Non è una gara tra modelli. È architettura.

Non perché sia “più intelligente di GPT”. Sarebbe una lettura sbagliata. Jev introduce una seconda dimensione nella scelta di un modello: non solo quanto è capace, ma per quale lavoro è stato progettato.

Il segnale sembra aver incuriosito anche gli sviluppatori: Vercel ha riportato che nelle prime 24 ore Jev è stato usato da quasi il 13% dei team paganti sull’AI Gateway, più del doppio di qualsiasi precedente lancio di modello sulla piattaforma. È un dato di adozione iniziale, non una prova che diventerà uno standard. Ma indica che il problema che prova a risolvere è reale abbastanza da meritare esperimenti.

EDITORIAL NOTE

“Il futuro dell’AI potrebbe non essere un cervello sempre più grande. Potrebbe essere un sistema che sa quale cervello usare, quando usarlo e quando non usare AI affatto.”

INAZUMA / SYSTEMS FIRST”

Abbiamo passato gli ultimi anni a costruire modelli che sapessero fare sempre più cose: scrivere, ragionare, programmare, vedere, ascoltare, usare strumenti. Forse il prossimo passo sarà imparare a distribuire quei lavori. Il codice gestisce ciò che sappiamo. Un decision model sceglie entro confini chiari. Un reasoning model affronta l’ambiguità. Un generative model comunica. Gli strumenti agiscono. Le persone controllano ciò che conta.

A quel punto l’AI smette di essere una chatbox infilata dentro un processo. Diventa parte dell’architettura.