Na Amazon, alguns desenvolvedores dizem que seu trabalho começou a se parecer com o de um depósito

• Desenvolvedores da Amazon estão enfrentando pressão por velocidade e simplificação do trabalho após a adoção de IA
• Gestores estão recomendando fortemente o uso de ferramentas de IA com o argumento de aumentar a produtividade
• Alguns veem que a redução de tarefas repetitivas melhorou a qualidade do trabalho, mas também há preocupação de que desenvolvedores juniores estejam perdendo oportunidades de crescimento
• À medida que programar deixa de ser um ato de criação direta e passa a ser um trabalho centrado em revisão e verificação, alguns dizem sentir que o trabalho já não parece seu
• Grupos internos como Amazon Employees for Climate Justice estão compartilhando preocupações sobre estresse no trabalho e ansiedade em relação ao futuro, incluindo esse problema

---

At Amazon, Some Coders Say Their Jobs Have Begun to Resemble Warehouse Work

Até a programação entrou na era da “corrida por velocidade”

• O fenômeno de simplificação das funções causado pela mecanização, repetido desde a Revolução Industrial, também está acontecendo na área de programação
• A IA, em vez de eliminar empregos, está transformando funções existentes em trabalho mais simples e mais rápido de executar
• Segundo pesquisa da Microsoft, a produtividade de desenvolvedores que usam o assistente de IA Copilot aumentou mais de 25%
• A Amazon adotou essa tendência e está exigindo trabalho mais rápido e mais eficiente com IA, destacando isso em sua carta aos acionistas como ponto central para redução de custos e manutenção da competitividade
• Por exemplo, uma equipe de desenvolvimento está operando com metade do tamanho do ano passado, mas ainda precisa entregar o mesmo volume de código

Tendência em todo o setor

• A Shopify definiu o uso de IA como requisito básico para todos os funcionários e afirmou que isso também será refletido na avaliação de desempenho
• O Google vem adotando em hackathons internos o tema de desenvolver ferramentas de IA para aumentar a produtividade do dia a dia. Já mais de 30% do código é gerado a partir de sugestões de IA

Lado positivo e preocupações

• Alguns gestores afirmam que, com a introdução da IA, tarefas repetitivas e tediosas diminuem, permitindo foco em trabalho mais criativo
• A Amazon afirmou que, graças à IA, economizou o equivalente a 4.500 anos de trabalho de desenvolvimento
• No entanto, o economista de Harvard Lawrence Katz aponta que isso elimina oportunidades de crescimento profissional para desenvolvedores iniciantes
• Assim como a antiga “corrida por velocidade” vivida por trabalhadores de fábrica no passado, desenvolvedores também estão sendo pressionados a fazer mais, mais rápido

As mudanças percebidas pelos desenvolvedores

• Assim como nos centros logísticos da Amazon, desenvolvedores também sentem a automação e a divisão de tarefas causadas pela IA
• O uso de IA é uma “escolha”, mas na prática se torna quase obrigatório para atingir metas de desempenho
• O desenvolvimento de funcionalidades que antes levava semanas agora precisa ser concluído em poucos dias, e para isso houve redução no tempo de reuniões e ampliação do uso de código gerado por IA
• A IA já consegue até gerar programas inteiros, mas o trabalho de ler e revisar código aumentou, reduzindo a diversão e o nível de imersão

Crescimento de carreira e queda de engajamento

• Desenvolvedores juniores podem perder a chance de entender o código em profundidade por causa da automação de testes
• A IA dá suporte em várias tarefas, como redação de documentos de planejamento e testes de código, mas o ambiente está mudando para uma avaliação centrada em ferramentas, e não em pessoas
• Harper Reed, ex-CTO da campanha de Obama, diz que estamos entrando em uma era em que não é mais necessário entender profundamente todas as partes, descrevendo isso como uma mudança semelhante à da manufatura
• Por outro lado, Simon Willison avalia a IA de forma positiva por acelerar a velocidade de transformar ideias em realidade

Insatisfação e reação organizacional

• Devido ao uso de IA e às mudanças no trabalho associadas a isso, muitos desenvolvedores estão compartilhando ansiedade e estresse no grupo Amazon Employees for Climate Justice
• Há preocupação especialmente com a queda na qualidade do trabalho e a incerteza sobre a carreira, algo semelhante ao estresse da antiga corrida por velocidade sentida por operários da indústria automobilística
• Ainda não há movimento pela formação de um sindicato de desenvolvedores, mas o consenso interno dentro da organização está se ampliando

Contexto histórico e perspectivas futuras

• Como na greve da GM de 1936, questões de ritmo de trabalho e autonomia podem se tornar catalisadoras de ação dos trabalhadores
• No passado, as pessoas podiam ajustar a forma e o ritmo de trabalho, mas agora o sistema mudou para um modelo em que todo o processo é monitorado e avaliado com foco em velocidade

[GN⁺]

Comentários no Hacker News

• conteúdo compartilhado do link archive.ph/HVZRL
• Para mim, desenvolvimento com base em LLM parece um hype exagerado, como cripto ou VR. Ao corrigir recentemente bugs em um codebase escrito com vibe coding, senti que esse método é um tipo de amontoado caótico em que problemas de negócio sem sistematização são passados para o código sem estrutura. Como as partes que precisam de melhoria vão sendo remendadas com patches estreitos, o resultado é a geração de código complexo e desorganizado. Quando bate no limite da context window, o LLM nem consegue lembrar dos próprios patches. O inglês (ou a linguagem humana) é ambíguo demais para descrever com precisão o código que eu quero, e transformar em prompt todo o conjunto de experiência e tentativa e erro que um desenvolvedor sênior embutiu no código é um trabalho extremamente pesado. Ao contrário de "por que isso foi feito assim", existe a diferença de precisar de uma lista imensa, específica e sem fim de "nessa situação não faça assim, faça assado"
  • É uma observação que bate exatamente com a descrição da maioria dos codebases que vi nos últimos 30 anos, exceto um único caso
  • Contra-argumento — também já houve casos em que a IA ajudou a encontrar padrões de código em cerca de 30 lugares dos quais era preciso extrair estrutura. Acho que o problema do vibe coding é a atitude. Quem tenta evitar programar diretamente tende a focar só na conveniência do momento, em vez da estrutura e da qualidade de longo prazo; parece uma espécie de amplificador de preguiça
  • Na prática, muito código de produção é um conjunto de fragmentos e snippets que vão funcionando à base de remendos. A realidade triste é que as CPUs são tão rápidas que até esse tipo de código simplesmente roda
  • Concordo com a crítica de que a linguagem humana não é clara. No fim, já tentaram várias vezes lidar com software de forma clara por meio de linguagem natural e, assim como no direito, as interpretações em zonas cinzentas nunca acabam. Se no futuro os desenvolvedores tiverem que discutir o significado de um programa antes de compilar, esse futuro é sombrio
  • Faz sentido ver a IA como um hype tão exagerado quanto cripto ou VR. Mas até profissões altamente técnicas, como engenharia de software, acabarão sendo afetadas pela automação. Nos últimos 10 anos, o pessoal de tecnologia achou que isso não tinha nada a ver com os problemas de outros trabalhadores, mas com a cultura de enxugamento e demissões, a contenção salarial agora começou de verdade. Mesmo que a IA não substitua tudo de uma vez, se um trabalho que antes era feito por 5 pessoas passar a ser feito por 4 com ajuda de IA, 1 pessoa é cortada, e quem fica também perde margem para pedir aumento. É um padrão que se repete. A ideia é que o pessoal de tecnologia precisa perceber que também é trabalhador
• Sobre a opinião de Harper Reed de que “não é necessário entender profundamente o código”, esse tipo de fala soa mais como uma lógica improvisada de “se compila, vamos pôr em produção”. Numa linha de automação, a qualidade é medida o tempo todo, mas as máquinas reais não têm alucinações como errar o ângulo ou fazer uma solda absurda; já o software baseado em LLM repete esse tipo de pequeno erro
• Fico em dúvida se ferramentas baseadas em LLM realmente aumentaram de forma dramática a produtividade dos desenvolvedores, ou se as organizações só descobriram que conseguem funcionar com menos desenvolvedores — e menos privilegiados do que antes. Também não vejo muitos casos de “ganho revolucionário de produtividade” dentro de big techs, e até agora o cenário parece ser apenas algum ganho de produtividade suficiente para compensar o investimento
  • Em grande parte, é um problema de percepção. Antes, desenvolvimento era visto como algo difícil, mas com as ferramentas de IA surgiu a sensação de que a barreira de entrada para programar caiu. O desenvolvimento de software está parecendo cada vez mais trabalho de fábrica, e o retorno intelectual diminuiu
  • Há dúvidas sobre a manutenibilidade de longo prazo do codebase. O vibe coding vai acumulando complexidade, bugs sutis e problemas de abstração, elevando no fim a dificuldade de manutenção e de desenvolvimento de novas funcionalidades. Existe o risco de ficar preso ao aumento de produtividade de curto prazo e sofrer queda de qualidade no longo prazo
  • As organizações já vêm há muito tempo tentando “se afastar da técnica” por meio de processos burocráticos, isto é, substituir mão de obra mais qualificada por padronização com pessoal menos especializado. É uma estratégia que pode ser venenosa no longo prazo, mas, desde que haja consistência, acabam se acomodando com soluções “razoavelmente utilizáveis”
  • Para essa lógica ser convincente, seria preciso assumir que a diretoria da Amazon valoriza mais o lucro de curto prazo do que a qualidade de longo prazo, mas não tenho certeza disso
• Como alguém prestes a se aposentar, fico desolado com as mudanças recentes. Quando comecei nos anos 90, havia tempo para mergulhar por longos períodos em experimentação e criatividade. Hoje, tarefas unitárias, relatórios de status e justificativas constantes são obrigatórios. Ainda haverá desenvolvedores interessantes no futuro, mas essas oportunidades estão diminuindo. Na verdade, estamos apenas seguindo o mesmo caminho de outras profissões cuja vida ficou mais difícil com a automação, então é um resultado justo
  • Relatórios cotidianos de status, como stand-up, tomam tempo e no fim são apenas uma resposta protocolar para ganhar mais um dia de liberdade de pessoas que não entendem meu trabalho, o que desvaloriza o trabalho em si
  • Eu também entrei nos anos 90 e me identifico com esse controle minucioso baseado em JIRA. Mas não acho que o passado tenha sido necessariamente uma era de ouro. Talvez exista também um reforço de nostalgia, lembrando só das boas experiências. Ainda assim, hoje também existem trabalhos bons, desafiadores e cheios de aprendizado
  • Mais do que automatizar vagas de engenharia, a direção parece ser substituir, na prática, cargos de gestão por vigilância centrada em IA
• Para acelerar drasticamente o desenvolvimento de software, também existe o método de copiar e usar diretamente o código open source de alguém e aplicar isso removendo os rastros de copyright/licença. Se tiver medo de ser pego diretamente, dá para usar uma terceirizada para “lavar” isso, ou hoje em dia até usar IA para lavar de forma barata e rápida. O Google antes se continha nesse tipo de comportamento e faltava ousadia. Mas startups pequenas buscam sucesso rápido usando IA e ignorando o risco de violação de direitos autorais
  • No setor em que trabalho, o problema maior muitas vezes não é a falta de código, e sim definir “o que” e “como” deve ser feito. Também há muitos problemas específicos que não se resolvem com Stackoverflow ou Github
  • Na verdade, o Google já fazia isso antes ao raspar conteúdo de sites e exibi-lo diretamente nos resultados de busca, aproveitando conteúdo alheio sem gerar tráfego. Agora ele só chegou atrasado de novo
  • Ironicamente, alguns dizem que até gostariam que grandes empresas plagiassem código open source, porque é melhor isso do que serem obrigados, como usuários, a usar os métodos frios e ineficientes que essas empresas criam por conta própria
  • Concordo com os limites de colocar código em open source. Grandes empresas tendem a incentivar open source como forma de obter trabalho gratuito. Mesmo que as contribuições caiam no curto prazo, talvez o setor fique mais saudável no longo prazo
  • Crítica à irresponsabilidade em torno da chegada do ChatGPT e da liderança de Sam Altman
• Achei marcante a fala de Simon Willison de que ler código é mais difícil e menos divertido do que escrevê-lo, assim como o caso de um desenvolvedor da Amazon em que a IA está ajudando bastante em trabalhos acessórios, como documentação e testes. Agora o papel está mudando para algo mais focado em revisão de código existente e correção de bugs do que em programar do zero
  • Lembrei de como era divertido escrever código no começo. Hoje, corrigir bugs é mais divertido, e o LLM assume a programação repetitiva simples, o que permite focar em desafios. Graças ao LLM, uma parte da diversão do desenvolvimento sobrevive
  • O clima que este texto transmite é bastante negativo
• Quando surge uma nova tecnologia de produtividade, as empresas rapidamente capturam o efeito e o padronizam. Para continuar acompanhando, é preciso estudar sem parar e, em algum momento, considerar a transição para um ambiente em que você mesmo fique com os ganhos do próprio crescimento, como trabalho autônomo. Mas trabalhar sozinho também significa competir com pessoas habilidosas no uso de IA, então não existe solução fácil
  • Prevejo três cenários futuros. 1) Os codebases entram cada vez mais em colapso, com caos e instabilidade, e no fim talvez seja preciso trazer de volta desenvolvedores experientes por um preço alto. 2) A IA produz código mais ou menos utilizável, com baixa qualidade e confiabilidade, mas sem grandes desastres. 3) A IA fica rapidamente inteligente a ponto de o próprio conceito de codebase desaparecer, dando lugar a um software gerado e evoluído dinamicamente conforme a necessidade. Os LLMs atuais ainda estão muito longe disso. Executivos acreditam no cenário 3, mas por enquanto o real está entre 1 e 2. Se houver boa gestão, talvez seja possível caminhar para a visão equilibrada do cenário 2
  • Também existem modelos em que os ganhos de produtividade são distribuídos de forma mais justa. Como na Europa de antes, com redução da jornada de trabalho. Hoje em dia, até os trabalhadores parecem presos a tarefas misteriosas que só servem para parecer ocupados
  • Você está basicamente descrevendo uma visão marxista, e é curioso que a conclusão acabe caindo em autoalienação. Com um pouco de esforço conjunto, isso poderia melhorar, mas não acontece
  • Em vez de aceitar que é preciso viver em autoaperfeiçoamento constante para sempre, também existe a opção de se unir a outras pessoas da sociedade e exigir coisas coletivamente dos empregadores. Semana de 5 dias, jornada de 8 horas e proibição do trabalho infantil também foram conquistas de ação coletiva. Não é preciso apenas se dedicar ao próprio trabalho e torcer para o resto dar certo
• Sempre me surpreende como nosso setor está ficando infantilizado. Quem já trabalhou em grandes empresas e grandes codebases sabe que gerar código novo é uma parte pequena do desenvolvimento
  • Na prática, além do código novo, outras partes acessórias também são ineficientes nas grandes empresas. Talvez a IA mude isso também e reduza reuniões intermináveis ou discussões abstratas
  • Muitos dos que estão empolgados agora, na verdade, são pessoas que ficaram travadas nos paradigmas mais recentes e passaram a ter dificuldade até para escrever código. Com ferramentas LLM como Copilot, fazem um POC rápido e já empurram isso para produção sem pensar profundamente em qualidade, escalabilidade etc. E essas pessoas acabam anunciando sem questionamento os supostos ganhos de produtividade da IA, repetindo argumentos alinhados ao interesse das grandes empresas. Quem usa de verdade no dia a dia sabe que há várias limitações
  • Eu também passo só uns 20% do tempo codando; o resto vai para levantamento de requisitos, design, testes e gestão de cronograma. Se esse trabalho de código, que é 20%, cair pela metade, talvez eu consiga usar o tempo restante para testar mais ou documentar melhor
• Existe uma ilusão de que a ajuda de LLM vai aumentar drasticamente a eficiência de desenvolvimento. Na verdade, só quando há base técnica forte é possível elevar a produtividade sem perder qualidade. Ou seja, para os experientes isso funciona como amplificador de produtividade, mas entregar LLMs para um exército ampliado de iniciantes não leva facilmente a software de qualidade
  • Esse argumento se repete, mas a questão importante é onde fica a linha de corte da “qualidade”. Na prática, conheço uma equipe jovem de estudo em desenvolvimento em que um amigo de SRE faz revisão semanal e eles usam LLM ativamente; a qualidade e a escalabilidade do código são boas o suficiente. A velocidade é baixa, mas o resultado não é ruim
  • Só uma parte dos casos realmente precisa de software “bom”, e olhando para o modelo de receita de consultorias como Deloitte e Accenture, a maioria das empresas nem liga para qualidade. Para a maior parte, um software “plausível” já basta