Ein Entwickler sitzt in einem fensterlosen Büro und starrt auf ein Diagramm. Links die Kosten in Dollar, rechts die Korrektheit in Prozent. Eine Punktwolke aus verschiedenen Programmiersprachen, mal grün, mal blau markiert – statisch, dynamisch, alles durcheinander. Er hat gerade zwei große Benchmarks abgeschlossen, einen mit einem Kompressionsformat, einen mit einem Dokumentkonverter. Und er fragt sich, ob die vielzitierte Weisheit, dass dynamische Sprachen für KI-Agenten effizienter seien, überhaupt noch Bestand hat.
Diese Frage treibt viele um, die mit LLM-basierten Coding-Agents arbeiten. Die ursprüngliche These klingt verlockend: Dynamische Sprachen wie Python oder Clojure benötigen weniger explizite Typdeklarationen, also weniger Token, also weniger Kosten. Einige Studien zeigten extreme Unterschiede – bis zu 2,6-mal effizienter als C. Doch neuere, größere Experimente zeichnen ein deutlich differenzierteres Bild. Wir schauen uns an, was die Daten wirklich hergeben, und warum einfache Erklärungen selten die ganze Wahrheit sind.
Die Ursprungsbehauptung: Dynamische Sprachen als Token-Sparer
Die oft zitierte Analyse basierte auf trivialen Aufgaben von der Rosetta-Code-Seite. Dort ging es etwa darum, ein paar Zeilen auszugeben oder einfache Algorithmen zu implementieren. Die Ergebnisse schienen klar: Clojure brauchte durchschnittlich 109 Token, C dagegen 300 oder mehr. Noch extremer wurde es mit der Array-Sprache J, die angeblich mit 70 Token pro Problem auskam – weniger als ein Drittel von Rust oder Go. Diese Zahlen verbreiteten sich schnell, nicht zuletzt weil Googles KI-Zusammenfassung sie übernahm.
Doch bei genauem Hinsehen zeigt sich ein bekanntes Problem: Triviale Aufgaben sind kein guter Maßstab. Wenn ein Problem in 70 Token lösbar ist, steckt kaum echte Logik dahinter – meistens nur ein print-Statement. Bei solchen Mini-Aufgaben dominieren syntaktische Unterschiede, nicht die tatsächliche Effizienz der Sprache. Das erinnert an die „Caveman-Mode“-Debatte, bei der extrem einfache Prompts angeblich riesige Geschwindigkeitsvorteile brachten – bis man größere, realistischere Probleme testete. Die Verhältnisse brachen komplett ein.
Der Autor des hier besprochenen Artikels hat deshalb eigene Evals entworfen, und zwar mit Aufgaben, die tatsächlich Arbeit erfordern. Seine Vorab-Vermutungen waren deutlich: mit 95% Wahrscheinlichkeit würde der dynamisch-statisch-Unterschied verschwinden, und mit 98% Wahrscheinlichkeit würde die Überlegenheit exotischer Sprachen wie J sich als Illusion herausstellen. Die Ergebnisse bestätigten diese Skepsis weitgehend.
Zwei eigene Experimente: Zstd und Pandoc
Das erste Experiment verlangte die Implementierung eines vollständigen Dekoders für das Kompressionsformat Zstd, basierend auf der offiziellen RFC-Dokumentation. Die Testsuite war den Agenten nicht bekannt, und es gab keine Internetverbindung. Bei mittlerer Anstrengung („medium effort“) sah es zunächst so aus, als lägen dynamische Sprachen vorn – mehrere von ihnen schafften es in die obere linke Ecke des Kosten-Korrektheit-Diagramms. Doch bei hoher Anstrengung („ultra effort“) drehte sich das Bild: Einige statische Sprachen schnitten plötzlich besser ab, und die Streuung war so groß, dass von einem klaren Muster keine Rede sein konnte.
Das zweite Experiment nutzte das Pandoc-ProgramBench-Eval, bei dem Agenten einen Dokumentkonverter implementieren müssen. Hier wurden die Tests aus der Basisversion zur Verfügung gestellt, aber gegen einen Holdout-Satz bewertet. Wieder zeigte sich: Weder die statisch-dynamische Einteilung noch die Dichte einer Sprache hatte einen signifikanten Einfluss auf Kosten oder Korrektheit. Auffällig war nur, dass obskure Sprachen wie Assembly oder selten genutzte Vertreter erwartungsgemäß schlecht abschnitten – einfach weil die Trainingsdaten der Modelle kaum Beispiele für sie enthalten.
Diese Ergebnisse decken sich mit dem, was man bei anderen Benchmarks beobachtet: Sobald Aufgaben ein wenig Komplexität haben, verwässern sich extreme Token-Unterschiede. Die Agenten müssen mehr Code schreiben, mehr Zwischenschritte abwickeln, mehr Fehler korrigieren. Da spielt es kaum noch eine Rolle, ob eine Sprache Typannotationen erfordert oder nicht. Die oft behaupteten Vorteile von Ruby, Clojure, J oder auch Elixir ließen sich in diesen größeren Tests nicht reproduzieren.
Warum Token-Effizienz überschätzt wird
Es ist verlockend, die Token-Anzahl als den entscheidenden Kostenfaktor zu sehen – schließlich zahlt man bei den meisten LLM-APIs pro Token. Aber die Realität ist komplexer. Ein Coding-Agent verbraucht Token nicht nur für den eigentlichen Code, sondern auch für Zwischenüberlegungen, Fehlermeldungen, Compiler-Ausgaben und Rückfragen. Wenn ein Agent einen Fehler macht und den gleichen Compiler-Fehler zehnmal behebt, wie es bei Codex häufig vorkommt, dann schlägt dieser Overhead weit stärker zu Buche als ein paar fehlende Typdeklarationen.
Hinzu kommt: Die synthetischen Trainings- und Verstärkungslern-Daten, die AI-Labore für Agenten erzeugen, konzentrieren sich auf Mainstream-Sprachen. Python, JavaScript, Java, Go, C++ – dafür gibt es Massen an Daten. Für J oder Clojure fast nichts. Ein Agent, der mit diesen Sprachen arbeiten soll, muss erst mühsam die richtigen Muster lernen, was in der Praxis zu zusätzlichen Token und Fehlern führt. Die in diesem Artikel berichteten Daten zeigen tatsächlich eine schwache bis moderate positive Korrelation zwischen Sprachpopularität und Leistung – populärere Sprachen schnitten billiger und korrekter ab.
Das bedeutet nicht, dass dynamische Sprachen prinzipiell schlecht sind. Aber die einfache Gleichung „weniger Token = besser“ greift nicht. Du solltest also nicht deine gesamte Codebasis auf eine exotische Sprache umstellen, nur weil ein Test mit Rosetta-Code-Aufgaben das nahelegt. Die Wahl der Sprache sollte sich an deinen realen Anforderungen orientieren, nicht an theoretischen Token-Einsparungen, die in komplexen Projekten ohnehin verschwinden.
Die Qualität der Evals: Was man aus Benchmarks lernen kann
Ein zentraler Punkt des Artikels ist die Methodik der Evals selbst. Der Autor zeigt detailliert auf, wie leicht man in die Irre geführt wird: Das zweite zitierte Experiment hatte zum Beispiel einen Pfad-Fehler, der dazu führte, dass ein Agent einen Symlink auf eine nicht existierende Datei legte und dadurch alle nachfolgenden Tests mit seiner eigenen ausführbaren Datei liefen – das verfälschte komplett die Ergebnisse für andere Sprachen wie Rust. Solche subtilen Konfundierungen sind die Regel, nicht die Ausnahme.
Ähnlich wie bei früheren Analysen zur „Caveman-Mode“-Optimierung zeigt sich: Ergebnisse aus Mini-Evals lassen sich nicht generalisieren. Erst wenn Aufgaben eine gewisse Größe erreichen – echte Algorithmen, Protokolle, Dateiformate – werden die Unterschiede aussagekräftig. Der Artikel empfiehlt deshalb, vor jeder Evaluation Präregistrierungen zu machen, also Hypothesen festzulegen, bevor man die Daten sieht. Das hilft, den eigenen Bestätigungsfehler zu reduzieren und die Aussagekraft der Ergebnisse realistisch einzuschätzen.
Für dich als Entwickler oder Entscheider bedeutet das: Nimm jedes Benchmark-Ergebnis mit einer gehörigen Portion Skepsis. Prüfe, welche Aufgaben gelöst wurden, ob die Testumgebung sauber war und ob die Effektgrößen auch bei realistischeren Szenarien bestehen bleiben. Oft reicht eine einzige robuste Evaluation, um eine weit verbreitete Behauptung zu widerlegen – so wie hier die Behauptung, dynamische Sprachen hätten prinzipiell niedrigere LLM-Kosten.
Was wirklich zählt: Mainstream-Sprachen und gute Testwerkzeuge
Wenn weder die statisch-dynamische Einteilung noch die Token-Dichte entscheidend ist, was sollte man dann bei Coding-Agents beachten? Die Daten legen nahe, dass die Unterstützung durch das Modell – also Trainingsdaten, Dokumentation, Community-Beispiele – der wichtigste Faktor ist. Sprachen mit großer Verbreitung und guter LLM-Abdeckung liefern konsistent bessere Ergebnisse. Das heißt nicht, dass du auf Rust verzichten solltest, nur weil etwas mehr Token anfallen – wenn dein Projekt das verlangt, ist es die richtige Wahl. Aber du solltest nicht auf eine exotische Sprache setzen, in der Hoffnung auf magische Token-Ersparnis.
Interessant ist auch die Rolle der Teststrategie. Der Autor vermutet, dass eine schnellere Feedback-Schleife – etwa durch kürzere Compile-Zeiten oder bessere Testausgaben – einen positiven Effekt haben könnte, konstatiert aber, dass dies auf Basis der Daten nicht klar belegt ist. In der Praxis siehst du immer wieder, dass Agenten bei langen Build-Zeiten in Warteschleifen verharren oder Fehler wiederholen. Ein guter Coding-Agent braucht also nicht nur eine geeignete Sprache, sondern auch ein sauberes Setup mit schnellen, isolierten Tests. Das ist wichtiger als die Wahl zwischen Java und Python.
Letztlich bleibt eine ernüchternde Erkenntnis: Die Frage „Was ist die beste Programmiersprache für Coding-Agents?“ hat keine universelle Antwort. Es gibt nicht die eine Sprache, die für alle Aufgaben und alle Modelle optimal ist. Statt nach einer goldenen Lösung zu suchen, solltest du eigene, auf deinen Kontext zugeschnittene Evals durchführen. Nutze realistische Aufgaben, prüfe mehrere Sprachen und achte auf die Kosten in Relation zur Korrektheit. Das Ergebnis wird in den meisten Fällen lauten: Der Unterschied zwischen den Mainstream-Sprachen ist kleiner, als die Marketing-Schlagzeilen vermuten lassen – und die Qualität deiner Tests und deines Prompt-Designs hat einen weit größeren Einfluss auf den Erfolg deines KI-Agenten.
Quelle: danluu.com
