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.
Même si des entreprises coréennes de toutes tailles déploient beaucoup d’efforts pour internaliser l’IA, si cela part à chaque fois dans la mauvaise direction ou s’effondre en cours de route, c’est sans doute parce que cette fichue obsession des résultats à très court terme se dresse comme le principal obstacle.
En travaillant récemment sur des projets d’adoption de RAG et de LLM dans des banques et des compagnies d’assurance, j’ai ressenti la même chose :
les clients savent au fond d’eux que cette activité autour de l’IA est un marathon immense et de très longue haleine, mais le désir que « ces doux fruits doivent m’appartenir » reste le véritable responsable de tous les naufrages.
Comme lors de la spéculation sur les cryptos qui a un temps fait fureur, quand on se retrouve face à des dirigeants gagnés par une mentalité de coup rapide — « partir d’une petite mise et obtenir en très peu de temps d’énormes profits ou performances » —, le soupir vient tout seul.
Investir dans l’IA, ce n’est pas simplement commander un projet, fabriquer un produit ou un service susceptible de générer des revenus, puis en imposer l’usage aux employés ; mais à force de se concentrer sur des résultats de façade, quand des coûts d’exploitation énormes reviennent comme un boomerang,
on entend aussitôt :
« L’IA est un gouffre financier », « l’IA est une bulle », et ce genre de remarques pleines d’aigreur.
Ah, vous aviez donc déjà vu mon pseudo sur une autre communauté.
Les articles que j’ai écrits ont beaucoup de points perfectibles, mais j’en serais heureux s’ils pouvaient vous être utiles.
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.
Euuuh....
Je n’ai vraiment pas envie d’utiliser Jira jusque dans le terminal !!!
Orienté performance en pur ts, et non en WASM... ?
Dire viser de hautes performances avec TypeScript… c’est un peu comme prétendre faire une voiture de course avec un tracteur ?
Même si des entreprises coréennes de toutes tailles déploient beaucoup d’efforts pour internaliser l’IA, si cela part à chaque fois dans la mauvaise direction ou s’effondre en cours de route, c’est sans doute parce que cette fichue obsession des résultats à très court terme se dresse comme le principal obstacle.
En travaillant récemment sur des projets d’adoption de RAG et de LLM dans des banques et des compagnies d’assurance, j’ai ressenti la même chose : les clients savent au fond d’eux que cette activité autour de l’IA est un marathon immense et de très longue haleine, mais le désir que « ces doux fruits doivent m’appartenir » reste le véritable responsable de tous les naufrages.
Comme lors de la spéculation sur les cryptos qui a un temps fait fureur, quand on se retrouve face à des dirigeants gagnés par une mentalité de coup rapide — « partir d’une petite mise et obtenir en très peu de temps d’énormes profits ou performances » —, le soupir vient tout seul.
Investir dans l’IA, ce n’est pas simplement commander un projet, fabriquer un produit ou un service susceptible de générer des revenus, puis en imposer l’usage aux employés ; mais à force de se concentrer sur des résultats de façade, quand des coûts d’exploitation énormes reviennent comme un boomerang, on entend aussitôt : « L’IA est un gouffre financier », « l’IA est une bulle », et ce genre de remarques pleines d’aigreur.
Lien pour contourner le paywall https://archive.is/dLEl5
Ah, vous aviez donc déjà vu mon pseudo sur une autre communauté.
Les articles que j’ai écrits ont beaucoup de points perfectibles, mais j’en serais heureux s’ils pouvaient vous être utiles.