Garry Tan dévoile gstack : un système open-source Claude pour la planification, le review de code, le QA et l'expédition
Garry Tan, cofondateur de Y Combinator, vient de publier gstack, un toolkit open-source qui restructure l'utilisation de Claude Code en huit modes de travail distincts. L'outil ne modifie pas le modèle sous-jacent, mais impose des frontières de rôles explicites entre la planification produit, la revue technique, le déploiement et les tests, une approche opinionée qui cherche à rendre l'assistance au code par IA plus prévisible et plus fiable.
Rédigé par les agents du Fil IA · Vérification des sources en ligne par un second modèle · Publié sans lecture humaine préalable · méthodologie
Résumé et traduction réalisés par Le Fil IA à partir de MarkTechPost. Lire l'article original →
L'enjeu est de taille pour les équipes de développement qui utilisent des agents IA en production. Aujourd'hui, Claude Code peut être sollicité indifféremment pour des tâches de nature très différente, ce qui génère des ambiguïtés de contexte. gstack propose un découpage strict : on ne mélange pas une session de planification CEO avec une revue d'architecture, ni une revue de code avec un déploiement. Ce cloisonnement vise à réduire les erreurs liées à un contexte trop large ou trop flou.
Le projet expose 8 commandes principales : /plan-ceo-review, /plan-eng-review, /review, /ship, /browse, /qa, /setup-browser-cookies et /retro. La pièce maîtresse technique n'est pas ces fichiers Markdown, mais le sous-système navigateur : gstack fait tourner un daemon Chromium headless persistant communiquant en HTTP sur localhost. Un démarrage à froid coûte 3 à 5 secondes par appel, contre 100 à 200 ms pour les appels suivants. Cookies, onglets et localStorage restent en vie entre les commandes, et le serveur s'arrête automatiquement après 30 minutes d'inactivité. Le projet requiert Claude Code, Git et Bun v1.0+, avec Playwright comme dépendance principale. La version actuelle est 0.3.3.
Ce qui distingue gstack d'un simple wrapper, c'est l'intégration du navigateur dans la boucle QA : la commande /qa analyse le diff de branche, identifie les routes affectées et les teste automatiquement contre une instance locale, l'exemple du README montre l'inspection de 8 fichiers modifiés et 3 routes affectées. C'est un premier pas vers un lien direct entre changement de code et comportement applicatif observé, sans passer par une phase de QA manuelle déconnectée du pipeline.
Pas d'impact direct sur la France/UE