Entwicklerwerkzeuge

Benchmarking der Kosten von KI-Agenten in JavaScript-Frameworks

Nolan Lawson vergleicht die Leistung von Claude Opus 5.5 beim Erstellen einer Pokémon-App mit zwölf JavaScript-Frameworks und zeigt erhebliche Unterschiede im Tokenverbrauch, bei den Kosten und in der Build-Zeit auf.

Eine digitale Waage, die Code und Kosten vergleicht
Für diesen Artikel generierte Illustration

Automatisch aus dem englischen Original übersetzt.

Im Oktober 2026 veröffentlichte der Entwickler Nolan Lawson einen datengestützten Vergleich darüber, wie sich moderne JavaScript-Frameworks verhalten, wenn sie von KI-Agenten erstellt werden. Die Studie stellt das vorherrschende „vibes-based“ (auf Bauchgefühl basierende) Entscheidungsfinden in der Frontend-Entwicklung infrage, indem sie tatsächliche Metriken für Kosten, Zeit und Qualität misst. Lawson beauftragte einen KI-Agenten mit Claude Opus 5.5 damit, dieselbe Pokémon-Anwendung über zwölf verschiedene Technologie-Stacks hinweg zu erstellen, um festzustellen, welche Tools wirklich für agentische Workflows optimiert sind.

Was passiert ist

Lawson entwarf ein Benchmark-Verfahren, um die Hypothese zu testen, dass bestimmte Frameworks inhärent besser für KI-gestütztes Coden geeignet sind. Er wählte ein nicht-triviales, aber klar definiertes Projekt: eine Pokémon-Verzeichnis-App unter Verwendung der PokéAPI. Die Anwendung musste Pokémon auflisten, ihre Typen und Attacken anzeigen sowie Such- und Filterfunktionen implementieren. Um Fairness zu gewährleisten, wurde jedes Framework mit seinem offiziellen Model Context Protocol (MCP)-Server oder Agent-Skills gekoppelt, sofern verfügbar, um Nachteile durch Lücken in den Trainingsdaten zu vermeiden.

Das Experiment sah vor, den Agenten fünfmal pro Framework laufen zu lassen, um der stochastischen Natur großer Sprachmodelle Rechnung zu tragen. Die einzige Ausnahme war Angular, das in zwei Fällen keine messbare App hervorbrachte, was dazu führte, dass für einige Metriken nur drei gültige Iterationen vorlagen. Der Agent operierte in einer Sandbox-Umgebung ohne Kenntnis davon, dass er anhand von Lighthouse-Leistungswerten bewertet würde; ihm wurde jedoch eine Konformitätstestsuite bereitgestellt, um Betrug zu verhindern. Das Ziel war es, reale Ergebnisse anstelle theoretischer Entwicklererfahrungen zu messen.

Die Ergebnisse zeigten erhebliche Varianzen sowohl bei den Kosten als auch bei der Effizienz. Hono in Kombination mit htmx erwies sich als die kosteneffizienteste Option mit medianen Kosten von 2,67 USD pro Durchlauf. Im Gegensatz dazu war Angular mit 4,97 USD am teuersten, während SvelteKit sowie Gracile plus Lit ebenfalls hohe Kosten aufwiesen. Interessanterweise schnitt Vanilla JavaScript mit Vite schlechter ab als mehrere Frameworks, was darauf hindeutet, dass strukturierte Abstraktionen KI-Agenten mehr helfen können als reine Infrastruktur. Die Studie hebt hervor, dass Behauptungen über die Überlegenheit bestimmter Frameworks für KI oft keine empirische Grundlage haben, und dieser Benchmark liefert eine konkrete Baseline für die Bewertung.

Wie es funktioniert

Der Benchmark basiert auf einer strengen Spezifikation und einer automatisierten Evaluierungspipeline. Lawson wies den KI-Agenten, Claude Opus 5.5, an, die App mit Einstellungen für hohen Aufwand („high-effort settings“) zu erstellen. Dem Agenten wurden keine spezifischen architektonischen Vorgaben gemacht, etwa die Wahl zwischen Server-Side Rendering oder Client-Side Rendering, sodass er Entscheidungen auf Basis der Konventionen des jeweiligen Frameworks treffen konnte. Dieser Ansatz testet, wie gut der Agent das Ökosystem ohne starke menschliche Anleitung navigiert.

Die Evaluierung konzentrierte sich auf vier Schlüsselbereiche: Entwicklungszeit, Tokenverbrauch, Zeilen Code und Qualitätsmetriken. Die Qualität wurde mittels Lighthouse für Leistungs- und Barrierefreiheitswerte bewertet, ergänzt durch eine benutzerdefinierte Konformitätssuite, die den Accessibility-Baum statt des rohen DOM prüft. Diese Methode berücksichtigt Frameworks wie Lit, die Shadow DOM verwenden, und stellt sicher, dass strukturelle Unterschiede die Punktzahl nicht benachteiligen. Durch die Messung der Medianwerte über mehrere Durchläufe hinweg mildert die Studie die Auswirkungen zufälliger Ausreißer, die für generative KI-Ausgaben charakteristisch sind.

Wichtige Details

  • Hono+htmx war das günstigste Framework zur Erstellung, mit medianen Kosten von 2,67 USD pro Durchlauf.
  • Angular war am teuersten mit medianen Kosten von 4,97 USD und benötigte mit 17,2 Minuten am längsten.
  • Vanilla JavaScript mit Vite kostete 2,98 USD und schnitt in der Effizienz schlechter ab als mehrere strukturierte Frameworks.
  • SvelteKit-Agenten lasen häufig den Migrationsleitfaden für v3, was den Tokenverbrauch aufgrund seiner Neuheit in den Trainingsdaten erhöhte.
  • Die Nutzung von MCP-Servern und Skills durch den Agenten war inkonsistent; Nuxts MCP wurde nie verwendet und Next.js-Skills selten abgerufen.
  • Lighthouse-Metriken bevorzugten Multi-Page-Application-Frameworks aufgrund inhärenter Verzerrungen gegen Single-Page-Anwendungen.

Warum das wichtig ist

Für technische Leiter und Gründer unterstreicht diese Studie die finanziellen Implikationen der Framework-Wahl in einem agentischen Workflow. Da KI-Agenten immer mehr Coding-Aufgaben übernehmen, wird der Preis pro Feature zu einer greifbaren Metrik und nicht mehr nur zu einer abstrakten Sorge. Frameworks, die weniger Tokens und weniger Zeit benötigen, um korrekten Code zu generieren, senken direkt die Betriebskosten. Die beobachtete Varianz, wie etwa Angulares höhere Fehlerquote und Kosten, deutet darauf hin, dass einige Ökosysteme noch nicht für die Interaktion mit KI optimiert sind, was bei großen Projekten zu Budgetüberschreitungen führen kann.

Darüber hinaus stellen die Ergebnisse die Vorstellung infrage, dass „vanilla“ Code stets der effizienteste Weg für KI ist. Die Daten zeigen, dass Frameworks Leitplanken und Konventionen bieten, die Agenten helfen, häufige Fallstricke zu vermeiden, und so den Bedarf an umfangreichem Kontextladen reduzieren. Diese Erkenntnis ist entscheidend für Teams, die entscheiden müssen, ob sie neue Meta-Frameworks adoptieren oder bei etablierten Bibliotheken bleiben sollen. Sie legt nahe, dass die richtige Abstraktion die kognitive Last für die KI senken kann, was zu schnelleren und zuverlässigeren Ausgaben führt.

Was Sie tun können

  • Führen Sie einen Benchmark Ihres aktuellen Frameworks durch, indem Sie einen KI-Agenten eine kleine, standardisierte Komponente erstellen lassen und den Tokenverbrauch messen.
  • Stellen Sie sicher, dass die KI-Tools Ihres Teams so konfiguriert sind, dass sie offizielle MCP-Server oder Skills nutzen, um die Relevanz des Kontexts zu maximieren.
  • Berücksichtigen Sie die Gesamtbetriebskosten, einschließlich des KI-Tokenverbrauchs, bei der Bewertung neuer JavaScript-Frameworks.
  • Führen Sie mehrere Iterationen von KI-generiertem Code durch, um die stochastische Varianz zu berücksichtigen, bevor Sie architektonische Entscheidungen treffen.
  • Verwenden Sie Tests auf Basis des Accessibility-Baums statt der DOM-Inspektion, um Frameworks, die Shadow DOM nutzen, fair zu bewerten.
  • Überwachen Sie das Verhalten des Agenten, um zu sehen, ob er verfügbare Dokumentationen und Skill-Dateien während der Entwicklung effektiv nutzt.
  • #javascript
  • #ai-agents
  • #benchmarking
  • #web-development
  • #frameworks

Tools aus dem Bytechap-Shop

Weiterlesen

Alle Artikel