在当前的 Web 开发时代，许多架构决策往往是由“感觉”驱动的——即对开发者体验（DX）的主观偏好或关于速度的营销宣传。然而，随着开发模式转向“智能体化”模型，即由 AI 智能体生成代码而非人类手动输入，DX 的约束变得不再那么重要。Nolan Lawson 通过基准测试研究了这一转变，探讨了不同的 JavaScript 框架如何影响承担构建非平凡 Pokémon 应用程序任务的 AI 智能体的效率和输出质量。
为了进行这项实验，Lawson 指示一个 AI 智能体（Opus 5.5）使用十种不同的框架或元框架（包括 Next.js、Nuxt、SvelteKit 和 Angular）构建一个内容丰富的应用程序。智能体获得了相关规范，并被允许在可用时使用官方工具，如 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 字节数和更高的总阻塞时间（TBT）。有趣的是，“原生” JavaScript 的表现不如多个框架，这表明虽然简洁是 AI 智能体效率的关键，但一定程度的框架抽象对于智能体的成功仍然是有益的。
虽然这些结果提供了 AI 智能体行为的清晰快照，但该实验存在特定的局限性。作为“原型”使用的 Pokémon 应用主要基于内容，缺乏像 Gmail 或 Figma 等复杂企业工具的高交互性。由于基准测试集中在小规模应用程序上，当智能体被要求构建高度动态、状态密集型系统时，性能和成本的权衡可能会发生显著变化。此外，由于大语言模型（LLM）的随机性质，单次运行的结果可能会大幅波动，因此这些结果是 AI 智能体行为的中位代表，而非每个项目的保证结果。
作为“原型”使用的 Pokémon 应用主要基于内容，缺乏像 Gmail 或 Figma 等复杂企业工具的高交互性。