Exécuter Claude Code en tant que moteur de jugement pur sur l'ensemble du cycle de développement logiciel

Un développeur sur r/ClaudeAI a détaillé sa configuration, utilisée depuis des mois, qui exploite Claude Code (l'environnement d'exécution avec utilisation d'outils et boucle multitours) sur l'ensemble du cycle de vie du développement logiciel — tickets, implémentation multi-dépôts, revue de code, MRs, et une couche de connaissances persistante.

Décision architecturale clé : Garder Claude Code en dehors de l'orchestration. Du Python simple gère tout le travail mécanique : appels API Jira, opérations git, exécution de tests, lint, déplacements de fichiers. Claude Code n'est invoqué que pour le jugement — écrire du code, évaluer les résultats de revue, choisir entre des options architecturales. L'auteur a constaté que mélanger les deux (laisser l'agent orchestrer via des outils) rendait la première version lente, coûteuse et non déterministe.

Cycle de vie concret d'un ticket :

• Orchestrateur Python : Récupère le ticket Jira, cherche dans le wiki local les décisions architecturales associées, prépare un espace de travail sur une nouvelle branche, assemble un brief d'implémentation de 30 à 50 lignes (critères d'acceptation, fichiers cibles, appelants des fonctions partagées modifiées, normes pertinentes). Génère un paquet JSON.
• Claude Code : Lit le brief et écrit le code. C'est la seule étape avec une consommation de tokens significative.
• Python + sous-agent de revue : Exécute les tests, lint, formatage. En cas d'échec, il repasse la main à l'agent d'implémentation (maximum 3 tentatives). Ensuite, il déclenche un sous-agent de revue de code configuré sans permissions d'Édition ou d'Écriture — il peut seulement lire et signaler des problèmes.
• Python : Crée une proposition dans un tableau de bord. Après approbation manuelle, l'orchestrateur pousse et crée la MR.

Techniques spécifiques à Claude Code qui ont compté :

• Isolation des sous-agents. L'agent de revue fonctionne dans sa propre fenêtre de contexte avec une liste de refus (Edit, Write). La séparation de la revue et de l'implémentation a permis de détecter des changements de comportement dans le code partagé que l'agent d'implémentation manquait constamment.
• Les briefs pré-assemblés surpassent l'exploration dynamique. Au début, laisser Claude Code explorer le code avant l'implémentation consommait nettement plus de tokens que de lui remettre un brief ciblé assemblé par Python (récupération Jira, recherche wiki, analyse des dépendances).
• Routage des compétences/commandes via YAML plutôt que de laisser l'agent décider. La correspondance entre /ticket, /review, /standup, etc. et les orchestrateurs est explicite, de sorte que les capacités sont inspectables plutôt qu'émergentes.
• Les hooks sécurisent les commits. Un hook pre-commit exécute lint et format avant tout commit tenté par Claude Code. Les violations bloquent le commit ; l'agent doit les corriger.

Couche wiki : Pages Markdown avec trois niveaux de confiance (vérifié, inféré, fourni par un humain) et seuils de fraîcheur par champ. Sans cette classification, les agents traitent leurs propres inférences passées comme des vérités et transforment les hallucinations en connaissances d'apparence autoritaire.

Difficultés encore en cours :

• Fonctionnalités multi-dépôts : l'agent perd en cohérence lorsqu'une fonctionnalité s'étend sur plusieurs services, même avec un suivi structuré des ensembles de modifications.
• Tickets vagues : l'agent produit des implémentations raisonnables mais souvent incorrectes à partir de spécifications ambiguës. L'auteur marque désormais les tickets ambigus comme bloquants.
• Dépassement du périmètre : une tendance à la sur-ingénierie nécessite un calibrage constant via les normes et l'agent de revue.
• Sessions longues : le contexte antérieur sort de l'attention effective ; la réinitialisation en début de session atténue le problème mais ne l'élimine pas.