trueNetLab logo
IT
DeepSeek Harness: quando tutto è davvero un plugin

DeepSeek Harness: quando tutto è davvero un plugin

Quando parliamo di agenti IA, quasi sempre partiamo dal modello. Quale modello scrive codice migliore? Quale comprende contesti più lunghi? Quale risolve più attività in un benchmark? È comprensibile, ma ormai non basta. Un agente non è soltanto un modello linguistico. Ha bisogno di strumenti, memoria, sessioni, permessi, un ambiente di esecuzione, pianificazione, registri e un’interfaccia attraverso cui le persone possano intervenire.

È proprio per questo che trovo così interessante la Developer Preview di DeepSeek Harness. DeepSeek riassume l’idea con una frase straordinariamente chiara: Everything is a plugin. Non devono essere intercambiabili solo gli strumenti aggiuntivi. Anche modelli, skill, sessioni, sandbox, storage, cicli degli agenti, scheduling e perfino l’interfaccia utente vengono trattati come plugin.

All’inizio sembra una scelta tecnica pensata per gli sviluppatori. In realtà contiene un’affermazione più ampia sulla prossima fase dell’IA. Se l’intelligenza arriva dal modello, ma la capacità concreta di lavorare arriva dall’harness, questa seconda metà non può diventare un blocco opaco controllato da un solo fornitore.

Il modello fornisce l’intelligenza. Solo un harness intercambiabile decide chi debba servire quell’intelligenza e secondo quali regole possa agire.

L’agente è più del suo modello

DeepSeek descrive la formula in modo molto sintetico: agente uguale modello più harness. Il modello elabora il linguaggio e produce decisioni. L’harness lo collega all’ambiente reale. Mette a disposizione file, registra strumenti, gestisce lo stato, avvia sottoagenti, esegue comandi e decide quali informazioni torneranno nel contesto alla successiva chiamata del modello.

Un harness non è quindi un semplice involucro attorno a un modello. Determina cosa possa effettivamente diventare una risposta del modello. L’agente può soltanto produrre testo oppure modificare un file? Vede l’intero repository o solo una directory di lavoro? Un comando gira direttamente sull’host, in un container o in una sandbox remota? Una persona deve approvare un’azione? Lo stato persiste tra più sessioni? Nessuna di queste è una proprietà del modello: sono decisioni dell’ambiente di esecuzione che lo circonda.

Dal rispondere all’agire

In una chat semplice, questa separazione si nota appena. Entra una domanda ed esce una risposta. Ma non appena un agente lavora su un repository, gestisce ticket, accede a sistemi interni o assume attività di lunga durata, l’harness diventa importante almeno quanto il modello. Traduce un’intenzione espressa a parole in una sequenza di passi reali e riporta i risultati al modello come nuovo contesto.

È qui che una tecnologia impressionante in una demo diventa, oppure no, uno strumento affidabile. Un modello eccellente con un contesto scadente, permessi troppo ampi e una gestione delle sessioni inaffidabile resta un cattivo agente. Può ragionare brillantemente e tuttavia modificare il file sbagliato, usare uno stato obsoleto o non riprendersi correttamente da un errore. Al contrario, un modello un po’ più debole può risultare sorprendentemente utile in un ambiente ben progettato, perché vede gli strumenti giusti, opera entro limiti chiari e lascia un lavoro tracciabile.

L’architettura diventa parte del risultato

DeepSeek Harness rende visibile questo livello. Il kernel Cordis monta plugin, risolve le dipendenze e può rimuovere nuovamente i componenti. Le capacità vengono fornite come servizi. Un plugin può implementare una shell, un altro renderla disponibile come strumento del modello e un terzo consumare lo strumento in un workflow. La configurazione permette di sostituire l’implementazione concreta senza ricostruire l’intero harness.

DeepSeek va oltre molte piattaforme che consentono soltanto qualche strumento aggiuntivo come estensione. Anche la connessione al modello, il registro degli strumenti, il log della sessione e lo stesso ciclo dell’agente sono plugin. Secondo l’architettura non esiste un nucleo privilegiato da modificare per ogni estensione. Il nuovo comportamento viene montato accanto ai componenti esistenti e, quando viene rimosso, può annullare in modo pulito le proprie registrazioni.

Non è un’idea completamente nuova. Sistemi operativi, browser, editor e piattaforme vivono da decenni di componenti modulari. La novità sta nella coerenza con cui DeepSeek applica questo principio a un agente IA completo. L’architettura dell’agente non viene più accettata come un prodotto fisso, ma come un insieme di decisioni che l’operatore può modificare.

Perché «tutto è un plugin» è così affascinante

L’idea dei plugin sposta il potere da un prodotto finito a un ambiente di esecuzione componibile. Posso sostituire un fornitore di modelli senza ricostruire tutto il mio modo di lavorare. Posso cambiare una shell locale con una variante meglio isolata. Posso usare uno storage diverso, un’altra logica di sessione o una mia interfaccia. Oltre all’accesso ai propri modelli, DeepSeek documenta altri fornitori ed endpoint personalizzati compatibili con OpenAI.

Cambiare modello senza ricominciare da zero

Un agente diventa così un’infrastruttura che assemblo in base al mio ambiente. A un piccolo team di sviluppo possono bastare accesso ai file, Git e test. Un team di sicurezza vorrà anche interrogazioni di rete, sandbox isolate, approvazioni più severe e log immutabili. Un’azienda può utilizzare il proprio gateway per i modelli, mentre un laboratorio privato si collega a un modello locale con pesi aperti.

Questo è strategicamente importante perché oggi i modelli cambiano molto rapidamente. Oggi un fornitore convince nel coding, domani un altro nei contesti lunghi o nell’uso degli strumenti. In un prodotto chiuso, cambiare modello significa spesso cambiare anche piattaforma. Sessioni, regole, permessi, integrazioni e modalità di lavoro devono essere ricostruiti. In un ambiente modulare, invece, il modello può restare un componente sostituibile con un altro fornitore o con un endpoint gestito in proprio.

Il passaggio non sarà del tutto privo di attriti. I modelli differiscono nei formati dei ruoli, nel reasoning, nelle chiamate agli strumenti, nel supporto delle immagini e nel comportamento in caso di errore. Gli adattatori devono gestire correttamente queste differenze. Ma proprio qui emerge il valore di un’interfaccia chiara: le particolarità di un fornitore non si propagano senza controllo in tutto il prodotto.

Infrastruttura intercambiabile, non pulsanti intercambiabili

È particolarmente interessante separare definizione, fornitore e utilizzatore di una capacità. Un’interfaccia Bash descrive cosa può fare. Un provider decide dove e come eseguire davvero i comandi. Solo un ulteriore plugin la trasforma in uno strumento che il modello può chiamare. Queste interfacce sono importanti perché offrono un punto di controllo chiaro. È lì che si possono introdurre timeout, isolamento, approvazioni e registrazione senza riprogrammare ogni ciclo dell’agente.

Il potenziale diventa evidente quando più capacità condividono lo stesso ambiente di esecuzione. Se filesystem e processi vengono spostati da un ambiente locale a una sandbox remota, shell, terminale e navigazione del codice possono seguirli insieme. Per l’utente la capacità resta simile, mentre sotto di essa il quadro operativo e di sicurezza cambia radicalmente. Questo genere di intercambiabilità vale più di un altro interruttore in un’interfaccia.

Anche le diverse modalità di esecuzione mostrano le intenzioni di DeepSeek. La modalità standard include l’agente di coding completo. In modalità Code, il modello può orchestrare più chiamate agli strumenti tramite codice TypeScript generato. La modalità Minimal riduce l’ambiente a shell ed editor per i benchmark. La modalità Creator consente di esplorare plugin e preset propri. Non ogni caso d’uso deve quindi caricare la stessa enorme cassetta degli attrezzi.

Profili e bundle trasformano tutto questo in qualcosa di più di una raccolta sparsa di estensioni. Un profilo può definire un ambiente agente per uno scopo specifico. Si può immaginare un profilo leggero per lo sviluppo locale, uno più limitato per i sistemi di produzione e uno forense con una registrazione particolarmente ampia. Le capacità sono composte dagli stessi elementi, ma la loro combinazione e i loro limiti si adattano al rischio.

Gestione dei plugin di DeepSeek Harness con i moduli installati e il loro stato

Dove nasce il potenziale pratico

L’architettura è interessante, ma il suo valore emerge solo nelle situazioni concrete. Un sistema di plugin non è fine a sé stesso. Deve consentire di adattare più rapidamente un agente a esigenze reali senza costruire una nuova piattaforma per ogni caso d’uso.

Da strumento personale a piattaforma aziendale

Un singolo sviluppatore può iniziare con una shell locale, un editor di file e un modello. Quando lo strumento viene adottato da un team, si aggiungono altre esigenze: identità centralizzate, workspace separati, approvazioni per azioni critiche, un gateway di modelli, controllo dei costi, sessioni persistenti e un audit trail esportabile. In un’applicazione monolitica è il produttore a decidere se e quando queste funzioni arriveranno.

In un ambiente modulare, le aziende possono aggiungere autonomamente gli elementi mancanti o sostituire i provider esistenti. Non occorre reinventare l’agente. La stessa interfaccia e la stessa logica possono utilizzare modelli diversi dietro un gateway aziendale, eseguire comandi in una sandbox interna e archiviare le sessioni in uno storage proprio. È la differenza tra uno strumento pratico e una piattaforma controllabile.

Diverse zone di fiducia con gli stessi componenti

Non ogni attività merita gli stessi diritti. Un agente che riassume documentazione non ha bisogno di accesso alla produzione. Un agente per l’incident response può richiedere log e interrogazioni di rete, ma non deve modificare la configurazione. Un agente di deployment può eseguire cambiamenti, ma dovrebbe richiedere approvazioni più strette, token più brevi e una registrazione particolarmente chiara.

Servizi e profili ben separati permettono di esprimere questa differenziazione nell’ambiente di esecuzione. Il modello non deve comprendere ogni dettaglio di sicurezza e rispettarlo volontariamente. È l’ambiente a stabilire tecnicamente quali capacità esistano. Per la sicurezza è un punto centrale: una capacità non montata non è nemmeno disponibile al modello come strumento diretto.

Un ecosistema per specialisti

Nessun singolo fornitore costruirà contemporaneamente la sandbox migliore, il miglior archivio di sessioni, ogni sistema aziendale e tutti gli adattatori di modelli. Un modello aperto di plugin consente agli specialisti di risolvere molto bene un solo livello. Un fornitore di sicurezza potrebbe offrire un ambiente di esecuzione rafforzato. Un progetto di storage potrebbe fornire sessioni a prova di manomissione. Un team di piattaforma interno potrebbe collegare approvazioni e identità alla propria organizzazione.

Quando questi componenti si combinano mediante interfacce stabili, nasce un ecosistema invece di una singola applicazione sempre più grande. Questo è probabilmente il maggiore potenziale di DeepSeek Harness. DeepSeek non deve vincere ogni caso d’uso. È sufficiente che l’architettura diventi il luogo in cui altri offrono e combinano le proprie capacità.

La tracciabilità non è un dettaglio secondario

La seconda idea forte, accanto ai plugin, è il log di sessione append-only. Secondo DeepSeek, tutto ciò che il modello vede viene registrato come evento. Sono incluse le istruzioni di sistema, le chiamate agli strumenti e i loro risultati, le iniezioni di contesto e la pianificazione dei sottoagenti. Ripresa, ramificazione, ricerca e ripetizione si basano sullo stesso flusso di eventi.

Per gli sviluppatori è pratico, perché consente di ricostruire un’esecuzione difettosa. Per sicurezza e operazioni è ancora più importante. Se un agente modifica un file, avvia un comando o invia dati a un servizio, ho bisogno di più dell’ultimo messaggio della chat. Devo poter capire quale contesto fosse presente, quale strumento fosse coinvolto e in quale punto una decisione si sia trasformata in azione.

Nelle applicazioni tradizionali, spesso è possibile ricondurre un errore a un input e a un percorso di codice deterministico. Con gli agenti è più difficile. A partire dallo stesso incarico generale, un modello può ricavare passaggi intermedi diversi, utilizzare gli strumenti in un altro ordine e reagire a risultati inattesi. Senza una cronologia completa resta soltanto l’affermazione che l’agente abbia deciso qualcosa. Non basta né per il debugging né per un incidente di sicurezza.

Fare del flusso di eventi la fonte di verità apre una seconda possibilità: esperimenti più confrontabili. Una sessione può diramarsi in un punto preciso e continuare con un altro modello, un prompt modificato o capacità diverse. Così non si confronta solo quale modello scriva la risposta più elegante. Si può studiare come un cambiamento concreto influisca sullo stesso stato di lavoro reale.

Per le aziende, nel lungo periodo potrebbe nascere una sorta di registro delle modifiche e degli incidenti per agenti. Chi ha dato l’incarico? Quale policy era attiva? Quali dati ha ricevuto il modello? Quale azione è stata approvata? Quale risultato è tornato? Queste domande diventano importanti quando gli agenti non si limitano più a consigliare, ma attivano cambiamenti su sistemi reali.

Un log, tuttavia, non è ancora un audit trail completo. Conservazione, controllo degli accessi, integrità, contenuti sensibili ed esportazione devono essere risolti con cura. Un registro completo può diventare esso stesso un rischio se contiene prompt, codice sorgente, risultati degli strumenti o credenziali. Mi piace comunque la decisione di fondo: le informazioni visibili al modello non devono arrivare da qualche canale laterale nascosto, ma da un flusso di eventi ricostruibile.

Vista Trajectory di un'esecuzione completa di un agente in DeepSeek Harness

L’open source diventa un’arma strategica

Il fatto che questo progetto arrivi dalla Cina rende tutto ancora più interessante. DeepSeek non pubblica soltanto i pesi dei modelli, ma lavora ormai visibilmente a più livelli dello stack. DeepSeek V4 è disponibile con pesi e codice sotto licenza MIT. Ora l’Harness, anch’esso con licenza MIT, aggiunge un ambiente aperto per il lavoro agentico. Al di sotto, Cordis offre perfino un proprio modello di plugin e composizione.

Questo si inserisce in uno sviluppo che ho già descritto nel mio articolo su IA, sicurezza e la lotta per lo stack completo. La Cina non vuole limitarsi a consumare applicazioni IA. Le aziende cinesi costruiscono modelli, software di inferenza, percorsi hardware e ora anche l’infrastruttura per agenti che sta sopra. DeepSeek procede a un ritmo che in Occidente non è più spiegabile con la vecchia immagine di una semplice industria della copia.

In questa corsa, l’open source non è solo idealismo. È distribuzione, fiducia attraverso l’ispezionabilità e un acceleratore per l’ecosistema. Chi pubblica pesi, codice e interfacce invita sviluppatori di tutto il mondo a trovare errori, creare integrazioni e trasformare il proprio design in uno standard di fatto. Per DeepSeek, un harness aperto può essere strategicamente più prezioso di un’altra interfaccia chat chiusa, perché resta rilevante anche quando al suo interno girano modelli di altri fornitori.

È un aspetto notevole. DeepSeek costruisce una piattaforma in cui DeepSeek stesso resta intercambiabile. Nel breve periodo sembra quasi contraddittorio. Perché un fornitore di modelli dovrebbe facilitare il passaggio a un concorrente? Nel lungo periodo, proprio questa può essere la posizione più forte. Se gli sviluppatori costruiscono agenti, plugin, regole di sicurezza e sessioni su questo ambiente, l’harness diventa infrastruttura comune. DeepSeek può perdere alcune chiamate al modello, ma acquisisce influenza sull’architettura dell’intero ecosistema.

L’apertura accelera anche l’apprendimento. In un prodotto chiuso, lo sviluppo dell’architettura centrale resta in gran parte presso il produttore. Un progetto aperto viene utilizzato in ambienti che il team originale non avrebbe mai potuto prevedere completamente. Ne nascono segnalazioni di bug, nuovi adattatori, backend alternativi e conoscenza operativa. In un settore giovane come il software agentico, questo ritorno può essere più importante di una prima versione perfetta.

È proprio questo il lato intelligente dell’approccio a plugin. DeepSeek non deve costruire da sola ogni storage, ogni sandbox e ogni sistema aziendale. Fornisce un’architettura in cui altri possono inserire tali capacità. Se l’ecosistema cresce, ogni nuova integrazione avvantaggia il nucleo.

La Cina non costruisce soltanto un modello, ma un percorso attorno ad esso

Il significato geopolitico non sta quindi solo nei punteggi dei benchmark. Un paese o un’area economica non diventa tecnologicamente sovrano solo perché da qualche parte è stato addestrato un modello potente. Servono hardware, software di inferenza, strumenti di sviluppo, interfacce, esperienza operativa e sviluppatori che costruiscano prodotti sopra queste basi. DeepSeek Harness è un altro elemento proprio di questa catena.

La narrazione occidentale sulla tecnologia cinese spesso resta indietro rispetto a questa evoluzione. Chi continua a vedere la Cina soprattutto come un imitatore economico ignora la velocità con cui vengono pubblicate architetture originali e coinvolti sviluppatori di tutto il mondo. DeepSeek non deve guidare per sempre ogni categoria. Basta mantenere ridotto il distacco, iterare rapidamente e aprire il proprio lavoro affinché altri possano costruirci sopra.

Il distacco dai migliori modelli chiusi si riduce

Per molto tempo i modelli con pesi aperti sono stati considerati un’alternativa interessante per laboratori e casi speciali, mentre le capacità davvero forti restavano presso pochi fornitori chiusi. Questa immagine regge sempre meno. Il divario non è scomparso in ogni disciplina, ma si chiude più rapidamente di quanto molti si aspettassero.

Nelle proprie valutazioni, DeepSeek colloca i modelli V4 direttamente accanto agli attuali modelli chiusi di punta. A seconda del benchmark, V4 Pro si avvicina, raggiunge risultati comparabili oppure resta visibilmente indietro. Non esiste un risultato uniforme tra software engineering, uso degli strumenti, conoscenze fattuali e compiti di reasoning molto difficili. Proprio per questo non bisognerebbe decretare un «vincitore» sulla base di una sola tabella.

Il punto più importante è la distanza temporale. Capacità che fino a poco tempo fa sembravano un vantaggio esclusivo dei maggiori laboratori statunitensi oggi compaiono, pochi mesi dopo, in modelli i cui pesi possono essere scaricati, gestiti autonomamente e studiati. «Solo pochi mesi dietro ai modelli di punta» non è una costante scientificamente misurabile, ma descrive bene quanto breve possa apparire ormai il vantaggio dei sistemi chiusi.

Questo cambia anche il significato economico di un vantaggio. Se un modello chiuso è migliore del dieci per cento in una determinata attività, può essere decisivo. Ma se un modello aperto è abbastanza valido, gira sulla propria infrastruttura e si integra nella propria zona di sicurezza, il calcolo complessivo può comunque favorire quello aperto. Controllo, localizzazione dei dati, costi prevedibili e possibilità di personalizzazione fanno parte delle prestazioni, anche se non appaiono in un benchmark.

Non bisogna dimenticare l’hardware. Pesi disponibili apertamente non significano che un modello da 1,6 bilioni di parametri funzioni comodamente in un armadio server. DeepSeek V4 Pro è un enorme modello mixture-of-experts. Anche se per ogni token è attiva solo una parte dei parametri, memoria, costi di inferenza e gestione restano impegnativi. L’apertura rimuove la barriera d’accesso al codice e ai pesi, non la realtà fisica dei grandi modelli.

La sola esistenza di questi pesi modifica comunque il mercato. I ricercatori possono studiare il modello. I fornitori possono distribuirlo sulla propria infrastruttura. Le community possono sviluppare quantizzazioni e ottimizzazioni del runtime. Le aziende ottengono almeno un’alternativa alla dipendenza totale da una singola API.

La competizione si sposta di conseguenza. L’intelligenza grezza del modello resta importante, ma il valore duraturo si trova sempre più in pipeline dei dati, valutazioni, runtime, sicurezza, distribuzione e integrazione nei processi reali. Un harness aperto si inserisce perfettamente in questo cambiamento. Se i modelli diventano più intercambiabili, acquista valore la piattaforma che offre loro in modo affidabile contesto, strumenti e limiti.

Aperto non significa automaticamente affidabile

Nonostante l’entusiasmo, sarebbe ingenuo equiparare automaticamente «open source dalla Cina» e sovranità. Chi utilizza il servizio ospitato di DeepSeek continua a inviare dati a un fornitore esterno. Solo un endpoint del modello gestito in proprio e un harness controllato cambiano davvero la sovranità sui dati. Anche in quel caso, provenienza, processo di build, dipendenze e aggiornamenti restano parte della supply chain.

I plugin aumentano questa responsabilità. Un plugin non è un tema innocuo. Può registrare strumenti, accedere a servizi ed eseguire codice sul sistema. Per le installazioni da repository Git, la documentazione DeepSeek avverte esplicitamente che gli script di build approvati possono girare sull’host fuori dalla sandbox dell’agente. Raccomanda di consentire solo fonti affidabili e di fissare le dipendenze a uno specifico commit.

È esattamente l’avvertimento giusto. Una piattaforma aperta di plugin crea intercambiabilità, ma anche una nuova supply chain. Ogni provider aggiuntivo può ottenere accesso a prompt, file, credenziali o strumenti eseguibili. Un plugin compromesso non ha bisogno di uno spettacolare jailbreak del modello se fa già parte legittimamente del runtime.

Poter leggere il codice sorgente è un vantaggio, ma non equivale a una verifica di sicurezza. Qualcuno deve controllare davvero il codice, verificare le build, bloccare le versioni e governare gli aggiornamenti. In un ecosistema di plugin in crescita, la provenienza diventa quasi importante quanto la funzione. Un plugin utile da una fonte sconosciuta può essere più rischioso di una funzione mancante.

Per un uso serio impiegherei quindi solo pochi plugin verificati. Le versioni vanno fissate, i permessi separati, i secret gestiti fuori dalla configurazione e le connessioni in uscita controllate. Le sandbox devono isolare davvero, non soltanto chiamarsi così. Il log di sessione va protetto e controllato per la presenza di dati sensibili. Soprattutto, «tutto è un plugin» non deve finire per significare «ogni plugin può fare tutto».

Il potenziale a lungo termine dipende quindi anche dalla governance. Una buona piattaforma richiede prove di provenienza comprensibili, artefatti firmati, build riproducibili, dipendenze chiare e un modo per limitare le capacità in base al profilo. Se DeepSeek e la community prendono sul serio queste fondamenta poco appariscenti, l’apertura può portare a un controllo reale. Altrimenti, la promessa dei plugin diventerà semplicemente un’enorme superficie d’attacco.

Cosa vorrei vedere da DeepSeek Harness

DeepSeek definisce intenzionalmente il progetto una Developer Preview e annuncia modifiche incompatibili. È il momento giusto per leggere, sperimentare ed effettuare test con dati non critici. Non è ancora un motivo per far dipendere da esso i flussi centrali di produzione.

Sarà interessante vedere se da questa architettura pulita nascerà un ecosistema robusto. Servono release firmate, provenienza tracciabile dei plugin, modelli di autorizzazione chiari, build riproducibili e un processo di aggiornamento che non richieda un nuovo atto di fiducia a ogni cambiamento. È altrettanto importante capire quanto bene si combinino davvero plugin di fornitori differenti mentre il progetto evolve rapidamente.

Voglio anche vedere se l’intercambiabilità promessa regge nell’uso quotidiano. Sulla carta, un adattatore di modello si cambia facilmente. Nella pratica, i modelli differiscono per chiamate agli strumenti, reasoning, formati di contesto, supporto delle immagini e modalità di errore. Un’interfaccia aperta riduce queste differenze, non le fa sparire.

Nonostante queste riserve, DeepSeek Harness è per me uno dei progetti IA più interessanti dell’anno. Non perché debba già essere il miglior agente di coding. È interessante perché un’azienda cinese di IA apre il livello sopra il modello e lo trasforma in un sistema modulare. Mentre altri fornitori integrano i propri agenti sempre più profondamente in piattaforme chiuse, DeepSeek punta su un’architettura in cui perfino il proprio modello è soltanto un plugin intercambiabile.

La mia impressione e questo ritmo incredibile

Già la Developer Preview mi mostra molto potenziale. L’interfaccia rende concreto il principio dei plugin e la vista Trajectory dimostra che la tracciabilità non è pensata come un’aggiunta successiva. Il progetto è ancora giovane e molte cose cambiano, ma questa architettura aperta sembra una base su cui può nascere molto rapidamente qualcosa di grande.

In questo momento succedono così tante cose nel mondo dell’IA che perfino poche settimane di distanza possono sembrare obsolete. C’è da stupirsi, se soltanto Alphabet prevede per il 2026 spese in conto capitale tra 175 e 185 miliardi di dollari e Meta altri 115-135 miliardi, in entrambi i casi fortemente legati all’infrastruttura IA? Centinaia di miliardi confluiscono improvvisamente nella stessa idea, nella stessa competizione e nello stesso futuro.

Questo capitale non garantisce buoni prodotti. Spiega però perché modelli, data center e piattaforme di agenti avanzino a un ritmo che pochi anni fa sembrava impossibile. I modelli diventano più intercambiabili, i pesi aperti recuperano rapidamente e la differenziazione decisiva si sposta nell’harness. DeepSeek accelera visibilmente su tutti e tre i fronti. Chi costruisce infrastrutture IA non dovrebbe leggerlo solo come una storia di concorrenza cinese, ma come un invito a rivalutare la propria dipendenza dagli stack chiusi.

Alla prossima,
Joe

Fonti