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 ?
Comme ce texte s’apparente davantage à une étude « expérimentale »,
toutes les valeurs qu’il contient ont été pensées pour permettre à toute personne qui le lit de le « reproduire ».
C’est pourquoi j’ai consigné l’intégralité du code source original utilisé ainsi que toutes les procédures de test,
afin de fournir les informations nécessaires pour que tous les expérimentateurs puissent obtenir les mêmes résultats.
À en juger par l’ambiance dans les commentaires,
je me demande s’il ne vaudrait pas mieux, à l’avenir, séparer cela en deux textes :
un article avec un résumé en 3 lignes, et un autre destiné à ceux qui veulent connaître les détails.
Si vous pouvez m’indiquer quelles parties de ce texte vous ont semblé inutilement complexes ou trop longues,
cela m’aidera beaucoup pour la rédaction des prochains articles.
Je suis entièrement d’accord. J’accueille très favorablement ce type de critique.
On ne vit pas seul dans ce monde, et les capacités comme les situations de chacun sont différentes.
Moi aussi, je ne suis qu’un simple développeur, et je ne peux pas financer personnellement l’ensemble des tests.
J’espère que cet article servira de graine, aura un impact positif sur beaucoup de personnes et deviendra le point de départ de nombreuses recherches à venir.
Il est nécessaire de comparer le code source avant et après le prétraitement.
Le sous-titre ne correspond pas vraiment au contenu. En le reformulant, quelque chose comme « une analyse plus claire des facteurs qui entraînent la réduction des tokens est nécessaire » semblerait mieux convenir comme sous-titre.
Je suis largement d’accord avec ce point de vue. Cela dit, la nature de cet article inclut aussi l’idée de « proposer aux lecteurs des méthodes d’application réalistes ».
On peut déjà sentir l’ambiance rien qu’en regardant les commentaires laissés sous cet article, et c’est aussi quelque chose que j’ai découvert récemment : il semble qu’il y ait beaucoup d’utilisateurs de l’IA parmi les non-développeurs, notamment des vibe coders.
Si l’auteur obtient des résultats remarquables à partir d’un code ajusté directement par lui-même, sans passer par l’IA,
cela peut facilement être perçu comme une manière de mettre en avant ses compétences de développement tout en rabaissant les capacités de l’IA.
C’est pourquoi j’ai choisi d’aborder un exemple que tout le monde peut concrètement apprécier, à travers l’élément du « prompt », que les vibe coders peuvent eux aussi exploiter.
J’espère qu’à la suite de cette étude, d’autres recherches permettront d’affiner et de catégoriser plus précisément les facteurs qui influencent l’usage des tokens par l’IA.
Le vibe coding ne permet pas d’obtenir un résultat finalisé avec un seul prompt.
Si une modification structurelle unique permet de réduire le taux de consommation de tokens de n prompts, la réduction du volume de tokens se répercute alors sur les n exécutions identiques. n est une valeur déterminée par l’objectif du projet, le nombre de fonctionnalités, ainsi que la quantité et la complexité du code nécessaire ;
et comme les agents récents de Cursor / Claude Code font l’objet de mises à jour visant à limiter les boucles infinies d’exécution ou l’usage excessif de tokens par l’IA en réduisant la taille des unités d’exécution,
il me semble juste de mener séparément une étude sur la valeur de n en lien avec la complexité du projet.
Afin de faciliter au maximum la compréhension, j’ai pris comme exemple une amélioration de code à partir d’un code rédigé par l’IA présentant des problèmes structurels, en l’absence d’instructions particulières.
Le point à ne pas manquer ici est que l’amélioration de la structure n’est absolument pas une action qui se produit indépendamment du développement du code.
Elle peut influencer le contexte de base via le prompt initial, ou via des contraintes comme un ruleset IA (.cursorrules),
et, au cours du cycle de développement du projet, une seule amélioration structurelle ne peut pas tout résoudre.
Autrement dit, plutôt que de planifier des améliorations de code à intervalles réguliers, il est préférable d’orienter correctement la structure dès le contexte de base.
Par ailleurs, il semble également juste de mener séparément une étude comparant les cas où il existe ou non, dans le contexte de base, des règles de consigne orientant la structure.
Pour résumer le point 1,
il est possible que l’usage total de tokens diminue lorsqu’il existe, dans le contexte de base, des règles de consigne orientant la structure ;
et comme l’obtention du résultat final dépend de la variable constituée par n prompts,
affirmer qu’il faut additionner la consommation de tokens d’un unique prompt d’amélioration structurelle dans le calcul est un argument discutable.
J’ai eu un ressenti assez proche moi aussi.
Je comprends l’intention de l’auteur, mais j’ai l’impression que le texte est excessivement complexe par rapport à ce qui a été fait.
On dirait que c’est écrit ainsi pour intégrer au maximum dans l’article les détails utilisés dans l’expérience,
mais je pense que si vous n’en reteniez que l’essentiel de façon concise, les personnes intéressées par ce sujet comprendraient probablement quand même.
À mon avis, ce serait mieux d’élaguer franchement les détails et de ne garder que les points clés.
Pour ma part, j’ai trouvé intéressante l’intention de l’auteur ainsi que le résultat lui-même.
L’idée principale, c’est qu’un meilleur code source conduit à une consommation de tokens plus faible,
et il me semble que c’est dans cette optique que l’expérience a été conçue et menée.
Si je liste seulement ce que j’ai compris de l’expérience :
Préparer deux versions : le code source à soumettre à l’IA, et ce même code source prétraité par un prompt
Exécuter chacun des deux codes source 5 fois sur GPT5 et Sonnet, puis comparer la consommation de tokens
Voilà ce qu’il me semble avoir compris.
Et si mon interprétation est correcte, la conclusion serait que le code source prétraité par prompt consomme globalement moins de tokens.
C’est une conclusion intéressante, mais voici mon avis sur l’expérience.
La comparaison n’est pas équitable
Numériquement, cela semble avoir baissé, mais il faudrait sans doute comparer le nombre total de tokens nécessaires pour traiter le code source.
Autrement dit, le nombre de tokens utilisés pour le prétraitement devrait lui aussi être pris en compte.
Si le nombre de tokens utilisé pour le prétraitement est excessivement élevé, alors au final on consomme davantage de tokens, ce qui rend l’approche sans intérêt ; et même s’il est faible, l’écart réel de consommation de tokens sera probablement bien moindre que ce que laisse entendre l’article.
Il faudrait comparer le code source avant et après prétraitement
Si l’on exclut les tokens utilisés pour le prétraitement, la consommation de tokens au moment de la requête semble effectivement avoir diminué de manière significative.
Mais si l’on analysait précisément quelles différences dans le code source produisent cet écart, l’article gagnerait davantage en portée.
Cela voudrait dire qu’il serait possible d’optimiser le prompt de prétraitement pour maximiser ces différences.
L’auteur affirme que c’est le refactoring de la structure du code qui a produit ce résultat, mais je ne suis pas d’accord : je pense qu’on ne peut pas encore le savoir.
Il est possible que d’autres améliorations que le refactoring apportées par l’IA réduisent elles aussi la consommation de tokens.
Il faudrait des expériences plus variées
Je pense qu’il faudrait reproduire la même expérience sur d’autres bases de code, pas seulement sur le code actuel.
Il faut pouvoir déterminer si le résultat est systématiquement positif ou non.
Cela dit, je comprends qu’en pratique ce type de test puisse être difficile à réaliser, donc il vaut peut-être mieux prendre cela simplement comme une piste de réflexion.
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 ?
Comme ce texte s’apparente davantage à une étude « expérimentale »,
toutes les valeurs qu’il contient ont été pensées pour permettre à toute personne qui le lit de le « reproduire ».
C’est pourquoi j’ai consigné l’intégralité du code source original utilisé ainsi que toutes les procédures de test,
afin de fournir les informations nécessaires pour que tous les expérimentateurs puissent obtenir les mêmes résultats.
À en juger par l’ambiance dans les commentaires,
je me demande s’il ne vaudrait pas mieux, à l’avenir, séparer cela en deux textes :
un article avec un résumé en 3 lignes, et un autre destiné à ceux qui veulent connaître les détails.
Si vous pouvez m’indiquer quelles parties de ce texte vous ont semblé inutilement complexes ou trop longues,
cela m’aidera beaucoup pour la rédaction des prochains articles.
Je suis entièrement d’accord. J’accueille très favorablement ce type de critique.
On ne vit pas seul dans ce monde, et les capacités comme les situations de chacun sont différentes.
Moi aussi, je ne suis qu’un simple développeur, et je ne peux pas financer personnellement l’ensemble des tests.
J’espère que cet article servira de graine, aura un impact positif sur beaucoup de personnes et deviendra le point de départ de nombreuses recherches à venir.
Le sous-titre ne correspond pas vraiment au contenu. En le reformulant, quelque chose comme « une analyse plus claire des facteurs qui entraînent la réduction des tokens est nécessaire » semblerait mieux convenir comme sous-titre.
Je suis largement d’accord avec ce point de vue. Cela dit, la nature de cet article inclut aussi l’idée de « proposer aux lecteurs des méthodes d’application réalistes ».
On peut déjà sentir l’ambiance rien qu’en regardant les commentaires laissés sous cet article, et c’est aussi quelque chose que j’ai découvert récemment : il semble qu’il y ait beaucoup d’utilisateurs de l’IA parmi les non-développeurs, notamment des vibe coders.
Si l’auteur obtient des résultats remarquables à partir d’un code ajusté directement par lui-même, sans passer par l’IA,
cela peut facilement être perçu comme une manière de mettre en avant ses compétences de développement tout en rabaissant les capacités de l’IA.
C’est pourquoi j’ai choisi d’aborder un exemple que tout le monde peut concrètement apprécier, à travers l’élément du « prompt », que les vibe coders peuvent eux aussi exploiter.
J’espère qu’à la suite de cette étude, d’autres recherches permettront d’affiner et de catégoriser plus précisément les facteurs qui influencent l’usage des tokens par l’IA.
Si une modification structurelle unique permet de réduire le taux de consommation de tokens de n prompts, la réduction du volume de tokens se répercute alors sur les n exécutions identiques.
n est une valeur déterminée par l’objectif du projet, le nombre de fonctionnalités, ainsi que la quantité et la complexité du code nécessaire ;
et comme les agents récents de Cursor / Claude Code font l’objet de mises à jour visant à limiter les boucles infinies d’exécution ou l’usage excessif de tokens par l’IA en réduisant la taille des unités d’exécution,
il me semble juste de mener séparément une étude sur la valeur de n en lien avec la complexité du projet.
Le point à ne pas manquer ici est que l’amélioration de la structure n’est absolument pas une action qui se produit indépendamment du développement du code.
Elle peut influencer le contexte de base via le prompt initial, ou via des contraintes comme un ruleset IA (
.cursorrules),et, au cours du cycle de développement du projet, une seule amélioration structurelle ne peut pas tout résoudre.
Autrement dit, plutôt que de planifier des améliorations de code à intervalles réguliers, il est préférable d’orienter correctement la structure dès le contexte de base.
Par ailleurs, il semble également juste de mener séparément une étude comparant les cas où il existe ou non, dans le contexte de base, des règles de consigne orientant la structure.
Pour résumer le point 1,
affirmer qu’il faut additionner la consommation de tokens d’un unique prompt d’amélioration structurelle dans le calcul est un argument discutable.
J’ai eu un ressenti assez proche moi aussi.
Je comprends l’intention de l’auteur, mais j’ai l’impression que le texte est excessivement complexe par rapport à ce qui a été fait.
On dirait que c’est écrit ainsi pour intégrer au maximum dans l’article les détails utilisés dans l’expérience,
mais je pense que si vous n’en reteniez que l’essentiel de façon concise, les personnes intéressées par ce sujet comprendraient probablement quand même.
À mon avis, ce serait mieux d’élaguer franchement les détails et de ne garder que les points clés.
Pour ma part, j’ai trouvé intéressante l’intention de l’auteur ainsi que le résultat lui-même.
L’idée principale, c’est qu’un meilleur code source conduit à une consommation de tokens plus faible,
et il me semble que c’est dans cette optique que l’expérience a été conçue et menée.
Si je liste seulement ce que j’ai compris de l’expérience :
Voilà ce qu’il me semble avoir compris.
Et si mon interprétation est correcte, la conclusion serait que le code source prétraité par prompt consomme globalement moins de tokens.
C’est une conclusion intéressante, mais voici mon avis sur l’expérience.
La comparaison n’est pas équitable
Numériquement, cela semble avoir baissé, mais il faudrait sans doute comparer le nombre total de tokens nécessaires pour traiter le code source.
Autrement dit, le nombre de tokens utilisés pour le prétraitement devrait lui aussi être pris en compte.
Si le nombre de tokens utilisé pour le prétraitement est excessivement élevé, alors au final on consomme davantage de tokens, ce qui rend l’approche sans intérêt ; et même s’il est faible, l’écart réel de consommation de tokens sera probablement bien moindre que ce que laisse entendre l’article.
Il faudrait comparer le code source avant et après prétraitement
Si l’on exclut les tokens utilisés pour le prétraitement, la consommation de tokens au moment de la requête semble effectivement avoir diminué de manière significative.
Mais si l’on analysait précisément quelles différences dans le code source produisent cet écart, l’article gagnerait davantage en portée.
Cela voudrait dire qu’il serait possible d’optimiser le prompt de prétraitement pour maximiser ces différences.
L’auteur affirme que c’est le refactoring de la structure du code qui a produit ce résultat, mais je ne suis pas d’accord : je pense qu’on ne peut pas encore le savoir.
Il est possible que d’autres améliorations que le refactoring apportées par l’IA réduisent elles aussi la consommation de tokens.
Il faudrait des expériences plus variées
Je pense qu’il faudrait reproduire la même expérience sur d’autres bases de code, pas seulement sur le code actuel.
Il faut pouvoir déterminer si le résultat est systématiquement positif ou non.
Cela dit, je comprends qu’en pratique ce type de test puisse être difficile à réaliser, donc il vaut peut-être mieux prendre cela simplement comme une piste de réflexion.
Offrir des cadeaux inutiles semble avoir la cote... ça pourrait être sympa pour dénicher de nouveaux cadeaux inutiles.