Lorsque l’on confie une fonctionnalité complète à un agent de codage IA (Claude Code, Cursor, Antigravity), le piège classique n’est plus la vitesse d’écriture du code, mais le mur de la revue de code. Un agent peut générer en dix minutes une Pull Request monolithique de 1 800 lignes touchant à la fois au schéma de base de données, au backend API, à l’interface utilisateur et aux tests. Face à un tel bloc, la revue humaine devient superficielle (« LGTM ») et le moindre bug oblige à annuler (revert) toute la fonctionnalité.
C’est exactement ce problème que résout gstack (garrytan/gstack) en combinant deux disciplines : le découpage systématique en Stacked PRs (Pull Requests empilées) et l’orchestration d’un sprint logiciel multi-rôles.
1. Pourquoi les « Stacked PRs » changent tout avec un agent IA
Au lieu de pousser une seule branche géante vers main, l’approche Stacked PRs consiste à empiler de petites branches atomiques qui dépendent les unes des autres :
PR #1 : Fondations & Modèle de données(~100-150 lignes) : uniquement la migration ou les structures de données et leurs tests unitaires. Zéro impact sur l’interface existante.PR #2 : Logique Métier & Endpoint API(~150-200 lignes) : branchée par-dessus laPR #1, elle implémente le service backend et les garde-fous de sécurité.PR #3 : Interface & Intégration(~150 lignes) : branchée par-dessus laPR #2, elle câble le composant visuel et les tests de bout en bout.
| Critère d’ingénierie | PR Monolithique IA (~1 500 lignes) | Stacked PRs avec gstack (3 x ~150 lignes) |
|---|---|---|
| Temps de revue cognitive | 45 min à 1 h (fatigue visuelle élevée) | < 10 minutes par tranche (contexte isolé) |
| Taux de détection des bugs subtils | Faible (noyés dans le volume de diff) | Élevé (chaque couche est vérifiée séparément) |
| Blocage en attente de validation | Total (impossible d’avancer sans merger) | Nul (on code la PR #2 pendant la revue de PR #1) |
| Précision du Rollback en production | Brutal (tout le lot est annulé) | Chirurgical (seule la couche fautive est annulée) |
2. Les rôles de sprint intégrés dans gstack
Au-delà de l’empilement Git, gstack transforme l’agent IA en une véritable équipe produit virtuelle grâce à des commandes spécialisées qui forcent l’agent à changer de casquette à chaque étape du cycle :
/plan-ceo-review: challenge la valeur produit et élague les fonctionnalités superflues avant d’investir du temps d’ingénierie ;/plan-eng-review: verrouille l’architecture technique, les flux de données, les cas limites (edge cases) et le découpage en tranches atomiques ;/review: inspecte chaque tranche de la pile à la recherche de failles de sécurité, de régressions ou de fuites de ressources ;/qa: lance un vrai navigateur headless (Playwright) pour tester l’application réelle, vérifier les formulaires et capturer les preuves visuelles ;/ship: synchronise la pile de branches, exécute la suite de tests complète, met à jour le changelog et ouvre/fusionne les Pull Requests dans l’ordre.
3. Intégration dans mon workflow Homelab & Cloud
Dans mon écosystème, gstack intervient juste après la phase de questionnement architectural (Grill Me) et en complément du cycle TDD de Superpowers :
/grill-meélimine les angles morts de conception ;/plan-eng-review(gstack) découpe la solution en 2 ou 3 tranches indépendantes ;- Chaque tranche est codée en mode minimaliste (
Ponytail) avec son test anti-régression et validée via/qaavant d’être poussée via/ship.
| Commande | Description |
|---|---|
`/plan-ceo-review`
| Évaluer la pertinence produit et supprimer les fonctionnalités non essentielles (YAGNI). |
`/plan-eng-review`
| Valider l'architecture, les diagrammes d'état et découper le travail en Stacked PRs. |
`/review`
| Auditer le diff de la branche courante (sécurité, concurrence, régressions). |
`/qa`
| Exécuter les tests de bout en bout dans un navigateur réel et vérifier le rendu. |
`/ship`
| Rebaser la pile de branches, vérifier les tests et publier la Pull Request. |
4. Dépôt GitHub Officiel
- gstack (Garry Tan) : https://github.com/garrytan/gstack