Je pense que j'ai été trop désinvolte à propos du nouveau LLM de codage Composer-1 de Cursor. Certes, il est strictement moins bon que GPT-5 High Effort et GPT-5-Codex, et dans ce sens, lorsque j'architecte et mets en œuvre des projets de code importants, je ne vois vraiment pas de place pour lui dans mes flux de travail. D'un autre côté, il est extrêmement rapide (je me demande comment ils ont fait cela ; utilisent-ils du matériel Groq ou Cerebras ? est-ce parce que le modèle est si petit et efficace ? pas sûr), et cela à lui seul débloque beaucoup de nouveaux flux de travail et techniques de travail pour les moments où le code n'est pas si critique, ou lorsque vous commencez un nouveau projet et que vous n'avez pas à vous soucier de casser du code existant. Il est également beaucoup, beaucoup moins cher comparé à n'importe quelle version de GPT-5. La combinaison d'une vitesse beaucoup plus rapide et d'un coût beaucoup plus bas crée une différence qualitative dans la façon dont vous pouvez utiliser le modèle que je n'avais pas pleinement appréciée auparavant. Lorsque le coût d'itération est si bas tant en termes de temps que d'argent, vous pouvez itérer beaucoup plus de fois. Cela réduit la valeur de la "correction en une seule fois" ; c'est-à-dire la capacité d'un modèle comme GPT-5 Pro à obtenir même une tâche de codage complexe correctement du premier coup sans bugs (bien que même ce modèle échoue souvent à ce test très strict). Mais si vous pouvez fermer la boucle de débogage et rapidement renvoyer les erreurs/avertissements dans le modèle, et que chaque cycle d'itération prend 20 secondes à une minute (au lieu de 5 à 10 fois plus longtemps au moins en utilisant GPT-5 avec un effort élevé), alors vous pouvez rapidement résoudre toutes les erreurs négligentes qu'il commet la première fois (ou même la deuxième, troisième ou quatrième fois) et finir avec un code fonctionnel plus tôt que vous ne pourriez le faire avec GPT-5. Si vous développez quelque chose dans le navigateur, vous pouvez maintenant vraiment fermer la boucle complètement en utilisant le nouvel onglet de navigateur de Cursor, qui est de loin la meilleure implémentation de ce genre que j'ai vue dans n'importe quel outil de codage (c'est de loin supérieur à l'utilisation de Playwright MCP de Codex ou de Claude Code !). J'ai utilisé ce prompt avec un grand effet aujourd'hui : "Utilisez l'onglet du navigateur pour explorer systématiquement cette application et utilisez l'interface de manière naturelle ; pendant que cela se produit, surveillez TOUT avertissement ou erreur dans la console de développement. Lorsque vous en voyez un, commencez à diagnostiquer et à corriger les bugs et problèmes de manière interactive et itérative, puis rafraîchissez l'application et vérifiez que l'erreur ou l'avertissement est complètement résolu. Lorsque vous corrigez des choses, concentrez-vous sur la détermination de la véritable cause profonde du bug et non sur l'application de faux "pansements" !" Là où cette approche se dégrade vraiment, cependant, c'est dans les phases conceptuelles et de planification où vous déterminez quoi créer et la meilleure façon de l'implémenter à un niveau élevé. Là, le manque de réflexion approfondie et d'exploration peut vous faire commencer sur un mauvais chemin dont il est difficile de se remettre. Cela est beaucoup plus apparent lorsque la tâche sur laquelle vous travaillez s'éloigne beaucoup du "manifold de données" des tâches de codage courantes. Si vous créez encore un autre site web CRUD simple, alors vous ne le remarquerez probablement pas beaucoup. Si vous essayez de fouler un nouveau terrain dans une simulation de vie artificielle ou quelque chose d'étrange comme ça, vous le remarquerez beaucoup. Mais il existe une belle approche hybride qui fonctionne très bien : combiner le modèle le plus intelligent pour la planification avec ces modèles rapides et bon marché pour produire des itérations. Donc, utilisez GPT-5 Pro dans l'application de navigateur pour élaborer votre plan et une implémentation initiale, puis collez cela dans Cursor et commencez à itérer, corriger et améliorer. Il est beaucoup mieux pour modifier une base solide existante que pour établir cette base elle-même. Là où tout cela brille vraiment, c'est lorsque vous jouez et explorez avec quelque chose de fun, dans un nouveau projet où il n'y a pas de délais ou d'attentes. Dans ce contexte, la vitesse est un véritable changement de jeu. Cela me rappelle cette ancienne recherche réalisée par IBM au début des années 80 qui a examiné la latence des systèmes informatiques, qui a révélé que lorsque la latence descend en dessous d'un certain niveau magique, comme 50 ms, vous obtenez ce grand changement de comportement parce que le cerveau humain perçoit qu'il traite un "système en direct". Et, inversement, lorsque la latence dépasse même un niveau modestement surprenant, comme 500 ms, vous obtenez beaucoup moins d'engagement, et c'est mentalement épuisant et frustrant. Lorsque la latence monte à quelques secondes ou plus, les gens ont tendance à se déconnecter mentalement et il devient difficile de rester engagé. Voir le modèle de codage répondre en quelques secondes et faire une rafale de 10 modifications en moins de 15 secondes est tout simplement une expérience complètement différente que d'attendre 5 minutes que GPT-5 à effort élevé traite quelque chose. ...