Quando una persona come Salvatore Sanfilippo, creatore di Redis e sviluppatore con una storia tecnica difficilmente contestabile, commenta un nuovo modello di frontiera, vale la pena ascoltarlo con attenzione. Non perché l'autorità sostituisca la verifica, ma perché alcune autorità tecniche hanno una qualità rara: non parlano di modelli in astratto, li portano dentro problemi reali.
Le sue considerazioni su Claude Fable 5, condivise nei suoi ultimi video su YouTube, Claude Fable e Altre considerazioni su Claude Fable, sono interessanti proprio perché non confermano una narrativa semplice. Da una parte Sanfilippo descrive Fable come un modello potentissimo, capace di ragionare sui trade-off prima di lanciarsi in patch e tentativi. Dall'altra, nel secondo video, affina il giudizio: il salto da Opus è enorme, ma da GPT 5.5 è un "salto incrementale", specialmente se si considera la versione Pro.
Questa sfumatura è più importante della classifica. In un ecosistema in cui molti cercano il verdetto assoluto - "Claude è il migliore", "GPT è il migliore", "questo modello ha vinto" - una valutazione seria deve partire da un'altra domanda: migliore per cosa, in quale workflow, con quale vincolo e sotto quale forma di controllo umano?
Perché l'opinione di Sanfilippo pesa
Sanfilippo non è un creator generico che prova modelli su prompt dimostrativi. È il creatore di Redis, ha lavorato per anni su sistemi concreti, performance, strutture dati, C, debugging e software usato in produzione da milioni di sviluppatori. Quando valuta un modello su coding, non sta guardando solo se produce una funzione elegante. Guarda se capisce i vincoli, se individua i limiti fisici del problema, se evita lavoro inutile, se sa dire "qui probabilmente non conviene".
Nel primo video racconta un caso su Dwarf Star, il suo progetto di engine di inferenza locale per modelli open weight; per chi volesse capire meglio il contesto tecnico, Sanfilippo lo presenta nel dettaglio sul suo blog nell'articolo Dwarf Star. Il punto del racconto riguarda lo speculative decoding: invece di proporre subito approcci, Fable analizza il timing, i limiti del mixture of experts, il costo dell'attention e il fatto che certi guadagni non siano garantiti. Questa è una qualità rara nei coding agent: non generare codice per inerzia, ma ragionare sullo spazio delle possibilità.
Però il secondo video è ancora più utile, perché riduce l'entusiasmo iniziale a una forma più operativa. Sanfilippo dice, in sostanza, che Fable rappresenta un salto enorme rispetto a Opus, ma non un salto enorme rispetto a GPT 5.5. Questo sposta il discorso: forse non siamo davanti a un modello che rende irrilevanti gli altri, ma davanti a due famiglie di modelli frontier abbastanza vicine, con distribuzioni di forza diverse.
Il mito del modello migliore
Nel mondo AI c'è una tendenza comprensibile ma pericolosa: trasformare ogni rilascio in una graduatoria unica. Un benchmark sale, un thread diventa virale, un laboratorio pubblica esempi impressionanti, e in poche ore nasce la frase: "non esiste niente meglio di questo".
Il problema è che lo sviluppo software non è un benchmark unico. Un coding agent deve fare molte cose insieme: leggere il progetto, rispettare pattern esistenti, non rompere ciò che funziona, capire quando fermarsi, comunicare mentre lavora, accettare correzioni, mantenere una visione globale, non over-ingegnerizzare, produrre patch piccole quando servono patch piccole, e sapere quando il costo di una soluzione supera il beneficio.
Un modello può essere superiore in matematica, reasoning locale o analisi verticale, ma meno efficace in un workflow lungo dove il programmatore deve sterzarlo continuamente. Un altro può essere meno brillante su un problema isolato, ma più utile come collaboratore quotidiano perché mantiene contesto, comunica meglio e si lascia guidare.
La domanda non è quale modello vince in assoluto. La domanda è quale modello ti fa arrivare a una soluzione corretta, mantenibile e verificabile con meno attrito.
Claude può essere fortissimo e comunque non ideale per tutto
Una delle osservazioni più interessanti che emergono dai video riguarda la steerability. Sanfilippo nota che Fable dà pochi feedback mentre lavora e sembra meno facile da correggere durante il turno. Questo non è un dettaglio di interfaccia: è una proprietà fondamentale del rapporto tra sviluppatore e agente.
Quando un modello è molto autonomo, può sembrare più potente. Ma se l'autonomia riduce la capacità dell'umano di intervenire nel momento giusto, il vantaggio può diventare ambivalente. In software engineering, spesso il problema non è solo arrivare a una patch. È arrivarci senza perdere controllo sul ragionamento, sulle assunzioni e sui compromessi.
Qui entra la percezione che molti sviluppatori hanno usando Codex o ChatGPT in modo intensivo: in alcuni contesti sembrano più collaborativi, più steerable, più adatti a lavorare dentro un progetto vivo. Non necessariamente più intelligenti in ogni task. Ma più efficaci quando il lavoro richiede dialogo, revisione continua e visione d'insieme.
Over-engineering e visione di progetto
Un altro punto che vale la pena esplicitare è l'over-engineering. Alcuni modelli molto forti tendono a rispondere a ogni problema come se fosse l'occasione per disegnare un sistema più grande. Questo può essere utile in architettura, ma dannoso quando la richiesta reale è: capire il codice esistente, applicare una modifica minima, rispettare le convenzioni locali e non introdurre complessità non richiesta.
Nel lavoro quotidiano, la qualità non è solo produrre codice sofisticato. È anche riconoscere che una soluzione noiosa, leggibile e coerente con il repository è spesso superiore a una soluzione elegante ma aliena al progetto. Da questo punto di vista, molti utenti avanzati percepiscono Codex come particolarmente forte nella continuità operativa: leggere il contesto, mantenere il filo, collegare file, test, vincoli, branch, deploy e regressioni.
Questo non smentisce la forza di Claude. Al contrario, la rende più leggibile. Claude può eccellere quando il problema è verticale, profondo, tecnico e circoscritto. Codex può risultare più competitivo quando il problema è sistemico: molti file, vincoli impliciti, history del repository, test, ergonomia del workflow e necessità di collaborazione continua.
La cross review come metodo
Sanfilippo propone una pratica molto concreta: usare due modelli in "cross code review". Non dividere banalmente "questo fa design" e "quello fa codice", ma far revisionare a un modello il lavoro dell'altro, riportare la review al primo, applicare modifiche e poi far ricontrollare.
È un'intuizione forte perché tratta i modelli non come oracoli, ma come sistemi con distribuzioni diverse di errore. Se un modello vede un problema che l'altro ha ignorato, il secondo può riconoscerlo una volta che l'argomento viene esplicitato. Non serve che entrambi siano perfetti. Serve che sbaglino in modo non identico.
Questa è probabilmente una delle pratiche più mature oggi per usare AI nel software: non chiedere al modello di sostituire il giudizio tecnico, ma inserirlo in un ciclo di critica, verifica e riduzione del rischio.
Modelli più convincenti, errori più pericolosi
C'è un passaggio dei video che dovrebbe far riflettere tutti. Sanfilippo osserva che un modello più potente può essere anche più potente nel convincerti quando sbaglia. Non perché sia malevolo, ma perché costruisce argomenti migliori, usa più contesto, suona più autorevole e rende più difficile accorgersi del salto logico mancante.
Questo è un tema centrale per chi lavora con AI avanzata. L'errore non arriva più come output confuso e facilmente scartabile. Arriva in forma elegante, coerente, plausibile. A quel punto la competenza umana non diventa meno importante: diventa più importante. Serve sapere dove guardare, quali invarianti verificare, quali test scrivere, quali assunzioni isolare.
Quando un modello produce una spiegazione bella ma falsa, l'utente inesperto rischia di accettarla. L'utente esperto, invece, può usarla come ipotesi da stressare. La differenza sta nel metodo.
Safety, accesso e potere
Nei video emerge anche un tema delicato: i limiti imposti ai modelli frontier, soprattutto quando si parla di ricerca su LLM, cybersecurity, distillazione o capacità sensibili. Qui il discorso non è semplice. Esistono rischi reali. Ma esiste anche un problema di potere: chi decide quali capacità possono essere usate, da chi, per quali scopi e con quale trasparenza?
Se un modello diventa abbastanza potente da accelerare ricerca e sviluppo, limitarne l'accesso può essere una misura di sicurezza. Ma può anche diventare una forma di concentrazione del sapere. Il confine tra safety legittima e vantaggio competitivo protetto non è sempre chiaro, e proprio per questo va discusso pubblicamente.
Per aziende come Xseven, il punto pratico è un altro: non possiamo costruire processi critici assumendo che il modello più forte sarà sempre accessibile, sempre prevedibile e sempre disponibile alle stesse condizioni. Serve architettura di fallback, pluralità di modelli, audit umano e controllo sui dati.
Una regola per valutare i modelli AI
La conclusione non dovrebbe essere "Claude è meglio" o "Codex è meglio". Sarebbe troppo semplice e probabilmente falso già alla prossima release. Una regola più utile è questa: valuta i modelli sui tuoi problemi reali, con i tuoi vincoli, nel tuo workflow, misurando non solo la risposta finale ma il costo cognitivo per arrivarci.
In pratica, quando proviamo un modello dovremmo chiederci:
- capisce il contesto del repository o forza una soluzione generica?
- sa dire quando una strada non conviene?
- accetta correzioni durante il lavoro?
- produce patch proporzionate al problema?
- si perde in over-engineering?
- rende verificabili le sue assunzioni?
- migliora davvero il tempo totale fino a una soluzione affidabile?
Queste domande valgono più di molte classifiche. Perché una classifica misura un modello in astratto. Un workflow misura un modello dentro la realtà.
Conclusione: restare critici anche davanti ai migliori
La parte più interessante delle riflessioni di Sanfilippo non è stabilire se Fable sia primo, secondo o mezzo gradino sopra GPT 5.5. È l'invito implicito a usare i modelli come strumenti potenti ma fallibili, da interrogare, confrontare e verificare.
Forse Claude Fable 5 è oggi il modello più impressionante in molti task. Forse Codex resta superiore in alcuni workflow complessi di sviluppo reale. Forse tra poche settimane un nuovo rilascio cambierà di nuovo la mappa. Ma il punto maturo è un altro: non delegare mai il giudizio alla narrativa dominante.
Nel software, come nell'AI, il consenso è un segnale. Non è una prova. La prova resta il lavoro: codice che passa i test, architetture che reggono, sistemi che restano manutenibili, decisioni che possiamo spiegare e responsabilità che non scompaiono dietro il nome del modello più forte del momento.
Vuoi usare l'AI senza perdere controllo tecnico?
Aiutiamo team e aziende a integrare coding agent e modelli AI in workflow verificabili, con attenzione a sicurezza, governance e qualità del software.
Inizia la conversazione