Spec Driven Development - rendre le vibe coding encore plus puissant

(ainativedev.io)

30 points par hexpeek 2025-09-06 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Avant de commencer

L’IDE Kiro a déjà été présenté sur GeekNews.

Cependant, il n’y avait pas encore eu d’introduction sous l’angle de la philosophie de la méthodologie de développement que vise Kiro, à savoir le Spec Driven Development (SDD),

et une vidéo très utile pour comprendre le Spec Driven Development ayant été publiée, je vous la présente ici.

Kiro

IDE de type agentique : un IDE qui aide au développement en langage naturel, tout en ayant un biais qui fait des « spécifications des artefacts de premier ordre ».
Il conserve la rapidité du « vibe coding » des IDE agentiques existants, tout en définissant les décisions, hypothèses et contraintes dans des documents de spécification.
Workflow : lorsqu’on saisit une idée, il démarre immédiatement en générant trois fichiers, requirements / design / tasks. L’éditeur prend la forme d’un fork de Code OSS sur lequel sont ajoutés les onglets « Specs / Hooks / Steering ».
- Specs : structure les exigences (histoires utilisateur + critères d’acceptation au format EAR), puis relie implémentation, tests et modifications aux spécifications.
- Hooks : surveille les changements de fichiers/code pour déclencher le workflow des spécifications.
- Steering : permet de versionner dans .kiro/, à la racine du dépôt, des règles d’équipe en markdown — par exemple des règles TDD pour uniformiser le comportement de l’agent.

Pourquoi le Spec Driven est nécessaire

Compenser les limites du vibe coding : lorsqu’on produit rapidement du code par aller-retour en chat, les raisons des décisions se perdent dans le flux de conversation, et plus tard il devient flou de savoir « ce qui a été construit et pourquoi ». Le SDD propose d’établir d’abord une spécification centrée sur le comportement afin de disposer d’une boussole stable.
Définition d’une spécification (comportement, propriétés, invariants) : il s’agit de décrire non pas l’implémentation, mais la manière dont le système doit se comporter — en reprenant les notions de propriétés de safety / liveness et d’invariants, tout en cherchant à les rendre accessibles avec une syntaxe pensée pour les développeurs.

Avantages du SDD

Visibilité et réutilisation des décisions : la spécification devient la « source » des changements de code, ce qui facilite revue et alignement, et même si la fonctionnalité évolue, l’intention (behaviors) demeure.
Spécifications vivantes et composables : scénarios utilisateur, critères d’acceptation, contrats d’interface/de données, performances/SLAs, etc. peuvent être modularisés, réutilisés et composés (du service au niveau système).
Application à tout le SDLC : de l’alignement en amont sur les exigences et la conception jusqu’à la boucle de feedback après le déploiement — l’idée étant de préserver revue, qualité et cohérence malgré la vitesse de génération de code à l’ère de l’IA.

Démo SDD

Pour le lien vers le moment de début de la démo dans la vidéo publiée dans le Main link, voir cette URL : https://youtu.be/olMxlFSxydc?si=sei-bBZ0Q0yszaWn&t=1085

Flux SDD

A. Configuration initiale

Configuration du projet - Hooks, Steering, MCP
Configuration TDD (recommandée)
Configuration des specs - rédaction de specs basées sur le format EAR (recommandé) (génération automatique possible via l’IA à partir de l’analyse d’un projet existant)

B. Implémentation des fonctionnalités

Dérivation des specs - refléter/mettre à jour de nouvelles exigences dans les specs
Mise en place de garde-fous (recommandé) - stubs de test, rédaction de règles
Implémentation <-> tests - cette phase est en grande partie répétée via l’IA, le développeur n’intervenant en général que pour de petites corrections de code que l’IA modifie mal

Une fois la structure du projet terminée, l’extension fonctionnelle se fait par répétition de l’étape « B. Implémentation des fonctionnalités ».

Points d’attention

Si la qualité du document de spécification n’atteint pas le niveau requis, cela ne fonctionne pas.
Les règles de référence appliquées aux documents de spécification dans la vidéo ne sont pas expliquées en détail. (Référence : https://kiro.dev/docs/specs/)
L’usage du TDD est recommandé, mais il est dit que la plupart des projets où le TDD n’était pas appliqué n’ont pas vraiment ressenti les bénéfices de cette méthodologie.

Avis personnel

L’une des méthodologies proposées depuis une autre perspective pour mieux exploiter l’IA.
Des documents toujours « bien » rédigés apportent énormément d’avantages. Cependant, au vu de l’expérience très concrète selon laquelle de nombreuses documentations sont difficilement maintenues dans le temps, la vraie question semble être de savoir dans quelle mesure cette approche pourra susciter une adhésion large.
À l’heure actuelle, la stratégie de développement IA + TDD est une méthodologie à laquelle de nombreux développeurs adhèrent et qui a été validée dans une certaine mesure. Si son efficacité pouvait être vérifiée en comparant l’usage du TDD seul et l’usage combiné avec le SDD, elle pourrait sans doute convaincre bien davantage.