亚马逊称用智能体把自己数以万计的生产 Java 应用从 Java 8 或 11 升到了 Java 17,并估计人工做完等于四千五百多人年的开发工作

后端工程师职业页 →

事件日期 / 报道日期

2024-08-01

证据阶段

实际部署企业已正式投入使用。可以改变基线,但要结合规模与场景相似度加权。

关联任务

接口,以及它们之间的管子

增删改查、校验、序列化、从一个服务调另一个服务,以及这一切的测试。

正在自动化✓ 有证据支撑

它花多少钱、有多快

查询计划、缓存、账单,以及那个因为上游变了而变慢的请求。

正在被增强✓ 有证据支撑

适用范围

亚马逊对亚马逊自家工程的内部估算,由出售这件工具的公司发布 —— 干活的一方、测量的一方与卖工具的一方是同一方,这一点写在这里,是因为它从外部无法核验。公司也公布了方法:节省的时间由迁移的 Java 依赖数量估出,假设人工迁移一个依赖需要一天或更久。要注意这是什么样的迁移:语言版本升级有编译器和既有测试套件充当判卷人,每一步的成败都可被机器判定 —— 这是这类自动化最有利的形态,不是关于后端工作的一般结论。也要注意它主张了什么、没主张什么:四千五百年是没有被做的工作,涉及一千多位开发者,而任何地方都没有一句话说他们中有人离开、或有一个岗位被取消。

这意味着什么

在一整片代码资产上做版本升级,是目前智能体在真实公司内部被展示得最清楚的一件大规模工作,而值得说清楚它为什么成立:这活量大、重复,并且有一个自动裁判。编译器会驳回错的,测试套件抓住剩下的大部分,于是机器可以在没有人盯着的情况下反复试错。后端工作里凡是具备这个性质的任务,都该预期它会动。另外,这类迁移也正是资深工程师最不想干、而最常被交给初级工程师的那一件。

还不能说明什么

亚马逊用自己的工具测量自己的工作,并发布了自己算的反事实;那个撑起整个数字的假设 ——「人工迁移一个依赖要一天」—— 没有任何外部的人核过。里面没有任何一句建立了人数变化:它主张的是没有被花掉的工时,而那些开发者当时在做别的事。更重要的是,让它成立的那个性质不能迁移:写一个新接口、划一条租户边界、或者在凌晨三点决定降级什么,都没有一个编译器会说不。

你可以核实什么

翻出你自己服务上还没做的升级工单,按「机器能不能在没有你的情况下判断成没成」排个序。能判的那些,别再主动接了;不能判的那些,是你下次评估该谈的内容。

是否改变评估

否。影响指数不会被单条事件改变。这条记录做到的是:上面 2 项关联任务的判断从「推断」变成了「有证据支撑」。

来源

AWS DevOps & Developer Productivity Blog (Amazon's own) · 核实于 2026-09-12 · Claude (VOLO agent) — AWS's own blog post fetched and read in full; the 'tens of thousands', '4,500 years', '$260 million' and the dependency-count estimation method are the post's own words · 解读于 2026-09-12 · Claude (VOLO agent)

一手来源 —— 由做这件事的当事人或记录的权威机构发布,无需联署。

这条记录被引用在