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.
Voici un récapitulatif complémentaire concernant le prompt utilisé.
Il est sans doute plus avantageux pour les développeurs lorsqu’il s’agit de rédiger des prompts destinés à améliorer la structure. Comme chaque programme a ses propres caractéristiques, un certain niveau de connaissances en développement est nécessaire pour obtenir des améliorations très efficaces.
Cela ne signifie pas pour autant que les vibe coders non développeurs ne peuvent pas utiliser cette méthode. L’efficacité peut varier, mais même avec une instruction simple comme « Fais un peu de ménage dans le code du projet. Supprime le code inutilisé. », l’IA peut séparer et réorganiser les fichiers et les classes.
En revanche, comme les différences de détail dans l’amélioration de la structure peuvent entraîner des écarts d’efficacité, il faut faire attention aux ressources de référence.
Merci beaucoup pour l’intérêt porté à cet article. Comme il visait avant tout une diffusion à l’international, il a été rédigé en anglais, mais cela semble avoir entraîné divers problèmes.
Je partage donc un billet récapitulatif en coréen.
L’idée centrale est qu’après avoir demandé à l’IA de refactoriser la structure du code, la quantité de tokens consommés a diminué.
À l’inverse, on peut aussi expliquer que si l’on continue à donner des instructions alors que le code présente des défauts structurels, l’utilisation de tokens augmente.
En résumé, il faut améliorer la structure du code source ; cela ne signifie pas qu’il suffit de rédiger un prompt de façon logique en n’y mettant que l’essentiel.
Il faut n’ajouter au prompt que l’essentiel, de façon logique. Autrement dit, plus on y ajoute toutes sortes de choses, plus il y a de bruit, donc le code produit devient lui aussi plus complexe et plus bruité, c’est bien ça ?
Moi aussi, j’ai trouvé cette introduction et le texte original beaucoup trop verbeux, au point de donner l’impression d’avoir été écrits par quelqu’un qui ne sait pas très bien écrire, ce qui a rendu la lecture difficile.
En gros, l’idée est la suivante :
« ajoutez une instruction d’une ligne contenant une contrainte structurelle pour réduire le nombre de tokens »
C’est à peu près ainsi qu’on peut le résumer.
L’API Web Codecs elle-même offre de très bonnes performances, donc les bibliothèques multimédia web sont toutes très performantes. Du coup, c’est un peu ambigu de parler de TypeScript pur.
Waouh, donc même Delphi et C++Builder intègrent désormais des composants de développement IA.
Delphi a quelque chose de nostalgique pour moi, alors je regarde toujours les nouveautés quand il y en a.
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.
Voici un récapitulatif complémentaire concernant le prompt utilisé.
Il est sans doute plus avantageux pour les développeurs lorsqu’il s’agit de rédiger des prompts destinés à améliorer la structure. Comme chaque programme a ses propres caractéristiques, un certain niveau de connaissances en développement est nécessaire pour obtenir des améliorations très efficaces.
Cela ne signifie pas pour autant que les vibe coders non développeurs ne peuvent pas utiliser cette méthode. L’efficacité peut varier, mais même avec une instruction simple comme « Fais un peu de ménage dans le code du projet. Supprime le code inutilisé. », l’IA peut séparer et réorganiser les fichiers et les classes.
En revanche, comme les différences de détail dans l’amélioration de la structure peuvent entraîner des écarts d’efficacité, il faut faire attention aux ressources de référence.
C’est un bon choix si vous avez besoin d’exploiter des données géospatiales.
Merci beaucoup pour l’intérêt porté à cet article. Comme il visait avant tout une diffusion à l’international, il a été rédigé en anglais, mais cela semble avoir entraîné divers problèmes.
Je partage donc un billet récapitulatif en coréen.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
L’idée centrale est qu’après avoir demandé à l’IA de refactoriser la structure du code, la quantité de tokens consommés a diminué.
À l’inverse, on peut aussi expliquer que si l’on continue à donner des instructions alors que le code présente des défauts structurels, l’utilisation de tokens augmente.
En résumé, il faut améliorer la structure du code source ; cela ne signifie pas qu’il suffit de rédiger un prompt de façon logique en n’y mettant que l’essentiel.
Il faut n’ajouter au prompt que l’essentiel, de façon logique. Autrement dit, plus on y ajoute toutes sortes de choses, plus il y a de bruit, donc le code produit devient lui aussi plus complexe et plus bruité, c’est bien ça ?
Une surcouche inutile.
Je suis l’auteur. Merci pour vos retours. J’en tiendrai compte lors de la rédaction du prochain article.
Moi aussi, j’ai trouvé cette introduction et le texte original beaucoup trop verbeux, au point de donner l’impression d’avoir été écrits par quelqu’un qui ne sait pas très bien écrire, ce qui a rendu la lecture difficile.
En gros, l’idée est la suivante :
« ajoutez une instruction d’une ligne contenant une contrainte structurelle pour réduire le nombre de tokens »
C’est à peu près ainsi qu’on peut le résumer.
Soudain, tous les points ont disparu.
Conclusion
L’usage de l’IA permet de gagner en productivité
et contribue à réduire les coûts,
mais cela ne rapporte pas d’argent en soi.
Avec quelque chose comme nodejs, le lier à d'autres applications devient assez fastidieux, donc j'aimerais que ce soit un peu plus simple.
L’API Web Codecs elle-même offre de très bonnes performances, donc les bibliothèques multimédia web sont toutes très performantes. Du coup, c’est un peu ambigu de parler de TypeScript pur.
À voir les benchmarks, il est étonnamment performant.
Waouh, donc même Delphi et C++Builder intègrent désormais des composants de développement IA. Delphi a quelque chose de nostalgique pour moi, alors je regarde toujours les nouveautés quand il y en a.