Il Qwen3.8-Max di Alibaba sostiene di poter programmare da solo per due settimane

Il 2 ottobre, il team Qwen di Alibaba ha rilasciato Qwen3.8-Max, un modello mixture-of-experts da 2,4 trilioni di parametri che l'azienda descrive come competente in centinaia di tipi di attività, tra cui diritto, finanza e design. L'affermazione che ha attirato più attenzione era più ristretta del conteggio dei parametri. Secondo il comunicato, il modello può lavorare in autonomia alla programmazione per più di una dozzina di giorni per consegnare un progetto completo.

Il numero di parametri ha smesso da tempo di fare notizia. “Dodici giorni” è il numero che vale la pena esaminare, perché descrive un tipo di capacità diversa da quella delle demo con cui la maggior parte dei modelli viene rilasciata.

Un compito contro un progetto

La maggior parte dei benchmark sui modelli di programmazione misura una singola unità di lavoro: scrivere una funzione, correggere un bug, rispondere a una domanda su un repository. L'orizzonte è di minuti. Un modello che supera quei test ha dimostrato di saper produrre un output corretto quando il problema è specificato del tutto e il risultato è verificabile in un solo passaggio.

Un progetto che richiede dodici giorni non è una funzione più lunga. È una sequenza di decisioni in cui ciascuna vincola la successiva, e in cui il modello deve tenere a mente un design attraverso migliaia di modifiche. Le modalità di fallimento cambiano. Un modello corretto al 95 per cento a ogni passaggio è un assistente eccezionale per un compito di cinque minuti e un rischio su uno di due settimane, perché gli errori si accumulano e nessuno controlla ogni modifica.

Ecco perché l'affermazione sull'orizzonte conta più del numero di parametri. Sposta la questione dalla capacità all'affidabilità.

Cosa richiede davvero un orizzonte lungo

Tre cose devono funzionare, e nessuna di esse è una proprietà puramente del modello.

Al primo posto ci sono la memoria e la gestione dello stato. Dodici giorni di lavoro non possono stare in una finestra di contesto, per quanto grande sia. Il sistema deve esternalizzare lo stato del compito, scrivere i risultati intermedi su disco e riprendere da un checkpoint dopo un'interruzione. Questa è infrastruttura attorno al modello, e la sua correttezza determina se un'esecuzione lunga sopravvive a un riavvio.

Al secondo posto c'è l'autocorrezione. Su un orizzonte lungo, il modello prenderà strade sbagliate. Senza un umano che riveda ogni passaggio, ha bisogno di un modo per accorgersi che un approccio sta fallendo e rivederlo prima che il fallimento si propaghi. Ciò significa che il modello deve valutare il proprio output intermedio rispetto all'obiettivo originale, un compito più difficile che generare l'output stesso.

Al terzo posto c'è la stabilità degli strumenti. Un progetto di più giorni toccherà una base di codice, un test runner, la documentazione e probabilmente un gestore di pacchetti. Ogni chiamata a uno strumento è un'occasione di disallineamento tra ciò che il modello si aspetta e ciò che l'ambiente restituisce. Su migliaia di chiamate, è la coda di quella distribuzione a porre fine all'esecuzione.

Messi insieme, i dodici giorni sono un'affermazione su un intero sistema: il modello più l'harness più l'ambiente. È un modo utile di leggerla, perché ti dice dove guardare quando fallisce.

Il dibattito sull'harness è il sottotesto

Il momento del rilascio non è casuale. C'è un acceso confronto tra i ricercatori di agenti su quanto scaffolding serva ancora a un modello forte. La domanda è se modelli migliori rendano obsoleti gli elaborati framework per agenti, o se sia il framework a generare l'affidabilità.

Un'affermazione di lavoro autonomo per dodici giorni si colloca su un lato di quel confronto. Implica che il modello possa portare il carico e che il framework sia un attore di supporto. Ma i tre requisiti appena visti suggeriscono il contrario: è il framework a rendere possibile l'orizzonte, e il modello è un componente al suo interno.

Entrambe le letture possono essere vere allo stesso tempo, ed è probabilmente il modo più equo di porre la questione. Modelli più forti riducono quanto accompagnamento richieda un compito, e alzano anche il tetto di ciò che un harness ben costruito può ottenere. Un modello capace di pianificare su un orizzonte lungo vale di più dentro un buon harness, non di meno.

La metà della promessa che riguarda l'ufficio

Il rilascio affianca la programmazione al lavoro d'ufficio, e questa combinazione non è casuale. Entrambe sono categorie in cui l'output è verificabile, ed è questo che rende praticabile l'autonomia. Un foglio di calcolo con un errore di formula si può testare. Un contratto a cui manca una clausola si può verificare rispetto a una checklist. Il modello non deve avere ragione sul mondo in generale, ma solo su un compito con una risposta verificabile.

È anche per questo che l'affermazione è più ristretta di quanto suoni all'inizio. Un modello che può lavorare in autonomia per due settimane su una base di codice non è la stessa cosa di un modello che può lavorare in autonomia per due settimane su una domanda di ricerca aperta, dove nessuno può dire se il lavoro è corretto se non molto più tardi. L'inquadramento del rilascio mantiene la promessa dentro il dominio in cui esiste il feedback.

Letta così, la cifra dei dodici giorni diventa un'affermazione tanto sulla verifica quanto sulla capacità. Più lungo è l'orizzonte, più il sistema dipende dalla capacità di controllare il proprio lavoro.

C'è una logica commerciale nella scelta di questi due domini. Programmazione e lavoro d'ufficio sono gli ambiti in cui le aziende hanno già budget e in cui l'output può essere valutato senza uno specialista. Un modello che automatizza un compito di sviluppo di due settimane ha un ritorno misurabile. Un modello che scrive poesie no.

Come valutare l'affermazione

Ignora il numero di parametri e cerca tre dettagli concreti.

Chiedi cosa significa “autonomo” in pratica. Un'esecuzione di dodici giorni con checkpoint umani occasionali è un prodotto diverso da una che procede senza supervisione. Le aziende raramente dichiarano dove si trovano i checkpoint, e quel dettaglio determina l'utilità più della durata complessiva.

Chiedi cosa ha prodotto l'esecuzione. Un progetto completato è un artefatto testabile. Un repository, una suite di test che passa e un deployment funzionante si possono verificare. Screenshot e demo narrate no.

Chiedi cosa è successo quando qualcosa si è rotto. Le esecuzioni lunghe falliscono, e l'informazione interessante sta nel come. Un modello che rileva un vicolo cieco e torna indietro è molto più utile di uno che va avanti e produce un risultato dall'aria plausibile che però non funziona.

Cosa dice questo sul mercato

Il fatto che Alibaba rilasci un modello di punta rivolto alla programmazione e al lavoro d'ufficio invece che alla chat generica è una dichiarazione su dove si trovi il valore. Il mercato dei chatbot per consumatori è affollato e difficile da monetizzare. Il lavoro per cui le aziende pagheranno è quello che sostituisce o potenzia ore di lavoro, e quel lavoro ha orizzonti lunghi.

Se l'affermazione dei dodici giorni regge anche solo in parte, l'effetto pratico è che un piccolo team può tentare progetti che prima ne richiedevano uno più numeroso. Se non regge, il modello resta comunque un forte assistente di programmazione con un contesto ampio, e la frase sui dodici giorni svanirà da sola dal marketing. In ogni caso, è l'inquadramento la parte utile. Oggi la capacità si misura tanto da quanto a lungo un modello riesce a continuare a lavorare senza supervisione quanto da ciò che sa fare in un colpo solo.