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

网页: https://flyvolo.ai/zh/changes/ev-20240801-backend-developer-1
日期: 2024-08-01 · 阶段: 实际部署
这条记录能改变任务判断吗? 能
职业: https://flyvolo.ai/zh/careers/backend-developer

## 适用范围

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

## 来源

- AWS DevOps & Developer Productivity Blog (Amazon's own) — https://aws.amazon.com/blogs/devops/amazon-q-developer-just-reached-a-260-million-dollar-milestone/ (一手来源)

## 这意味着什么

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

## 它还不能说明什么

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

## 怎么自己核实

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


更多: https://flyvolo.ai/llms.txt