Garry Tan publie son Claude Code : 23 outils-rôles et 139 000 étoiles

Une scène familière : vous demandez à un agent IA de « développer une fonctionnalité », et dans un seul flux il imagine le produit, dessine l'interface, écrit le code, se félicite lui-même et oublie la documentation. Le résultat est généralement médiocre sur tous les plans. Le dépôt garrytan/gstack tente justement de remédier à ce problème, et il figure aujourd'hui de nouveau dans le top quotidien de GitHub Trending : 139 039 étoiles au total et 285 au cours des dernières 24 heures.

De quoi s'agit-il ?

Garry Tan présente gstack comme son réglage précis de Claude Code. La description du projet indique qu'il s'agit de 23 outils « opinionated » (tranchés, avec des partis pris) qui fonctionnent comme un PDG, un designer, un responsable de l'ingénierie, un responsable des releases, un ingénieur documentation et un QA. Le projet est écrit en TypeScript.

Une réserve importante : nous nous appuyons sur la description du dépôt et ses métriques. Nous ne proposons pas ici d'analyse ligne par ligne de chacun des 23 outils, et il est conseillé de la réaliser soi-même avant toute adoption.

Pourquoi les rôles fonctionnent mieux qu'un prompt générique

La logique est simple et familière à quiconque a déjà constitué une équipe. Lorsqu'une seule personne est responsable à la fois de la décision produit et du contrôle qualité, elle a tendance à être d'accord avec elle-même. Il en va de même avec un modèle de langage : si, dans un même contexte, il écrit le code et l'évalue, la critique reste indulgente.

Imaginez une journée type. Vous voulez ajouter un écran de paramètres à un service. Dans un schéma par rôles, l'ordre pourrait être le suivant :

• le « PDG » vérifie si la fonctionnalité est vraiment nécessaire et quel en est l'élément essentiel ;
• le « designer » décrit les états de l'écran et les cas limites ;
• le « responsable de l'ingénierie » découpe la tâche en étapes ;
• le « QA » tente séparément de casser le résultat ;
• le « responsable des releases » et le « rédacteur de documentation » bouclent les derniers détails : version, liste des changements, README.

Chaque rôle reçoit ses propres instructions et ses propres critères de réussite. Ce n'est pas de la magie, mais une discipline de processus intégrée aux outils, pour ne pas avoir à la garder en tête ni à réécrire le prompt à chaque fois.

Pourquoi tout le monde en parle

La première raison est évidente : le nom de l'auteur. Quand le dirigeant d'un grand accélérateur de startups montre précisément comment il travaille avec un agent, cela intéresse comme artefact de travail, et non comme théorie. La seconde raison est plus profonde : la communauté est lasse des discours abstraits sur les agents et veut voir des configurations concrètes qu'on peut copier et lancer.

Il faut toutefois lire les étoiles avec prudence. Les 139 000 témoignent d'attention et de curiosité, mais pas d'une productivité démontrée. La popularité d'un dépôt ne remplace pas des mesures sur votre propre base de code.

Limites

La description dit honnêtement que les outils sont « opinionated ». Cela signifie que les goûts d'autrui y sont intégrés : à quoi doit ressembler une bonne release, ce qui constitue une documentation suffisante, le degré de rigueur du QA. Pour une équipe avec une autre stack, d'autres conventions ou des exigences réglementaires, une partie des règles devra être réécrite.

Il existe aussi un coût caché : plus de rôles signifie plus d'appels au modèle, plus de tokens et plus d'endroits où quelque chose peut mal tourner. Pour un petit projet, 23 outils peuvent s'avérer superflus, et deux ou trois suffiront.

Que faire en pratique

N'installez pas l'ensemble du kit sur votre dépôt de production dès le premier jour. Mieux vaut procéder ainsi :

• clonez le projet et lisez les instructions des rôles : c'est un manuel gratuit sur la manière de structurer le travail d'un agent ;
• essayez deux rôles dont l'utilité est la plus évidente, par exemple QA et documentation ;
• exécutez-les sur une petite tâche et comparez le résultat avec votre méthode habituelle ;
• conservez ce qui a fonctionné et jetez le reste.

Les product managers et les fondateurs devraient regarder gstack sous un autre angle : comme un modèle de processus. Même si vous n'utilisez pas le code lui-même, la question « quels rôles manquent encore dans mon développement avec un agent ? » est utile. Le plus souvent, il s'agit justement du contrôle qualité et de l'hygiène des releases.

En résumé : la valeur de gstack ne tient pas à ce qu'il serait le « meilleur setup », mais à ce qu'il montre à quoi ressemble un travail mature avec un agent de code : des rôles, des règles et une séparation des responsabilités plutôt qu'un seul long prompt.