SpecScore vs CodeSpeak
Deux visions du rôle des spécifications. CodeSpeak traite la spécification comme lecode source — un LLM la compile, et vous maintenez la spécification au lieu du code. SpecScore traite la spécification comme un contrat ouvert et pérenne — vous conservez votre code, et n'importe quel agent (ou aucun) peut la lire, la linter et la tracer.
Ce qu'ils partagent.
Ce que CodeSpeak fait bien.
CodeSpeakest un système de programmation piloté par LLM qui compile des spécifications en anglais structuré vers du code.
Une thèse audacieuse, défendue avec crédibilité
« Maintenez la spécification, pas le code » est un véritable changement de paradigme, pas un ajustement incrémental. Formulée par le concepteur du langage Kotlin, l'idée mérite d'être prise au sérieux : si la spécification est la source, le code généré devient un simple détail d'implémentation.
Reprise de code existant vers la spécification
codespeak takeover analyse le code source existant et produit une spécification capturant son comportement — une passerelle à faible friction pour le code hérité, avec une compression annoncée de spécification-vers-code d'environ 5 à 10×.
Extraction d'intention depuis les sessions d'agents
L'Intent Studio de CodeSpeak extrait les exigences depuis les sessions d'agents passées — capturant l'intention que vous avez déjà exprimée au lieu de vous demander de rédiger une spécification depuis une page blanche.
Comparaison des fonctionnalités.
Les deux approches reposent sur des paris différents : le tableau compare philosophie et mécanique, pas des vainqueurs.
| Capacité | CodeSpeak | SpecScore |
|---|---|---|
| Source de vérité | La spécification (entrée de compilation) | La spécification est le contrat ; le code est le livrable |
| Code généré | Produit par un LLM, non maintenu manuellement | Vous et vos agents écrivez et possédez le code |
| Format de spécification | Anglais simple, défini par CodeSpeak | Standard ouvert Markdown + YAML, schéma publié |
| Spécification → code | Fonctionnalité centrale (compilateur LLM propriétaire) | Hors périmètre — tout agent implémente |
| Fonctionne sans le fournisseur | Les spécifications se compilent via CodeSpeak | Oui — les spécifications fonctionnent avec tout agent, ou aucun |
| Linting de spécifications | Non documenté | Qualité de contenu — verbes vagues, ACs manquants, références orphelines |
| Traçabilité code-vers-spécification | Via régénération | Annotations specscore: + remorques Verifies: |
| Déterminisme | Compilation LLM (non déterministe) | Requêtes CLI déterministes ; code écrit normalement |
| Code → spécification | codespeak takeover | survey + rédaction |
| Ouverture | Système propriétaire | Ouvert — format CC BY 4.0, outillage MIT / Apache-2.0 |
| Maturité | Aperçu alpha | En production |
En quoi SpecScore diffère.
Vous conservez votre code
CodeSpeak génère et régénère l'implémentation ; le code est une sortie, pas un actif. SpecScore laisse le code là où il doit être — entre vos mains, dans votre langage, révisable ligne par ligne. La spécification apporte clarté et traçabilité sans vous déposséder de votre code.
Vos spécifications sont portables
Une spécification CodeSpeak tire sa valeur du fait que CodeSpeak la compile. Une spécification SpecScore a une valeur propre intrinsèque — c'est un Markdown bien structuré que n'importe quel agent peut interpréter, et qui reste utile sans aucun outil SpecScore installé. Adoptez-la avec l'outil de votre choix, ou aucun. Quittez-la quand vous voulez.
L'ambiguïté est détectée avant qu'elle ne coûte cher
Avec un compilateur LLM, une spécification ambiguë se traduit par un code défectueux au moment du build. Le lint de SpecScore met en évidence les verbes vagues, les critères d'acceptation manquants et les références orphelines avant qu'un agent ne commence à coder.
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ verb "handle gracefully" — non mesurable
Déterminisme et traçabilité
La réponse de CodeSpeak à « quel code implémente cette exigence ? » est « tout le code, régénéré. » La réponse de SpecScore est un fichier et une ligne précis, viaspecscore code refs et les remorques de commit Verifies:— déterministe, auditable et directement vérifiable dans vos diffs.
Un graphe d'artefacts structuré
L'unité de base de CodeSpeak est un document de spécification en prose. SpecScore s'appuie sur une hiérarchie typée — les Idées deviennent des Features, les Features portent des Exigences et des Critères d'Acceptation munis d'identifiants, les Plans référencent les ACs, les Tâches référencent les Plans — le tout directement navigable par machine.
Aucun fournisseur dans la chaîne de build
SpecScore est un binaire Go autonome unique. Le linter s'exécute en CI et dans les hooks pre-commit sans compte requis, sans appel d'API distant et sans allers-retours vers un LLM dans votre build.
Quand choisir l'un ou l'autre.
Tournez-vous vers CodeSpeak quand…
- Vous souhaitez cesser de maintenir du code et laisser la spécification être la source unique.
- Vous êtes à l'aise avec la dépendance envers le compilateur d'un fournisseur unique pour obtenir ce levier.
- Vous souhaitez condenser une base de code existante en une spécification nettement plus compacte.
Utilisez SpecScore quand…
- Vous voulez des spécifications qui survivent à n'importe quel outil — portables par conception.
- Vous souhaitez conserver la maîtrise de votre code, dans votre langage, inspectable et souverain.
- Vous exigez un contrôle de qualité formel — le linting identifie l'ambiguïté au plus tôt.
- Vous avez besoin d'une traçabilité code-vers-spécification déterministe.
- Vous refusez tout fournisseur ou aller-retour vers un LLM dans le chemin critique de build.
Deux paris différents.
CodeSpeak parie sur un compilateur : confiez-lui la spécification et faites confiance au système pour produire et reproduire le code. SpecScore parie sur un format : gardez la spécification ouverte et portable, restez propriétaire de votre code, et laissez n'importe quel agent travailler dessus.
L'un troque la portabilité contre un levier puissant. L'autre préserve votre liberté — tout en restant vérifiable par linter.
Autres comparaisons.
Le même format, à côté d’autres outils de développement piloté par les spécifications :
Tous ensemble, sur une page : meilleurs outils de développement piloté par les spécifications en 2026.
Retour
Cette comparaison repose sur une documentation et un code source publics. Quelque chose est faux ou périmé ? ouvrez un ticket de correction. Voulez-vous que nous comparions SpecScore à un autre outil ? demandez-en une.