Comprendre le développement piloté par les spécifications (SDD) : Kiro, Spec-Kit, Tessl

• Le Spec-Driven Development (SDD) est une approche du codage assisté par l’IA qui consiste à rédiger d’abord une spécification (spec) avant d’écrire le code ; cette spécification sert de source de vérité pour les développeurs comme pour l’IA
• Le SDD se décline en trois niveaux de mise en œuvre : spec-first (spécification rédigée en premier), spec-anchored (spécification conservée pour la maintenance) et spec-as-source (la spécification devient le fichier source principal et le développeur n’édite pas directement le code)
• Kiro propose un workflow simple en 3 étapes — exigences → conception → tâches ; spec-kit utilise un workflow puissant fondé sur des règles appelé constitution (constitution) ; Tessl expérimente une approche spec-as-source avec un mappage 1:1 entre spécification et code
• Les trois outils imposent un processus trop lourd pour de petites corrections de bugs, la revue de fichiers Markdown est plus fastidieuse qu’une revue de code, et malgré de grandes fenêtres de contexte, l’IA ne suit pas toujours correctement toutes les consignes
• Le SDD rappelle les échecs passés du Model-Driven Development (MDD) et risque de cumuler les défauts des deux mondes — non-déterminisme et manque de flexibilité — ce qui exige encore de vérifier son utilité réelle en projet

---

Définition du développement piloté par les spécifications (SDD)

• Le SDD consiste à rédiger d’abord une spécification avant d’écrire le code, dans une approche « documentation first », où la spécification sert de source unique de vérité (single source of truth) pour les développeurs comme pour l’IA
• GitHub le définit ainsi : « la maintenance logicielle signifie faire évoluer la spécification ; le langage commun du développement se déplace vers un niveau plus élevé, et le code devient l’étape finale »
• Tessl le décrit comme « une approche du développement où la spécification devient l’artefact principal plutôt que le code ; la spécification décrit l’intention dans un langage structuré et testable, et les agents génèrent le code en conséquence »
• Le SDD se divise en trois niveaux de mise en œuvre
  • Spec-first : rédiger d’abord une spécification bien structurée, puis l’utiliser dans un workflow de développement assisté par l’IA
  • Spec-anchored : conserver la spécification après l’achèvement du travail afin de continuer à l’utiliser pour l’évolution et la maintenance de la fonctionnalité
  • Spec-as-source : la spécification reste le fichier source principal dans le temps ; les développeurs n’éditent que la spécification et ne touchent pas directement au code
• Toutes les approches SDD sont de type spec-first, mais elles ne visent pas toutes le spec-anchored ou le spec-as-source ; la stratégie de maintenance des spécifications dans le temps reste souvent floue, voire complètement ouverte

Qu’est-ce qu’une spécification (spec) ?

• Une spécification est un artefact structuré, orienté comportement et rédigé en langage naturel qui décrit une fonctionnalité logicielle et sert de guide à un agent de codage IA
• La définition la plus cohérente consiste à comparer la spécification à un document d’exigences produit (PRD)
• Il faut distinguer la spécification des documents de contexte général d’une base de code
  • Le contexte général inclut des fichiers de règles, des descriptions de haut niveau du produit et de la base de code ; certains outils appellent cela une memory bank
  • Les fichiers de memory bank sont pertinents pour toutes les sessions de codage IA sur la base de code, tandis qu’une spécification n’est pertinente que pour la création ou la modification d’une fonctionnalité donnée
• Chaque variante du SDD définit sa propre approche concernant la structure de la spécification, son niveau de détail et son organisation dans le projet

Pourquoi il est difficile d’évaluer les outils SDD

• Évaluer des outils et approches SDD dans des conditions proches de l’usage réel prend énormément de temps
  • Il faut les essayer sur des problèmes de tailles variées, sur des projets greenfield comme brownfield, et consacrer du temps à relire et corriger en profondeur les artefacts intermédiaires au lieu de les survoler
• Dans son billet sur spec-kit, GitHub souligne que « votre rôle n’est pas seulement de donner une direction, mais aussi de valider, puis de réfléchir et d’améliorer à chaque étape »
• Deux des trois outils semblent demander davantage de travail pour être introduits dans une base de code existante, ce qui rend encore plus difficile l’évaluation de leur utilité sur un codebase brownfield
• Tant qu’on n’a pas les retours de personnes qui les ont utilisés pendant un certain temps sur un vrai codebase, il reste de nombreuses questions sans réponse sur leur fonctionnement réel

Kiro

• Kiro est l’outil le plus simple et le plus léger des trois, et relève pour l’essentiel d’une approche spec-first
  • On n’a trouvé des exemples que pour des tâches ou user stories, sans mention de la manière d’utiliser les documents d’exigences dans une logique spec-anchored sur plusieurs tâches au fil du temps
• Workflow : exigences → conception → tâches
  • Chaque étape du workflow est représentée par un document Markdown, et Kiro guide ces trois étapes dans sa distribution basée sur VS Code

• Principaux composants de Kiro

  • Exigences (Requirements)
    • Structurées comme une liste d’exigences dans laquelle chaque exigence représente une « user story » (au format As a...)
    • Les critères d’acceptation utilisent le format GIVEN... WHEN... THEN...
  • Conception (Design)
    • Comprend des sections comme diagramme d’architecture des composants, flux de données, modèle de données, gestion des erreurs, stratégie de test, approche d’implémentation, stratégie de migration, etc.
    • Il n’est pas certain que cette structure soit constante ou variable selon la tâche
  • Tâches (Tasks)
    • Liste de tâches traçables via les numéros d’exigence
    • Fournit aussi des éléments d’interface supplémentaires permettant d’exécuter les tâches une par une et de revoir les modifications tâche par tâche

• La memory bank de Kiro

  • Kiro appelle son concept de memory bank le steering
    • Le contenu est flexible et le workflow ne semble pas dépendre de la présence de fichiers spécifiques
  • Quand on demande à Kiro de créer des documents de steering, la structure par défaut générée est product.md, structure.md, tech.md

Spec-kit

• spec-kit est la version SDD de GitHub, distribuée sous forme de CLI capable de générer la configuration d’un workspace pour différents assistants de codage génériques
• Une fois la structure en place, on interagit avec spec-kit via les slash commands de l’assistant de codage
• Comme tous les artefacts sont placés directement dans le workspace, c’est l’outil le plus personnalisable des trois

• Le workflow de spec-kit

  • Workflow : constitution (Constitution) → 𝄆 spécification (Specify) → plan (Plan) → tâches (Tasks) 𝄇
  • La notion de memory bank dans spec-kit est une condition préalable à l’approche spec-driven
    • Elle est appelée constitution (constitution) et contient des principes de haut niveau « immuables » qui doivent toujours s’appliquer à chaque modification
    • C’est un fichier de règles très puissant, largement utilisé dans le workflow

• Fonctionnement de spec-kit

  • À chaque étape du workflow (specify, plan, tasks), il utilise des scripts bash et des templates pour instancier des fichiers et des ensembles de prompts
  • Le workflow utilise abondamment des checklists dans les fichiers pour suivre les clarifications utilisateur nécessaires, les violations de constitution, les travaux de recherche, etc.
    • Cela joue le rôle d’une « definition of done » à chaque étape du workflow (sans garantie à 100 %, puisque c’est l’IA qui l’interprète)
  • Une même spécification est composée de plusieurs fichiers
    • Par exemple : data-model, plan, tasks, spec, research, api, component, soit huit fichiers

• L’approche de spec-kit

  • GitHub semble au départ viser une approche spec-anchored
    • « Nous repensons les spécifications non plus comme des documents statiques, mais comme des artefacts vivants et exécutables qui évoluent avec le projet ; la spécification devient une source de vérité partagée »
  • Mais spec-kit crée une branche pour chaque spécification générée, ce qui laisse penser qu’il considère les spécifications comme des artefacts vivants pendant la durée d’une demande de changement, plutôt que pendant tout le cycle de vie d’une fonctionnalité
  • Les discussions de la communauté relèvent aussi cette confusion, et spec-kit semble encore relever seulement du spec-first, sans véritable dimension spec-anchored dans le temps

Tessl Framework

• Tessl Framework est en bêta privée et, comme spec-kit, distribué sous forme de CLI capable de générer des structures de workspace et de configuration pour divers assistants de codage
• Les commandes CLI fonctionnent aussi comme serveur MCP

• Caractéristiques de Tessl

  • C’est le seul des trois outils à viser explicitement une approche spec-anchored, tout en explorant aussi un SDD de niveau spec-as-source
  • Les spécifications Tessl peuvent devenir l’artefact principal à maintenir et à éditer, tandis que le code est marqué en tête par le commentaire // GENERATED FROM SPEC - DO NOT EDIT
    • À ce stade, il existe un mappage 1:1 entre spécification et fichier de code, autrement dit une spécification est transformée en un fichier de la base de code
    • Comme l’outil est encore en bêta et expérimente différentes versions, cela pourrait évoluer vers une spécification mappée à un composant de code comprenant plusieurs fichiers

• Structure des spécifications Tessl

  • Des tags comme @generate ou @test indiquent à Tessl quoi générer
  • La section API illustre l’idée de définir dans la spécification l’interface minimale exposée au reste du codebase, afin de garantir que des parties importantes du composant généré restent sous le contrôle total du mainteneur
  • L’exécution de tessl build génère alors le fichier de code JavaScript correspondant

• Le niveau d’abstraction de Tessl

  • En plaçant les spécifications spec-as-source à un niveau d’abstraction assez bas, fichier par fichier, on réduit le nombre d’étapes et d’interprétations que le LLM doit effectuer, et donc les risques d’erreur
  • Pourtant, même à ce faible niveau d’abstraction, on observe du non-déterminisme lors de plusieurs générations de code à partir de la même spécification
    • Le fait de devoir réécrire sans cesse la spécification et la rendre de plus en plus précise pour améliorer la reproductibilité du code rappelle les pièges et difficultés d’une spécification complète et non ambiguë

Observations et questions

• Un seul workflow peut-il couvrir toutes les tailles de problème ?

  • Kiro et spec-kit proposent chacun un workflow assez dogmatique, qui pourrait ne pas convenir à la plupart des vrais problèmes de développement
  • On ne sait pas s’ils offrent assez de variété pour s’adapter à la taille du problème
    • En essayant de corriger un petit bug avec Kiro, le workflow a donné l’impression d’utiliser un marteau pour casser une noix
    • Le document d’exigences a transformé un petit bug en 4 « user stories » avec 16 critères d’acceptation au total
  • Avec spec-kit aussi, il est difficile de savoir pour quelle taille de problème l’utiliser
    • En essayant une fonctionnalité qui aurait autrefois représenté une user story de 3 à 5 points dans une équipe, le nombre d’étapes et de fichiers Markdown générés par spec-kit a semblé disproportionné par rapport à la taille du problème
    • Dans le même temps, la fonctionnalité aurait probablement pu être implémentée avec un codage IA « classique », avec une bien plus grande sensation de contrôle
  • Un outil SDD efficace devrait offrir au moins plusieurs workflows de base adaptés à des changements de tailles et de types variés

• Relire du Markdown plutôt que du code ?

  • spec-kit génère beaucoup de fichiers Markdown à relire
    • Ils sont redondants entre eux et aussi par rapport au code existant
    • Certains contiennent déjà du code, ce qui rend l’ensemble très verbeux et fastidieux à passer en revue
  • Dans Kiro, il n’y a que 3 fichiers, et le modèle mental “exigences > conception > tâches” est plus intuitif, donc un peu plus facile à suivre
    • Mais Kiro reste lui aussi trop verbeux pour le petit bug qu’on voulait corriger
  • Franchement, on se dit qu’il vaut mieux relire le code que tous ces fichiers Markdown
  • Un outil SDD efficace devrait fournir une excellente expérience de revue des spécifications

• Un faux sentiment de contrôle ?

  • Malgré tous ces fichiers, templates, prompts, workflows et checklists, on observe souvent que l’agent ne suit pas au final toutes les consignes
  • L’agrandissement des fenêtres de contexte est souvent présenté comme un facteur rendant le SDD possible, mais une fenêtre plus grande ne signifie pas que l’IA comprend correctement tout ce qu’elle contient
  • Exemples
    • spec-kit avait une phase de recherche lors de la planification et avait beaucoup analysé le code existant, mais au final l’agent a ignoré le fait qu’il s’agissait de la description d’une classe existante, l’a prise pour une nouvelle spécification et a tout régénéré, créant ainsi des doublons
    • On a vu non seulement des cas où les consignes étaient ignorées, mais aussi des agents qui en faisaient trop en essayant de suivre trop scrupuleusement une instruction, par exemple un article de la constitution
  • L’expérience passée montre que la meilleure manière de garder le contrôle sur ce qu’on construit reste de petites étapes itératives, d’où un fort scepticisme face à une lourde conception préalable des spécifications
  • Un outil SDD efficace devrait accepter une approche itérative, mais de petits lots de travail semblent presque aller à l’encontre de l’idée même du SDD

• Comment séparer efficacement spécification fonctionnelle et spécification technique ?

  • Dans le SDD, l’idée de séparer volontairement spécification fonctionnelle et implémentation technique est courante
    • L’ambition de fond est que l’IA finisse par compléter tous les détails de la solution et permette même de changer de stack technique à partir de la même spécification
  • En pratique, lors de l’essai de spec-kit, il y avait souvent de la confusion sur le moment où il faut rester au niveau fonctionnel et celui où il faut ajouter des détails techniques
    • Les tutoriels et la documentation n’étaient pas cohérents sur ce point, avec différentes interprétations de ce que signifie réellement « purement fonctionnel »
  • Quand on repense à toutes les user stories qui n’ont pas su séparer correctement exigences et implémentation, il faut bien reconnaître que la profession n’a pas un grand historique de réussite sur ce sujet

• À qui cela s’adresse-t-il ?

  • Beaucoup de démos et tutoriels d’outils spec-driven incluent la définition des objectifs produit et fonctionnels, et utilisent aussi des termes comme “user story”
  • L’idée est peut-être d’utiliser l’IA comme levier de cross-skilling pour amener les développeurs à participer plus activement à l’analyse des besoins
    • Ou bien de faire travailler le développeur en binôme avec le responsable produit dans ce workflow ?
  • Rien de tout cela n’est vraiment expliqué explicitement, et tout est présenté comme si le développeur allait naturellement faire lui-même toute cette analyse
  • Dans ce cas, pour quelle taille et quel type de problème le SDD est-il fait ?
    • Il est probablement peu adapté à de grandes fonctionnalités encore très floues ; dans ces cas, il faut clairement davantage de travail produit et d’exigences, ainsi que de la recherche et l’implication des parties prenantes

• Spec-anchored et spec-as-source : apprend-on du passé ?

  • Beaucoup rapprochent le SDD du TDD ou du BDD, mais surtout pour le spec-as-source, un autre parallèle important mérite d’être examiné : le MDD (Model-Driven Development)
  • Au début de carrière, plusieurs projets utilisaient largement le MDD, et l’essai de Tessl Framework y a constamment fait penser
    • Les modèles du MDD étaient en pratique des spécifications, mais exprimées non en langage naturel, mais via un UML personnalisé ou un DSL textuel
    • On construisait des générateurs de code sur mesure pour transformer ces spécifications en code

• Comparaison entre MDD et SDD

  • Au final, le MDD n’a pas réussi dans les applications métier, car il se situait à un niveau d’abstraction maladroit et générait trop d’overhead et de contraintes
  • Mais les LLM suppriment une partie de cet overhead et de ces contraintes du MDD, ce qui fait naître un nouvel espoir : se concentrer sur la rédaction des spécifications et générer le code
  • Avec les LLM, on n’est plus limité à un langage de spécification prédéfini et parseable, et il n’est plus nécessaire de construire un générateur de code sophistiqué
    • Le prix à payer, bien sûr, c’est le non-déterminisme des LLM
  • Les structures parseables avaient aussi l’avantage d’offrir de nombreux outils d’assistance à l’auteur de spécifications pour produire des spécifications valides, complètes et cohérentes ; cet avantage se perd désormais
  • Le spec-as-source, et même le spec-anchoring, pourrait finir par cumuler les inconvénients du MDD et ceux des LLM : rigidité et non-déterminisme
  • Il faut regarder les tentatives passées de spec-from-code et en tirer des leçons lorsqu’on explore aujourd’hui les approches spec-driven

Conclusion

• Personnellement, lorsqu’on utilise le codage assisté par l’IA, on passe souvent du temps à rédiger soigneusement la forme de spécification qu’on va fournir à l’agent
  • Le principe général du spec-first a donc clairement de la valeur dans bien des situations
• Il y a un vrai besoin de différentes approches pour structurer les spécifications, et c’est actuellement l’une des questions qui reviennent le plus souvent chez les praticiens
  • « Comment structurer une memory bank ? », « Comment rédiger de bons documents de spécification et de conception pour l’IA ? »
• Mais le terme « spec-driven development » reste encore mal défini, et son sens s’est déjà largement dilué
  • On entend même parfois utiliser « spec » comme simple synonyme de “prompt détaillé”

• Évaluation des outils

  • Certains essaient de transposer de manière trop littérale des workflows existants vers des agents IA, au risque d’amplifier des problèmes déjà connus comme la surcharge de revue ou les hallucinations
  • Surtout pour les approches les plus sophistiquées qui génèrent beaucoup de fichiers, cela fait penser au mot composé allemand « Verschlimmbesserung » (rendre quelque chose pire en essayant de l’améliorer)
    • On peut se demander si, en voulant améliorer les choses, on n’est pas en train de les rendre plus mauvaises

[aer0700]

Cela ressemble un peu aux discussions précédentes sur le document driven development ou le README driven development.
https://fr.news.hada.io/topic?id=15502

[GN⁺]

Avis Hacker News

• Je suis de près la tendance récente du SDD (développement piloté par les spécifications) ; l’approche paraît raisonnable, mais j’ai aussi l’impression qu’on revient à l’époque pré-Agile des spécifications fonctionnelles et des documents de conception. Ce n’est pas tout à fait du Big Design Up Front, mais on dirait qu’on se rapproche peu à peu de « logiciel qui fonctionne == documentation parfaite ».
  Référence Big Design Up Front, Référence Agile Manifesto

  • Au fond, les spécifications fonctionnelles et les documents de conception reviennent à coder en langage naturel. Autrefois, un humain devait ensuite les retranscrire dans un langage de programmation, mais désormais des compilateurs automatisés comme les LLM (grands modèles de langage) commencent à prendre le relais. Cela permet de sauter une étape, avec des taux de réussite variables.<br /> À l’inverse, l’Agile ne se préoccupe pas du langage dans lequel le logiciel est produit ; l’essentiel est d’« écarter les managers » et de faire en sorte que les développeurs prennent aussi en charge les tâches de gestion. Les 12 principes détaillent davantage ce que les développeurs doivent faire en l’absence de managers.

  • Le Behaviour Driven Design peut produire des « spécifications vivantes » comme le Test Driven Design. On peut laisser une trace sous forme de documents lisibles par des humains, depuis les critères d’exploration du domaine jusqu’au passage des tests, puis les relier directement au test harness pour valider les fonctionnalités en place. On obtient ainsi, via les rapports BDD, des spécifications clairement vérifiées, collaboratives et itérables, tout en conservant Agile, JIT et YAGNI sans travail initial superflu. Pas besoin de revenir au waterfall.

  • On peut aussi partir d’une petite conception : rédiger une spécification d’une ou deux pages, générer le code et les tests avec un LLM, puis affiner par itérations. Si l’on fait vraiment confiance au codage 100 % LLM, alors il est logique de gérer de manière structurée les entrées de spécification (prompts en anglais). En les organisant au lieu de les jeter, on peut les réutiliser plus tard ou ajouter clairement des contraintes supplémentaires.<br /> Cela dit, je reste mal à l’aise à l’idée d’utiliser des LLM pour du code de production critique, donc je n’expérimente que pour des usages sandbox / test / démo, là où la qualité du code n’a pas besoin d’être irréprochable.

  • Le spec driven development est en soi une bonne idée. En revanche, les implémentations actuelles se contentent souvent de passer à l’agent des fichiers Markdown non structurés, ce qui donne des résultats peu fiables et en pratique aucune reproductibilité. Si l’agent rédige aussi les spécifications, il faudrait qu’elles soient structurées de manière à pouvoir être transformées automatiquement en code stub et en tests. Il ne faut pas jeter le Markdown, mais si on le relie à un générateur de code, la reproductibilité s’améliorerait nettement. Et en pratique, cela permettrait de réduire fortement le temps passé à générer du code répétitif.

• En essayant SpecKit, j’ai trouvé ça vraiment intéressant et satisfaisant, mais j’ai eu du mal à trouver des exemples ou des usages réalistes et complexes. Les tutoriels s’arrêtent généralement à une simple installation suivie d’un « créer une app de todo-list ». J’aimerais voir de vrais cas d’usage sur l’amélioration progressive ou le refactoring d’une base de code legacy, ou encore sur la manière d’aborder un grand projet où le spec driven development n’a pas été appliqué dès le départ.

  • De mon côté aussi, en combinant approche BDD et codage via CLI, j’ai constaté qu’enregistrer les fonctionnalités directement dans du vrai code était bien plus efficace que de longs fichiers Markdown verbeux. S’il faut une checklist pour que l’IA suive, un fichier comme agents.md suffit largement. Il suffit de consigner une fois les coding patterns et les exigences non fonctionnelles (NFR) pour que l’agent puisse s’y conformer clairement.

  • Pour une vraie utilisation, il faut lire directement le template ou le source code afin de comprendre ce qui tourne réellement. Dans ce genre de projet, je trouve que c’est presque inévitable.

• Après la présentation d’un spécialiste de la livraison pilotée par l’IA issu de Thoughtworks, le sujet des memory banks est arrivé et j’ai immédiatement compris de quoi il retournait. Nous aussi, à force de travailler dans un environnement où « l’IA est partout », on a constaté que plus le memory bank grossit, plus l’IA perd la direction et plus les résultats deviennent chaotiques. Au final, il faut qu’une personne qui comprend complètement le produit guide elle-même l’IA pour que cela soit réellement applicable sur le terrain. J’ai vécu d’innombrables cas où l’IA m’a induit en erreur ; quand un humain la recadre, elle s’excuse et dit comprendre, mais en pratique cela ne change rien. Et il est irréaliste d’imaginer qu’une IA puisse lire et vérifier l’énorme masse de documents qu’elles produisent entre elles. À ce compte-là, on se dit qu’il vaut souvent mieux faire le travail soi-même.

  • Je me demande ce qu’on entend exactement par memory bank, et plus précisément ce qu’on veut dire à propos de son rôle.

  • À ce stade, les fonctions de memory font plutôt plus de mal que de bien. Sans vraie stratégie de recherche / consultation, elles ne font qu’amplifier de mauvais résultats. La plupart des systèmes de memory sont conçus pour un paradigme de chat unique, et provoquent donc surtout des problèmes dans des environnements variés. Une véritable « mémoire » devrait plutôt prendre la forme d’un « métacognitif / réseau en mode par défaut » séparé de l’agent principal, qui conçoit de façon asynchrone la structure des tâches et le contexte, puis oriente chaque prompt. En d’autres termes, ce qu’il faut, c’est une « mémoire pilotée par agents ».

  • Et puis ces intitulés de « thought leader » sur LinkedIn et ailleurs, je ne comprends pas non plus. J’ai vraiment du mal à savoir ce que ce genre de titre signifie aujourd’hui.

• J’aimerais partager mon expérience des deux dernières semaines d’expérimentation avec SpecKit et Claude Code sur deux nouveaux projets. Comme j’ai développé les deux projets seul, je pouvais me permettre d’expérimenter sans trop de risque. Pour le premier projet, j’ai laissé SpecKit faire comme prévu : il a fallu 10 jours pour terminer toutes les tâches, mais la plupart des tests du résultat échouaient et le build était cassé. Il a fallu consacrer autant de temps à corriger les problèmes, et Claude réparait une chose pour en casser une autre, ce qui a énormément fait chuter ma confiance.<br /> Sur le deuxième projet, j’ai voulu travailler par petites itérations. Après le planning SpecKit, j’ai ajouté des slash commands pour créer un backlog.md, puis utilisé plan-sprint pour générer un fichier contenant l’objectif du sprint et le détail du travail, avant d’exécuter implement-sprint en lot. Mais là aussi, le processus ne suivait pas correctement les consignes d’implémentation : même après plusieurs ajustements, il oubliait de créer les tests ou omettait certaines tâches.<br /> J’ai donc encore modifié la configuration : j’ai introduit un subagent dédié à une tâche précise, et transformé implement-sprint en simple orchestrateur. Avec cette approche, je pouvais examiner l’état du code à chaque sprint, ce qui rendait l’ensemble bien plus fiable. Il arrive encore qu’il dise avoir terminé alors que les tests échouent, mais c’est tout de même plus gérable que de devoir tout revoir soi-même.<br /> Mon hypothèse actuelle est que Claude est faible en TDD. Il rencontre toujours des problèmes à l’étape d’écriture des tests en premier. La prochaine fois, je compte essayer d’écrire les tests après l’implémentation. Ce n’est pas idéal, mais si cela améliore malgré tout la productivité, ce sera sans doute préférable au codage manuel.

• J’ai trouvé intéressant que la plupart des outils soient alignés sur une stratégie « spécification d’abord », tout en restant flous sur la manière de maintenir ces spécifications. De mon côté, avec mon cofondateur, nous misons totalement sur le « spec as source ». Nous essayons de faire de la spécification la vraie source, car cela nous semble être l’usage le plus intéressant, mais c’est très difficile à faire adopter en pratique. Si quelqu’un a de l’expérience ou des retours sur le sujet, j’aimerais vraiment en entendre parler.<br /> Si cela vous intéresse, vous pouvez aussi essayer notre terrain d’expérimentation, specific.dev, et nous dire ce que vous en pensez.

  • Si la spécification est vraiment la source, alors elle doit devenir un langage formel exécutable — autrement dit, un langage de programmation. Sinon, une spécification reste une spécification, et le code source reste du code source. Au final, tout le monde doit quand même apprendre ce qu’est du « bon code ».

• J’ai essayé le workflow spec-driven de Kiro, et il génère une quantité énorme de tâches (au moins 4 sous-tâches par tâche, plus de 12 tâches au total). Le workflow en lui-même était correct, mais il supprimait du code de manière imprévisible et ne faisait pas de rollback. On dirait que, comme il a été conçu comme un IDE, trop de ressources sont absorbées par la gestion des cas limites de l’interface. Plutôt que de découper à l’excès, il est plus simple de faire des itérations légères et d’améliorer progressivement. C’est « casser une noix avec une énorme masse ».

• J’ai bien aimé l’idée d’utiliser des slash commands personnalisées pour emballer les entrées dans des prompts bien structurés, ainsi que le fait d’injecter aussi comme contexte les fragments extraits depuis des fichiers comme agents.md.<br /> En revanche, je n’aime pas trop le fait de vouloir tout démêler à tout prix, car on retombe sur cette impression de casser une noix au marteau, donc de créer de la complexité. Mais je pense que cela pourrait devenir plus léger si l’on pouvait gérer le contexte de manière sélective avec des slash commands supplémentaires seulement quand c’est nécessaire (/experiment, /stub, etc.). Et à la fin, une commande dédiée du type "/wrap-up" pourrait tout rattacher d’un coup, un peu comme un médecin qui fait une vérification générale après une opération.

• En utilisant SpecKit, je me demandais toujours : « à quel moment toutes ces specs vont-elles enfin être réunies en une seule vraie source de vérité (ground truth) ? » J’étais déçu de voir que cette étape semblait tout simplement absente.<br /> Il reste maintenant à définir et concevoir ce que devrait être une spécification de communication entre humains et agents. Je réfléchis à la manière de concrétiser l’idée de « spec anchored » évoquée par Birgitta.

  • Avec l’arrivée de l’IA, j’ai l’impression qu’il est vraiment temps de définir ce type de standard. Il faut formaliser les spécifications de manière à ce qu’un humain puisse encore les lire et les gérer, tout en permettant qu’elles tiennent au moins partiellement dans le contexte d’un LLM, et qu’il soit possible de n’en ingérer qu’une partie tout en conservant l’intention essentielle et la conception afin d’effectuer un vrai travail utile.<br /> Si les approches du type UML ou Rational Rose ont échoué, c’est selon moi parce que l’intention n’y était pas suffisamment concrète et qu’il n’en restait que des schémas, utilisés seulement aux étapes de documentation, de maintenance et de refactoring. En conséquence, cela ne devenait utile qu’après la mise en production, ce qui le rendait presque sans intérêt.<br /> C’est pourquoi je commence maintenant à m’intéresser à de nouvelles approches comme le modèle C4.

• Je ne sais pas pourquoi le SDD est soudainement devenu si populaire, mais personnellement j’y vois surtout un intérêt pratique : créer simplement des fichiers de spécification pour « visualiser à l’avance le résultat final » et suivre la progression lorsqu’on découpe un projet en petites parties. Je n’utilise ni outil ni framework particulier, seulement des fichiers Markdown. Je n’ai pas trouvé beaucoup de valeur à aller vers un système plus complexe.

• Quand j’ai utilisé spec-kit pour la première fois, j’étais vraiment enthousiaste. Mais en pratique, il forçait la création de tâches comme si l’on allait jusqu’à « construire un robot dans une grotte », et transformait démesurément de simples travaux où il aurait juste fallu resserrer quelques vis. À force de corriger ces excès, j’ai fini par me lasser et abandonner. Je trouve ce workflow excessivement complexe, au point de ne même pas valoir l’effort de compensation.

[jjw9512151]

En fait, c’est simple et pratique si vous pensez à ce que vous avez appris en génie logiciel, mais en le faisant en Markdown. Il suffit de bien rédiger le cahier des exigences.