[Editor’s Note: Agents of Transformation is an independent GeekWire series, underwritten by Accenture, exploring the adoption and impact of AI and agents. See coverage of our related event.]
A Amazon é lendária por seu processo de “trabalhar de trás para frente”. Comece com um problema do cliente, think about um futuro em que ele será resolvido, elabore um comunicado à imprensa e perguntas frequentes como se já tivesse acontecido, fique obcecado com o documento até que esteja certo e então torne-o realidade.
Mas em algum momento do ano passado, ocorreu Swami Sivasubramanianvice-presidente de IA de agência da Amazon Internet Companies, que as novas ferramentas de codificação de repente tornaram mais fácil para suas equipes desenvolver uma demonstração – software program realmente funcional – do que escrever e aperfeiçoar o clássico “PRFAQ” de seis páginas da Amazon.
Então eles começaram a começar com o protótipo.
Se algo é “uma aposta de baixo risco em que queremos apenas provar nossa intuição, então eu realmente digo, vamos primeiro construir a demonstração e depois iterar”, disse Sivasubramanian em uma entrevista na semana passada, antes de seu discurso de abertura na quarta-feira no AWS New York Summit.
É uma ilustração de como as ferramentas de agência estão remodelando até mesmo as práticas e tradições mais arraigadas no native de trabalho. Mas é apenas uma das maneiras pelas quais a equipe de IA agente da AWS está se afastando das normas estabelecidas pela empresa e, de certa forma, retornando às suas raízes.
Dentro da Amazon, o CEO Andy Jassy diz que deseja que a empresa funcione como a maior startup do mundo. A divisão de Sivasubramanian pode ser a coisa mais próxima do que isso parece na prática.
De volta às duas pizzas
A divisão de IA agente da AWS está organizada em dezenas de pequenas equipes, muitas delas grandes o suficiente para alimentar duas pizzas. Esse foi o princípio organizacional em que a Amazon foi pioneira nos seus primeiros dias e que grande parte da empresa cresceu à medida que se expandia para 1,5 milhões de funcionários.
Quando Matt Garman, CEO da AWS, criou a IA de agência como sua própria divisão no ano passado, Sivasubramanian optou por equipes pequenas de propósito. Corresponde à nova realidade da period da IA: projetos que antes exigiam de 30 a 40 pessoas, disse ele, agora podem ser realizados por equipes de seis a oito.
Caso em questão: o aplicativo de desktop Amazon Fast, que se conecta ao e-mail, calendário, Slack, documentos e outros aplicativos de um usuário em um único espaço de trabalho e usa IA para pesquisá-los, responder perguntas e executar tarefas. É a entrada da Amazon em um mercado onde a Anthropic, a Microsoft, o Google e a OpenAI capturaram grande parte da atenção.
Suas raízes remontam ao closing de janeiro deste ano, quando Sivasubramanian disse que ficou claro para ele e para outros membros da equipe que os modelos subjacentes haviam se twister bons o suficiente para que o principal ingrediente que faltava fosse conectá-los aos sistemas onde as pessoas realmente trabalham.
Ele reuniu uma equipe de cerca de seis engenheiros para construí-lo. Seis semanas depois, 200 pessoas dentro da Amazon o usavam. Dez semanas depois, chegava a ten.000 internamente. A equipe voltou a escrever o PRFAQ depois que o produto já estava em beta, para ajudar a refinar sua abordagem para o lançamento externo. Eles foram enviados em 28 de abril, três meses depois de terem começado.
No sistema antigo – escrever o PRFAQ, encaminhá-lo através de camadas de revisão – a papelada por si só poderia levar tanto tempo quanto construir e enviar o produto actual.
Histórias semelhantes estão acontecendo em toda a divisão.
- Uma equipe abriu o código-fonte do Strands, um equipment de desenvolvimento de software program da AWS para a construção de agentes de IA, depois que um membro da equipe de Sivasubramanian lhe enviou uma mensagem às 7h com a ideia. Após uma rápida ligação com Garman, eles decidiram seguir em frente. Em poucos dias, estava feito.
- Kiro, a ferramenta de codificação de IA, foi construída por uma equipe deliberadamente pequena, usando o próprio Kiro para construí-la. Um engenheiro criou um protótipo de um recurso complexo de notificação multiplataforma para o Kiro, estimado em quatro semanas de trabalho, e o enviou em um dia e meio.
- A equipe interna da Amazon que reconstruiu o mecanismo de inferência para a plataforma Bedrock da empresa para modelos de IA fez isso com seis engenheiros em 76 dias, um projeto originalmente esperado para levar 30 desenvolvedores de 12 a 18 meses.
Equipes menores em todos os lugares
O que está acontecendo dentro da divisão de IA de agentes da Amazon faz parte de uma tendência em toda a indústria de tecnologia em direção a equipes menores e organizações mais planas, impulsionadas por IA e agentes.
O Índice de Tendências de Trabalho de 2026 da Microsoft, um inquérito realizado a 20.000 trabalhadores em 10 países, descobriu que o maior issue por detrás do impacto actual da IA no native de trabalho não são as competências individuais, mas sim se a organização se reestruturou em torno das novas tecnologias.
Vijaye Raji, CTO de aplicativos da OpenAI, disse durante um recente evento da Expertise Alliance que as “ambições da empresa estão crescendo mais rápido do que podemos contratar pessoas” – mas o perfil de quem é contratado está mudando. A OpenAI procura cada vez mais engenheiros que trabalham com ferramentas de IA de forma nativa, e a lacuna entre aqueles que o fazem e aqueles que não o fazem é grande: os principais engenheiros da OpenAI usam cerca de 100 vezes mais tokens de IA do que a mediana.
Tudo isto leva a uma questão pure: o que isto significa para o emprego? A Amazon cortou cerca de 30.000 empregos corporativos desde o closing de 2025, como parte do que Jassy descreveu como um esforço para reduzir a burocracia. Ele disse que espera que a IA diminua a força de trabalho corporativa ao longo do tempo.
Cortes semelhantes estão ocorrendo em todo o setor, do Meta ao Block e ao LinkedIn, à medida que as empresas repensam não apenas as funções que precisam preencher, mas também quantas pessoas precisam em geral.
Objetivos maiores, mesma equipe
Sivasubramanian descreve a mudança de forma diferente: Na sua divisão, o mesmo número de pessoas está agora a perseguir um estatuto maior. Com a nova estrutura, eles podem assumir mais projetos e com mais rapidez, realizando tarefas em semanas que no passado levariam muito mais tempo.
A natureza das funções dentro dessas equipes também está mudando. Cada vez mais, os gerentes de produto escrevem códigos e os engenheiros tomam decisões sobre os produtos. Na equipe Kiro, por exemplo, um gerente de produto construiu a primeira versão de um painel de análise de custos usando o próprio Kiro.
Isto também exige que os líderes operem de forma diferente. Por exemplo, Sivasubramanian disse que tem o cuidado de monitorizar quais as decisões que necessitam da sua aprovação, mesmo quando viaja. No ritmo atual, mesmo quatro ou cinco dias de atraso podem adicionar até 10% ao cronograma de entrega de uma equipe.
A gestão destas equipas também levanta novas questões. Sivasubramanian disse que sua divisão começou a monitorar quanto gasta em tokens de IA – a unidade básica de interação com um modelo de IA – da mesma forma que rastrearia qualquer outro custo operacional.
Até agora, os números têm sido administráveis: ferramentas como o Kiro investem antecipadamente na definição de especificações e na extração do contexto certo antes de gerar o código, o que os torna mais eficientes com tokens, em vez de queimá-los em idas e vindas sem rumo.
Mesmo os usuários mais assíduos consomem apenas alguns milhares de dólares por mês, disse ele. Mas ele espera que, com o tempo, as empresas precisem de uma visão completa das suas despesas operacionais, que inclua não apenas o número de funcionários, mas também o custo dos agentes de IA que trabalham com elas.
Isto chega a um ponto mais importante: “O gargalo não tem a ver com o tempo que leva para construir algo”, disse Sivasubramanian. “O gargalo é elaborar as especificações e os testes corretos, o produto certo e a experiência do cliente.”
Em uma postagem no blog publicado na semana passada, Sivasubramanian escreveu que as equipes de toda a empresa que reestruturaram seus fluxos de trabalho em torno da IA obtiveram um ganho médio de produtividade de 4,5x, com alguns ganhos superiores a 10x. As equipes que simplesmente adicionaram ferramentas de IA à sua forma de trabalhar existente não obtiveram os mesmos resultados.
Codificação e teste
Essa mudança criou seus próprios desafios. As equipes podem gerar código mais rápido do que nunca, mas se não definirem antecipadamente como será o sucesso – as especificações, os testes, os casos extremos – os agentes não terão tantas probabilities de sucesso.
A Amazon agora está empurrando os testes para o momento da codificação, em vez de lidar com eles em etapas, para que os agentes possam verificar seu próprio trabalho antes que qualquer coisa chegue à produção.
Sivasubramanian aprendeu isso em primeira mão, da maneira mais difícil. No início deste ano, com o jet lag e incapaz de dormir em seu quarto de resort durante uma viagem à Índia, ele decidiu tentar um projeto divertido: ele usou o Kiro para reconstruir uma parte da infraestrutura da AWS que ele havia desenvolvido originalmente à mão há quase 20 anos — um mecanismo de replicação que ainda sustenta serviços essenciais como S3 e DynamoDB.
Ele e um dos primeiros engenheiros ilustres da Amazon, Allan Vermeulen, passaram quatro meses no unique. Sivasubramanian imaginou que o agente resolveria isso rapidamente. Em vez disso, ele passou quatro noites indo e voltando, cuidando de cada passo.
Na quinta noite, ele percebeu o problema: não havia dado ao agente as ferramentas para testar seus próprios resultados. Depois que ele escreveu as especificações corretas e configurou o ambiente de teste, isso foi feito em cerca de duas horas. Questionado sobre o que ele fez com sua versão reconstruída do motor, Sivasubramanian riu. Ele nunca enviou. “Talvez eu devesse”, disse ele.
Com a equipe certa e algumas pizzas, talvez ele ainda consiga.
