AI coding agent 正在加速比例排序

Andrew Ng 在最新一期 The Batch（第 350 期）给出的洞见 AI coding agent 正在加速比例排序：前端 > 后端 > 基础设施 > 研究 排序本身不奇怪，真正值得看的是他每一档背后的解释
第一档：前端,加速最猛为什么? 因为 coding agent在前端这件事上几乎全占，TypeScript / JavaScript / React / Angular 全是它们最熟悉的语言和框架，而且它们能自己开浏览器看渲染效果,自己改,再自己看,形成完整闭环 唯一的短板：视觉设计还差，但只要给一个设计稿（或者你不在乎设计精致度），实现速度直接起飞 Andrew 自己的话：现在我对前端团队的产出预期，比一年前高一大截
第二档：后端,加速很大 但不如前端 后端写起来快了很多，但 agent 对边角情况的覆盖差 模型对 corner case 的覆盖需要人类反复 steer 后端的 bug 经常会沿数据库往下游传（数据库被污染 偶尔返回错的数据 这种 bug 比前端难调多了） 数据库迁移 agent 能帮忙 但仍然容易丢数据 必须人工把关 Andrew 的判断：经验丰富的工程师，仍然比「新手 + coding agent」做出来的后端好得多
第三档：基础设施 ,加速更少,把一个电商网站撑到10K并发，同时保证 99.99% 可用性，这种事 agent 帮不了多少 为什么？ LLM 对基础设施的知识相对薄,各种权衡（cost / latency / reliability）需要工程经验,基础设施很多时候要靠测试和实验 agent 写代码快没用 实验本身要花时间,一个隐蔽的网络配置错,找起来要深功夫,所以 agent 对关键基础设施的加速比对后端还小
第四档：研究 ,几乎没怎么加速, 研究的核心环节是想新想法 / 形成假设 / 跑实验 / 解读结果 / 修改假设 / 再迭代 agent 能帮的部分，写研究代码快了，帮你管 experiments 让一个研究员能管更多实验,但研究里大部分时间花在「写代码」之外，对这部分 agent 帮的极有限 Andrew 自己的话：我对研究团队的产出预期 跟一年前几乎没变 我自己的延伸观察 这个排序其实跟「任务的反馈环路是否封闭」高度相关 - 前端：能看到渲染 反馈环路最封闭 - 后端：要等数据流过完整路径才知道对错 反馈环路较长 - 基础设施：很多 bug 要在生产规模下才暴露 反馈环路最长 - 研究：很多时候连「对错」本身都还没定义 反馈环路开放 agent 加速的本质是它在封闭反馈环里能高速试错，环路越开放，agent 能加的速越少