Dans le cas des ordres de transaction, des injections de prompt ou autres pourraient entraîner l’exécution d’ordres non intentionnels ; il semble donc indispensable d’ajouter des fonctionnalités supplémentaires, comme des restrictions sur les actifs concernés ou des plafonds de montant.
Pour tout ce qui relève de la perte de temps, les réseaux sociaux ressemblent davantage au jeu ou aux drogues, avec ce sentiment de « regret » ou de « honte ».
Indépendamment du contenu, j’ai l’impression que c’est d’autant plus le cas que, à cause du titre parlant d’« une seule ligne de prompt », ce qu’on s’attend à voir et le contenu de l’article ne correspondent pas.
En inversant le flux où le PRD et les documents de design n’étaient que des auxiliaires centrés sur le code, la spécification devient la source d’origine et le code n’est plus qu’une expression implémentée dans un langage ou un framework donné
Le constat est qu’il était difficile de combler le fossé permanent entre spécification et implémentation par le seul renforcement documentaire ou procédural
Si des spécifications exécutables et un plan d’implémentation génèrent le code, alors le fossé disparaît et il ne reste plus qu’une transformation
L’IA rend possible l’interprétation de spécifications complexes et l’élaboration de plans d’implémentation, mais une génération sans structure provoque de la confusion ; la SDD garantit donc la qualité grâce à une structure précise et des garde-fous
La maintenance devient un travail d’évolution de la spécification, l’intention de développement s’exprime en langage naturel, actifs de design et principes clés, et le code occupe la position du dernier kilomètre
Le débogage privilégie la correction de la spécification et du plan d’implémentation plutôt que celle d’un mauvais code, et le refactoring est redéfini comme une recomposition de la clarté
The SDD Workflow in Practice
Une idée est affinée en PRD via une interaction conversationnelle avec l’IA, qui précise les questions, les cas limites et les critères d’acceptation
Les exigences et la conception deviennent une activité continue, avec prise en charge d’un travail de spécification basé sur les branches à l’échelle de l’équipe, ainsi que de la revue et du versioning
Un agent de recherche explore la compatibilité des bibliothèques, les performances, la sécurité et les contraintes de l’organisation (standards DB, authentification, politiques de déploiement) pour les refléter automatiquement dans la spécification
À partir du PRD, un plan d’implémentation est généré afin de mapper de façon traçable les exigences et les décisions techniques, tandis que l’IA vérifie en continu les contradictions, ambiguïtés et omissions
Une fois la spécification et le plan suffisamment stables, la génération de code commence, avec au départ une génération exploratoire pour valider la faisabilité
Les concepts métier deviennent des modèles de données, les user stories des endpoints API et les scénarios d’acceptation des tests
En phase d’exploitation, les métriques et incidents mettent à jour la spécification pour être reflétés dans la génération suivante ; les goulets de performance sont promus en exigences non fonctionnelles et les vulnérabilités en contraintes globales
Why SDD Matters Now
Seuil critique des capacités de l’IA : il devient possible de générer de manière fiable du code fonctionnel à partir de spécifications en langage naturel, et l’automatisation de la part mécanique de la traduction vers l’implémentation soutient l’exploration et l’amplification de la créativité
Explosion de la complexité : avec la multiplication des services, frameworks et dépendances, il devient difficile de préserver l’alignement entre intention et implémentation, d’où la nécessité de l’alignement piloté par la spécification de la SDD
Accélération du changement : dans des contextes de pivots fréquents, la SDD traite les évolutions par une régénération systématique au lieu d’une propagation manuelle dans la documentation, le design et le code
Elle permet par exemple les simulations what-if et les implémentations en parallèle, apportant ainsi de l’agilité décisionnelle
Core Principles
Spécification = langage commun : la spécification est un artefact de premier rang, le code est une expression d’une stack donnée, et la maintenance est un travail d’évolution de la spécification
Spécifications exécutables : des spécifications précises, complètes et non ambiguës permettent de générer un système opérationnel
Affinage continu : la vérification de cohérence est permanente, et non un simple contrôle ponctuel
Contexte fondé sur la recherche : les performances, la sécurité et les contraintes organisationnelles sont collectées en continu puis injectées dans la spécification
Feedback bidirectionnel : la réalité de l’exploitation devient une entrée de mise à jour de la spécification
Branching pour l’exploration : prise en charge de la génération de plusieurs implémentations à partir d’une même spécification selon des objectifs d’optimisation comme la performance, la maintenabilité, l’UX ou le coût
Implementation Approaches
En pratique aujourd’hui, l’essentiel consiste à combiner les outils existants et à maintenir la discipline, avec une mise en œuvre possible via les éléments suivants
Assistant IA pour l’affinage itératif de la spécification
Agent de recherche pour la collecte du contexte technique
Outil de génération de code pour la transformation spécification → implémentation
Gestion de versions adaptée à un workflow spec-first
Vérification basée sur une analyse de cohérence par IA des documents de spécification
Le principe commun consiste à faire de la spécification l’unique source de vérité, et à considérer le code comme un livrable exigé par la spécification
Streamlining SDD with Commands
/specify : convertit une description de fonctionnalité en spécification structurée et automatise la numérotation, la création de branche et l’organisation d’un répertoire basé sur des templates
/plan : analyse la spécification → vérifie la conformité à la constitution → effectue la traduction technique → documente les modèles de données, contrats API et scénarios de test → génère une validation quickstart
/tasks : lit plan.md et les conceptions associées pour produire une liste de tâches exécutable, avec signalement des tâches parallélisables et regroupement parallèle sûr
Exemple : fonctionnalité de chat
Présente un exemple de flux où environ 12 heures de travail documentaire dans une approche traditionnelle sont ramenées à environ 15 minutes de configuration grâce à l’automatisation de la spécification, du plan et des tâches
Les livrables incluent la spécification, le plan d’implémentation et ses justifications, les contrats API et modèles de données, les scénarios quickstart et tasks.md, le tout versionné dans la branche
The Power of Structured Automation
Prévention des oublis : les templates couvrent aussi les exigences non fonctionnelles et la gestion des erreurs
Traçabilité des décisions : chaque choix technique est relié à une exigence précise
Documents vivants : comme la spécification génère le code, il est plus facile de maintenir la synchronisation
Itération rapide : en cas de changement d’exigence, la régénération du plan permet de réagir à l’échelle de la minute ou de l’heure
Template-Driven Quality
Prévention de l’intrusion prématurée des détails d’implémentation : les règles centrées sur le WHAT/WHY, en excluant le HOW, encouragent le maintien du bon niveau d’abstraction
Imposition de marqueurs d’incertitude : le marqueur [NEEDS CLARIFICATION] évite les suppositions et pousse à poser des questions explicites
Auto-vérification par checklist : la vérification de la complétude, de la clarté et de critères d’acceptation mesurables met en place une barrière qualité
Constitution gate : application de contrôles en phase préalable (-1), comme la barrière de simplicité (≤3 projets), la barrière anti-abstraction (utilisation directe du framework) et la barrière integration-first (contrats et tests de contrat en amont)
Gestion hiérarchisée du détail : le code et les détails excessifs sont séparés dans implementation-details/ afin de préserver la lisibilité
Primauté des tests : des règles fichiers et tests d’abord, dans l’ordre contrat → intégration → E2E → unité, garantissent la vérifiabilité
Frein aux fonctionnalités supposées ou spéculatives : l’interdiction des fonctionnalités spéculatives et la définition explicite des préconditions étape par étape renforcent la maîtrise du périmètre
The Constitutional Foundation
Adoption d’une constitution de développement qui, à travers les principes immuables de memory/constitution.md, maintient toutes les implémentations cohérentes, simples et de haute qualité
Article I: Library-First — toute fonctionnalité commence comme une bibliothèque indépendante afin d’assurer la modularité
Article II: CLI Mandate — chaque bibliothèque expose une interface CLI prenant en charge entrées/sorties texte et JSON, afin de garantir observabilité et facilité de test
Article III: Test-First — interdiction d’implémenter avant validation des tests et confirmation de l’échec (red), avec priorité à la définition du comportement
Articles VII & VIII : simplicité et anti-abstraction — réduction du nombre de projets et confiance directe dans le framework pour limiter la sur-ingénierie
Article IX: Integration-First Testing — préférence donnée aux tests proches des conditions réelles, et exigence que les tests de contrat précèdent l’implémentation
Les gates de phase -1 des templates transforment la conformité à la constitution en checklist, et les exceptions consignent leurs justifications explicites dans Complexity Tracking
Via une procédure d’amendement, les modalités d’application de ces principes peuvent évoluer tout en conservant la philosophie de base
The Transformation
L’objectif n’est pas de remplacer les développeurs, mais d’automatiser la traduction mécanique pour amplifier les capacités humaines et préserver l’alignement entre intention et implémentation
La SDD met en pratique une transformation continue où la spécification génère le code, et où spécification, recherche et code coévoluent dans une boucle de feedback étroite
Vous m’avez aussi interrogé au sujet de l’expérience liée au nombre d’enchaînements de prompts,
mais en réalité, c’est à l’inverse un élément idéal pour que l’auteur, pour le dire crûment, puisse tricher.
L’activité de développement elle-même comporte énormément de choix dans la direction à prendre, et si l’on accumule les prompts dans un sens où la consommation de tokens se creuse davantage, ce chiffre gonflera encore plus, comme une boule de neige.
Dans la recherche, il existe une philosophie appelée « Cumulative Science ».
Comme, de mon point de vue du moins, je n’ai encore jamais trouvé la moindre étude sur la consommation de tokens pour une seule instruction,
je me suis donc concentré non pas sur une étude immédiate sur N exécutions, mais sur des tests solides et des conclusions portant sur une seule exécution,
et pour l’étude sur N exécutions, il suffira qu’elle prolonge cette expérimentation.
Pour l’expliquer brièvement, il s’agit de tests et de résultats montrant que la qualité du résultat produit varie selon la codebase fournie en entrée à l’IA.
Selon la qualité initiale de la codebase et son orientation, la qualité du code produit ensuite peut soit se maintenir, soit continuer à se dégrader.
Autrement dit, le coût d’un refactoring au début d’un projet et le coût d’un refactoring sur un projet déjà bien avancé peuvent être très différents.
Si la personne qui pose la question est développeuse, elle a peut-être déjà entendu l’expression « un porte-avions sur un voilier ».
Le refactoring est un sujet profond : à quel moment faut-il le réaliser, et à quel point les idées et l’architecture appliquées au début d’un projet peuvent-elles faire exploser les coûts.
Plutôt que d’inclure cela comme variable et d’aboutir à une conclusion instable,
j’ai mené un test qui permet au moins d’expliquer clairement ceci : « ah, quand la qualité de la codebase est bonne, l’utilisation de tokens diminue. »
Les pratiquants du vibe coding couvrent un spectre très large, des non-développeurs jusqu’aux développeurs expérimentés. Selon leur niveau de connaissances, et indépendamment du contenu de cet article, la qualité du résultat produit peut varier énormément.
Certains, en partant naturellement du principe qu’ils utilisent Cursor, peuvent renseigner dans .cursorrules des conventions OOP de base ainsi que des règles de séparation des classes et des méthodes, au point d’obtenir un fonctionnement qui ne nécessite presque aucun refactoring ;
d’autres, au contraire, peuvent produire en masse du code de bas niveau simplement faute d’avoir saisi des points essentiels pourtant très basiques.
Il existe même déjà de nombreux articles et retours d’expérience expliquant qu’il faut, par défaut, maintenir une bonne qualité de code via la configuration des règles du projet.
Cela suggère que certains bénéficient peut-être déjà d’un gain en matière de consommation de tokens, même sans refactoring explicite.
Cependant, les cas ci-dessus ne récapitulent pas clairement la réduction de consommation de tokens par unité d’exécution obtenue grâce à la définition de ces règles. C’est pourquoi cet article teste la différence de consommation de tokens selon la qualité de la base de code et en résume les résultats.
Autrement dit, selon l’utilisateur, le nombre de refactorings explicites devient lui-même une variable allant de 0 à n,
et l’intention essentielle de cet article peut être comprise comme suit : « pourquoi est-il utile de prêter attention à la qualité d’une base de code ? »
J’ai du mal à bien comprendre ce que vous voulez dire dans votre commentaire. Mon propos était que, pour comparer équitablement les deux méthodes, ne faut-il pas comparer le nombre total de tokens consommés ? Le refactoring ne consomme-t-il pas lui aussi des tokens ?
Par ailleurs, ce que vous avez ajouté dans votre réponse ne semble pas être écrit dans l’article, et l’expérience ne semble pas non plus avoir été menée sur ce point. Il me semble que vous ne parlez pas d’une comparaison du nombre de tokens par requête unique, mais plutôt de l’idée que, sur plusieurs requêtes, le surcoût du refactoring diminue et que, comme le nombre attendu de tokens par requête baisse, on finirait par y gagner sur le total de tokens. Mais cela ne me paraît valable que si la réduction de coût se maintient effectivement sur plusieurs requêtes, comme vous l’imaginez, ce qui me semble être une hypothèse très idéale. Rien ne garantit que la baisse de coût due au refactoring se maintiendra indépendamment du nombre de requêtes suivantes, et on ne peut pas non plus le supposer sans expérimentation. Si vous voulez défendre ce point, il faudrait montrer expérimentalement une baisse de coût sur plus d’une requête. Or l’expérience n’a-t-elle pas été réalisée une seule fois pour cette comparaison ?
J’ajoute que ce n’est qu’une hypothèse de ma part, mais si l’on répétait indéfiniment les requêtes pour atteindre le même objectif (la sortie finale idéale), alors, dans une situation idéale, le code devrait converger vers une forme identique, qu’il y ait eu refactoring ou non. (La sortie finale idéale est unique.)
Si cette hypothèse est raisonnable, alors plus les requêtes se répètent, plus la différence entre la présence ou non d’un refactoring devrait se réduire, et donc plus le gain de réduction du coût en tokens devrait diminuer progressivement. Dès lors, à un niveau macroscopique, si ce bénéfice de réduction de coût ne se maintient pas suffisamment dans le temps, la différence du nombre total de tokens utilisés pour les requêtes pourrait ne pas être significative, non ?
Je me dis soudain qu'en faisant comme ça, ça pourrait être possible pour le hangeul aussi... On pourrait en faire des puzzles, en tout cas...
Je l’utiliserai uniquement à des fins de screening.
Dans le cas des ordres de transaction, des injections de prompt ou autres pourraient entraîner l’exécution d’ordres non intentionnels ; il semble donc indispensable d’ajouter des fonctionnalités supplémentaires, comme des restrictions sur les actifs concernés ou des plafonds de montant.
Désolé ;;
Ça me rappelle l’IDE Kiro.
Merci.
Oui, je pense la même chose. snif
J'ai trouvé l'expérience très intéressante à suivre.
Vous avez pris des cours pour trouver des titres, ou quoi..
Pour tout ce qui relève de la perte de temps, les réseaux sociaux ressemblent davantage au jeu ou aux drogues, avec ce sentiment de « regret » ou de « honte ».
Intéressant. C’est assez logique aussi.
Indépendamment du contenu, j’ai l’impression que c’est d’autant plus le cas que, à cause du titre parlant d’« une seule ligne de prompt », ce qu’on s’attend à voir et le contenu de l’article ne correspondent pas.
k9s - Un outil pour gérer les clusters Kubernetes via une interface utilisateur en terminal
Le lien de présentation détaillée de la SDD au milieu de l’article est vraiment intéressant. Ci-dessous, voici un résumé fait avec l’IA.
Développement piloté par les spécifications (Specification-Driven Development, SDD)
The Power Inversion
The SDD Workflow in Practice
Why SDD Matters Now
Core Principles
Implementation Approaches
Streamlining SDD with Commands
/specify: convertit une description de fonctionnalité en spécification structurée et automatise la numérotation, la création de branche et l’organisation d’un répertoire basé sur des templates/plan: analyse la spécification → vérifie la conformité à la constitution → effectue la traduction technique → documente les modèles de données, contrats API et scénarios de test → génère une validation quickstart/tasks: litplan.mdet les conceptions associées pour produire une liste de tâches exécutable, avec signalement des tâches parallélisables et regroupement parallèle sûrtasks.md, le tout versionné dans la brancheThe Power of Structured Automation
Template-Driven Quality
[NEEDS CLARIFICATION]évite les suppositions et pousse à poser des questions explicitesimplementation-details/afin de préserver la lisibilitéThe Constitutional Foundation
memory/constitution.md, maintient toutes les implémentations cohérentes, simples et de haute qualitéThe Transformation
Le code source de Big Brother a fuité !
Vous m’avez aussi interrogé au sujet de l’expérience liée au nombre d’enchaînements de prompts,
mais en réalité, c’est à l’inverse un élément idéal pour que l’auteur, pour le dire crûment, puisse tricher.
L’activité de développement elle-même comporte énormément de choix dans la direction à prendre, et si l’on accumule les prompts dans un sens où la consommation de tokens se creuse davantage, ce chiffre gonflera encore plus, comme une boule de neige.
Dans la recherche, il existe une philosophie appelée « Cumulative Science ».
Comme, de mon point de vue du moins, je n’ai encore jamais trouvé la moindre étude sur la consommation de tokens pour une seule instruction,
je me suis donc concentré non pas sur une étude immédiate sur N exécutions, mais sur des tests solides et des conclusions portant sur une seule exécution,
et pour l’étude sur N exécutions, il suffira qu’elle prolonge cette expérimentation.
Dans des domaines comme le génie civil, c’est déjà utilisé même dans les cours à l’université.
J’ai aussi déjà abordé, dans un autre article, les différences de comportement de l’IA selon les écarts entre codebases.
(Cela a d’ailleurs aussi déjà été présenté sur GeekNews : https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)
Pour l’expliquer brièvement, il s’agit de tests et de résultats montrant que la qualité du résultat produit varie selon la codebase fournie en entrée à l’IA.
Selon la qualité initiale de la codebase et son orientation, la qualité du code produit ensuite peut soit se maintenir, soit continuer à se dégrader.
Autrement dit, le coût d’un refactoring au début d’un projet et le coût d’un refactoring sur un projet déjà bien avancé peuvent être très différents.
Si la personne qui pose la question est développeuse, elle a peut-être déjà entendu l’expression « un porte-avions sur un voilier ».
Le refactoring est un sujet profond : à quel moment faut-il le réaliser, et à quel point les idées et l’architecture appliquées au début d’un projet peuvent-elles faire exploser les coûts.
Plutôt que d’inclure cela comme variable et d’aboutir à une conclusion instable,
j’ai mené un test qui permet au moins d’expliquer clairement ceci : « ah, quand la qualité de la codebase est bonne, l’utilisation de tokens diminue. »
Je vais essayer de l’expliquer à nouveau.
Les pratiquants du vibe coding couvrent un spectre très large, des non-développeurs jusqu’aux développeurs expérimentés. Selon leur niveau de connaissances, et indépendamment du contenu de cet article, la qualité du résultat produit peut varier énormément.
Certains, en partant naturellement du principe qu’ils utilisent Cursor, peuvent renseigner dans
.cursorrulesdes conventions OOP de base ainsi que des règles de séparation des classes et des méthodes, au point d’obtenir un fonctionnement qui ne nécessite presque aucun refactoring ;d’autres, au contraire, peuvent produire en masse du code de bas niveau simplement faute d’avoir saisi des points essentiels pourtant très basiques.
Il existe même déjà de nombreux articles et retours d’expérience expliquant qu’il faut, par défaut, maintenir une bonne qualité de code via la configuration des règles du projet.
Cela suggère que certains bénéficient peut-être déjà d’un gain en matière de consommation de tokens, même sans refactoring explicite.
Cependant, les cas ci-dessus ne récapitulent pas clairement la réduction de consommation de tokens par unité d’exécution obtenue grâce à la définition de ces règles. C’est pourquoi cet article teste la différence de consommation de tokens selon la qualité de la base de code et en résume les résultats.
Autrement dit, selon l’utilisateur, le nombre de refactorings explicites devient lui-même une variable allant de 0 à n,
et l’intention essentielle de cet article peut être comprise comme suit : « pourquoi est-il utile de prêter attention à la qualité d’une base de code ? »
J’ai du mal à bien comprendre ce que vous voulez dire dans votre commentaire. Mon propos était que, pour comparer équitablement les deux méthodes, ne faut-il pas comparer le nombre total de tokens consommés ? Le refactoring ne consomme-t-il pas lui aussi des tokens ?
Par ailleurs, ce que vous avez ajouté dans votre réponse ne semble pas être écrit dans l’article, et l’expérience ne semble pas non plus avoir été menée sur ce point. Il me semble que vous ne parlez pas d’une comparaison du nombre de tokens par requête unique, mais plutôt de l’idée que, sur plusieurs requêtes, le surcoût du refactoring diminue et que, comme le nombre attendu de tokens par requête baisse, on finirait par y gagner sur le total de tokens. Mais cela ne me paraît valable que si la réduction de coût se maintient effectivement sur plusieurs requêtes, comme vous l’imaginez, ce qui me semble être une hypothèse très idéale. Rien ne garantit que la baisse de coût due au refactoring se maintiendra indépendamment du nombre de requêtes suivantes, et on ne peut pas non plus le supposer sans expérimentation. Si vous voulez défendre ce point, il faudrait montrer expérimentalement une baisse de coût sur plus d’une requête. Or l’expérience n’a-t-elle pas été réalisée une seule fois pour cette comparaison ?
J’ajoute que ce n’est qu’une hypothèse de ma part, mais si l’on répétait indéfiniment les requêtes pour atteindre le même objectif (la sortie finale idéale), alors, dans une situation idéale, le code devrait converger vers une forme identique, qu’il y ait eu refactoring ou non. (La sortie finale idéale est unique.)
Si cette hypothèse est raisonnable, alors plus les requêtes se répètent, plus la différence entre la présence ou non d’un refactoring devrait se réduire, et donc plus le gain de réduction du coût en tokens devrait diminuer progressivement. Dès lors, à un niveau macroscopique, si ce bénéfice de réduction de coût ne se maintient pas suffisamment dans le temps, la différence du nombre total de tokens utilisés pour les requêtes pourrait ne pas être significative, non ?