Pi vous donne un contrôle exceptionnellement fin sur le routage de provider, le mode de pensée, la réutilisation de session et l'exposition d'outils, mais un workflow purement terminal laisse encore la gestion de projet, l'orchestration et la persistance des connaissances à long terme à l'utilisateur.
Dans le travail de livraison réel, ces couches manquantes comptent plus qu'une seule commande intelligente. HagiCode fournit la structure de workflow que Pi lui-même n'essaie pas de posséder.
Multithreading : laisser Pi faire tourner plusieurs voies de codage contrôlées à la fois
Pi peut faire beaucoup au sein d'une session, mais la vraie livraison arrive rarement une tâche à la fois.
HagiCode vous permet de faire tourner plusieurs sessions Pi en parallèle, chacune avec un contexte isolé, une frontière de responsabilité claire et une progression indépendante.
Cela transforme Pi d'une CLI à thread unique configurable en un atelier d'ingénierie parallèle qui correspond à la façon dont les équipes construisent réellement des logiciels.
- Le thread A peaufine les endpoints API backend;
- Le thread B refactore des composants frontend;
- Le thread C écrit des tests unitaires;
- Le thread D audite le code pour les vulnérabilités de sécurité.
Sessions de proposition OpenSpec : lier les choix de provider et de modèle de Pi à des décisions traçables
Dans le développement quotidien, le chaos le plus courant n'est pas l'incapacité d'écrire du code — c'est de faire un tas de changements puis d'oublier pourquoi vous les avez faits, ce que vous avez changé et comment ces changements sont reliés.
Le workflow de proposition OpenSpec intégré à HagiCode résout fondamentalement ce problème. Chaque tâche de développement démarre comme une proposition :
Cette approche 'réfléchir d'abord puis agir' donne au modèle de routage flexible de Pi une place pour être documenté. Des mois plus tard, vous pouvez voir non seulement ce qui a changé, mais aussi pourquoi un certain provider, une route de modèle ou une frontière d'outil a été choisi.
- D'abord, notez quel problème cette tâche résout et pourquoi cette approche a du sens;
- Discutez en profondeur de l'approche technique avec Pi dans le cadre de la proposition — toutes les conversations et décisions sont enregistrées dans le contexte de la proposition;
- Une fois l'approche confirmée, Pi implémente le code dans les contraintes de la proposition;
- Le document de proposition final, les enregistrements de discussion et les changements de code forment une chaîne de traçabilité complète.
Commits IA : transformer la sortie de Pi en un historique de commit propre
Écrire des messages de commit après avoir fini le code est une forme de friction mentale pour beaucoup de développeurs. Trop décontracté et vous ne retrouvez pas les commits clés plus tard ; trop formel et cela ressemble à du temps perdu.
La fonctionnalité de commit IA de HagiCode confie cela entièrement à Pi : elle analyse vos changements de code, comprend l'intention et la portée de l'impact, puis génère automatiquement des messages de commit clairement structurés, sémantiquement exacts. Plus important encore, durant le commit IA, HagiCode verrouille automatiquement le dépôt pour empêcher les conflits d'état des opérations concurrentes, garantissant des commits sûrs et fiables.
Économisez votre attention pour la création — laissez Pi gérer la paperasse du commit.
Éditeur de navigateur Code Server : sauter de l'analyse Pi directement à l'édition
Après que Pi analyse le code, identifie le fichier problématique et localise le numéro de ligne exact, le moment gênant familier se produit : vous devez quitter la fenêtre de conversation IA, retourner dans votre IDE, retrouver le fichier et sauter manuellement au bon endroit. Cette rupture de contexte de l'analyse à l'édition n'interrompt pas seulement votre flux mais maintient la valeur de l'IA à 'vous dire où est le problème' plutôt que 'vous aider à entrer directement en mode édition'.
L'éditeur de navigateur basé sur Code Server intégré à HagiCode est conçu spécifiquement pour résoudre cette rupture :
L'intégration Code Server fait de HagiCode non pas seulement une page frontend qui peut analyser le code, mais une workstation complète où l'analyse de Pi peut atterrir directement comme actions d'édition. Elle minimise le coût de changement d'outil entre l'analyse IA et la modification hands-on.
- En un clic de l'analyse à l'édition : une fois que Pi identifie dans une proposition le fichier nécessitant des changements, HagiCode peut ouvrir directement ce fichier dans l'atelier pour l'éditer. Vous n'avez pas besoin de changer d'outil ni de retrouver le fichier.
- Local, conteneur, distant — couverture totale : que votre projet tourne localement, dans un conteneur Docker ou sur un serveur distant, le Code Server de HagiCode peut ouvrir le répertoire du projet via le navigateur pour l'édition.
- Édition directe du Vault : les bibliothèques de référence de code et les projets d'apprentissage enregistrés dans votre Vault peuvent aussi être ouverts et parcourus directement via le Code Server quand Pi vous pointe vers des exemples pertinents.
Preset Task : empaqueter les workflows Pi en plans de commande réutilisables
La flexibilité de Pi est puissante, mais répéter les mêmes choix de provider, frontières d'outils et cadrages de tâche encore et encore est gaspilleur.
Le mécanisme Preset Task de HagiCode transforme ces patterns répétés en modèles réutilisables. C'est plus que des commandes raccourcies — c'est une plateforme d'intégration Skills extensible :
Preset Task met à niveau votre collaboration avec Pi de 'reconstruire le workflow à chaque fois' à 'choisir le workflow préparé et l'exécuter'. C'est là que la configurabilité devient un véritable levier opérationnel.
- Compétences communautaires prêtes à l'emploi : importez des workflows de revue, refactor, CRUD et documentation éprouvés au lieu de les reconstruire à partir de zéro à chaque fois.
- Système de Skills extensible : adaptez les modèles partagés à vos conventions d'équipe, aux valeurs par défaut de routage et aux standards de codage.
- Opérations visuelles, pas de comptabilité terminal : choisissez des tâches, changez des paramètres et réordonnez l'exécution dans une interface dédiée au lieu d'encoder tout dans des habitudes CLI répétées.
Interface gamifiée : rendre les boutons de provider de Pi visibles et accessibles
La programmation elle-même peut être tedious, mais elle peut aussi être amusante. La conception d'interface gamifiée de HagiCode rompt avec l'expérience froide des outils en ligne de commande :
Pi fournit le contrôle, HagiCode fournit l'expérience — ensemble, ils transforment une CLI hautement configurable en un espace de travail que les gens peuvent réellement apprécier utiliser quotidiennement.
- Retour visuel clair : l'état de session, la progression et les résultats sont visibles sans fouiller dans la sortie terminal.
- Visualisation des accomplissements et de la progression : les commits, les jalons de proposition et les points de contrôle de livraison deviennent des marqueurs de rythme visibles au lieu d'un état d'arrière-plan invisible.
- Moins de friction d'utilisation : les développeurs qui ne sont pas des puristes du terminal peuvent aussi bénéficier du modèle de contrôle de Pi à travers une couche d'interface bien plus amicale.
Gestion des Agents : transformer plusieurs sessions Pi en une flotte d'Agents gérable
Les sessions parallèles sont utiles, mais une fois que vous en avez plusieurs qui tournent, la coordination devient le prochain goulot d'étranglement.
La couche de gestion des Agents de HagiCode transforme chaque worker Pi en un Agent nommé, planifiable, avec un statut visible, une portée assignée et une configuration indépendante.
Vous passez de 'beaucoup de terminaux sont ouverts' à 'une petite équipe IA est coordonnée en un seul endroit'.
- Visualisation de l'identité et du statut de l'Agent : voyez d'un coup d'œil quel Agent est en cours d'exécution, en attente, bloqué ou prêt à être archivé.
- Liaison tâche-à-Agent : propositions, revues, refactors et travaux de test peuvent chacun être assignés à un Agent dédié.
- Configuration d'Agent indépendante : différents Agents peuvent utiliser différentes routes de modèle, Skills, règles d'exposition d'outils et portées de contexte sans s'interférer.
Gestion multi-repo Monospecs : donner à Pi la carte de repo dont il a besoin
Dans les projets réels, le code vit rarement dans un seul dépôt. Frontend, backend, documentation, bibliothèques partagées sont dispersés à travers différents repos, et un seul changement de fonctionnalité peut nécessiter de toucher plusieurs repos simultanément. Pour Pi, le mode mono-repo fonctionne, mais il n'a pas de compréhension native des relations cross-repo — vous devez lui dire manuellement dans chaque conversation que 'ce changement doit aussi se synchroniser à deux autres repos', ce qui est clairement inefficace.
Le mécanisme Monospecs de HagiCode est la solution structurée conçue pour les scénarios multi-repo. Via le fichier de configuration .hagicode/monospecs.yaml, il déclare toutes les adresses, noms et relations des sous-repos dans le groupe de projets, donnant à Pi une carte cross-repo automatique au lancement des propositions :
Monospecs élimine essentiellement les angles morts cognitifs de Pi dans la collaboration cross-repo. La flexibilité de routage de Pi compte davantage une fois qu'il peut aussi voir la surface de changement complète.
- Prise de conscience automatique des relations de repo : lors de la création d'une proposition de développement, Pi peut lire directement la liste des sous-repos depuis la configuration Monospecs au lieu de s'appuyer sur une explication manuelle répétée.
- Suivi des changements cross-repo : les specs restent centralisées tandis que les changements de code restent dans les repos pertinents, gardant l'historique de décision et l'implémentation proprement séparés.
- Ciblage intelligent de repo lors des commits IA : HagiCode analyse vos changements par rapport à la configuration Monospecs et suggère où chaque commit appartient.
- AGENTS.md par repo : Pi reprend automatiquement les conventions spécifiques au repo en opérant à travers différentes codebases.
Base de connaissance cross-projet Vault : faire se souvenir Pi de plus qu'un tour terminal
Les contrôles de session de Pi sont utiles, mais même les sessions persistantes ne sont pas la même chose qu'une couche de mémoire cross-projet durable. Sans cela, un contexte important doit encore être réintroduit trop souvent.
Vault est la couche de stockage de connaissance persistante cross-projet de HagiCode. Sa philosophie de conception fondamentale est 'enregistrer une fois, réutiliser partout' :
Si Monospecs laisse Pi comprendre où sont les projets, Vault laisse Pi se souvenir de ce que vous avez déjà accumulé. Cela transforme une CLI configurable en un partenaire d'ingénierie à plus long terme.
- Conteneurs de connaissance multi-types : enregistrez des dossiers, des projets de référence de code, des notes Obsidian et des actifs de prompt gérés par le système en un seul endroit.
- Injection automatique de contexte IA : les nouvelles propositions démarrent avec le bon matériel de référence déjà disponible pour Pi.
- Contrôle d'accès fin : séparez les références en lecture seule des espaces de projet éditables pour que Pi puisse apprendre largement sans modifier la mauvaise chose.
- Réutilisation des connaissances cross-projet : les patterns capturés une fois peuvent soutenir chaque proposition ultérieure au lieu d'être reconstruits à partir de zéro.
Routage de modèle OmniRoute : rendre la conception provider-first de Pi utilisable à grande échelle
Les équipes devraient pouvoir conserver le workflow qu'elles aiment sans verrouiller l'accès au modèle à un seul fournisseur ou un seul chemin d'abonnement.
OmniRoute sépare la couche d'interaction de la couche de routage de modèle, de sorte que HagiCode peut garder Pi dans le workflow tout en changeant les sources de modèle en dessous.
Cela vous donne un meilleur contrôle des coûts, un meilleur appariement tâche-à-modèle et moins de remous de workflow quand les prix ou la disponibilité des modèles changent.
- Conservez la CLI ou le style d'interaction que vous préférez déjà tout en ne changeant que la route de modèle en dessous.
- Partagez une stratégie de routage entre plusieurs Agents et plusieurs outils IA connectés à HagiCode.
- Ajustez différentes routes de modèle pour différentes charges de travail, comme le codage rapide, la revue approfondie ou la planification d'architecture.
- Ajustez les coûts et capacités une fois sur la couche de routage au lieu de retravailler chaque workflow individuel.
