Comment sauver les assistants IA de la dégradation du contexte avec le framework GSD Core

Les 15 premières minutes de travail avec un assistant réseau neuronal comme Claude Code ou Cursor semblent généralement parfaites. Le modèle saisit instantanément la structure du projet, écrit des fonctions propres et organise proprement les modules en dossiers. Une demi-heure passe, la session grandit jusqu'à des dizaines de messages, et quelque chose d'étrange commence à se produire. Le modèle se confond dans ses propres modifications, « oublie » l'architecture et commence à boucler sur les mêmes erreurs.

En ingénierie de prompts, cet effet est appelé dégradation du contexte (pourriture du contexte). Lorsque la fenêtre de contexte se bouche avec des logs de débogage, d'anciennes versions de code et des messages aléatoires, la qualité de la génération diminue. Le projet GSD Core a été créé spécifiquement pour résoudre ce problème.

L'idée du projet

L'outil est un système de méta-prompting pour la gestion du contexte. Au lieu d'un long chat où les discussions, les recherches et la génération de fichiers sont mélangées, GSD Core organise le développement à travers une chaîne de sous-agents indépendants.

La session principale avec le modèle reste propre. Tout le travail lourd — recherche dans le dépôt, planification et écriture de code — est déplacé vers des processus en arrière-plan. Chaque sous-agent démarre avec une nouvelle fenêtre de contexte de 200 000 jetons, accomplit une tâche isolée spécifique et retourne uniquement un résumé compressé au flux principal.

Le framework est adapté aux outils et environnements CLI populaires : Claude Code, Cursor, Copilot, Codex, Windsurf, Kimi CLI et OpenCode.

Le cycle de développement en cinq étapes

Tout le travail au sein de GSD Core est construit autour d'une boucle fixe de cinq étapes séquentielles :

1. Discuter. Vous verrouillez les décisions architecturales avec l'assistant avant de créer un plan. Cela empêche les situations où le modèle commence à inventer des choses en cours d'écriture du code.
2. Planifier. Le sous-agent explore la base de code, décompose la tâche en petites étapes et vérifie que le plan résultant tient dans la fenêtre de contexte.
3. Exécuter. Les tâches sont lancées en vagues parallèles. Chaque worker reçoit un nouveau contexte, donc le volume des logs accumulés précédemment n'a aucun impact sur la qualité du code.
4. Vérifier. L'agent passe en revue les fichiers écrits, identifie les incohérences, vérifie les fonctionnalités et prépare un plan de correction avant la fin de l'étape.
5. Livrer. L'outil crée une pull request dans Git, archive la phase terminée et passe à l'étape suivante.

Cette approche résout aussi un autre problème courant — la perte de mémoire lors du redémarrage d'une session. Toutes les décisions, statuts actuels et contexte sont enregistrés dans des fichiers markdown STATE.md et CONTEXT.md directement à la racine de votre dépôt. Si le terminal se ferme ou que vous changez d'éditeur, toute l'historique est préservée.

Installation et commandes principales

L'installation se fait avec une seule commande console :

npx @opengsd/gsd-core@latest

L'assistant interactif demandera quel runtime vous utilisez et offrira d'installer le framework globalement ou localement dans le répertoire du projet. Les auteurs du dépôt demandent spécifiquement d'utiliser l'installateur plutôt que de copier les fichiers manuellement pour éviter de casser la compatibilité avec les agents.

Une fois la configuration terminée, des commandes spécialisées deviennent disponibles dans votre environnement de travail :

/gsd-new-project   # Для старта нового проекта с чистого листа
/gsd-onboard       # Для подключения фреймворка к существующему репозиторию

La commande onboard analyse la base de code, crée automatiquement une carte du projet et génère les fichiers d'état de base.

Ce que ça donne en pratique

J'ai testé l'outil sur un petit projet. Le confort principal se manifeste lors de la chasse aux bugs. Normalement, le chat se pollue immédiatement avec les logs console et les stack traces, après quoi l'assistant ne comprend plus le contexte. Avec la séparation par sous-agents, le dialogue principal reste propre et les modifications sont faites avec précision. L'historique des modifications est stocké directement dans Git, donc vous pouvez revenir en toute sécurité à n'importe quelle étape.

D'un autre côté, le format exige de la discipline. Si vous avez l'habitude de simplement coller des captures d'écran d'erreurs dans la fenêtre de chat et d'attendre des corrections immédiates, vous devrez vous adapter. D'abord la discussion, puis un plan clair, la vérification, et seulement ensuite le commit. De plus, exécuter plusieurs agents en arrière-plan avec des contextes de 200 000 jetons consomme заметно plus vite les limites de l'API.

À qui l'outil est destiné

GSD Core sera utile pour les ingénieurs qui utilisent des assistants IA sur des tâches plus importantes que le refactoring local de quelques fonctions. Si vos sessions dans Cursor ou Claude Code se transforment régulièrement en chaos après une demi-heure de travail, une planification stricte des phases contribuera à restaurer la stabilité du modèle.