Je pense que beaucoup de personnes qui souhaiteraient développer un nouveau projet logiciel se heurtent souvent à des difficultés dès le début du processus de démarrage, car il semble très intimidant de commencer avec un dépôt vierge. J'ai donc pensé vous présenter rapidement mon nouveau flux de travail, qui réduit considérablement le temps et les efforts nécessaires pour démarrer. L'élément le plus important, et de loin, est d'avoir une bonne idée, ou quelque chose à créer qui serait réellement utile à beaucoup de gens si cela fonctionnait correctement et remplissait bien sa fonction. Je ne peux pas vraiment vous aider sur ce point, mais le conseil habituel de s'attaquer à ses propres problèmes et de résoudre ses propres difficultés (hors niche) est une excellente façon de commencer. Je me surprends à avoir constamment des idées de projets. Bref, l'étape suivante consiste à coucher l'idée sur le papier de manière informelle, comme vous le feriez dans un courriel rapide à un ami proche. Il ne s'agit pas d'en faire un plan formel, mais simplement de communiquer rapidement l'idée de base, son fonctionnement et de préciser les éléments de la pile technologique ou les bibliothèques que vous souhaitez utiliser. Les captures d'écran ci-jointes illustrent une idée qui m'est venue il y a quelques jours. La rédaction m'a pris une dizaine de minutes. Le texte n'a pas besoin d'être long et peut s'appuyer sur d'autres sources pour plus de concision. Cette description initiale sert ensuite d'invite pour GPT-5 Pro. L'exécution prend généralement au moins 15 à 20 minutes (curieusement plus longtemps que la rédaction de l'invite). Vous pourriez essayer d'autres modèles, mais ils seront bien moins performants. Ensuite, je reprends souvent la même requête et la soumets à Grok4 Heavy ou Opus4.1, puis je réinjecte les idées dans GPT-5 Pro en l'incitant à intégrer les meilleures idées parmi les autres propositions. Si ces plans contiennent une idée pertinente, GPT-5 Pro la reconnaîtra et l'intégrera. Ensuite, je demanderai à Pro de créer un document de plan Markdown détaillé et précis basé sur sa première réponse, et je l'enregistrerai comme fichier dans un dossier de projet nouvellement créé. Ensuite, je retravaille souvent ce processus à plusieurs reprises, en démarrant une nouvelle conversation Pro dans l'application web, en fournissant l'intégralité du fichier de plan Markdown et en lui demandant d'améliorer le plan de diverses manières afin de le rendre plus fiable, robuste, performant, intuitif, convivial, et autres adjectifs positifs. Et j'encouragerai Pro à effectuer des recherches approfondies sur le Web concernant la documentation, les blogs, les tutoriels, etc. les plus récents afin de trouver de meilleures bibliothèques ou de meilleures façons de faire les choses. Je reprendrai ensuite les révisions proposées, je les collerai dans Codex et je demanderai à Codex d'intégrer ces révisions au document de plan Markdown existant. Après deux ou trois itérations, les choses se stabilisent et on obtient un plan vraiment bien ficelé. C'est essentiel, car tant que le projet est encore en phase de planification, il est beaucoup plus facile de l'ajuster et de l'améliorer puisqu'il n'y a pas encore de code. Mieux vaut prévenir que guérir. Voici un lien vers le document de planification résultant de la demande initiale concernant cette idée : https://t.co/mXHOZH9b2p À ce stade, je commence à ajouter un fichier AGENTS dot md ; je pars d'un fichier existant que je possède et je demande à Pro (au cours de la même session que celle où le dernier document de planification a été rédigé) de le personnaliser pour ce nouveau projet et cette nouvelle pile technologique tout en préservant les éléments génériques. S'il existe des bibliothèques d'une importance capitale, je crée parfois également un guide de bonnes pratiques spécialisé (par exemple, si vous créez un serveur MCP, je générerai un guide de bonnes pratiques spécialisé pour la bibliothèque fastmcp, où j'expliquerai également comment structurer le projet, etc.). À ce stade, je demande ensuite à Codex, en une seule session, de commencer à construire la structure du projet, à créer des dossiers et des fichiers d'espace réservé vides, à créer le fichier .gitignore, etc. C’est là que ma méthode diffère radicalement de l’approche classique. Je commence par utiliser le projet Beads de Steve Yegge et je demande à Codex de transformer le document de planification en une série de tâches et de sous-tâches à l’aide de Beads. Ensuite, j'utilise tmux pour créer plusieurs sessions codex, jusqu'à 8 simultanément (je pense que plus de 8 fonctionneraient également bien)…
Ensuite, je lance mon projet de messagerie pour les agents MCP et je leur demande de s'inscrire par e-mail et de se présenter à leurs collègues agents, de lire le site AGENTS.md et le document du plan dans leur intégralité (en faisant référence à ce fichier par son nom), et de passer en revue les tâches liées aux perles dans un message initial. Ensuite, il s'agit simplement d'un processus consistant à répéter la même série de messages préétablis où je leur dis de choisir une tâche et de commencer à travailler dessus, je les encourage à continuer ainsi à plusieurs reprises, puis à relire leur travail, puis à consulter leur messagerie d'agent et à répondre aux messages reçus qui nécessitent une réponse, et à communiquer ce qu'ils font à leurs collègues agents. J'ai enregistré hier une vidéo de 23 minutes montrant comment cette partie fonctionne pour l'exemple de projet présenté dans cet article, ce qui clarifie tout cela : https://t.co/KedUEzSRRG Après avoir enregistré cela, j'ai trouvé comment automatiser même cette dernière étape afin de mettre en file d'attente automatiquement de nombreux messages pour tous les agents et les occuper pendant des heures, en utilisant tmux pour diffuser les commandes. Je vous mets le lien vers ce message ci-dessous. Voilà le processus de base. Si vous le suivez, vous pouvez créer des logiciels incroyablement complexes et puissants en quelques jours, avec peut-être 1 ou 2 heures de « temps humain » effectif requises, mais de très nombreuses heures de travail (en équivalent temps de travail humain). Et chaque heure de travail autonome d'un agent avec gpt-5-codex, lorsqu'il n'attend pas constamment des instructions humaines, équivaut probablement à 10 ou 20 heures de travail humain. Ils pensent et tapent vraiment très vite !
Voici le lien vers ma discussion sur la fermeture de la boucle d'automatisation avec tmux :
Voici le lien vers le projet MCP Agent Mail qui rend tout cela possible : https://t.co/aXsf08Pms7