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. Algumas delas são as mesmas pessoas. Sei disso porque reconheço seus nomes no sistema de rastreamento de candidatos. Eles se candidataram em janeiro. Foram rejeitados porque seus cargos foram marcados para "transformação de AI." Eles estão se candidatando novamente em março, para os novos cargos, que existem porque a transformação de AI quebrou coisas. Seus currículos agora incluem "experiência em revisão de código de AI." Eles adquiriram essa experiência nas oito semanas entre serem demitidos e se candidatarem novamente — o que significa que a adquiriram em seus empregos temporários, onde estão revisando código gerado por AI para outras empresas que também demitiram pessoas e também implantaram AI que também quebraram coisas. O mercado criou uma nova categoria de trabalho: babá humana de AI. O trabalho é sentar ao lado da máquina que deveria eliminar seu emprego e garantir que ela não delete a produção. Participei de uma conferência no mês passado. Um painel foi intitulado "A Organização de Engenharia Aumentada por AI." Os painelistas descreveram como a AI aumenta a produtividade dos desenvolvedores em 40 por cento. Eles não mencionaram que também aumenta os incidentes Sev2 em 261 por cento. Quando perguntei sobre isso na sessão de perguntas e respostas, o moderador disse que a pergunta era "reducionista." A interrupção de 13 horas que custou cerca de 180 milhões de dólares em receita foi, aparentemente, uma redução. O conselho está satisfeito. O número de funcionários caiu 22 por cento. Os custos operacionais por unidade de produção de engenharia diminuíram. A métrica não leva em conta a interrupção de 13 horas, porque a interrupção é categorizada como "infraestrutura" e a produtividade de engenharia é categorizada como "desenvolvimento." Essas são linhas orçamentárias diferentes. Em linhas orçamentárias diferentes, causa e efeito não se encontram. Fui promovido. Meu novo título é SVP de Excelência em Engenharia Centrada em AI. Reporto-me diretamente ao CTO. O CTO enviou um e-mail para toda a empresa na semana passada que dizia que estamos "construindo o futuro do desenvolvimento de software." Ele não mencionou que o futuro do desenvolvimento de software atualmente requer a aprovação de um engenheiro sênior para cada pull request porque a AI não pode ser confiada para tocar a produção sozinha. O ciclo está completo. Demitimos os humanos. Implantamos a AI. A AI quebrou coisas. Estamos contratando humanos para vigiar a AI. Os humanos que estamos contratando são os humanos que demitimos. Estamos pagando a eles mais, porque "revisão de código de AI" é uma habilidade especializada. Criamos a especialização. Criamos a necessidade da especialização. Estamos nos congratulando por atender à demanda que fabricamos. Minha próxima apresentação ao conselho é na terça-feira. O título é "Transformação de AI: Resultados do Primeiro Ano." O slide 4 mostra a redução de pessoal. O slide 7 mostra o novo fluxo de trabalho aumentado por AI. Entre os slides 4 e 7 não há um slide explicando por que as pessoas no slide 7 são necessárias. Esse slide não existe. Fui solicitado a removê-lo na execução geral. A jornada tem uma interrupção de 13 horas no meio dela. Mas o número de funcionários é menor, e esse é o número no slide.

No ano passado, publiquei 500 vagas abertas para a minha empresa. Contratámos 34 pessoas. As outras 466 vagas nunca foram reais. Sou o Chefe de Aquisição de Talentos. Isso não é o que eu adquiro. O que eu adquiro é dados. Currículos, expectativas salariais, conjuntos de habilidades, inteligência de mercado. 160.000 candidatos deram-nos o seu histórico profissional de graça. Usámos isso para comparar compensações. Não para aumentar salários. Para confirmar que estávamos a pagar abaixo do mercado e a safar-nos com isso. Eu chamo isso de "construir um pipeline de talentos." Um pipeline é algo que se constrói e nunca se ativa. Os recrutadores chamam isso de "sourcing passivo." Não há nada de passivo em desperdiçar o tempo de 160.000 pessoas. Mas soa como uma estratégia. Algumas das nossas listagens estão publicadas há 11 meses. Uma está no ar há dois anos. É para um "Diretor de Inovação." Não temos um departamento de inovação. Não temos o orçamento. Mas a listagem faz-nos parecer que estamos a crescer. Os investidores veem vagas abertas e pensam em momentum. As nossas ações subiram 8% depois de publicarmos 200 empregos em uma semana. Não contratámos ninguém naquela semana. Ou na semana seguinte. Temos um sistema de rastreamento de candidatos. Ele rejeita automaticamente 95% dos candidatos. Baseado em palavras-chave. Não sei quais palavras-chave. Ninguém sabe. Foi configurado em 2019 por um contratado que já não trabalha aqui. Nunca o atualizámos. Alguns candidatos passam horas personalizando os seus currículos. O sistema lê-os por seis segundos. Depois envia um e-mail de rejeição. "Após cuidadosa consideração." Não houve consideração. Cuidadosa ou de outra forma. Eu sei disso porque fui eu quem escreveu o modelo. Às vezes, eu republico o mesmo emprego com um título diferente. "Analista de Dados Sênior" torna-se "Líder de Análise de Dados." Mesma descrição. Mesma salário. Mesma ninguém sendo contratado. Mas isso redefine a data de publicação. Listagens frescas recebem mais candidatos. Mais candidatos significam mais dados. Mais dados significam melhor benchmarking. Melhor benchmarking significa que eu apresento na revisão trimestral. Eu apresentei no último trimestre. Mostrei um slide que dizia que recebemos "um interesse sem precedentes de candidatos." 160.000 pessoas candidataram-se a empregos que não existiam. Esse é o interesse sem precedentes. O VP de Pessoas chamou isso de "força da marca." O CFO perguntou sobre a nossa eficiência de contratação. Eu disse que estávamos "otimizando para qualidade em vez de velocidade." Qualidade significa que não contratámos ninguém. Velocidade significa que não planejamos fazê-lo. O RH perguntou sobre a experiência do candidato. Eu mostrei-lhes a nossa pontuação NPS. Era 12. De 100. Eu disse que isso estava "dentro da faixa da indústria." Eu inventei a faixa da indústria. Ninguém verificou. Eles nunca verificam. No mês passado, uma candidata enviou-me um e-mail diretamente. Ela disse que se candidatou a quatro funções ao longo de oito meses. Personalizou cada currículo. Escreveu cada carta de apresentação. Nunca recebeu resposta. Ela perguntou se os empregos eram reais. Eu a enviei para as perguntas frequentes automatizadas. As perguntas frequentes dizem "Valorizamos cada candidatura." Isso não é verdade. Valorizamos cada ponto de dados. Há uma diferença. Estou a caminho de uma promoção. Os meus métricas são excepcionais. 500 funções publicadas. 160.000 candidatos capturados. Custo por aquisição: $0. Não adquiri ninguém. Mas o custo foi zero. Zero é um bom número em um painel. Painéis são apresentados. Apresentações são aprovadas. Aprovações fazem-me ser promovido. Serei VP de Talentos até o Q4. Não encontro talentos. Coleciono-os. Como um frasco que nunca se abre.

No mês passado fundei uma startup de AI. Não sei programar. Isso costumava ser um problema. Agora é uma "vantagem do fundador." Eu me chamo de "vibe coder." Isso significa que eu descrevo o que quero para um LLM e colo o que quer que ele me dê. Eu não leio. Ler código é para pessoas que escrevem código. Eu escrevo prompts. Meu primeiro prompt foi "construa-me uma plataforma SaaS." Ele construiu algo. Eu implantei. Não sei onde. Mas tem uma URL e isso é suficiente para uma rodada de seed. Levantei $2,3 milhões. O pitch deck dizia "arquitetura nativa de AI." Isso significa que Claude escreveu tudo. Tudo. A arquitetura. O deck. As projeções financeiras. Eu pedi "faça as projeções parecerem ambiciosas, mas críveis." Ele alucina um ARR de $40M no segundo ano. Isso não é crível. Mas os VCs não fazem matemática. Eles fazem vibes. Daí o termo. Meu CTO sou eu também. Coloquei isso no LinkedIn. "Fundador não técnico atuando como CTO." Alguém comentou "isso é corajoso." Não é corajoso. É só que engenheiros custam $200K e prompts custam $20 por mês. Eu tenho 14.000 linhas de código. Não li nenhuma delas. Mas pedi ao Claude para "revisar o código quanto à qualidade." Ele disse que o código era "bem estruturado e limpo." Ele escreveu o código. Claro que ele disse isso. É como perguntar ao seu cabeleireiro se você precisa de um corte de cabelo. Um pesquisador de segurança me mandou uma DM. Disse que meu app tinha uma vulnerabilidade de travessia de caminho. Eu não sabia o que isso significava. Colei a mensagem dele no Claude. Claude disse "isso é uma preocupação de segurança séria." Eu pedi "conserte isso." Ele mudou algo. Eu implantei. O pesquisador me mandou outra DM. Ele disse que eu tinha introduzido mais três vulnerabilidades. Eu o bloqueei. Problema resolvido. Essa é a mentalidade de fundador. Contratei meu primeiro funcionário. Também um vibe coder. O currículo dele dizia "construiu mais de 200 aplicações." Ele quis dizer que clicou em "aceitar" no Cursor 200 vezes. Mas isso é experiência agora. Nós programamos em par. Isso significa que sentamos um ao lado do outro e pedimos ao mesmo LLM de laptops diferentes. Às vezes recebemos respostas diferentes. Escolhemos aquela que roda sem um erro visível. Visível está fazendo muito trabalho nessa frase. Não temos testes. Testes são para código que você entende. Temos "confiança." Confiança significa que carregou uma vez no Chrome. Nós lançamos em produção numa sexta-feira. Todo mundo disse para não lançar na sexta. Mas não temos monitoramento. Então todo dia é o mesmo. Se um servidor cai na nuvem e ninguém está olhando os logs, ele faz barulho? Filosoficamente não. Financeiramente também não. Porque não temos logging também. Um cliente relatou que o app estava "vazando dados." Eu disse "vazando é uma palavra forte." Ele disse que suas chaves de API estavam visíveis no código fonte da página. Eu disse "isso é um recurso para usuários avançados." Ele cancelou. Eu marquei como churn devido à "recalibração do ajuste produto-mercado." Processamos pagamentos. Eu pedi ao Claude para "adicionar Stripe." Ele adicionou Stripe. Eu acho. O dinheiro chega em algum lugar. Na maioria dos meses chega na nossa conta. Eu não pergunto sobre os outros meses. Nosso banco de dados não tem autenticação. Eu não pedi por isso. O LLM não sugeriu. Estamos em um relacionamento aberto com os dados dos nossos usuários. Eles só não sabem ainda. Alguém encontrou nosso banco de dados no Shodan. Eu não sabia o que era Shodan. Agora eu sei. Assim como 40.000 outras pessoas. Incluindo nossos usuários. Ex-usuários. Eu fui a um podcast. O anfitrião perguntou sobre meu "stack tecnológico." Eu disse "principalmente Claude e qualquer pacote npm que ele sinta vontade de instalar." Ele riu. Eu não estava brincando. Há 847 dependências no nosso package.json. Não reconheço nenhuma delas. Uma delas é de 2016 e não foi atualizada desde então. Provavelmente está tudo bem. "Provavelmente está tudo bem" é nosso SLA interno. Fomos aceitos em um acelerador. A aplicação perguntava sobre nosso "moat." Eu disse "velocidade de execução." Velocidade de execução significa que posso produzir bugs em massa mais rápido do que qualquer um pode encontrá-los. Isso é tecnicamente um moat. O dia da demonstração é na próxima semana. Eu preciso que o app funcione por onze minutos. Depois disso, pode fazer o que quiser. Geralmente faz. Estou levantando uma Série A. $12 milhões. O deck diz "construído por uma equipe de engenheiros de elite." A equipe sou eu, um cara que também não sabe programar, e um LLM que não sabe que estamos em produção. Mas nos movemos rápido. Quebramos coisas. Principalmente nossas próprias coisas. Às vezes coisas de outras pessoas. Vamos descobrir a diferença depois. Ainda não sei programar. Mas tenho uma fábrica de responsabilidade que produz em massa e funciona algumas vezes. Em 2026, isso é chamado de empresa. E o gráfico sobe e para a direita. Porque pedi ao Claude para garantir que isso aconteça.