Ich verstehe nicht ganz, was Sie in Ihrem Kommentar sagen wollen. Mein Punkt war, dass man zum fairen Vergleich der beiden Methoden nicht die insgesamt verbrauchte Token-Anzahl vergleichen sollte? Verbraucht auch Refactoring nicht Tokens?
Außerdem scheint Ihre zusätzliche Antwort weder im Artikel zu stehen noch experimentell überprüft worden zu sein. Sie meinen offenbar nicht den Token-Vergleich pro einzelner Anfrage, sondern dass sich bei mehreren Anfragen der Refactoring-Overhead verringert und sich daraus durch die geringere erwartete Token-Anzahl pro Anfrage ein Vorteil bei der Gesamtzahl der Tokens ergibt. Das wäre aber nur dann zutreffend, wenn diese Kostenreduktion bei mehreren Anfragen tatsächlich so bestehen bleibt, wie Sie annehmen, und das wirkt auf mich wie eine sehr ideale Annahme. Es gibt keine Garantie dafür, dass die Kostensenkung durch Refactoring unabhängig von der Anzahl der folgenden Anfragen erhalten bleibt, und ohne Experiment kann man das auch nicht einfach voraussetzen. Wenn Sie genau diese Aussage vertreten wollen, müssten Sie die Kostensenkung über mehr als eine Anfrage hinweg experimentell zeigen. Aber haben Sie nicht nur ein einziges Experiment durchgeführt und darauf basierend verglichen?
Ergänzend: Das ist nur meine eigene Annahme, aber wenn man für dasselbe Ziel (ein ideales Endergebnis) die Anfragen unendlich oft wiederholt, dann sollte der Code im Idealfall unabhängig davon, ob Refactoring stattfindet oder nicht, gegen dieselbe Form konvergieren. (Das ideale Endergebnis ist eindeutig.)
Wenn diese Annahme vernünftig ist, dann dürfte mit zunehmender Zahl an Anfragen der Unterschied mit oder ohne Refactoring kleiner werden, sodass auch der Vorteil der Token-Kostenreduktion allmählich sinkt. Wenn man das also aus einer makroskopischen Perspektive betrachtet: Falls dieser Vorteil durch die Kostenreduktion nicht lange genug anhält, könnte der Unterschied in der insgesamt für die Anfragen verwendeten Token-Anzahl am Ende vielleicht gar nicht signifikant sein, oder?
Da dieser Text eher den Charakter einer Studie zum Thema „Experiment“ hat,
liegt der Fokus aller in diesem Text enthaltenen Zahlen darauf, dass alle, die diesen Text lesen, die Ergebnisse „reproduzieren“ können.
Daher wurden sowohl der verwendete Original-Source-Code als auch sämtliche im Test verwendeten Verfahren vollständig dokumentiert,
sodass der Inhalt darauf ausgerichtet ist, Informationen bereitzustellen, mit denen alle Versuchspersonen dieselben Ergebnisse erzielen können.
Wenn ich die Stimmung in den Kommentaren betrachte, habe ich das Gefühl,
ich sollte künftig vielleicht zwei getrennte Texte schreiben: einen mit der Tendenz zu einer Zusammenfassung in drei Zeilen
und einen weiteren für Menschen, die die Details wissen möchten.
Wenn Sie mir mitteilen, welcher Teil dieses Textes als übermäßig komplex oder zu ausführlich empfunden wurde,
würde mir das beim Verfassen künftiger Texte sehr helfen.
Es ist nötig, den Quellcode vor und nach der Vorverarbeitung zu vergleichen.
Der Untertitel passt nicht ganz zum Inhalt. Wenn man es neu ordnet, scheint „Es ist eine Analyse klarerer Faktoren nötig, die zur Token-Reduktion führen“ als Untertitel passender zu sein.
Diesem Inhalt stimme ich in vielen Punkten zu. Allerdings hat dieser Artikel auch den Charakter, den Menschen, die ihn lesen, realistische Anwendungsmethoden vorzuschlagen.
Schon an den Kommentaren unter diesem Artikel lässt sich die Stimmung erkennen; auch ich habe erst vor Kurzem erfahren, dass es unter den AI-Nutzern vermutlich viele Nicht-Entwickler gibt, die als Vibe-Coder unterwegs sind.
Wenn durch vom Autor direkt angepassten Code, also ohne den Einsatz von AI, ein herausragendes Ergebnis erzielt wird,
wirkt das leicht so, als wolle der Autor seine Entwicklungsfähigkeiten zur Schau stellen und die Fähigkeiten von AI herabsetzen.
Daher wurde als Element das „Prompt“ gewählt, das auch andere Vibe-Coder nutzen können, und es wurden Beispiele behandelt, bei denen jeder das Ergebnis nachvollziehen kann.
Ich fände es gut, wenn im Anschluss an diese Untersuchung weitere Studien folgen würden, die die Faktoren, welche den AI-Token-Verbrauch beeinflussen, differenzierter aufschlüsseln.
Vibe Coding führt nicht mit nur einem einzigen Prompt zu einem fertigen Ergebnis.
Wenn durch eine einmalige strukturelle Überarbeitung die Token-Nutzungsrate von n Prompts gesenkt wird, dann spiegelt sich diese Reduktion über alle n identisch ausgeführten Durchläufe hinweg wider.
Dabei ist n ein Wert, der durch Ziel und Funktionsumfang des Projekts sowie durch Menge und Komplexität des dafür nötigen Codes bestimmt wird.
Außerdem gab es zuletzt bei Cursor- und Claude-Code-Agenten Updates, die die Ausführungseinheiten kleiner halten, um Probleme wie Endlosschleifen oder den unkontrollierten Token-Verbrauch durch KI zu lösen.
Ich halte es daher für richtig, Studien zum n-Wert in Bezug auf die Projektkomplexität getrennt durchzuführen.
Um das Verständnis möglichst zu erleichtern, wurde als Beispiel eine Codeverbesserung ausgehend von von der KI geschriebenem Code mit strukturellen Problemen gezeigt, sofern keine gesonderten Vorgaben gemacht werden.
Was man an dieser Stelle nicht übersehen darf, ist, dass eine Verbesserung der Struktur niemals ein Vorgang ist, der absolut unabhängig von der eigentlichen Codeentwicklung stattfindet.
Sie kann bereits über den ersten Prompt oder über Einschränkungen wie ein KI-Regelwerk (.cursorrules) als Base Context Einfluss nehmen.
Und eine einzige strukturelle Verbesserung kann im Verlauf des Projektentwicklungszyklus nicht alle Probleme auf einmal lösen.
Mit anderen Worten: Statt Codeverbesserungen in festen Intervallen zu planen, ist es sinnvoller, als Base Context von Anfang an die richtige Struktur anzuleiten.
Außerdem erscheint es sinnvoll, die Untersuchung getrennt danach durchzuführen, ob es als Base Context Regeln zur strukturellen Anleitung gibt oder nicht.
Zur Zusammenfassung von Punkt 1:
Wenn es als Base Context Regeln zur strukturellen Anleitung gibt, kann der gesamte Token-Verbrauch möglicherweise sinken, und
da es die Variable gibt, dass das Endergebnis über n Prompt-Anweisungen erreicht wird,
ist die Behauptung irreführend, man müsse den Token-Verbrauch eines einzelnen Prompts zur strukturellen Verbesserung zusätzlich aufschlagen und so berechnen.
Das habe ich ähnlich empfunden.
Ich verstehe zwar die Absicht des Autors, aber im Verhältnis zu dem, was gemacht wurde, wirkt der Text übermäßig komplex.
Vermutlich wurde er so geschrieben, weil möglichst viele der im Experiment verwendeten Details in den Text einfließen sollten.
Wenn Sie aber nur die Kernaussagen knapp herausziehen, werden Leser, die sich für so ein Thema interessieren, es wahrscheinlich trotzdem verstehen.
Wenn Sie mutig Details weglassen und nur das Wesentliche zusammenfassen, wäre es meiner Meinung nach besser.
Ich fand die Absicht des Autors und auch das Ergebnis selbst interessant.
Die Hauptthese ist, dass besserer Sourcecode zu geringerem Token-Verbrauch führt,
und dazu scheint ein entsprechendes Experiment entworfen und durchgeführt worden zu sein.
Wenn ich nur das aufzähle, was ich vom Experiment verstanden habe:
Es wurden zwei Versionen vorbereitet: der Sourcecode, zu dem die KI befragt werden sollte, und derselbe Sourcecode, der per Prompt vorverarbeitet (?) wurde.
Auf GPT5 und Sonnet wurden beide Sourcecodes jeweils fünfmal ausgeführt und der Token-Verbrauch verglichen.
So scheint es zu sein.
Und wenn ich es richtig verstanden habe, lautet das Fazit, dass der per Prompt vorverarbeitete Sourcecode insgesamt weniger Tokens verbraucht.
Ein interessantes Fazit, aber meine Meinung zum Experiment ist wie folgt.
Kein fairer Vergleich
Zahlenmäßig scheint der Verbrauch zwar gesunken zu sein, aber eigentlich müsste man die gesamte Token-Zahl vergleichen, die für die Verarbeitung des Sourcecodes benötigt wurde.
Anders gesagt sollten auch die Tokens berücksichtigt werden, die für die Vorverarbeitung verbraucht wurden.
Wenn die dafür verwendete Token-Zahl übermäßig groß war, wurde in Wirklichkeit insgesamt mehr verbraucht und das Ganze wäre damit bedeutungslos. Und selbst wenn sie gering war, dürfte der tatsächliche Unterschied beim Token-Verbrauch deutlich kleiner sein, als es der Text vermuten lässt.
Ein Vergleich des Sourcecodes vor und nach der Vorverarbeitung ist nötig.
Wenn man die für die Vorverarbeitung verwendeten Tokens ausklammert, scheint der Token-Verbrauch bei der Anfrage tatsächlich signifikant gesunken zu sein.
Wenn man aber analysiert, welcher genaue Unterschied im Sourcecode zu diesem Effekt führt, würde der Beitrag deutlich an Aussagekraft gewinnen.
Denn das würde bedeuten, dass sich der Vorverarbeitungs-Prompt optimieren lässt, um genau diese Unterschiede zu maximieren.
Der Autor sagt, dass das Refactoring der Code-Struktur zu diesem Ergebnis geführt habe, aber ich stimme dem nicht zu und denke, dass man das noch nicht wissen kann.
Denn auch wenn man die KI nicht zum Refactoring, sondern zur Verbesserung anderer Aspekte einsetzt, könnte der Token-Verbrauch sinken.
Es braucht vielfältigere Experimente
Ich denke, derselbe Versuch sollte nicht nur mit dem aktuellen Code, sondern auch mit anderen Codebasen durchgeführt werden.
Denn man muss beurteilen können, ob das konsistent gute Ergebnisse liefert oder nicht.
Ich verstehe allerdings, dass das in der Praxis schwer zu testen sein kann, daher würde ich das nur als Hinweis betrachten.
Ich fasse ergänzend die Inhalte zu dem verwendeten Prompt zusammen.
Offenbar ist das besonders für Entwickler vorteilhaft, wenn sie Prompts zur Verbesserung der Struktur schreiben. Da jedes Programm unterschiedliche Eigenschaften hat, ist für hocheffiziente Optimierungen ein gewisses Maß an Entwicklungswissen erforderlich.
Das bedeutet jedoch nicht, dass Vibe-Coder ohne Entwicklerhintergrund diese Methode nicht nutzen können. Die Effizienz mag unterschiedlich ausfallen, aber selbst mit einfachen Anweisungen wie „Bitte räume den Projektcode etwas auf. Entferne ungenutzten Code.“ trennt und organisiert die AI Dateien und Klassen.
Allerdings kann der Unterschied im Detailgrad der Strukturverbesserung zu Effizienzunterschieden führen, daher ist beim Referenzmaterial Vorsicht geboten.
Vielen Dank für das große Interesse an diesem Beitrag. Da der Hauptzweck offenbar die Verbreitung im Ausland ist, wurde der Artikel auf Englisch verfasst, wodurch wohl verschiedene Probleme entstehen.
Daher teile ich hier einen auf Koreanisch zusammengefassten Beitrag.
Der Kern der Aussage ist, dass nach der Anweisung an die AI, die Codestruktur zu refaktorieren, der Tokenverbrauch gesunken ist.
Umgekehrt könnte man auch erklären, dass der Tokenverbrauch steigt, wenn man Befehle in einem Zustand mit strukturellen Mängeln im Code weiterführt.
Zusammengefasst geht es darum, dass die Struktur des Quellcodes verbessert werden muss; es bedeutet nicht, dass der Prompt nur die Kernaussagen logisch verdichtet enthalten sollte.
Man sollte im Prompt nur das Wesentliche logisch formulieren. Heißt das also, je mehr man diesem und jenem in den Prompt packt, desto mehr Rauschen entsteht und desto komplexer und rauschbehafteter wird auch der daraus resultierende Code?
Auch ich fand diese Einleitung und den Originaltext viel zu weitschweifig und hatte den Eindruck, als wäre er von jemandem geschrieben worden, der nicht besonders gut schreibt, weshalb das Lesen schwierig war.
Der Kern ist
„Füge eine einzeilige Anweisung hinzu, die strukturelle Beschränkungen zur Reduzierung von Tokens enthält.“
so in etwa.
Die Web Codecs API selbst ist bereits sehr leistungsstark, daher bieten Web-Medienbibliotheken durchweg eine hervorragende Performance. Es wirkt daher etwas fraglich, das als reines TS zu bezeichnen.
Ich verstehe nicht ganz, was Sie in Ihrem Kommentar sagen wollen. Mein Punkt war, dass man zum fairen Vergleich der beiden Methoden nicht die insgesamt verbrauchte Token-Anzahl vergleichen sollte? Verbraucht auch Refactoring nicht Tokens?
Außerdem scheint Ihre zusätzliche Antwort weder im Artikel zu stehen noch experimentell überprüft worden zu sein. Sie meinen offenbar nicht den Token-Vergleich pro einzelner Anfrage, sondern dass sich bei mehreren Anfragen der Refactoring-Overhead verringert und sich daraus durch die geringere erwartete Token-Anzahl pro Anfrage ein Vorteil bei der Gesamtzahl der Tokens ergibt. Das wäre aber nur dann zutreffend, wenn diese Kostenreduktion bei mehreren Anfragen tatsächlich so bestehen bleibt, wie Sie annehmen, und das wirkt auf mich wie eine sehr ideale Annahme. Es gibt keine Garantie dafür, dass die Kostensenkung durch Refactoring unabhängig von der Anzahl der folgenden Anfragen erhalten bleibt, und ohne Experiment kann man das auch nicht einfach voraussetzen. Wenn Sie genau diese Aussage vertreten wollen, müssten Sie die Kostensenkung über mehr als eine Anfrage hinweg experimentell zeigen. Aber haben Sie nicht nur ein einziges Experiment durchgeführt und darauf basierend verglichen?
Ergänzend: Das ist nur meine eigene Annahme, aber wenn man für dasselbe Ziel (ein ideales Endergebnis) die Anfragen unendlich oft wiederholt, dann sollte der Code im Idealfall unabhängig davon, ob Refactoring stattfindet oder nicht, gegen dieselbe Form konvergieren. (Das ideale Endergebnis ist eindeutig.)
Wenn diese Annahme vernünftig ist, dann dürfte mit zunehmender Zahl an Anfragen der Unterschied mit oder ohne Refactoring kleiner werden, sodass auch der Vorteil der Token-Kostenreduktion allmählich sinkt. Wenn man das also aus einer makroskopischen Perspektive betrachtet: Falls dieser Vorteil durch die Kostenreduktion nicht lange genug anhält, könnte der Unterschied in der insgesamt für die Anfragen verwendeten Token-Anzahl am Ende vielleicht gar nicht signifikant sein, oder?
Da dieser Text eher den Charakter einer Studie zum Thema „Experiment“ hat,
liegt der Fokus aller in diesem Text enthaltenen Zahlen darauf, dass alle, die diesen Text lesen, die Ergebnisse „reproduzieren“ können.
Daher wurden sowohl der verwendete Original-Source-Code als auch sämtliche im Test verwendeten Verfahren vollständig dokumentiert,
sodass der Inhalt darauf ausgerichtet ist, Informationen bereitzustellen, mit denen alle Versuchspersonen dieselben Ergebnisse erzielen können.
Wenn ich die Stimmung in den Kommentaren betrachte, habe ich das Gefühl,
ich sollte künftig vielleicht zwei getrennte Texte schreiben: einen mit der Tendenz zu einer Zusammenfassung in drei Zeilen
und einen weiteren für Menschen, die die Details wissen möchten.
Wenn Sie mir mitteilen, welcher Teil dieses Textes als übermäßig komplex oder zu ausführlich empfunden wurde,
würde mir das beim Verfassen künftiger Texte sehr helfen.
Dem stimme ich voll und ganz zu. Solche Formen der Kritik begrüße ich sehr.
Man lebt nicht allein auf der Welt, und die Fähigkeiten oder Umstände jedes Einzelnen sind unterschiedlich.
Auch ich bin letztlich nur ein Entwickler und kann nicht alle Tests auf eigene Kosten durchführen.
Ich hoffe, dass dieser Beitrag als Samen dient, viele Menschen positiv beeinflusst und zum Ausgangspunkt für viele weitere Forschungen wird.
Der Untertitel passt nicht ganz zum Inhalt. Wenn man es neu ordnet, scheint „Es ist eine Analyse klarerer Faktoren nötig, die zur Token-Reduktion führen“ als Untertitel passender zu sein.
Diesem Inhalt stimme ich in vielen Punkten zu. Allerdings hat dieser Artikel auch den Charakter, den Menschen, die ihn lesen, realistische Anwendungsmethoden vorzuschlagen.
Schon an den Kommentaren unter diesem Artikel lässt sich die Stimmung erkennen; auch ich habe erst vor Kurzem erfahren, dass es unter den AI-Nutzern vermutlich viele Nicht-Entwickler gibt, die als Vibe-Coder unterwegs sind.
Wenn durch vom Autor direkt angepassten Code, also ohne den Einsatz von AI, ein herausragendes Ergebnis erzielt wird,
wirkt das leicht so, als wolle der Autor seine Entwicklungsfähigkeiten zur Schau stellen und die Fähigkeiten von AI herabsetzen.
Daher wurde als Element das „Prompt“ gewählt, das auch andere Vibe-Coder nutzen können, und es wurden Beispiele behandelt, bei denen jeder das Ergebnis nachvollziehen kann.
Ich fände es gut, wenn im Anschluss an diese Untersuchung weitere Studien folgen würden, die die Faktoren, welche den AI-Token-Verbrauch beeinflussen, differenzierter aufschlüsseln.
Wenn durch eine einmalige strukturelle Überarbeitung die Token-Nutzungsrate von n Prompts gesenkt wird, dann spiegelt sich diese Reduktion über alle n identisch ausgeführten Durchläufe hinweg wider.
Dabei ist n ein Wert, der durch Ziel und Funktionsumfang des Projekts sowie durch Menge und Komplexität des dafür nötigen Codes bestimmt wird.
Außerdem gab es zuletzt bei Cursor- und Claude-Code-Agenten Updates, die die Ausführungseinheiten kleiner halten, um Probleme wie Endlosschleifen oder den unkontrollierten Token-Verbrauch durch KI zu lösen.
Ich halte es daher für richtig, Studien zum n-Wert in Bezug auf die Projektkomplexität getrennt durchzuführen.
Was man an dieser Stelle nicht übersehen darf, ist, dass eine Verbesserung der Struktur niemals ein Vorgang ist, der absolut unabhängig von der eigentlichen Codeentwicklung stattfindet.
Sie kann bereits über den ersten Prompt oder über Einschränkungen wie ein KI-Regelwerk (
.cursorrules) als Base Context Einfluss nehmen.Und eine einzige strukturelle Verbesserung kann im Verlauf des Projektentwicklungszyklus nicht alle Probleme auf einmal lösen.
Mit anderen Worten: Statt Codeverbesserungen in festen Intervallen zu planen, ist es sinnvoller, als Base Context von Anfang an die richtige Struktur anzuleiten.
Außerdem erscheint es sinnvoll, die Untersuchung getrennt danach durchzuführen, ob es als Base Context Regeln zur strukturellen Anleitung gibt oder nicht.
Zur Zusammenfassung von Punkt 1:
ist die Behauptung irreführend, man müsse den Token-Verbrauch eines einzelnen Prompts zur strukturellen Verbesserung zusätzlich aufschlagen und so berechnen.
Das habe ich ähnlich empfunden.
Ich verstehe zwar die Absicht des Autors, aber im Verhältnis zu dem, was gemacht wurde, wirkt der Text übermäßig komplex.
Vermutlich wurde er so geschrieben, weil möglichst viele der im Experiment verwendeten Details in den Text einfließen sollten.
Wenn Sie aber nur die Kernaussagen knapp herausziehen, werden Leser, die sich für so ein Thema interessieren, es wahrscheinlich trotzdem verstehen.
Wenn Sie mutig Details weglassen und nur das Wesentliche zusammenfassen, wäre es meiner Meinung nach besser.
Ich fand die Absicht des Autors und auch das Ergebnis selbst interessant.
Die Hauptthese ist, dass besserer Sourcecode zu geringerem Token-Verbrauch führt,
und dazu scheint ein entsprechendes Experiment entworfen und durchgeführt worden zu sein.
Wenn ich nur das aufzähle, was ich vom Experiment verstanden habe:
So scheint es zu sein.
Und wenn ich es richtig verstanden habe, lautet das Fazit, dass der per Prompt vorverarbeitete Sourcecode insgesamt weniger Tokens verbraucht.
Ein interessantes Fazit, aber meine Meinung zum Experiment ist wie folgt.
Kein fairer Vergleich
Zahlenmäßig scheint der Verbrauch zwar gesunken zu sein, aber eigentlich müsste man die gesamte Token-Zahl vergleichen, die für die Verarbeitung des Sourcecodes benötigt wurde.
Anders gesagt sollten auch die Tokens berücksichtigt werden, die für die Vorverarbeitung verbraucht wurden.
Wenn die dafür verwendete Token-Zahl übermäßig groß war, wurde in Wirklichkeit insgesamt mehr verbraucht und das Ganze wäre damit bedeutungslos. Und selbst wenn sie gering war, dürfte der tatsächliche Unterschied beim Token-Verbrauch deutlich kleiner sein, als es der Text vermuten lässt.
Ein Vergleich des Sourcecodes vor und nach der Vorverarbeitung ist nötig.
Wenn man die für die Vorverarbeitung verwendeten Tokens ausklammert, scheint der Token-Verbrauch bei der Anfrage tatsächlich signifikant gesunken zu sein.
Wenn man aber analysiert, welcher genaue Unterschied im Sourcecode zu diesem Effekt führt, würde der Beitrag deutlich an Aussagekraft gewinnen.
Denn das würde bedeuten, dass sich der Vorverarbeitungs-Prompt optimieren lässt, um genau diese Unterschiede zu maximieren.
Der Autor sagt, dass das Refactoring der Code-Struktur zu diesem Ergebnis geführt habe, aber ich stimme dem nicht zu und denke, dass man das noch nicht wissen kann.
Denn auch wenn man die KI nicht zum Refactoring, sondern zur Verbesserung anderer Aspekte einsetzt, könnte der Token-Verbrauch sinken.
Es braucht vielfältigere Experimente
Ich denke, derselbe Versuch sollte nicht nur mit dem aktuellen Code, sondern auch mit anderen Codebasen durchgeführt werden.
Denn man muss beurteilen können, ob das konsistent gute Ergebnisse liefert oder nicht.
Ich verstehe allerdings, dass das in der Praxis schwer zu testen sein kann, daher würde ich das nur als Hinweis betrachten.
Nutzlose Geschenke zu machen scheint gerade beliebt zu sein … um neue nutzlose Geschenke aufzuspüren, ist das wohl ganz gut.
Ich fasse ergänzend die Inhalte zu dem verwendeten Prompt zusammen.
Offenbar ist das besonders für Entwickler vorteilhaft, wenn sie Prompts zur Verbesserung der Struktur schreiben. Da jedes Programm unterschiedliche Eigenschaften hat, ist für hocheffiziente Optimierungen ein gewisses Maß an Entwicklungswissen erforderlich.
Das bedeutet jedoch nicht, dass Vibe-Coder ohne Entwicklerhintergrund diese Methode nicht nutzen können. Die Effizienz mag unterschiedlich ausfallen, aber selbst mit einfachen Anweisungen wie „Bitte räume den Projektcode etwas auf. Entferne ungenutzten Code.“ trennt und organisiert die AI Dateien und Klassen.
Allerdings kann der Unterschied im Detailgrad der Strukturverbesserung zu Effizienzunterschieden führen, daher ist beim Referenzmaterial Vorsicht geboten.
Wenn Sie mit Geodaten arbeiten müssen, ist das eine gute Wahl.
Vielen Dank für das große Interesse an diesem Beitrag. Da der Hauptzweck offenbar die Verbreitung im Ausland ist, wurde der Artikel auf Englisch verfasst, wodurch wohl verschiedene Probleme entstehen.
Daher teile ich hier einen auf Koreanisch zusammengefassten Beitrag.
https://modgo.org/tokeun-sayongryang-37-91-reul-gamsosikin-dan-hanjuly…
Der Kern der Aussage ist, dass nach der Anweisung an die AI, die Codestruktur zu refaktorieren, der Tokenverbrauch gesunken ist.
Umgekehrt könnte man auch erklären, dass der Tokenverbrauch steigt, wenn man Befehle in einem Zustand mit strukturellen Mängeln im Code weiterführt.
Zusammengefasst geht es darum, dass die Struktur des Quellcodes verbessert werden muss; es bedeutet nicht, dass der Prompt nur die Kernaussagen logisch verdichtet enthalten sollte.
Man sollte im Prompt nur das Wesentliche logisch formulieren. Heißt das also, je mehr man diesem und jenem in den Prompt packt, desto mehr Rauschen entsteht und desto komplexer und rauschbehafteter wird auch der daraus resultierende Code?
Doppelt gemoppelt
Ich bin der Autor. Vielen Dank für das Feedback. Ich werde es beim Verfassen des nächsten Artikels berücksichtigen.
Auch ich fand diese Einleitung und den Originaltext viel zu weitschweifig und hatte den Eindruck, als wäre er von jemandem geschrieben worden, der nicht besonders gut schreibt, weshalb das Lesen schwierig war.
Der Kern ist
„Füge eine einzeilige Anweisung hinzu, die strukturelle Beschränkungen zur Reduzierung von Tokens enthält.“
so in etwa.
Plötzlich sind alle Punkte verschwunden.
Fazit
Der Einsatz von KI hilft, Produktivität zu sichern und
Kosten zu senken,
aber er bringt für sich genommen kein Geld ein.
So etwas wie Node.js an andere Anwendungen zu binden, ist ziemlich umständlich; es wäre schön, wenn das etwas einfacher wäre.
Die Web Codecs API selbst ist bereits sehr leistungsstark, daher bieten Web-Medienbibliotheken durchweg eine hervorragende Performance. Es wirkt daher etwas fraglich, das als reines TS zu bezeichnen.
Wenn man sich die Benchmarks ansieht, ist es erstaunlich, dass die Leistung gar nicht so schlecht ist.