Workflow Pi + Claude Code

Le workflow combiné : explorer puis implémenter

Pi et Claude Code ne sont pas en concurrence — ils se complètent. Pi excelle en exploration rapide avec des modèles économiques. Claude Code excelle en implémentation avec le contexte projet complet. Un workflow mature utilise les deux, chacun là où il est le plus efficace.

Les 4 phases du workflow combiné

Point clé : La logique est économique autant que technique. L’exploration consomme beaucoup de tokens (essais, erreurs, itérations). Utiliser un modèle cher pour explorer, c’est brûler du budget sur des tentatives jetables. Réserver le modèle cher pour l’implémentation finale, c’est payer pour de la valeur.

Phase 1 : Pi pour explorer

L’exploration consiste à tester une approche avant de s’engager. Avec Pi, on peut lancer une session avec un modèle Groq ou Gemini (quasi gratuit), essayer plusieurs directions, et jeter sans regret.

Exemple concret

# Explorer une approche avec un modèle économique
pi --model groq:llama-3.3-70b "Comment structurer un middleware
  d'authentification en .NET 8 ?"

# Tester une variante dans un tree session
pi --model gemini:gemini-2.5-flash "Même question mais avec
  des policies-based authorization"

Les tree sessions de Pi sont particulièrement utiles ici : chaque branche est une direction d’exploration indépendante. On peut explorer 3 approches en parallèle sans polluer l’historique.

Attention : L’exploration avec Pi ne produit pas du code production-ready. Elle produit une direction validée. Le code final sera écrit par Claude Code avec le contexte projet.

Phase 2 : Claude Code pour implémenter

Une fois la direction choisie, on bascule sur Claude Code. Le CLAUDE.md du projet encode les conventions, l’architecture, les patterns. Le modèle Claude (Sonnet ou Opus) produit du code qui respecte le contexte.

Le transfert de contexte

Le passage de Pi à Claude Code est un moment critique. Il faut transférer la conclusion de l’exploration, pas l’exploration elle-même.

# Prompt pour Claude Code après exploration Pi

J'ai exploré avec Pi un middleware d'authentification .NET 8.
Conclusion : policies-based authorization avec des requirements
custom plutôt que des roles statiques.

Implémente cette approche en suivant les conventions du CLAUDE.md.
Fichiers concernés : src/Infrastructure/Auth/

Point clé : Ne pas copier-coller le code de Pi dans Claude Code. Transmettre la décision, pas le brouillon. Claude Code repartira du CLAUDE.md et produira un code cohérent avec le projet.

Phase 3 : Pi en CI

Pi en mode print ou avec une sortie JSON est un outil de CI puissant et économique. On peut automatiser des vérifications avec un modèle pas cher.

Cas d’usage CI

# Vérifier la cohérence d'un fichier de config
pi --print --model groq:llama-3.3-70b \
  "Vérifie que ce docker-compose.yml est cohérent" < docker-compose.yml

# Générer un résumé de PR en JSON
pi --print --model gemini:gemini-2.5-flash \
  --format json "Résume les changements de ce diff" < pr.diff

Le mode --print désactive l’interactivité : Pi lit stdin, génère une réponse, et sort. C’est le mode pipeline, idéal pour les scripts CI. Le coût par exécution est négligeable avec un modèle Groq ou Gemini.

Attention : Les checks CI avec Pi sont des vérifications heuristiques, pas des garanties formelles. Un modèle économique peut rater des subtilités. Ce sont des filets de sécurité supplémentaires, pas des remplacements de tests.

Phase 4 : Claude Code pour la review

La review de code est une tâche à haute valeur ajoutée qui justifie un modèle premium. Claude Code peut lancer un sub-agent dédié à la review avec le contexte projet complet.

# Review avec sub-agent Claude Code
claude "Review les changements sur la branche feature/auth-middleware.
  Vérifie la cohérence avec l'architecture hexagonale du projet."

Le sub-agent review a accès au CLAUDE.md, à l’historique git, aux tests existants. Il peut détecter des incohérences architecturales qu’un modèle sans contexte manquerait.

Le modèle PITER multi-outils

Le modèle PITER (Planner, Implementer, Tester, Evaluator, Reviewer) se distribue naturellement entre Pi et Claude Code.

Le Core Four dans le workflow combiné

Le Core Four (Context, Model, Prompt, Tools) s’applique différemment selon la phase :

• Context : minimal en exploration (Pi), maximal en implémentation (Claude Code + CLAUDE.md)
• Model : économique en exploration et CI (Groq, Gemini), premium en implémentation et review (Claude)
• Prompt : exploratoire et ouvert avec Pi, précis et contraint avec Claude Code
• Tools : 4 outils core avec Pi, 15+ outils intégrés avec Claude Code

Point clé : Le workflow combiné optimise chaque dimension du Core Four selon la phase. C’est l’application directe du principe “bon outil pour la bonne tâche” à l’échelle d’un cycle de développement complet.