Deux mois avec Spec-Kit de GitHub et Claude Code : ce qui fonctionne, ce qui ne fonctionne pas

Après deux mois d'utilisation de spec-kit de GitHub pour le développement piloté par les spécifications (Spec-Driven Development, SDD) avec Claude Code comme agent principal, un développeur sur r/LocalLLaMA fait le point sur ce qui fonctionne et ce qui ne fonctionne pas. La boîte à outils, disponible sur github.com/github/spec-kit, impose un flux de travail en cinq phases : Constitution, Specify, Plan, Tasks, Implement. L'idée centrale : la spécification, et non l'invite, est la source de vérité.

Ce qui est vraiment bien

• Indépendant de l'agent : La même spécification fonctionne avec Claude Code, Cursor, Codex, Gemini CLI, Copilot. L'auteur a généré du code avec Claude Code, puis a transmis la spécification à Cursor pour le refactoring des tests de manière transparente.
• Points de contrôle stricts entre les phases : La phase Plan montre l'architecture complète proposée avant qu'aucun code ne soit écrit, ce qui permet de détecter les mauvaises décisions à un coût de correction de 5 minutes au lieu de 5 heures.
• Fichier de constitution comme porte qualité : Vous définissez à l'avance des règles inviolables — seuils minimaux de couverture de tests, listes d'autorisation de dépendances, budgets de performances, rigueur de typage. L'agent échoue à sa propre validation s'il tente de les violer.
• Déterminisme amélioré : Réexécuter la phase Implement produit des résultats plus cohérents qu'une invite brute, car l'agent ne comble pas 30 décisions implicites.

Ce qui agace

• La dérive est réelle : Des modifications manuelles du code sans mise à jour de la spécification provoquent une désynchronisation rapide. spec-kit dispose d'outils, mais ils sont encore jeunes.
• Surcharge pour les petites modifications : Les corrections de bogues inférieures à 50 lignes de code ou les fonctionnalités triviales semblent cérémonielles. La règle de l'auteur : utiliser le SDD complet uniquement pour les nouveaux modules ou les fonctionnalités touchant 200+ lignes de code.
• Migration de l'héritage douloureuse : Adapter le SDD à une base de code de 30 000 lignes prend des mois.
• La qualité dépend de l'agent : Claude Code (Sonnet/Opus 4.6+) le gère bien ; les modèles plus petits génèrent des plans qui compilent mais manquent de raisonnement architectural.

Configuration pratique

• Installation : uv tool install --from git+https://github.com/github/spec-kit.git specify-cli. Seul le dépôt officiel est sûr — PyPI contient des typosquatteurs.
• Agent principal : Claude Code, avec validation croisée sur Cursor et Gemini CLI.
• Persistance locale : SQLite (facile à spécifier/valider, aucune dépendance au cloud).
• Modèle de constitution réutilisable : typage strict, couverture pytest >80%, liste d'autorisation de dépendances explicite, aucun service cloud sauf si nécessaire.

Questions ouvertes

• Les modèles locaux (Qwen, DeepSeek-Coder, GLM, Llama) peuvent-ils gérer les phases Plan et Implement de manière compétente ? L'auteur a constaté que les petits modèles suivent le format mais que le raisonnement architectural échoue.
• Le SDD multi-agent fonctionne-t-il ? Spécification par un modèle, implémentation par un autre, audit par un troisième — théoriquement meilleur, mais pas significativement meilleur qu'un seul agent en pratique.