LO
Implementação realAutomatização cognitiva2024-08-01
A Amazon diz ter movido dezenas de milhares das suas próprias aplicações Java de produção de Java 8 ou 11 para Java 17 com um agente, e estima o equivalente manual em mais de 4.500 anos de trabalho de desenvolvimento
Programador backendpágina da profissão →
Data do facto / publicação
2024-08-01
Categoria da prova
Implementação realUma empresa pô-lo em produção. Pode mover a linha de base, ponderado pela escala e por quanto esse contexto se parece com o teu.
Tarefas sobre as quais incide
Endpoints e a canalização entre eles
CRUD, validação, serialização, chamar um serviço a partir de outro, e os testes de tudo isso.
A automatizar-se✓ Com prova
Quanto custa e quão rápido é
Planos de consulta, cache, a fatura, e o pedido que ficou lento porque algo a montante mudou.
Aumentada pela máquina✓ Com prova
Onde é que isto se aplica
Uma estimativa interna da Amazon sobre a própria engenharia da Amazon, publicada pela empresa que vende a ferramenta — quem faz o trabalho, quem o mede e quem o vende são a mesma parte, o que é dito aqui porque não pode ser verificado de fora. A empresa publica também o seu método: o tempo poupado foi estimado a partir do número de dependências Java migradas, assumindo um dia ou mais de tempo de programador por dependência feita à mão. Repara no que a migração é: uma subida de versão de linguagem tem um compilador e uma bateria de testes existente como árbitro, por isso o sucesso é verificável por máquina em cada passo — a forma mais favorável possível para este género de automatização e não um resultado geral sobre o trabalho de backend. E repara no que é afirmado e no que não é: 4.500 anos é trabalho não feito, mais de mil programadores, sem que em lado nenhum se diga que algum deles saiu ou que um lugar foi eliminado.
O que isto significa
Uma subida de versão num parque grande é a coisa mais clara que já se mostrou um agente a fazer em escala dentro de uma empresa real, e vale a pena dizer com precisão porquê: o trabalho é enorme, repetitivo e tem um árbitro automático. O compilador rejeita o que está errado e a bateria de testes apanha quase todo o resto, por isso uma máquina pode tentar, falhar e tentar de novo sem ninguém a ver. Onde uma tarefa de backend tiver essa propriedade, conta que ela se mexa. A migração é além disso a tarefa que os engenheiros experientes menos querem e a que mais é entregue aos júnior.
O que ainda não mostra
A Amazon mediu o seu próprio trabalho com a sua própria ferramenta e publicou o seu próprio cenário alternativo; ninguém de fora verificou o pressuposto de um dia por dependência sobre o qual todo o número assenta. Nada disso estabelece uma mudança de efetivos: o que se afirma são horas não gastas por programadores que estavam a fazer outra coisa em vez disso. E a propriedade que fez aquilo funcionar não se transfere: escrever um novo ponto de acesso, decidir uma fronteira de multi-inquilino ou escolher o que degradar às três da manhã não têm compilador nenhum a dizer que não.
O que podes verificar
Olha para os pedidos de atualização abertos do teu próprio serviço e separa-os consoante uma máquina conseguisse distinguir o sucesso do falhanço sem ti. Aqueles em que conseguiria são os que há a deixar de pedir voluntariamente; aqueles em que não conseguiria são aquilo sobre que a tua próxima avaliação devia ser.
Muda a avaliação?
Não. O índice de impacto nunca é movido por um único facto. O que este registo fez: 2 juízos de tarefa ligados em cima apoiam-se agora em prova em vez de em inferência.
Fonte
AWS DevOps & Developer Productivity Blog (Amazon's own) · verificado 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 · interpretado 2026-09-12 · Claude (VOLO agent)
Fonte primária: publicada pela parte que fez isto, ou pela autoridade de referência. Não precisa de coassinatura.
Este registo é citado em