現在のWeb開発において、多くの設計上の決定は「バイブス（直感）」、つまり開発者体験（DX）に対する主観的な好みや、スピードに関するマーケティング上の主張によって左右されることが少なくありません。しかし、開発が人間が手動でタイピングするのではなく、AIエージェントがコードを生成する「エージェンティック」なモデルへと移行するにつれ、DXの制約は重要ではなくなってきます。Nolan Lawsonは、異なるJavaScriptフレームワークが、複雑なPokémonアプリケーションの構築を任されたAIエージェントの効率と出力品質にどのように影響するかをベンチマークすることで、この変化を調査しました。
実験を実施するために、LawsonはAIエージェント（Opus 5.5）に対し、Next.js、Nuxt、SvelteKit、Angularを含む10種類の異なるフレームワークまたはメタフレームワークを使用して、コンテンツの多いアプリケーションを構築するよう指示しました。エージェントには仕様書が提供され、利用可能な場合にはModel Context Protocol（MCP）スキルなどの公式ツールを使用することが許可されました。結果として、フレームワークの複雑さと生成の「コスト」との間に明確な相関関係があることが示されました。Hono+htmxやAstroのようなシンプルなアーキテクチャが最も効率的であり、Hono+htmxの実行コストは中央値で2.67ドルでした。対照的に、SvelteKit（4.28ドル）やAngular（4.97ドル）のようなより複雑なフレームワークは、米ドルと実時間の両方において大幅に高コストであり、Angularの完了には中央値で17.2分を要しました。
ベンチマークの結果は、フレームワークの複雑さと生成コストの間に明確な相関があることを示しており、よりシンプルなアーキテクチャの方が効率的であることが証明された。
生成コストだけでなく、このベンチマークではLighthouseメトリクスを使用して最終的なアプリケーションのパフォーマンスも測定しました。データは、マルチページアプリケーション（MPA）寄りのフレームワークと、シングルページアプリケーション（SPA）重視のフレームワークの間にパフォーマンスの差があることを明らかにしました。AstroとHono+htmxは最高の結果を達成し、AstroはクライアントサイドのJavaScriptを0 KiB転送し、Hono+htmxはわずか18 KiBの転送にとどまりました。逆に、Next.js（142 KiB）やAngular（93 KiB）のような重量級のフレームワークは、より高いJavaScriptバイト数と高いTotal Blocking Time（TBT）をもたらしました。興味深いことに、「Vanilla」JavaScriptはいくつかのフレームワークと比較してパフォーマンスが低く、エージェントの効率にはシンプルさが鍵である一方で、エージェントの成功のためにはある程度のフレームワークの抽象化が依然として有益であることを示唆しています。
これらの結果はエージェントの挙動を明確に捉えていますが、この実験には特定の制限があります。テストの「ホロタイプ」として使用されたPokémonアプリは主にコンテンツベースであり、GmailやFigmaのような複雑なエンタープライズツールの高いインタラクティブ性を備えていません。このベンチマークは小規模なアプリケーションに焦点を当てているため、エージェントに高度に動的で状態の多いシステムを構築するタスクを課した場合、パフォーマンスとコストのトレードオフは大きく変化する可能性があります。さらに、LLMの確率的な性質により、個々の実行結果は大きく変動する可能性があるため、これらの結果はエージェントの挙動の中央値を示すものであり、すべてのプロジェクトにおいて保証された結果ではありません。
「ホロタイプ」として使用されたPokémonアプリは主にコンテンツベースであり、GmailやFigmaのような複雑なエンタープライズツールの高いインタラクティブ性を備えていない。