Di solito la conversazione gira intorno ai soliti “big”: Opus, Sonnet, Gemini, Codex. Modelli fortissimi, ovviamente. Però, nella pratica di tutti i giorni, Composer 2.5 mi sta sorprendendo parecchio.
Il modello da daily work, non da benchmark
Non lo vedo come il modello da benchmark o da demo spettacolare. Lo vedo più come il modello da daily work: bugfix, piccoli refactor, comprensione del progetto, modifiche multi-file, pulizia del codice, task ripetitivi ma delicati.
La cosa interessante è che Composer 2.5 non è solo “un altro modello disponibile in un editor”. È un modello pensato per vivere dentro Cursor. E questa differenza si sente.
Integrazione > capacità pura
Ho provato diversi modelli, tra cui GLM 5.1, GLM 4.7, MiniMax M2.7, DeepSeek 4 Flash e DeepSeek 4 Pro, ma nel mio workflow reale, su codice vero e task di lavoro, non sono riuscito a usarli con la stessa naturalezza.
Spesso il problema non è solo la capacità del modello, ma l’integrazione: recupero del contesto, modifiche multi-file, patch, terminale, navigazione tra sorgenti, continuità del task. Composer 2.5 invece ha un vantaggio fortissimo: è integrato di default dentro Cursor, è pensato per l’agent loop di Cursor, e sembra ottimizzato proprio per quelle cose che nei benchmark spesso non emergono.
Allenato per il punto esatto in cui lo usi
Cursor spiega che Composer 2.5 parte dallo stesso checkpoint open-source di Composer 2, cioè Kimi K2.5 di Moonshot, e che il post-training include targeted RL, feedback testuale, distillation/KL loss e task sintetici basati su codebase reali. E secondo me questa cosa, usandolo, si sente.
Non dà solo l’impressione di essere “intelligente”. Dà l’impressione di essere allenato per lavorare bene nel punto esatto in cui lo stai usando.
Ad oggi, tra i modelli fuori dalla fascia dei grandi nomi, Composer 2.5 è uno dei pochissimi che riesco davvero a usare a lavoro senza sentire subito il bisogno di tornare a Opus, Sonnet, Gemini o Codex.
Non sempre vince il modello più famoso
A volte vince quello più integrato nel workflow.
Case study: Nexus AI in full vibe coding
Il mio ultimo progetto l’ho sviluppato praticamente in full vibe coding con Composer 2.5: Nexus AI, un’app Flutter pensata per far girare modelli AI on-device, usando librerie come flutter_gemma, modelli quantizzati e un flusso locale dove l’utente può interagire con un assistente direttamente dal dispositivo.
Il senso è semplice: meno dipendenza da API remote, meno costi ricorrenti, più controllo sui dati e più privacy.
Il flusso è stato AI centrico:
- Google Stitch per la UI
- Composer per scrittura codice e implementazione design Stitch tramite MCP
- Omni per il video promozionale partendo dal design
Quindi non parlo solo di “mi ha aiutato a scrivere qualche funzione”. La cosa divertente è che, alla fine, un’AI mi ha aiutato a scrivere un’app per far girare altre AI.