Qu'est-ce qui constitue un bon document de planification en markdown pour un projet de développement logiciel ? Quelle est la différence entre un bon plan et un excellent ? Je parle toujours de la façon dont je passe plus de 85 % de mon temps et de mon énergie sur les phases de planification. Eh bien, qu'est-ce que cela implique exactement ? C'est difficile à expliquer de manière abstraite ; vous avez besoin d'un exemple tangible pour vraiment illustrer les nuances. Alors j'ai pensé que je partagerais un bon exemple d'aujourd'hui. Cela répond également à une question récente que j'ai reçue concernant mon approche. Les gens semblent avoir l'impression que vous devez tout faire dans votre projet d'un seul coup. Et dans mon approche, c'est vrai, mais seulement pour la version 1 ! Si vous décidez que vous souhaitez ajouter de nouvelles fonctionnalités ou changer le fonctionnement des choses, vous pouvez évidemment le faire une fois que vous avez une v1 fonctionnelle. Et la façon de le faire est la même que celle que vous utilisez pour créer la v1, en créant d'abord un plan markdown super détaillé, puis en le transformant en beads. Je vais donc vous donner un exemple de Cass, mon programme de recherche de sessions d'agent de codage, qui est un programme Rust assez élaboré qui détecte, analyse, stocke et indexe automatiquement tous vos journaux de session précédents de presque tous les agents de codage disponibles. Il offre une recherche instantanée "recherche au fur et à mesure que vous tapez" en moins de 50 ms sur tous ces journaux et possède de nombreuses autres fonctionnalités intéressantes. J'ai décidé que j'aimerais ajouter une fonctionnalité à Cass qui est similaire à une fonctionnalité que j'ai déjà dans MCP Agent Mail et dans beads_viewer (bv) : la possibilité d'exporter votre configuration en tant que site web statique pouvant être servi via GitHub Pages. Vous pouvez voir un exemple pour bv pour ce projet, qui est le résultat final du processus de planification que je vais décrire dans ce post : Cette fonctionnalité rend très rapide et facile la génération et le déploiement du site exporté à l'aide de l'utilitaire gh. Le site lui-même consiste généralement en un fichier sqlite et un tas de typescript et wasm qui s'exécutent entièrement dans le navigateur, mais avec de très bonnes performances et de belles fonctionnalités et un bon style, que vous pouvez observer dans l'exemple donné ci-dessus. Maintenant, partager des messages de MCP Agent Mail ou un tas de beads est une chose, mais partager un tas de journaux de session d'agent de codage est très différent ; ces choses sont souvent pleines d'informations sensibles, de clés API, de jurons/invectives (du moins les miens le sont !), et d'autres éléments que vous ne voudriez certainement pas exposer au monde. Mais GitHub Pages, aussi agréable soit-il, ne fonctionne que pour les dépôts publics (au fait, mes outils prennent également en charge les pages Cloudflare, mais GH Pages est meilleur et plus facile pour ce cas d'utilisation). Alors, comment gérer ces problèmes ? La réponse est le chiffrement : l'utilisateur sélectionne d'abord quels agents de codage inclure, quels dossiers de projet, la période, etc., et un bundle est généré (notez que ce bundle est au format canonique dans lequel Cass convertit en interne tous les messages des agents de codage à partir de leurs formats natifs d'origine) et ensuite l'utilisateur fournit un mot de passe à utiliser pour le chiffrement de ce bundle. Donc, l'idée est que bien que le dépôt et la page web soient publics, tout le monde sauf vous et les autres à qui vous donnez le mot de passe verra simplement un champ de mot de passe et ne pourra pas lire aucun des messages. Une fois le mot de passe saisi, cela déverrouillerait une belle interface utilisateur réactive qui vous permet de rechercher facilement à travers les messages presque aussi rapidement et efficacement que Cass le fait. Et si vous n'avez vraiment rien à cacher, vous pouvez laisser le mot de passe de côté et rendre tout cela réellement public. Quoi qu'il en soit, c'est une nouvelle fonctionnalité super complexe à ajouter pour de nombreuses raisons. L'assistant d'exportation à lui seul est extrêmement complexe et compliqué. Mais les exigences supplémentaires concernant le chiffrement et la sécurité rendent cela difficile à bien faire. Quoi qu'il en soit, j'ai demandé à Claude Code avec Opus 4.5 d'étudier d'abord tout le code pertinent de mon projet bv pour mettre en œuvre cette fonctionnalité, puis j'ai expliqué comment la fonctionnalité correspondante dans Cass devrait différer. Il a ensuite créé pour moi une première ébauche d'un plan. J'ai demandé à CC de vérifier à nouveau le code bv pour obtenir plus d'informations et de compréhension sur la façon dont la fonctionnalité a été mise en œuvre dans bv et d'utiliser ensuite ces informations pour développer et améliorer le document de planification sur place. Enfin, j'ai déplacé le plan vers ChatGPT Pro dans le navigateur avec GPT 5.2 avec Raisonnement Étendu accompagné de cette préface : "Examinez attentivement ce plan entier pour moi et proposez vos meilleures révisions en termes de meilleure architecture, nouvelles fonctionnalités, fonctionnalités modifiées, etc. pour l'améliorer, le rendre plus robuste/fiable, plus performant, plus convaincant/utile, etc. Pour chaque changement proposé, donnez-moi votre analyse détaillée et votre justification/rationnel pour expliquer pourquoi cela améliorerait le projet, ainsi que le changement de style git-diff par rapport au plan original montré ci-dessous :" J'ai ensuite collé les sorties dans Claude Code comme ceci : OK, maintenant intégrez ces révisions au plan markdown sur place ; utilisez ultrathink et soyez méticuleux. À la fin, vous pouvez me dire quels changements vous approuvez totalement, lesquels vous approuvez partiellement et lesquels vous n'êtes pas d'accord : ```[Texte collé #1 +995 lignes]``` J'ai ensuite répété cela encore 2 fois. Ce n'est pas un processus rapide : la dernière révision, dont vous pouvez voir une capture d'écran ci-dessous, a pris 27 minutes à terminer : Vous pouvez voir le plan markdown final d'environ 3 500 lignes ici : Mais ce qui est plus intéressant, c'est de voir les révisions dans GitHub, où vous pouvez voir les améliorations massives qui ont été apportées de la v2 à la v3, et comment les améliorations continuent réellement jusqu'à la fin : Cela a finalement pris un total d'environ 3 heures. Je soupçonne que c'est pourquoi la plupart des gens semblent réticents à faire ce niveau de planification. On a l'impression de ne pas avancer beaucoup parce qu'aucun code n'est écrit, mais si vous le faites correctement et que vous démarrez ensuite suffisamment d'agents dans votre essaim avec Agent Mail, Beads et bv, alors le code sera écrit si rapidement qu'il compense largement cette partie lente. Et ce qui est plus, le code sera vraiment bon. Pour revenir à l'histoire, j'étais alors prêt à transformer le plan en beads. J'ai déjà expliqué ce processus dans un autre post récent, mais l'essence est d'utiliser cette invite avec Claude Code : "OK alors maintenant lisez TOUT PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md ; veuillez prendre TOUT cela et l'élaborer pour créer un ensemble complet et granulaire de beads pour tout cela avec des tâches, sous-tâches et structure de dépendance superposées, avec des commentaires détaillés afin que l'ensemble soit totalement autonome et auto-documenté (y compris les antécédents pertinents, le raisonnement/la justification, les considérations, etc. - tout ce que nous voudrions que notre "futur moi" sache sur les objectifs et les intentions et le processus de réflexion et comment cela sert les objectifs globaux du projet). Les beads devraient être si détaillés que nous n'ayons jamais besoin de nous référer au document de planification markdown original. N'oubliez pas d'utiliser UNIQUEMENT l'outil `bd` pour créer et modifier les beads et ajouter les dépendances. Utilisez ultrathink." Ensuite, j'ai simplement fait des tours après des tours de cette invite de suivi dans Claude Code : "Relisez AGENTS dot md pour que ce soit toujours frais dans votre esprit. Ensuite, lisez TOUT PLAN_TO_CREATE_GH_PAGES_WEB_EXPORT_APP.md. Utilisez ultrathink. Vérifiez chaque bead super soigneusement - êtes-vous sûr qu'il a du sens ? Est-ce optimal ? Pourrions-nous changer quelque chose pour que le système fonctionne mieux pour les utilisateurs ? Si oui, révisez les beads. C'est beaucoup plus facile et rapide d'opérer dans l'espace "plan" avant de commencer à mettre en œuvre ces choses ! NE PAS SIMPLIFIER LES CHOSES ! NE PAS PERDRE AUCUNE FONCTIONNALITÉ OU CARACTÉRISTIQUE ! Assurez-vous également qu'en tant que partie des beads, 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 la mise en œuvre. Il est crucial que TOUT soit intégré dans les beads afin que nous n'ayons jamais besoin de nous référer au plan markdown et que nous ne perdions aucune information contextuelle ou idées ou aperçus sur les nouvelles fonctionnalités prévues et pourquoi nous les mettons en œuvre." Après environ 8 ou 9 tours, cela atteint enfin un état stable. J'ai ensuite demandé à Codex avec GPT 5.2 un effort de raisonnement élevé de faire un dernier tour en utilisant cette même invite. Le résultat final peut être vu au lien partagé ci-dessus. Et voilà, mes amis, à quoi ressemble un bon plan. Et aussi à quoi ressemble un bon ensemble de beads basé sur un plan. Ces beads sont si polis et détaillés que vous pouvez mécaniquement libérer un grand essaim d'agents pour les mettre en œuvre en utilisant Agent Mail, Beads et bv, et cela sortira presque parfaitement sans trop de tracas. Je suis trop fatigué pour commencer à faire ce travail d'implémentation ce soir, mais je le ferai demain et partagerai ensuite la nouvelle fonctionnalité, que je pense que les utilisateurs de Cass vont vraiment apprécier.

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. Maintenant, vous pouvez encore obtenir beaucoup de mileage supplémentaire en intégrant des idées intelligentes de Gemini3 dans l'application web avec Deep Think activé, ou de Grok4 Heavy, ou Opus 4.5 dans l'application web, mais vous voulez toujours utiliser GPT Pro sur le web comme l'arbitre final de ce qu'il faut prendre de quel modèle et comment l'intégrer au mieux. Et puisque ce post pourrait encore être encore plus comiquement long, je vous laisse avec mon invite pour intégrer ces plans concurrents en un seul plan markdown canonique "meilleur de tous les mondes" : "J'ai demandé à 3 LLM concurrents de faire exactement la même chose et ils ont proposé des plans assez différents que vous pouvez lire ci-dessous. Je veux que vous analysiez VRAIMENT soigneusement leurs plans avec un esprit ouvert et soyez intellectuellement honnête sur ce qu'ils ont fait qui est mieux que votre plan. Ensuite, je veux que vous proposiez les meilleures révisions possibles à votre plan (vous devriez simplement mettre à jour votre document existant pour votre plan original avec les révisions) qui habilement et habilement mélangent le "meilleur de tous les mondes" pour créer une véritable version hybride ultime et supérieure du plan qui atteint le mieux nos objectifs déclarés et fonctionnera le mieux dans la pratique réelle pour résoudre les problèmes auxquels nous sommes confrontés et nos objectifs globaux tout en assurant le succès extrême de l'entreprise autant que possible ; vous devriez me fournir une série complète de changements de style git-diff à votre plan original pour le transformer en le nouveau plan amélioré, beaucoup plus long et détaillé qui intègre le meilleur de tous les plans avec chaque bonne idée incluse (vous n'avez pas besoin de mentionner quelles idées proviennent de quels modèles dans le plan final révisé amélioré) :" (Allez, une invite de plus pour le plaisir ; j'utilise celle-ci pour améliorer itérativement un plan markdown existant) : "Examinez soigneusement ce plan entier pour moi et proposez vos meilleures révisions en termes de meilleure architecture, nouvelles fonctionnalités, fonctionnalités modifiées, etc. pour le rendre meilleur, plus robuste/fiable, plus performant, plus convaincant/utile, etc. Pour chaque changement proposé, donnez-moi votre analyse détaillée et votre justification/rationnel pour expliquer pourquoi cela améliorerait le projet, ainsi que le changement de style git-diff par rapport au plan original montré ci-dessous :"

Niveaux d'engagement sataniques ici... 𖤐⁶⁶⁶𓃶