Penso di essere stato troppo scettico riguardo al nuovo LLM di codifica Composer-1 di Cursor. Certo, è decisamente peggiore di GPT-5 High Effort e GPT-5-Codex, e in questo senso, quando progetto e implemento importanti progetti di codice, non vedo davvero un posto per esso nei miei flussi di lavoro. D'altra parte, è estremamente veloce (mi chiedo come abbiano fatto; stanno usando hardware Groq o Cerebras? è perché il modello è così piccolo ed efficiente? non sono sicuro), e questo da solo sblocca molti nuovi flussi di lavoro e tecniche di lavoro per quando il codice non è così critico per la missione, o quando stai iniziando un nuovo progetto e non devi preoccuparti di rompere il codice esistente. È anche molto, molto più economico rispetto a qualsiasi variante di GPT-5. La combinazione di molto più veloce e molto più economico crea una differenza qualitativa in come puoi usare il modello che non avevo pienamente apprezzato prima. Quando il costo di iterazione è così basso sia in termini di tempo che di denaro, puoi iterare molte più volte. Questo abbassa il valore della "correttezza al primo colpo"; cioè, la capacità di un modello come GPT-5 Pro di ottenere anche un compito di codifica complesso giusto la prima volta senza bug (anche se anche quel modello spesso fallisce in questo test molto rigoroso). Ma se puoi chiudere il ciclo di debug e rapidamente reinserire gli errori/avvisi nel modello, e ogni ciclo di iterazione richiede 20 secondi a un minuto (invece di 5 a 10 volte quel tempo almeno usando GPT-5 con alto sforzo), allora puoi risolvere rapidamente tutti gli errori grossolani che fa la prima volta (o anche la seconda, terza o quarta volta) e finire comunque con codice funzionante prima di quanto potresti fare con GPT-5. Se stai sviluppando qualcosa nel browser, ora puoi davvero chiudere il ciclo completamente usando la nuova scheda del browser di Cursor, che è di gran lunga la migliore implementazione di questo tipo che abbia visto in qualsiasi strumento di codifica (è di gran lunga superiore all'uso di Playwright MCP da Codex o Claude Code!). Ho usato questo prompt con grande effetto oggi: "Usa la scheda del browser per esplorare sistematicamente questa app e utilizzare l'interfaccia in modo naturale; mentre ciò accade, osserva eventuali avvisi o errori nella console di sviluppo. Quando ne vedi uno, inizia a diagnosticare e risolvere interattivamente e iterativamente i bug e i problemi e poi aggiorna l'app e verifica che l'errore o l'avviso sia completamente risolto. Quando risolvi le cose, concentrati sul determinare la vera causa radice del bug e non sull'applicare falsi "cerotti"!" Dove questo approccio si rompe davvero, però, è nelle fasi concettuali e di pianificazione in cui stai cercando di capire cosa fare e il modo migliore per implementarlo a un livello alto. Lì, la mancanza di pensiero profondo ed esplorazione può portarti su un cattivo cammino da cui è difficile riprendersi. Questo è molto più evidente quando il compito su cui stai lavorando si allontana molto dal "manifolds di dati" delle attività di codifica comuni. Se stai creando un altro semplice sito web CRUD, probabilmente non lo noterai molto. Se stai cercando di esplorare nuovi terreni in una simulazione di vita artificiale o qualcosa di strano del genere, lo noterai molto. Ma c'è un bel approccio ibrido che funziona davvero bene: combinare il modello più intelligente per la pianificazione con questi modelli veloci ed economici per produrre iterazioni. Quindi, usa GPT-5 Pro nell'app del browser per elaborare il tuo piano e un'implementazione iniziale, poi incolla quello in Cursor e inizia a iterare, risolvere e migliorare. È molto meglio nel modificare una solida base esistente che nel creare quella base stessa. Dove tutto questo brilla davvero è quando stai giocando ed esplorando con qualcosa di divertente, in un nuovo progetto dove non ci sono scadenze o aspettative. In questo contesto, la velocità è un vero cambiamento di gioco. Mi ricorda quella vecchia ricerca condotta da IBM all'inizio degli anni '80 che esaminava la latenza nei sistemi informatici, che scoprì che quando la latenza scende sotto un certo livello magico, come 50 ms, si verifica un grande cambiamento nel comportamento perché il cervello umano percepisce che sta trattando con un "sistema dal vivo." E, al contrario, quando la latenza supera anche un livello sorprendentemente modesto, come 500 ms, si ottiene molto meno coinvolgimento, ed è mentalmente faticoso e frustrante. Quando la latenza aumenta a pochi secondi o più, le persone tendono a disconnettersi mentalmente e diventa una lotta rimanere coinvolti. Vedere il modello di codifica rispondere in pochi secondi e fare una raffica di 10 modifiche in meno di 15 secondi è un'esperienza completamente diversa rispetto all'attendere 5 minuti affinché GPT-5 ad alto sforzo elabori qualcosa in modo metodico. ...