Leçons tirées d’une bibliothèque no-code : le développement piloté par les spécifications n’est pas une équation, mais un triangle

À l’ère des agents de codage IA, considérer le développement piloté par les spécifications (Spec-Driven Development) comme une simple équation linéaire « spécification → code » est une vision erronée.

Argument central

Le développement piloté par les spécifications n’est pas une équation statique, mais un triangle dynamique.
Une boucle de feedback où trois axes s’influencent en permanence :

• Spécifications (Spec)
• Code (Code)
• Tests (Tests)

Ces trois éléments doivent rester synchronisés pour que l’ensemble fonctionne correctement.

Principaux cas et expérimentations

• La bibliothèque sans code whenwords, créée par Drew Breunig
  → Sans code, seules les spécifications (Markdown) et 750 tests (YAML) ont été publiés, puis un agent IA a généré le code
  → Intérêt d’Andrej Karpathy + plus de 1k étoiles sur GitHub + contributions actives

Mais un problème revient sans cesse dans ce type d’expériences :

• L’implémentation est rapide, mais dès que la complexité augmente un peu, corriger une partie en casse une autre
• Au final, la plupart des projets restent inachevés et tombent dans l’oubli
• Même avec de bonnes spécifications, les débats sur la manière d’implémenter persistent

Pourquoi un triangle ?

En écrivant le code → on découvre des ambiguïtés/erreurs dans les spécifications → on corrige les spécifications → de nouveaux tests deviennent nécessaires → on modifie à nouveau le code → …
→ parce que ce processus est une boucle qui se répète sans cesse.

Piste de solution : l’outil Plumb

L’outil CLI Plumb, créé par Drew

• À chaque commit Git, il analyse les journaux de conversation avec l’agent et les modifications du code
• Il extrait les décisions prises implicitement par l’agent → le développeur les approuve
• Les décisions approuvées → mise à jour automatique des spécifications
• Il fournit un rapport sur les écarts de couverture entre spécifications et tests
  → Avec un « mode d’échec du commit », il force une revue humaine des décisions importantes

Contexte historique

Nous revivons aujourd’hui la « crise du logiciel » des années 1960.
À l’époque, le code devenait trop volumineux pour être contenu mentalement → naissance du waterfall, de l’agile et du CI/CD
Aujourd’hui, il devient impossible même de lire le code → un nouveau processus est nécessaire
→ l’idée est que des outils comme Plumb montrent cette direction.

Conclusion en une phrase

À une époque où l’IA produit du code à une vitesse impressionnante,
la vraie difficulté est de maintenir en permanence la synchronisation du triangle spécifications-code-tests.

https://aisparkup.com/posts/9837