SVP da Amazon escreveu 100.000 linhas sem aprovação

Um voo para Seattle, e 100.000 linhas depois de 25 anos de pausa

Beth Galetti, vice-presidente sénior da Amazon para People Experience and Technology, passou 25 anos a liderar as equipas que gerem engenheiras e engenheiros de software sem escrever ela própria uma linha de código, e esta semana o próprio blogue corporativo da Amazon disse que já escreveu mais de 100.000 linhas com uma ferramenta interna de IA chamada Kiro. Galetti descreveu o regresso em termos pessoais: "Sabem como é libertador perceber que, depois de 25 anos sem programar, ainda se consegue construir algo?" O seu primeiro projeto foi uma aplicação de calendário familiar, pensada para a sua própria casa e não para o negócio da Amazon.

A história maior é a que a Amazon escolheu publicar em torno dela. Galetti escreveu a sua candidatura para um concurso interno chamado Everyone Can Build durante um voo para Seattle, e o concurso atraiu mais de 1.500 colaboradores em poucas semanas. A publicação da Amazon destacou outras candidaturas no mesmo espírito: uma pessoa automatizou um processo manual de quatro horas para um segundo, outra construiu por diversão um animal de estimação digital chamado Momo, sem qualquer finalidade de negócio.

A Amazon não esconde para que serve isto. A publicação liga o regresso de Galetti à programação diretamente ao Future Ready 2030, o compromisso de 2,5 mil milhões de dólares acabado de anunciar com o qual a Amazon quer preparar mais de 50 milhões de pessoas para o futuro do trabalho, incluindo mil milhões de dólares destinados ao já existente programa educativo Career Choice, além de formação gratuita em IA e certificação AWS para todos os colaboradores da Amazon. A aplicação pessoal de uma dirigente sénior tornou-se o rosto humano de um orçamento de formação enorme.

Cinco meses antes, os próprios engenheiros da Amazon receberam a instrução contrária

Lido a par do memorando interno que a organização de engenharia da Amazon distribuiu em março de 2026, a celebração parece apenas metade da história. Cinco meses antes da publicação sobre Galetti, a Amazon exigiu às suas engenheiras e engenheiros de software formados, não a quem programava pela primeira vez, a aprovação de uma pessoa sénior antes de lançar qualquer código com o qual uma ferramenta de IA tivesse ajudado a escrever.

O gatilho foi uma série de falhas ligadas ao que as comunicações internas da Amazon chamaram alterações assistidas por IA generativa com um raio de impacto elevado, um padrão que o memorando fazia remontar ao terceiro trimestre de 2025. Em dezembro de 2025, uma falha da AWS durou 13 horas depois de a ferramenta Kiro ter sido autorizada a alterar infraestrutura sem revisão humana, tendo decidido sozinha apagar e recriar um ambiente. No início de março de 2026 seguiram-se mais dois incidentes em três dias: um custou cerca de 120.000 encomendas e gerou 1,6 milhões de erros no site, o outro fez cair o volume de encomendas na América do Norte em 99 por cento, com 6,3 milhões de encomendas perdidas segundo o relatado. O vice-presidente sénior da Amazon Dave Treadwell disse claramente às equipas que a disponibilidade do site e da infraestrutura associada não tinha sido boa recentemente.

A TechRadar noticiou a política resultante, citando um memorando interno obtido pelo Financial Times: engenheiras e engenheiros júnior e de nível intermédio têm agora de obter a aprovação de uma pessoa sénior antes de qualquer alteração de código assistida por IA ser lançada, no âmbito de uma reposição de segurança do código de 90 dias que abrange cerca de 335 sistemas críticos de retalho, com revisão a duas pessoas e controlos automatizados mais rigorosos. A Amazon contestou parte da versão apresentada, classificando pelo menos um incidente como um erro humano de controlo de acesso, mas manteve em vigor a própria exigência de aprovação.

Um calendário de família e uma caixa registadora não carregam o mesmo risco

A diferença entre a aplicação de Galetti e o código que despoletou as falhas da Amazon nunca esteve em quem escreveu a instrução à IA, mas sim no que o código resultante podia tocar. Uma aplicação de calendário familiar e uma candidatura a um concurso interno não leem nem escrevem nada que pertença a um cliente, e nada do que fazem chega ao público pagante da Amazon.

A política de março visava uma categoria mais restrita: código escrito com IA a correr dentro de sistemas de produção que processam encomendas, preços e contas de clientes reais, a uma escala em que uma única implementação defeituosa elimina milhões de transações em horas. Essa categoria precisa de uma segunda pessoa formada a rever antes do lançamento, seja quem, ou o que, tiver escrito o primeiro rascunho.

O limiar que a Amazon traçou para si própria é a parte desta história que se pode transpor. A empresa continuou a usar o Kiro e continuou a incentivar quem não é engenheiro a construir. Só acrescentou uma revisão humana quando o código chegava à produção, tocava dados de clientes, ou tinha um raio de impacto suficientemente grande para importar.

A decisão que todo o empresário tem agora pela frente

Para quem dirige uma empresa e vê uma responsável de marketing ou um responsável financeiro a construir as suas próprias ferramentas com um assistente de programação de IA, a questão não é se deve permitir isso, o próprio ano da Amazon já respondeu a essa pergunta. A decisão está em onde colocar a linha que a Amazon fixou em 335 sistemas de produção e uma aprovação sénior obrigatória.

Abaixo dessa linha, deixe as pessoas construir. Uma automatização de folhas de cálculo, um painel interno alimentado com dados a que quem o constrói já tem acesso legítimo, uma ferramenta pessoal de calendário como a de Galetti, nada disso precisa de um processo formal de revisão, e exigi-lo na mesma só ensina as equipas a construir em silêncio em vez de perguntar.

Acima dela, aplique diretamente a própria regra da Amazon. No momento em que uma ferramenta criada com IA por alguém sem perfil técnico for tocar numa base de dados de produção, tocar em dados reais de clientes, ou ficar acessível a partir de fora da empresa, exija a aprovação de uma pessoa técnica qualificada antes de entrar em produção, segundo o mesmo critério que a Amazon acabou de aplicar internamente em 2026. Se ninguém na equipa conseguir realmente fazer essa revisão, coloque o lançamento em pausa até haver alguém qualificado.

O que verificar antes de a próxima ferramenta feita com IA entrar em produção

Comece esta semana por listar todas as ferramentas criadas com IA fora da equipa de engenharia no último trimestre, e faça uma pergunta a cada uma: toca em dados de produção, num cliente pagante, ou num sistema acessível a partir de fora da empresa. Um sim em qualquer um desses pontos exige a mesma aprovação que a Amazon agora exige aos seus próprios engenheiros, seja quem for na empresa a tê-la construído.

Ponha um nome por trás da aprovação, não apenas um documento de política. A solução da Amazon funciona porque uma pessoa sénior concreta tem de associar o seu nome a uma alteração concreta antes de esta ser lançada, e uma regra sem uma pessoa revisora identificada é um memorando, não uma barreira.

Leia a seguir: A nova cifra padrão da Ring não é o que parece  |  A equipa europeia da DuckDB já está na AWS