Specification-Driven Development : du Vibe Coding à l’Agentic Engineering

Apparu en février 2025, le terme Vibe Coding a fait l’objet d’une hype sans précédent. Si l’on en croyait certains de ses promoteurs à l’époque, il était désormais possible de générer des applications entières et fonctionnelles sans connaissance préalable en développement, uniquement en utilisant des agents conversationnels augmentés d’outils de type no-code. De nombreux posts et vidéos sur les réseaux sociaux ont argué du fait que le métier de développeur et développeuse informatique s’en trouvait incroyablement menacé, nourrissant discussions et débats enflammés mais rarement constructifs et réellement argumentés. Toutefois, le développement augmenté se déploie à grande vitesse au sein des organisations, c’est donc une tendance de fond que les ingénieurs se doivent d’analyser, et pour laquelle ils doivent le cas échéant mettre à niveau leurs pratiques.

Les limites du vibe coding

Le Vibe Coding représente le fait d’exprimer un besoin dans une conversation avec un agent, lequel va l’implémenter. Il suffit d’expérimenter un peu pour constater un effet “wouah” indéniable pour peu que l’on sache indiquer des instructions plus ou moins avancées, car le feedback est très rapide même pour une personne expérimentée particulièrement véloce. Si l’on continue l’expérience sans prendre de précaution particulière, on observe néanmoins plus ou moins rapidement quelques-uns des phénomènes suivants : c’est de moins en moins rapide, il faut se répéter, faire du micro-management d’agent, cela devient ainsi un peu contre-productif. On a le sentiment que cette activité est un peu au développement augmenté ce que du code sans tests et non versionné est au développement classique : une version “quick and dirty”, aventureuse, jetable. Mais est-ce inéluctable ?

Comment fonctionne un agent

Que vous utilisiez un agent de code dans un IDE, un chat, ou un terminal, le fonctionnement reste le même. Pour résumer, leur rôle est de faire l’intermédiaire entre l’humain et des tiers : le modèle LLM, des outils locaux ou distants, des ressources comme des fichiers, etc.

Tout ce qui s’y passe, notamment ce qui est issu des échanges avec l’humain, est directement dicté par le LLM : réflexion, ordonnancement, contenu généré, etc. L’agent n’est donc qu’un exécutant de tâches au sein de qu’on appelle une boucle “ReAct” constituée de 4 phases : Réflexion / Action / Observation / Feedback

Les LLMs n’ont toutefois pas de mémoire conversationnelle; lorsqu’on les interroge il faut ainsi leur donner en entrée l’intégralité de l’information dont ils ont besoin pour répondre, ils sont sans “état”. 

La responsabilité de l’agent est donc de maintenir un tel état, représentatif de l’historique d’une session de travail à un moment donné, pour pouvoir interroger le modèle de manière consistante dans le temps : le contexte.

Un travail peu cadré par défaut

Dans un contexte professionnel, avec des outils dont la sortie n’est pas complètement prévisible, il est donc impératif de poser un cadre qui permet de maîtriser la qualité de la production de manière durable. 

Sans un tel cadre, cette activité souffre d’un manque de:

• prédictibilité : les mêmes échanges ne produisent pas de résultats équivalents (LLM probabiliste, changement de modèle en cours de session)
• traçabilité : prompts volatiles et non versionnés
• maintenabilité et cohérence : rien ne relie une génération de code à une autre
• progressivité : lorsque le résultat n’est pas satisfaisant, la seule option est de tout recommencer ce qui est coûteux en temps et en consommation de ressources

Cette position n’est donc pas tenable car elle nourrit la dérive du contexte, ce phénomène que l’on observe lorsque ce qui est généré s’éloigne du résultat souhaité. 

Ce que génère un LLM

Un LLM est un outil qui manipule des tokens : un mot ou une partie d’un mot. Ceux-ci sont les éléments d’un espace vectoriel de grande dimension dans lequel sont effectuées des opérations de calcul matriciel à haute fréquence, d’où la nécessité de disposer de beaucoup de mémoire et de pouvoir paralléliser massivement ces calculs via des GPUs . 

Dans cet espace, plus 2 vecteurs ont un angle proche de 0, plus ils sont proches sémantiquement pour un contexte donné. Le travail d’une IA générative consiste à essayer de trouver un minimum angulaire à l’intérieur d’un ensemble de vecteurs, dans une direction donnée. L’enjeu est donc de maîtriser la convergence de cette direction grâce à l’ajout de contraintes supplémentaires.

Dérive du contexte

Un contexte mal géré lors d’une session avec un agent aboutit tôt ou tard à une dégradation de la qualité. Voici quelques-unes des conséquences les plus répandues.

Erreur en cascade (Snowballing)

La génération d’un texte se fait token par token en ré-injectant le texte généré à l’étape n dans le contexte de l’étape n+1 sans jamais revenir en arrière, c’est le mécanisme d’auto-régression. Le moindre écart intermédiaire peut donc faire dévier la génération du résultat souhaité car la direction finale n’est pas connue a priori, elle change à chaque étape. 

Lost in the middle

Les modèles accordent une plus grande importance au début et à la fin du prompt. Tout ce qui se trouve entre les 2 peut ainsi s’en trouver impacté, c’est le phénomène “Lost in the middle”. Ce phénomène semble s’expliquer par le fait que les données d’entraînement comportent souvent des introductions et conclusions, lesquelles sont statistiquement plus synthétiques et pertinentes. Une règle métier importante noyée au milieu d’un contexte massif a donc des chances de voir son importance sous-estimée lors d’une génération de code.

Biais de régression

Un LLM tend à générer du texte qui se rapproche d’une “moyenne” des textes sur lesquels il a été entraîné, qui sont statistiquement de qualité également moyenne. Conséquence des phénomènes précédents, les règles qualitatives et structurantes de spécification ou d’architecture peuvent se retrouver noyées au milieu du reste.

Hallucination de complaisance

Avez-vous remarqué la politesse de votre agent ? Elle provient du fait que les feedbacks humains ont tendance à être plus positifs lorsque les réponses des agents sont polies. Or ces feedbacks sont reinjectés dans les données d’entraînement; en conséquence, un biais, appelé sycophancy, pousse parfois le modèle à privilégier la complaisance à la pertinence. 

Du fait d’un contexte pas assez riche, il essaiera ainsi toujours de trouver une direction mathématique statistiquement correcte même si celle-ci amène à des résultats indésirables.  

Des pistes pour y remédier

Plan and solve prompting

Pour contourner les travers liés au mécanisme d’auto-régression, le “mode Plan” permet de réduire le champ des divergences possibles en ajoutant une première phase d’évaluation de la direction – au sens mathématique du terme – et en le complétant avec des étapes intermédiaires pour y converger de manière plus certaine.

On peut y voir une analogie avec le labyrinthe : si vous êtes à l’intérieur sans plan, vous n’avez que votre mémoire et l’embranchement suivant pour vous aider. Si vous disposez du plan, vous pouvez choisir votre sortie et établir une stratégie efficace pour y parvenir de manière plus rapide et certaine.

Le “plan and solve” s’appuie notamment sur le mécanisme de Chain-of-thought qui consiste à ajouter au contexte les conséquences directes de ce qui y est exprimé.

Il est toutefois insuffisant. S’il n’existe pas de documentation synthétique cartographiant l’implémentation existante, l’agent doit à chaque nouvelle fonctionnalité repartir de zéro, aidé en cela par l’expérience de l’humain, des quelques règles de haut niveau énoncées dans le projet, de l’expressivité du code source, et des outils qu’il a à disposition. 

Une meilleur gestion du contexte 

Stateless context, Context pruning et Information Density

Une conversation avec un agent est tout sauf une spécification claire. On y explore souvent le domaine ou l’architecture traitée en émettant des hypothèses qui vont être validées ou non en cours de route. L’historique peut donc être pollué par une dérive hallucinatoire (Context Drift). 

Les requêtes envoyées par l’agent au LLM gagnent ainsi à être préparées pour être optimisées, spécifiques, complètes, et reproductibles. Les spécifications doivent donc être découpées avec une granularité suffisamment petite pour pouvoir générer le contexte approprié à la volée à partir d’une session réinitialisée. 

Enfin, un LLM a une Attention ( sa “charge mentale”) limitée. Restreindre la taille physique des spécifications à quelques centaines de lignes garantit un poids d’attention mathématique maximal pour chaque mot du contexte.

Prompt engineering

Certaines pratiques de rédaction de prompts permettent également d’améliorer le contexte.

Few-Shot Prompting

Une des fonctionnalités les plus remarquables des LLMs est leur moteur de reconnaissance de motifs. En indiquant des entrées/sorties possibles, on ajoute des contraintes qui font là encore converger la génération de manière plus certaine vers un résultat attendu. On retrouve ici la faculté à extrapoler du texte sur des contextes très précis.

Des pratiques comme le Test-Driven Development ou Specification by exemple sont donc très efficaces pour rédiger des spécifications puis les implémenter.

Persona pattern

Exprimer que le modèle doit se considérer comme ayant un rôle, une profession donnée par exemple, permet de spécialiser et réduire considérablement les données d’entraînement à considérer, en choisissant celles qui correspondent le mieux au métier du persona en question.

C’est un moyen simple et puissant de synthétiser en peu de mots un ensemble d’activités, de tâches, et donc de sélection d’exemples de format de sortie.

Exemple :  “tu es développeur ou développeuse“.

Le modèle va :

• trouver où ils et elles échangent sur le web : github, stack overflow, etc.
• constater que leurs discussions aboutissent sur du code
• se baser sur les exemples de code pour en générer 

Anti-Prompting et Flipped Interaction

Du fait du mécanisme d’auto-régression, les spécifications doivent être optimisées pour indiquer une finalité claire. La pratique d’anti-prompting vise à exprimer un résultat attendu et démontrable plutôt qu’une liste d’instructions à exécuter – le fameux “Show, don’t tell”. 

On peut leur associer une définition de prêt précise, pour s’assurer par exemple de la présence de règles métiers consistantes, ou de critères d’acceptation. 

Pour y parvenir, la Flipped Interaction peut être utile pour cadrer les échanges. Elle est un mode de conversation dans lequel l’agent va prendre le rôle de facilitateur/rédacteur et interroger l’humain de manière itérative jusqu’à lever toutes les incertitudes, sans intervenir sur le contenu, réduisant ainsi le risque d’hallucination.

Multi-agent Debate / Reflection

Cette technique propose d’utiliser différents Persona de manière à varier les contextes afin de réduire les risques liés à la dérive du contexte et l’hallucination de complaisance. 

On propose ainsi de passer d’un contexte neutre à des contextes spécialisés dans la réalisation de certaines tâches : spécifier, coder, valider, concevoir, planifier, etc

C’est cette variété de contexte qui va permettre de compenser le caractère probabiliste des LLMs et faire converger vers une solution plus satisfaisante à la manière d’une triangulation.

Execution-Based Feedback 

Les LLMs seraient de mauvais relecteurs du code qu’ils ont eux-mêmes générés.

Dès lors, comment accélérer sans avoir à tout relire soi-même?

On l’a vu, générer des tests automatisés en boîte noire avant de générer le code permet de rajouter du contexte qui restreint le champ des possibles en terme de génération de code (test-driven prompting), et donc augmente sa pertinence. 

Un des enjeux de l’Agentic Engineering, c’est donc d’enfermer le caractère probabiliste de l’activité dans des boucles de rétroaction à feedback déterministe, auto-correctives. On l’aura compris, plus ces boucles sont de petites tailles, plus les erreurs sont corrigées au plus tôt et plus le résultat global restera satisfaisant. 

Le Spec-Driven Development

Définition

Le Specification Driven Development est un paradigme de développement qui vise à poser un cadre au travail avec des agents qui résout les problèmes ci-dessus. Il est un sujet relativement neuf mais dont le nombre d’implémentations apparues ces derniers temps est le signe d’une certaine convergence du métier et des pratiques.

L’idée centrale est de considérer la spécification comme la nouvelle source de vérité du logiciel, le code source généré par les agents en devenant un artefact. 

Les frameworks SDD ont les caractéristiques suivantes en commun.

Un ou des workflows

Ils consistent en des étapes avec des garde-fous à chaque transition. Celles-ci peuvent être appelées explicitement par l’humain, ou proposées par l’agent.

Des skills 

Ces prompts, souvent associés à une ou plusieurs étapes du workflow permettent de disposer d’agents spécialisés. Ils sont l’implémentation du Persona Pattern,  par exemple  “Architecte” ou “Product Owner”.

Des outils

Les outils mis à disposition peuvent être des exécutables, des templates de spécifications, des commandes, etc. Leur présence ou leur implémentation peuvent varier d’un agent à l’autre. 

Comment optimisent-ils le contexte

On l’a vu précemment, il y a un équilibre à trouver sur la quantité de contexte à envoyer au LLM pour s’assurer que les réponses restent pertinentes. Le rôle de l’agent est donc de créer la bonne combinaison au bon moment, à partir des artefacts à sa disposition.

C’est pourquoi les frameworks SDD créent eux-mêmes quantité de fichiers texte (en markdown par exemple), de manière à pouvoir les assembler en fonction du besoin en prenant en compte leur poids relatifs, grâce à un persona et un format de rédaction dédié. Ces fichiers sont les plus petits possibles pour pouvoir être réutilisés tels quels lors de l’injection de prompt, sous forme de concaténation ordonnée. On dispose ainsi d’un arbre de spécifications dont chaque branche peut être injectée dans le contexte en fonction du sujet (fonctionnalité) et de la phase (exploration, implémentation) sur lesquels on est en train de travailler, le niveau de détail étant adapté.

Par exemple, lors du développement d’une nouvelle fonctionnalité dans une application existante, on pourra trouver dans le contexte au moment où on va générer le code, dans l’ordre:

1. des instructions générales de l’agent
2. des instructions relatives aux règles de développement de l’entreprise
3. des patterns d’architecture à appliquer
4. des spécifications de la macro fonctionnalité déjà implémentée
5. des spécifications de la fonctionnalité à ajouter et les critères d’acceptation associés
6. un liste de tâches à accomplir pour l’implémentation

Comparatif de frameworks SDD

Les 2 frameworks présentés ci-dessous sont parmi les plus populaires et représentatifs. Ils ont en commun d’être open source et de reposer entièrement sur des informations stockées dans le dépôt Git, sans ajout d’outil tiers. Il en existe d’autres : SpecKit, Kiro, GSD,  etc.

OpenSpec : le plus simple

Il propose 3 étapes : 

1. propose : vous travaillez sur un “change”, une modification que vous souhaitez apporter à la base de code: nouvelle fonctionnalité, modification d’une existante, bugfix, ce que vous voulez. C’est la phase de génération de la spécification.
2. apply : implémente le change compte tenu des étapes de préparation générées en 1 
3. archive : les spécifications sont ajoutées à celles existantes, les détails d’implémentations sont archivés

Une étape d’exploration optionnelle est également disponible.

Très facile à prendre en main, plutôt à destination des développeurs et développeuses, c’est la porte d’entrée idéale pour rentrer dans le SDD.

Si vous connaissez le Behaviour Driven Development (BDD), vous vous y retrouverez car les spécifications y sont formalisées sous forme Gherkin, en langage naturel. 

Si vous n’avez pas un gros besoin en terme d’exploration du besoin, il est suffisant. Les spécifications étant versionnées, vous pouvez collaborer et travailler en parallèle sur plusieurs fonctionnalités. A tout moment, vous pouvez connaître l’état de votre workflow.

BMad : le plus complet

A l’opposé, BMad offre une panoplie d’agents spécialisés pour vous aider à explorer un besoin, le prioriser, l’implémenter, le tester, le documenter… Son Workflow est très complet mais peut rebuter par sa longueur -il existe une version rapide. Il se veut agile dans le sens où la notion de business value est bien mise en avant, et profite de la complémentarité des agents. Pour le reste, le “Time to code” peut être dissuasif, on peut y passer plusieurs heures avant de commencer à produire quelque chose. 

Le différenciant : le party mode.

A tout moment, vous pouvez invoquer un brainstorming d’agents spécialisés qui vont vous donner leurs points de vue sur un sujet donné, fonctionnel, technique, ou de pilotage. Du fait de leur paramétrage différent, leurs points de vue vont être complémentaires voire divergents, mais une solution de consensus va vous être proposée. Effet Wouah garanti.

A noter qu’avec cette solution vous adoptez plutôt une posture de manager car vous devez piloter l’équipe d’agents de l’exploration à la réalisation, dans un processus tout de même assez balisé. Vous devez donc être capable de pouvoir interagir avec l’ensemble des experts à votre disposition.

Spec-first – dualité spec/code

Rapprocher spécifications et code n’est pas nouveau. 

A l’ère de l’ingénierie agentique, certaines pratiques à la frontière des deux deviennent ainsi encore plus pertinentes dans la perspective d’ajout de contexte sémantique.

Le Behaviour Driven Development par exemple, a pour but d’exprimer des scénarios utilisateurs en langage naturel, puis de s’en servir d’une part pour générer des tests automatisés, et d’autre part de mieux partager la connaissance aux diverses parties prenantes de la conception d’un logiciel. 

Autres exemples, l’Ubiquitous Language du Domain Driven Design et les Use Case de la Clean Architecture proposent d’utiliser explicitement les termes métiers et les processus associés dans l’écriture du code source et son organisation.

Pour aller plus loin

On l’a vu, il est possible d’encadrer le travail avec les agents pour limiter les biais et dérives  du contexte. C’est bien sûr insuffisant car cela n’adresse pas la qualité globalement.

Néanmoins, nous connaissons déjà les pistes pour ajouter des garde-fous externes à ces solutions. Lorsque les développeurs et développeuses ont commencé à écrire des tests unitaires pour vérifier le comportement de leur code, c’était déjà dans le but de produire du feedback immédiat. De même, une chaîne d’intégration continue efficace, c’est la capacité à détecter des défauts au plus tôt. L’occasion de se (re)mettre au Lean IT et à l’eXtreme programming ? Ça n’est peut-être plus une option.

A l’ère des agents, les boucles de rétroaction ont donc un rôle central et il est crucial de les expliciter, exploiter et industrialiser encore plus qu’auparavant, notamment via la Developer Experience. Ce travail peut bien sûr être effectué avec une approche “spec-driven”.

De nouveaux indicateurs et formes de feedbacks sont sans doute encore à inventer. Dans tous les cas : nous n’avons pas de recul suffisant sur le sujet, comme le dit bien Kent Beck Nobody knows.