Avant de brûler beaucoup de tokens avec un grand essaim d'agents sur un nouveau projet, le vieil adage du travail du bois "Mesurez deux fois, coupez une fois !" vaut la peine d'être révisé en "Vérifiez vos perles N fois, implémentez une fois," où N est essentiellement autant que vous pouvez supporter. J'ai constaté que vous continuez à obtenir de plus en plus d'améliorations, même si elles sont subtiles, plus vous exécutez cela consécutivement avec Opus 4.5 (notez que l'invite suivante est uniquement à utiliser APRÈS que vous ayez déjà transformé votre plan markdown initial en perles en utilisant l'autre invite que j'ai donnée récemment dans mon très long post sur mes flux de travail) : "Relisez AGENTS dot md pour que ce soit encore frais dans votre esprit. Vérifiez chaque perle super soigneusement-- êtes-vous sûr qu'elle a du sens ? Est-elle optimale ? Pourrions-nous changer quelque chose pour que le système fonctionne mieux pour les utilisateurs ? Si oui, révisez les perles. C'est beaucoup plus facile et rapide d'opérer dans l'espace "plan" avant de commencer à implémenter ces choses ! NE SIMPLIFIEZ PAS LES CHOSES ! NE PERDEZ AUCUNE CARACTÉRISTIQUE OU FONCTIONNALITÉ ! De plus, assurez-vous qu'en tant que partie de ces perles, nous incluons des tests unitaires complets et des scripts de test e2e avec une excellente journalisation détaillée afin que nous puissions être sûrs que tout fonctionne parfaitement après l'implémentation. N'oubliez pas d'utiliser UNIQUEMENT l'outil `bd` pour créer et modifier les perles et pour ajouter les dépendances aux perles. Utilisez ultrathink." J'avais l'habitude de ne l'exécuter qu'une ou deux fois avant de commencer l'implémentation, mais j'ai récemment expérimenté en l'exécutant 6 fois ou plus, et cela continuait à apporter des améliorations utiles. Si cela commence à stagner en termes d'améliorations incrémentales des perles, vous pourriez essayer de commencer une toute nouvelle session CC, en commençant par : "Lisez d'abord TOUT le fichier AGENTS dot md et le fichier README dot md super soigneusement et comprenez TOUT des deux ! Ensuite, utilisez votre mode agent d'investigation de code pour comprendre pleinement le code, l'architecture technique et le but du projet. Utilisez ultrathink." Et ensuite, suivez avec la même invite que celle montrée ci-dessus, mais précédée de : "Nous avons récemment transformé un fichier de plan markdown en un tas de nouvelles perles. Je veux que vous examiniez et analysiez cela très soigneusement en utilisant `bd` et `bv`." Plus votre plan markdown est complexe et intriqué, plus cette technique est pertinente. Si vous avez un petit plan trivial et un projet très simple, cela est évidemment excessif. Mais dans ce cas, vous verrez probablement peu de gains/changements incrémentaux à chaque tour, donc il devrait être assez évident quand il est temps d'arrêter. N'oubliez pas : les tokens de planification sont beaucoup moins nombreux et moins chers que les tokens d'implémentation. Même un plan markdown très grand et complexe est plus court que quelques fichiers de code substantiels, sans parler d'un projet entier. Et les modèles sont beaucoup plus intelligents lorsqu'il s'agit de raisonner sur un plan qui est très détaillé et élaboré mais qui reste suffisamment petit pour tenir facilement dans leur fenêtre de contexte (c'est vraiment la clé de mon obsession pour la planification et pourquoi je passe plus de 80 % de mon temps sur cette partie). Et si vous vous appuyez sur GPT Pro avec Raisonnement Étendu dans l'application web pour la planification initiale comme je le recommande fortement (c'est-à-dire pour créer et améliorer votre plan markdown que vous finissez par transformer en perles), vous les obtenez essentiellement sur une base à volonté avec un plan Pro, alors profitez-en pleinement ! Aucun autre modèle ne peut rivaliser avec Pro sur le web lorsqu'il s'agit d'entrées qui s'intègrent facilement dans sa fenêtre de contexte. C'est vraiment unique. ...