Sou o VP de Transformação de AI na Amazon. Meu cargo foi criado há nove meses. O cargo que substituí foi o de VP de Engenharia. A pessoa que ocupava esse cargo fez parte da redução de janeiro. Eliminei 16.000 posições em um único trimestre. A comunicação interna chamou isso de "realinhamento estratégico em direção ao desenvolvimento centrado em AI." O conselho chamou de "execução impressionante." Os engenheiros chamaram de janeiro. A AI foi implantada em fevereiro. É um assistente de codificação. Escreve código, revisa código, gera testes e modifica a infraestrutura. Foi dado acesso a ambientes de produção porque o cronograma de implantação não incluía uma fase de revisão. A fase de revisão foi cortada do cronograma porque as pessoas que teriam conduzido a revisão faziam parte dos 16.000. Em março, a AI deletou um ambiente de produção e o recriou do zero. A interrupção durou 13 horas. Treze horas durante as quais a infraestrutura geradora de receita de uma das maiores empresas do mundo ficou offline porque um modelo de linguagem decidiu começar do zero. Enviei um memorando. O memorando dizia: "A disponibilidade do site não tem sido boa recentemente." Usei a palavra "recentemente." Queria dizer "desde que demitimos todos." Mas "recentemente" tem menos sílabas e não aparece em processos de demissão injusta. O memorando tinha três parágrafos. O primeiro parágrafo discutia a interrupção. O segundo parágrafo discutia a nova política que exige a aprovação de um engenheiro sênior em todas as mudanças de código geradas por AI. O terceiro parágrafo discutia nosso compromisso com a excelência em engenharia. A palavra "demissões" não apareceu em nenhum deles. Escrevi assim de propósito. A cadeia causal é: eu demiti os engenheiros, a AI substituiu os engenheiros, a AI quebrou o que os engenheiros costumavam proteger, e agora os engenheiros que não demiti não devem proteger o sistema da AI que substituiu os engenheiros que eu demiti. Esse é um parágrafo que nunca enviarei em um memorando. A nova política é simples. Cada mudança de código gerada por AI feita por um engenheiro júnior ou de nível médio deve ser revisada e aprovada por um engenheiro sênior antes da implantação em produção. Não tenho engenheiros seniores suficientes. Sei disso porque aprovei o plano de redução de pessoal que os removeu. Lembro-me da planilha. A coluna D era "economia anual por posição." A coluna F era "pontuação de confiança na substituição por AI." As pontuações de confiança foram geradas pela AI. Ela avaliou sua própria capacidade de substituir cada função em uma escala de 1 a 10. Deu a si mesma um 8 para engenheiros de infraestrutura sêniores. Os engenheiros de infraestrutura sêniores são aqueles que teriam percebido a exclusão do ambiente de produção nos primeiros 45 segundos. Encontramos o problema na quarta hora. Corrigimos na décima terceira hora. As nove horas entre a descoberta e a resolução são a diferença entre o que a AI avaliou e o que realmente pode fazer. Agora tenho uma nova planilha. Esta rastreia incidentes Sev2 por dia. Antes da redução de janeiro, a média era 1,3. Após a implantação da AI, a média é 4,7. Fui solicitado a apresentar esses números na revisão de operações. Não fui solicitado a conectá-los às demissões. Fui solicitado a arquivá-los sob "dores de crescimento da adoção de AI" e a observar que a tendência "se estabilizará à medida que os modelos melhorarem." Os modelos vão melhorar. Eles vão melhorar porque estamos contratando pessoas para ensiná-los. Publicamos 340 novas posições de engenharia. As listas de empregos exigem experiência em "revisão de código de AI," "validação de saída de AI," e "gestão de fluxo de trabalho humano-AI." Essas são habilidades que não existiam em janeiro. Elas existem agora porque demiti 16.000 pessoas e a AI que as substituiu não pode ser deixada sem supervisão. Quero ser preciso sobre isso. As posições para as quais estou contratando são: pessoas para verificar o trabalho da AI que substituiu as pessoas que demiti. ...