De Assistido por IA a Nativo em IA: Construindo uma Equipe de Desenvolvimento de Fronteira — Clare Liguori, AWS
AAI Engineer
컴퓨터/소프트웨어경영/리더십AI/미래기술
스크립트
00:00:00Clare Liguori: Meu nome é Clare Liguori e sou Principal Engineer Sênior na AWS.
00:00:17Eu trabalho principalmente no Kiro, nosso assistente de decodificação de agentes, mas hoje quero falar sobre
00:00:23algumas das práticas que temos visto dentro da Amazon, em equipes da Amazon, onde temos observado
00:00:28resultados realmente empolgantes de aumentos de produtividade que representam melhorias em função degrau em relação ao que
00:00:35temos visto com IA até agora. Trabalho com IA agêntica há mais de três anos,
00:00:43e acompanhei a evolução que aconteceu em nossa indústria quando se trata de assistência de codificação
00:00:48com IA. Primeiro, tivemos a autocompletação de código em linha nos ajudando a escrever a próxima linha,
00:00:55talvez a próxima função. Passamos para o chat, fazendo perguntas sobre nosso código. Todo mundo começou a fazer
00:01:02vibe coding em algum momento do ano passado, mas agora estamos começando a ver uma fase de adoção inicial de
00:01:08algo que temos chamado de desenvolvimento de fronteira. E totalmente por anedota, com base na minha própria experiência,
00:01:14eu realmente só me senti talvez 10 a 20% mais produtiva com todas essas fases que
00:01:20vieram antes. Mas agora, dentro da Amazon, temos realizado pilotos com diferentes equipes em toda a empresa,
00:01:27e temos visto uma mediana de melhoria de produtividade de 4,5x e, às vezes, mais de 10x. Então,
00:01:34algo realmente mudou aqui agora que estamos vendo essas melhorias em função degrau na produtividade.
00:01:40E gosto de definir o que temos chamado de desenvolvedores de fronteira dentro da Amazon
00:01:47por três comportamentos que tenho observado. Um é a codificação sem intervenção manual. Desenvolvedores de fronteira escrevem talvez
00:01:541 a 2% do código que produzem. O resto são agentes. O segundo é que eles interagem com seus
00:02:01agentes com pouca frequência. Eles buscam fazer com que seu assistente de código funcione por até horas seguidas sem
00:02:08intervenção deles. E o terceiro é que eles minimizam o tempo ocioso. Esses desenvolvedores de fronteira tendem a executar
00:02:15múltiplos agentes em paralelo, despachando uma lista de tarefas pendentes. A primeira vez que vi uma equipe de desenvolvedores
00:02:24de fronteira foi a equipe do Bedrock Mantle. O Bedrock é nosso serviço de hospedagem de modelos. Ele hospeda LLMs como Claude
00:02:34e GPT. E em algum momento do ano passado sabíamos, ou digo nós, mas a equipe do Bedrock sabia que eles iriam
00:02:43precisar construir um novo plano de dados de inferência. Mas eles haviam estimado isso em 30 pessoas ao longo de 18 meses. Este é um,
00:02:52um grande serviço. E levaria tempo para construir o novo, migrar os clientes, migrar os modelos
00:02:58para lá. E eles decidiram dar um passo atrás. Pegaram seis pessoas e o construíram em 76 dias com o Kiro.
00:03:06Portanto, esta foi uma enorme conquista. Esta foi a primeira vez que vimos algo do gênero dentro da Amazon.
00:03:12Então, esta foi verdadeiramente a equipe pioneira que provou ser possível obter uma melhoria de até 20x. Agora, eles analisaram
00:03:21os commits, e falarei sobre algumas outras maneiras pelas quais estamos medindo as melhorias de produtividade. Mas
00:03:27havia um problema com essa história, que era: sim, foi construído com seis pessoas. Foi construído
00:03:34com alguns dos principais engenheiros literalmente da empresa, incluindo dois distinguished engineers. Portanto, esta
00:03:40não era qualquer equipe de seis pessoas. Eram especialistas em sistemas distribuídos, especialistas em LLMs e em sua
00:03:49arquitetura. Então essa história foi incrível e meio que se espalhou como um incêndio pela Amazon. Mas também era
00:03:57muito inalcançável para muitas equipes. Havia muitas perguntas sobre: isso realmente pode ser reproduzido
00:04:03em outra equipe? Então, outro experimento sobre o qual quero falar é um sprint experimental realizado
00:04:10na organização do Prime Video. Eles fizeram um sprint de 10 dias e conduziram um experimento onde colocaram, novamente, seis engenheiros
00:04:19em uma sala e os deixaram livres para usar o Kiro à vontade. Eles reduziram a estimativa de tempo de entrega do projeto do que
00:04:29seria 90 semanas para 24, com base em todo o progresso que haviam feito neste sprint de 10 dias.
00:04:36E eles examinaram seu histórico de commits e o que costumavam fazer antes deste
00:04:42sprint de 10 dias, e quantos commits produziram apenas nesses 10 dias. E então este sprint realmente
00:04:49provou que podemos alcançar, novamente, algo próximo do que a equipe do Bedrock Mantle havia alcançado
00:04:58com um conjunto diferente de engenheiros. Mas, novamente, havia um desafio nessa história, que era: eram seis
00:05:05engenheiros em uma sala, sem plantões (on-call), reuniões limitadas e pouquíssimas distrações, que nós sabemos
00:05:12que são comuns na vida de um engenheiro. E o engenheiro sênior da equipe havia passado as três semanas
00:05:20anteriores criando tarefas muito detalhadas, pequenas e bem escopadas, com requisitos minuciosos para esses seis
00:05:28engenheiros apenas executarem durante aquelas duas semanas. Então, novamente, isso não era necessariamente a vida real.
00:05:35Este foi um sprint estruturado, um ponto no tempo em que eles conseguiram alcançar isso. Mas, mais uma vez, a
00:05:41questão é: isso é alcançável em equipes reais para o trabalho do dia a dia? Portanto, a Amazon Stores, que engloba
00:05:51o Amazon.com, todos os nossos sites de varejo, bem como nossas lojas físicas, realizou um piloto mais estruturado.
00:05:59Eles acompanharam 50 equipes totalmente normais, com uma distribuição normal de profissionais em início de carreira, de meio de carreira
00:06:07e engenheiros seniores, que trabalhavam em sistemas existentes. Nada do tipo Greenfield, como a equipe do Mantle pôde
00:06:14construir do zero, mas sistemas existentes com bases de código existentes. E eles as observaram durante
00:06:21a maior parte do ano passado e descobriram algo super interessante. Eles descobriram que havia uma grande
00:06:28diferença nos ganhos de produtividade observados entre metade das equipes e a outra metade. E, em
00:06:34neste caso, eles usaram como métrica de produtividade a velocidade de implantação em produção. Portanto, não apenas commits, quantos
00:06:41commits estão produzindo, mas com que rapidez estamos levando alterações para os clientes? Com que rapidez
00:06:48somos capazes de lançar as coisas? E eles viram que, para metade das equipes, o aumento alcançado foi inferior a 3x. E o que
00:06:56constataram ser a diferença entre ver um aumento de produtividade inferior a 3x e essas equipes que viram
00:07:01uma mediana de 4,5x e, em alguns casos, mais de 10x, foi a forma como usaram as ferramentas. 90% dessas equipes usam o Kiro, entre
00:07:11outras ferramentas internas que possuímos. E o que descobriram foi que não se tratava das ferramentas, mas da maneira
00:07:18como trabalhavam. As equipes que alcançaram melhorias em função degrau mudaram intencionalmente a forma de trabalhar,
00:07:26enquanto as outras simplesmente aplicaram o Kiro e algumas das outras ferramentas que temos por cima de sua
00:07:31forma de trabalho existente. E para mim, pelo menos, este foi o grande momento de revelação: o motivo pelo qual eu não vinha sentindo
00:07:39potencialmente os ganhos massivos de produtividade que a IA prometeu é que se trata de mudar a maneira como
00:07:47trabalhamos. Portanto, ao longo deste piloto, eles entrevistaram as equipes envolvidas no piloto, bem como algumas
00:07:55dessas outras equipes da equipe do Bedrock Mantle e do Prime Video, e descobriram cinco hábitos. E eu uso
00:08:03a palavra hábitos muito especificamente porque, novamente, não se trata daquele único sprint, mas de fazer isso no
00:08:09dia a dia. E o que descobriram ao entrevistar essas equipes foi que eram realmente hábitos que precisavam
00:08:15construir no dia a dia. Quando mudamos nossa forma de trabalhar, é difícil construir esses hábitos; leva tempo para construir
00:08:22esses hábitos. Então, vamos examinar cada um deles, um por um. O hábito número um é investir em contexto para os agentes.
00:08:30Temos muitas coisas em nossas cabeças, tendemos a transferir tudo o que está em nossas cabeças para outras pessoas
00:08:35por meio de conversas no Slack, de mentores de integração, coisas assim, revisões de código,
00:08:42reuniões de alinhamento e planejamento de sprints, e eles tiveram que escrever tudo isso. E o hábito que
00:08:50eles construíram foi: toda vez que o agente comete um erro ou faz algo diferente da maneira como você faria,
00:08:55o que está faltando nos meus arquivos de habilidades? O que está faltando nos meus arquivos de diretrizes que o agente precisava?
00:09:01Mas então, como sabemos, ao longo do ano passado, vimos saltos gigantescos nas capacidades e comportamentos dos modelos.
00:09:09O Sonnet 3.7, em meados do ano passado, tinha muitas peculiaridades que exigiam colocar muitas restrições de “não faça”
00:09:16em nossos arquivos de diretrizes. E agora não precisamos fazer tanto isso com o Opus 4.5, desde novembro passado,
00:09:23e tivemos seis meses, mais de seis meses de melhorias desde então, com todas as novas
00:09:29versões de modelos lançadas desde lá. E então a pergunta, o novo hábito mais uma vez é: eu
00:09:35ainda preciso disso nos meus arquivos de diretrizes? Ou isso está apenas sobrecarregando o contexto? O segundo é desacelerar para
00:09:41acelerar. Em quase todas as equipes entrevistadas, foi relatado que a produtividade na verdade diminuiu
00:09:48quando adotaram intencionalmente uma nova maneira de trabalhar. Isso é contra-intuitivo,
00:09:53não é? Você precisa fazer um trabalho de engenharia intencional antes de ver aquela
00:09:59curva de crescimento na melhoria de produtividade. Porque precisamos realizar um trabalho real em nossas bases de código
00:10:05primeiro para que os agentes tenham sucesso lá, especialmente em bases de código legadas já existentes. Então eles tiveram que
00:10:11construir esse contexto para os agentes, tiveram que melhorar as mensagens de erro de ferramentas existentes para que o modelo soubesse
00:10:17o que estava acontecendo quando falhava, construíram novas ferramentas, novos servidores MCP para ajudar o modelo a realmente realizar
00:10:24o que precisava ser feito. Muitas equipes acabaram reestruturando sua base de código para que os agentes
00:10:29pudessem navegar por ela com mais facilidade. E eu até vi mudanças drásticas, como alterar a linguagem de programação
00:10:36da base de código. Frequentemente tenho visto equipes lutando com Python, com JavaScript, porque são
00:10:43linguagens sem tipagem. É difícil de testar. Não há erros de compilador. Então o modelo meio que adivinha e
00:10:50entrega para você. Por isso, tenho visto equipes migrando para TypeScript. Rust tornou-se muito popular
00:10:56dentro da Amazon. O compilador fornece ótimas mensagens de erro. Você não precisa fazer isso. Mas vi muitas
00:11:03equipes fazendo essas mudanças intencionais em busca dos ganhos de produtividade que conseguem obter.
00:11:09O terceiro é alimentar os agentes, não ficar babá dos agentes. E para mim, este foi um daqueles momentos
00:11:16de revelação do porquê estamos vendo essa melhoria em função degrau na produtividade. Se você está fazendo vibe coding, se você está
00:11:23tendo uma conversa de vai e volta com o seu agente o dia todo, é claro que você não vai ver
00:11:30melhorias de produtividade de quatro a cinco vezes, porque você está no loop o tempo todo. Provavelmente
00:11:36você está sentado lá por 30 segundos a um minuto esperando que ele gere código e retorne para você
00:11:42com o código para revisar. Se você está sentado lá esperando por ele, então não pode ir fazer outras
00:11:48coisas. É muito difícil executar agentes em paralelo. É muito difícil conseguir clonar a si mesmo
00:11:55em vários agentes. E se as suas conversas se parecem um pouco com esta à esquerda, então você está
00:12:01mimando esse agente, em vez de fazer o que está no lado direito, onde você o alimenta com o que ele precisa fazer e como
00:12:08ele pode se autovalidar. E essa é realmente a chave para que os agentes possam se autocorrigir e só voltar até você
00:12:14quando atingirem um certo nível de qualidade, quando realmente rodarem, compilaram e passarem nos testes, quando
00:12:20forem testáveis, quando realmente tiverem alta cobertura. E claro, o próximo nível é colocar todo esse
00:12:26conteúdo no seu arquivo de diretrizes. Assim ele faz isso sempre, sem que você precise pedir.
00:12:33O quarto hábito é tornar a intenção explícita. Na Amazon, nós praticamos muito o desenvolvimento baseado em especificações.
00:12:40Nós incorporamos isso no produto Kiro. E por isso é muito natural que os engenheiros da Amazon o adotem
00:12:46no Kiro. O que eu tenho visto tipicamente na programação intuitiva, em contraste com a engenharia de vanguarda, é dar
00:12:54um comando de nível muito alto, deixar o agente gerar uma tonelada de código e depois ter uma conversa
00:13:02de vai e vem dizendo: Oh, não foi bem isso que eu quis dizer. Você não acertou exatamente nos requisitos.
00:13:10Não, eu não queria construir desse jeito. Aqui está um projeto técnico. E eu acho menos produtivo
00:13:17iterar com o agente sobre o código quando a própria intenção estava incorreta. Com frequência vemos engenheiros
00:13:26da Amazon passarem por esse processo de escrever a especificação para recursos ambíguos e complexos.
00:13:34E no Kiro, é claro, você não precisa escrever essa especificação inteira, você pode pedir para o modelo gerar
00:13:39a, mas é muito mais fácil iterar com o modelo em uma conversa de vai e vem sobre um
00:13:46documento do que sobre alterações de código espalhadas por uma base de código. O quinto hábito é antecipar os testes.
00:13:56Uma das chaves aqui é dar ao agente um ciclo de feedback rápido, porque é isso que permite que ele trabalhe sozinho por horas
00:14:04e se autocorrija. O agente vai cometer erros, e tudo bem. Mas se você der os sinais certos, ele pode
00:14:12se autocorrigir e passar um bom tempo fazendo isso. Então tenho visto equipes adicionando linters, testes unitários,
00:14:20testes de integração, testes de desempenho, testes de segurança. Estas são coisas que todos sabemos que deveríamos
00:14:24estar fazendo o tempo todo. Essa é uma boa higiene e prática de engenharia. Mas agora o retorno sobre o investimento é, acho eu, finalmente
00:14:32alto o suficiente para realmente investirmos nisso. Uma coisa que tenho visto muitas equipes fazerem é criar mocks de
00:14:40serviços. Com frequência, em testes de integração, testávamos um sistema inteiro de ponta a ponta, incluindo serviços
00:14:46ativos. Mas temos investido muito em serviços mockados que rodam inteiramente de forma local com respostas
00:14:52determinísticas, porque isso permite que o agente faça tudo localmente. Fazer tudo no seu notebook sem
00:15:01precisar iniciar vários outros serviços e se conectar a serviços em nuvem torna tudo muito mais rápido.
00:15:07Porque quanto mais feedback rápido o seu agente puder obter, mais ciclos ele
00:15:14poderá realizar e mais produtivo o seu próprio agente poderá ser. Portanto, estes são alguns dos
00:15:21hábitos que temos visto. Mas é claro, eu estaria mentindo se dissesse que, ao adotar todos esses hábitos,
00:15:28você alcançará o nirvana, sendo a organização de engenharia mais produtiva que o mundo já
00:15:35viu. As coisas ainda são difíceis. Ainda estamos fortemente na fase de adoção inicial e as equipes ainda estão
00:15:42entendendo as coisas. Então, algo que temos visto em nossas equipes organizacionalmente é o risco de
00:15:48esgotamento. Não fui eu que criei este termo, esqueço quem foi em qual conferência, mas o FOMAT é real. Temos visto
00:15:56engenheiros ficarem acordados até tarde da noite, tentando encontrar aquele comando perfeito que fará seu
00:16:03agente rodar por horas durante a noite para que acordem de manhã com uma alteração de código pronta. A carga cognitiva
00:16:09aumenta à medida que você executa esses múltiplos agentes em paralelo, alternando constantemente entre
00:16:15abas do terminal. E também vemos que revisar a saída da IA costuma ser mais difícil para alguns do que realmente
00:16:22escrevê-la, especialmente no início da carreira. Engenheiros sêniores já passaram uma boa parte de suas
00:16:29carreiras revisando o código dos outros. Mas os engenheiros em início de carreira ainda não têm esse hábito desenvolvido. E por isso, revisar
00:16:37pode parecer uma carga cognitiva muito maior do que estão acostumados ao escrever o código de fato. O outro
00:16:44ponto é a mudança organizacional. Portanto, já é difícil mudar a forma como trabalhamos como engenheiros. A maneira como
00:16:52passamos o dia inteiro muda completamente quando somos engenheiros de vanguarda. Mas as organizações também precisam
00:16:58mudar para capacitar equipes de engenharia de vanguarda. Um ponto que tenho visto muito comumente é aceitar desacelerar
00:17:07para acelerar. E eu mesmo já fui culpado disso. Meus colegas líderes já foram culpados disso ao dizer:
00:17:14bem, agora vocês têm as ferramentas de IA e os modelos estão tão incríveis. Por que vocês não estão indo mais rápido?
00:17:22E isso acontece porque é preciso tirar aqueles dois meses para investir na sua base de código, descobrir as melhores
00:17:29práticas para a sua equipe e fazer mudanças difíceis de hábitos nela. E se você espera constantemente
00:17:38entregar recursos todos os meses, porque agora temos esses modelos incríveis e estamos vendo
00:17:44todas essas empresas no X dizendo como entregam 20 PRs por dia, nós precisamos desacelerar para acelerar.
00:17:54O segundo ponto é ir rápido demais para uma abrangência muito ampla na organização. Acredito que se tivéssemos
00:18:01esperado que todas as equipes em organizações massivas fossem equipes de vanguarda imediatamente, não teríamos tido
00:18:08o aprendizado que obtivemos com os pioneiros, com o experimento de sprint, com as equipes piloto
00:18:16dentro da Amazon. E agora o desafio para nós é como dimensionar isso? E é disso que 2026 trata.
00:18:22Para a Amazon, trata-se de como expandir isso para mais e mais equipes, para as próximas 2.000 equipes em vez de 50 equipes.
00:18:31E por isso acho que, quando você implementa rápido demais, você tem muitas equipes que não sabem o que estão
00:18:37fazendo. Você não teve tempo para encontrar as melhores práticas para suas próprias organizações, o contexto
00:18:43que sua organização precisa. E o último ponto é que você vai encontrar novos gargalos.
00:18:49Antigamente, escrever código manualmente era o gargalo. Descobri que dentro da Amazon nós percebemos que
00:18:58a velocidade de tomada de decisão se torna um novo gargalo. Quanto mais tempo você gasta revisando a decisão de
00:19:05realmente construir um novo produto, mais lento é para construí-lo agora, porque o código leva apenas de um a dois meses para ser escrito.
00:19:12Todos os processos de revisão associados ao lançamento de um produto tornam-se o gargalo.
00:19:20Quando levava de nove a doze meses para construir um novo produto, isso não importava tanto no cômputo
00:19:27geral das coisas, se levava dois meses para tomar a decisão de construir o produto e depois mais dois meses para
00:19:33aprovar o lançamento. Mas agora esses são os gargalos. Eles são o fator limitante. E assim você percebe que todas
00:19:40essas coisas que atrasam você... Muitas vezes acho que equipes de engenharia de vanguarda gastam mais tempo
00:19:48tomando decisões do que escrevendo código. Portanto, quanto mais rápido você puder tomar decisões, especialmente aquelas
00:19:54que são fáceis de reverter, melhor. Então, minha grande conclusão para todos aqui é que a engenharia de vanguarda
00:20:03consiste em mudar intencionalmente a forma como você trabalha. E isso é difícil. Isso leva tempo.
00:20:10Trata-se de formar novos hábitos e uma nova maneira de trabalhar. E isso vale para qualquer equipe de engenharia, bem como para a sua
00:20:18organização. Por isso, encorajo vocês a pensarem em como estão interagindo com as ferramentas de IA e como isso pode
00:20:27mudar para libertá-los de ficarem presos no ciclo. Obrigado. Vou ficar por aqui mais um pouco caso alguém tenha
00:20:34perguntas no fundo. Mas obrigado pelo tempo de hoje.