# Amazon says it moved tens of thousands of its own production Java applications from Java 8 or 11 to Java 17 with an agent, and estimates the manual equivalent at over 4,500 years of development work

Page: https://flyvolo.ai/en/changes/ev-20240801-backend-developer-1
Date: 2024-08-01 · Stage: Deployment
Can this record move a task judgement? yes
Occupation: https://flyvolo.ai/en/careers/backend-developer

## Scope

Amazon's own internal estimate about Amazon's own engineering, published by the company that sells the tool - the party doing the work, the party measuring it and the party selling it are the same, which is stated here because it cannot be checked from outside. The company also publishes its method: time saved was estimated from the number of Java dependencies migrated, assuming a day or more of developer time per dependency manually. Note what the migration is: a language-version upgrade has a compiler and an existing test suite as its oracle, so success is machine-checkable at every step - the most favourable possible shape for this kind of automation and not a general result about backend work. And note what is claimed and what is not: 4,500 years is work not done, over a thousand developers, with no statement anywhere that any of them left or that a role was removed.

## Source

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

## What this means

A version upgrade across a large estate is the clearest thing an agent has been shown doing at scale inside a real company, and it is worth being precise about why: the work is enormous, repetitive, and has an automatic referee. The compiler rejects what is wrong and the test suite catches most of the rest, so a machine can try, fail and retry without a person watching. Where a backend task has that property, expect it to move. The migration is also the task most senior engineers least want and most junior engineers get handed.

## What it does not show yet

Amazon measured its own work with its own tool and published its own counterfactual; nobody outside checked the day-per-dependency assumption that the whole figure rests on. Nothing in it establishes a headcount change - the claim is hours not spent by developers who were doing something else instead. And the property that made it work does not transfer: writing a new endpoint, deciding a tenancy boundary or choosing what to degrade at 3 a.m. have no compiler to say no.

## How to verify it yourself

Look at your own service's open upgrade tickets and sort them by whether a machine could tell success from failure without you. The ones where it could are the ones to stop volunteering for; the ones where it could not are what your next review should be about.


More: https://flyvolo.ai/llms.txt