Cela peut sembler stupide, mais l'un des plus grands hacks de productivité lors de l'utilisation de Claude Code avec Opus 4.1 est le suivant : après avoir demandé à CC d'implémenter une fonctionnalité ou de corriger un bug ou quoi que ce soit d'autre, et après qu'il ait dit qu'il avait tout terminé, vous devez simplement lui répéter la phrase suivante encore et encore jusqu'à ce qu'il ne trouve plus d'erreurs (ce qui peut parfois prendre jusqu'à 7 ou 8 essais !) : "Super, maintenant je veux que tu relises attentivement tout le nouveau code que tu viens d'écrire et l'autre code existant que tu viens de modifier avec des "yeux neufs", en cherchant très attentivement des bugs évidents, des erreurs, des problèmes, des soucis, de la confusion, etc." Oui, cela prend un certain temps, mais c'est pourquoi il est si pratique d'avoir plusieurs sessions CC ouvertes en même temps. Vous pouvez alors simplement faire défiler ces sessions, en collant cette phrase encore et encore. D'une manière ou d'une autre, le truc des "yeux neufs" change la façon dont il perçoit ce qu'il vient d'écrire d'une manière vraiment utile. Étrangement, ce truc ne semble pas fonctionner aussi bien avec la réflexion de GPT-5 - il a tendance à dire simplement "Oui, tout semble correct !" Claude est beaucoup plus enclin à douter et à faire des erreurs par négligence la première fois, mais il est bon pour les attraper si on lui donne suffisamment d'occasions.

Quiconque chez OpenAI a décidé de casser l'API pour GPT-5 (et o3, c'est un vieux problème) en changeant le paramètre "max_tokens" en "max_completion_tokens" dans une tentative de rendre les choses plus claires... vous avez fait une grosse erreur. Cela ne couvrira jamais les innombrables heures perdues par les développeurs sur du code cassé.

Après plusieurs jours d'utilisation intensive de GPT-5 via Cursor et via le modèle GPT-5 Pro dans l'application web, je maintiens tout ce que j'ai dit sur le fait que c'est un modèle beaucoup plus intelligent et meilleur en codage que l'Opus 4.1. J'aime toujours Opus et je trouve que l'ergonomie de Claude Code est plus agréable à bien des égards, mais si vous essayez de faire des choses vraiment difficiles qui nécessitent une réflexion vraiment intelligente basée sur des principes fondamentaux et des compétences en informatique, GPT-5 est d'un niveau supérieur. Mais je soupçonne que cela n'émerge que lorsque le mode d'effort de raisonnement est réglé sur au moins moyen, et se manifeste vraiment avec le réglage d'effort élevé. Un bon exemple de problème est la préparation des "redlines" de deux longs et complexes documents juridiques. Pas différentes versions du même document, mais deux documents différents qui proviennent d'un modèle général partagé. C'est un problème très, très difficile à bien résoudre, et cela nécessite de nombreuses astuces et heuristiques intelligentes pour donner des performances et une qualité de sortie décentes (je parle ici d'utiliser des techniques de programmation traditionnelles, pas d'utiliser des LLMs pour faire cette comparaison). GPT-5 avec l'agent Cursor peut simplement proposer plus d'idées, meilleures, plus intelligentes (mais pragmatiques) plus rapidement, et les mettre en œuvre correctement et sans trop de guidance, par rapport à l'Opus 4.1. Cela dépend de ce sur quoi vous travaillez, cependant. Je pense toujours que je préfère le code frontend en NextJS par Opus, par exemple. Mais vous devriez absolument vérifier par vous-même sur vos propres problèmes réels et ne pas faire confiance à toutes les nombreuses personnes disant que le modèle est nul et que c'est la preuve que nous avons atteint un mur. Soit ils utilisent la mauvaise version gratuite sans réfléchir, soit ils n'ont aucune idée de comment formuler des requêtes efficacement, soit ils laissent leurs sentiments envers OpenAI et Altman influencer leurs opinions.

J'adore à quel point les "améliorations" sont faciles à réaliser à l'ère des LLM. Boum, vous venez d'améliorer votre application en environ 3 secondes !

Le GPT-5 Max gratuit dans Cursor pour la semaine de lancement est un cadeau incroyable d'une grande valeur. J'ai déjà 6 agents Cursor qui travaillent dur à la recherche de problèmes dans un gros projet. Ça a l'air très bon jusqu'à présent !

Dire que GPT-5 ment beaucoup moins que o3 ne signifie en réalité pas grand-chose étant donné à quel point o3 est un menteur pathologique absolu ! Même une réduction de 80 % se traduirait toujours par plusieurs mensonges par jour en cas d'utilisation intensive.

C'est drôle que la démo de GPT-5 mette en avant à quel point il est un grand écrivain... et ensuite montre un pur désordre avec des tirets dans chaque phrase. Ils devraient s'en tenir aux démos de codage, qui sont beaucoup plus impressionnantes ! De plus, je déteste qu'ils déprécient tous les anciens modèles...

Avec le recul, il est difficile de croire que personne n'a pris la peine de mettre en œuvre un réseau de neurones multi-couches avec une descente de gradient stochastique de base en 1997 sur le 3dfx Voodoo, quelques années avant même le premier GPU de Nvidia en 1999. Les éléments étaient essentiellement tous là pour un petit LLM.

Je pense que le plus grand compliment que je peux faire à @patrickc et à l'équipe de Stripe, c'est qu'ils ont une si grande réputation et un tel palmarès de création d'interfaces utilisateur/expériences utilisateur (UI/UX) vraiment soignées et intuitives pour leurs services qu'il est très pratique de les mentionner par leur nom dans les invites de codage pour obtenir de meilleurs résultats des agents de codage IA. Par exemple, j'ai une variante de cela enregistrée dans mon éditeur de texte et je la colle dans Claude Code au moins 10 fois par jour : "Je veux que tu fasses un travail spectaculaire en construisant des composants UI/UX de classe mondiale pour afficher ces rapports de notation, montrant à la fois les détails et aussi sous forme de "badges" ou de "cartes de résumé", avec un accent intense sur la création de la qualité UI/UX la plus visuellement attrayante, conviviale, intuitive, élégante, soignée, de niveau "Stripe" possible pour cela, en tirant parti des bonnes bibliothèques qui font déjà partie du projet." Ensuite, je lui dis que ce qu'il a créé n'est vraiment pas si génial ("terrible" ou "incroyablement mauvais") même si c'est déjà assez bon, et qu'il doit l'améliorer DRAMATIQUEMENT pour atteindre véritablement des niveaux de plaisir utilisateur et d'élégance, de finition, d'intuitivité, etc. de classe Stripe. En gros, appliquer la technique de manipulation de Steve Jobs pour obtenir itérativement des résultats "incroyablement géniaux". Et oui, cela fonctionne incroyablement bien si vous continuez à le faire encore et encore. Le truc, c'est que vous devez inclure TOUS ces adjectifs, sinon cela se dégradera en icônes tournant et pulsant comme des acrobates ("élégant" et "visuellement attrayant"); vous avez besoin des autres termes comme "soigné" et "intuitif" et "de niveau Stripe" pour tempérer cela afin que ce soit aussi quelque peu minimaliste et agréable à utiliser en pratique. Je suis content de ne pas avoir à travailler pour moi en tant qu'agent IA :/

Je viens de lire le nouveau document GSPO de l'équipe Qwen. C'est drôle de voir à quel point ces grandes améliorations théoriques, malgré une base fondamentale apparemment profonde (dans ce cas, le fait qu'optimiser à travers des séquences de tokens est meilleur qu'optimiser à travers des tokens individuels), se résument finalement à laisser les gradients circuler mieux en évitant les problèmes de conditionnement numérique. Quand on prend du recul et qu'on regarde cela, le GSPO est fondamentalement un moyen d'obtenir un meilleur conditionnement numérique en moyennant les choses ensemble lors des mises à jour pour éviter les bosses bruyantes (presque comme utiliser le momentum dans rmsprop ou Adam) et en ignorant également les mises à jour qui pourraient mener à des situations « dangereuses » sur le plan numérique en termes de conditionnement. Mais tout cela a du sens d'un point de vue historique, puisque l'apprentissage profond a vraiment explosé lorsque nous avons compris comment éviter le problème de gradient qui disparaît/explose en utilisant des choses comme le momentum dans les optimisateurs. Donc, d'une certaine manière, c'est simplement la dernière étape dans cette tradition de navigation dans le paysage de la perte de manière plus robuste pour éviter de « conduire dans un fossé ».