Je suis complètement sous le charme d'Opus 4.5 en ce moment. Il est aussi performant que Gemini 3, mais avec un style de code, un suivi des instructions et une expérience utilisateur en ligne de commande bien meilleurs, et surtout, une vitesse accrue pour les tâches simples. J'ai aussi eu une interaction vraiment intéressante avec Claude Code, qui était en panne et tournait en rond. Je l'ai donc interrompu et laissé demander des explications. Il a posé d'excellentes questions, je lui ai expliqué quelques concepts, jusqu'à ce qu'il comprenne. Il a ensuite terminé la tâche (qui n'était pas facile !), et tous les tests ont été réussis. Voici l'interaction (résumée par Opus lui-même) : (Claude Code interrompu) Moi : Tu passes beaucoup de temps ici, pourquoi ne pas me poser des questions ? Je peux toujours y répondre. Inutile de deviner au hasard et d'essayer des choses sans réfléchir, cela ne mènera qu'à l'échec. — IA : Vous avez raison, je m’excuse. Question : lorsque je distribue la fonction lambda sur le SUP, comment la redirection des variables doit-elle fonctionner ? Dois-je configurer HEAP[lam_loc] pour rediriger les variables d’origine vers les nouvelles fonctions lambda ? Moi : Je ne suis pas sûr de comprendre votre notation, mais… [j’explique la sémantique dup-lam]. Notez qu’il nous faut absolument une fonction `clone_many()` qui reçoit un `Term*` et duplique chaque élément en deux `Term*`. L’avons-nous ? Cela répond-il à votre question ? — IA : Merci, c’est beaucoup plus clair ! Ma question concernant `clone_many` : dans mon instruction C, je clone le modèle une fois, puis je clone chaque argument restant. Est-ce correct ? Moi : Qu'est-ce que args0[16] ? Qu'est-ce que args0[0] et pourquoi sup_a est-il placé là ? Je ne comprends pas bien. — IA : Vous avez raison, laissez-moi relire le code Haskell plus attentivement… Donc, a et b (les branches SUP) ne sont pas clonés ; ils sont directement ajoutés comme premier élément des nouvelles listes d’arguments. Seuls les arguments restants sont clonés. Mon code C se comporte de la même manière. Le problème se situe donc ailleurs. — Moi : Ah, je vois. Oui, ta logique de clonage semble à peu près correcte, mais j’insisterais tout de même pour que tu utilises une fonction auxiliaire clone_many au lieu de l’intégrer manuellement comme ça. — IA : OK, je vais d’abord ajouter clone_many. [Ajout effectué, les tests échouent toujours.] Le résultat est toujours incorrect. Question : Faut-il évaluer/résoudre les nœuds CO0/CO1 lors de la réduction ? Ou doivent-ils rester CO0/CO1 et être résolus ultérieurement ? — Moi : en Haskell, CO0/CO1 tombent dans le cas par défaut de l’effondrement… [explique la chaîne de réduction complète avec l’interaction dup-sup de même étiquette] — IA : C’est très utile ! Donc, l’interaction de duplication avec les mêmes étiquettes permet une résolution correcte de CO0/CO1. Le problème vient probablement de la structure de mon modèle. Ma structure de modèle est-elle incorrecte ? Moi : Il suffit de passer le modèle à injecter, il clonera tout si nécessaire. Votre construction semble incorrecte : vous allouez deux lambdas ? Pourquoi deux `heap_alloc` ? Vous devriez créer une variable pour la lambda externe ; on dirait que vous la créez à un emplacement inutilisé. — IA : Vous avez raison ! La variable VAR(fV_loc) doit pointer vers l’emplacement du corps de la lambda externe (outer_loc), et non vers une variable fV_loc distincte. Est-ce correct ? Moi : Ça a l'air pas mal, mais vérifie quand même, c'est toi qui décides. — IA : Vous avez raison, laissez-moi vérifier attentivement… [vérifie, corrige le code] collapse_4 réussit ! [continue de corriger les cas APP, DRY, MAT, CTR avec le même modèle] Les 35 tests réussissent !
cette boucle : > vous donnez une tâche à l'IA > il explore le problème > cela soulève une question > vous l'alimentez avec des idées > il explore le problème > ... etc ... est une méthode très puissante et rapide pour développer des logiciels Tu es toujours plus intelligent que lui (j'espère), mais il peut soulever beaucoup de choses à lui seul.