GPT-5.3-Codex-Spark vale la pena provarlo
Categories:
Chi conosce le valutazioni degli LLM sa che opus supera spesso gpt nelle classifiche di benchmark, ma nell’uso reale la capacità di gpt di risolvere problemi è imbattibile. Al momento della pubblicazione, i principali modelli più recenti della serie gpt5 includono gpt-5.2-mini, gpt-5.2, gpt-5.3-codex, gpt-5.3-codex-spark, ecc. Tra questi, i non-codex sono modelli generali, con logica potente ma molto lenti. Codex è un modello ottimizzato per la codifica; nei modelli codex precedenti a gpt5.2codex, ho riscontrato di persona un degrado delle capacità logiche, quindi ho continuato a usare gpt5.2 nonostante la sua velocità esasperantemente lenta. Dopo l’uscita di gpt-5.3-codex l’ho testato subito e i risultati reali sono ottimi: è ormai difficile dire se gpt-5.3-codex sia logicamente più debole di gpt5.2, ma in velocità surclassa gpt5.2, diventando il mio modello principale per la codifica. Di recente è uscito gpt-5.3-codex-spark: all’inizio si diceva fosse velocissimo, ma con punteggi di benchmark più bassi, così per un po’ non gli ho prestato attenzione. Vedendolo utilizzabile gratuitamente in cursor, ho deciso di dargli una chance e nei test reali si è comportato molto bene, senza fare sciocchezze. Secondo quanto ho appreso, la logica di 5.3-codex-spark è leggermente inferiore a 5.3-codex e il contesto è solo di 128K, ma sufficiente per la maggior parte delle esigenze. La caratteristica principale del modello codex-spark è la “pigrizia”: si muove un po’ solo se spronato. In primo luogo, non può essere il modello di guida per un agent: di fatto il suo punteggio come agent è basso. Non fa integrazioni non richieste, inclusi fix lint, esecuzione test, funzionalità non menzionate e todo. A differenza di modelli come opus/sonnet che appaiono subito brillanti, scavano infinite buche, partono refactoring immediati e lasciano problemi a catena, ritengo che codex spark sia un modello amichevole per i programmatori esperti. Non aggiunge ciò che non serve, segue il principio della minima modifica: se hai già una chiara pianificazione funzionale del prodotto, puoi provare codex spark. Una mia riflessione superficiale, benvenute le discussioni. Il vibe coding è codifica d’atmosfera; qualcuno dice che permette di entrare nel flow, ma ritengo che chi lo afferma non conosca la definizione precisa di flow. Un punto cruciale per entrare nel flow è che il pensiero dello sviluppatore non deve essere interrotto: serve un modello che primo non divaghi, secondo abbia obiettivi concentrati, terzo risponda prontamente. Nessun modello ci era riuscito prima; ora codex spark potrebbe diventare il modello che aiuta gli sviluppatori a entrare nel flow.
