O que separa as equipes que realmente ganham produtividade com IA das que ficam no mesmo lugar
Seis engenheiros. Setenta e seis dias. Um projeto originalmente estimado para 30 desenvolvedores trabalhando de 12 a 18 meses — entregue em menos de um trimestre. Esse não é um cenário hipotético: foi o que aconteceu quando uma equipe do Amazon Bedrock parou de tratar a IA como um atalho de codificação e passou a tratá-la como a fundação de todo o processo de trabalho. A equipe entregou mais código em produção em cinco meses do que nos dez anos anteriores somados.
A AWS publicou um estudo detalhado sobre o que chama de “frontier teams” — ou equipes de ponta — e o que elas têm em comum. O resultado é revelador: a diferença entre quem colhe ganhos reais de produtividade com IA e quem fica estagnado não está na escolha da ferramenta, mas na disposição de reestruturar completamente como o trabalho é feito.
O gargalo não é a IA — é o fluxo de trabalho
Agentes de codificação com IA mudaram radicalmente a velocidade com que o software é escrito. Os commits estão disparando, os pipelines de Integração Contínua/Entrega Contínua (CI/CD) estão mais movimentados do que nunca. Mas as funcionalidades chegando à produção não acompanharam esse ritmo.
O gargalo identificado pela AWS não é a capacidade do agente de gerar código. É o acesso do agente ao conhecimento necessário para tomar boas decisões — e a disposição da equipe de reorganizar o trabalho em torno dessa realidade.
As equipes de ponta não estão concentradas apenas em laboratórios de elite. Elas existem em diferentes setores e tamanhos de empresa, e compartilham uma disciplina comum: tratam a adoção de IA como um investimento de engenharia, não como a implantação de mais uma ferramenta.
Três caminhos para o desenvolvimento nativo com IA dentro da Amazon
Desenvolvimento de software nativo com IA significa tratar a IA como a base de como o software é construído, com agentes cada vez mais capazes sendo direcionados por especialistas humanos. A AWS identificou pelo menos três caminhos distintos ao experimentar com centenas de equipes de engenharia internas.
A iniciativa “pathfinder”: reconstruindo o motor de inferência do Bedrock
No primeiro caminho, seis engenheiros seniores receberam um único mandato: reconstruir o motor de inferência do Amazon Bedrock — um projeto originalmente estimado em 30 desenvolvedores trabalhando de 12 a 18 meses. Em vez de aumentar o headcount, a equipe passou as primeiras semanas redesenhando os fluxos de trabalho ao redor da IA: migrando de tarefas discretas para resultados orientados a objetivos, rodando múltiplos agentes em paralelo e configurando sistemas para que a IA trabalhasse de forma independente fora do horário comercial.
O projeto foi entregue em 76 dias. A produtividade individual dos desenvolvedores aumentou aproximadamente 20x, medida pela velocidade de commits normalizados — de 2 commits por semana para 40. A equipe entregou mais código de alta qualidade em cinco meses do que em projetos dos dez anos anteriores.
O sprint estruturado: Prime Video Financial Systems
O segundo caminho foi um experimento de 10 dias inspirado no modelo anterior. A equipe do Prime Video Financial Systems reuniu seis engenheiros em uma sala, com zero troca de contexto, sem plantões, sem outros projetos e com reuniões limitadas. Um engenheiro sênior passou três semanas antes do sprint decompondo a complexidade em tarefas bem delimitadas com requisitos detalhados.
A equipe usou desenvolvimento orientado a especificações para funcionalidades complexas e desenvolvimento assistido por agente diretamente para tarefas com requisitos já claros. Em 10 dias, produziram 556 commits contra uma linha de base de 96, e reduziram uma estimativa de projeto de 90 semanas para 24 semanas — quase 6x de throughput e 4x de aceleração.
Os três fatores que se multiplicaram para gerar esse resultado foram:
- Aceleração de trabalho de baixo julgamento: 1,5x
- Maior foco em trabalho de alto julgamento sem troca de contexto: 1,5x
- Acesso instantâneo à expertise de domínio capturada pelos agentes: 1,5x
A conclusão é importante: remova qualquer um desses três fatores e os ganhos desaparecem.
O experimento in-situ: Amazon Stores
No terceiro caminho, a Amazon Stores conduziu pilotos estruturados com equipes de desenvolvimento típicas trabalhando nos seus backlogs normais, usando o Kiro e ferramentas de IA específicas — sem condições especiais e sem engenheiros selecionados a dedo. Das mais de 50 equipes estudadas, as 25 que implementaram tanto novas ferramentas quanto novas práticas superaram significativamente as que simplesmente adicionaram IA aos fluxos existentes.
O ganho mediano de produtividade foi de 4,5x, com algumas equipes chegando a mais de 10x de melhoria na velocidade de implantação normalizada. A equipe Perfect Order Experience passou a entregar funcionalidades em uma tarde, em vez de duas semanas. O time WW Grocery reduziu a criação de documentos de design de cinco dias para algumas horas.
A lição é a mesma em todos os três caminhos: o fluxo de trabalho importa, não apenas a ferramenta.
As cinco práticas das equipes de ponta
Nos três caminhos, as equipes de melhor desempenho compartilham cinco práticas com uma lógica comum: reduzir as barreiras de contexto para o agente e aumentar a superfície de trabalho que ele consegue fazer de forma independente. Enquanto a abordagem histórica otimizava a velocidade de geração de código individual, as equipes de ponta otimizam outra coisa: a taxa com que software correto e pronto para produção chega aos clientes.
1. Invista no contexto do agente
As equipes mais avançadas investem pesadamente em tornar projetos e conhecimento mais fáceis de consumir pelos agentes — por meio de arquivos de direcionamento e orientações sobre convenções da equipe, padrões de codificação, testes e navegação no código-base. A equipe de infraestrutura do Bedrock colocou todo o código e documentação em um monorepo e manteve os comentários inline gerados pelos agentes de IA, tratando-os como memória persistente. Equipes que pulam essa etapa ficam se perguntando por que seus agentes continuam cometendo os mesmos erros.
2. Desacelere para acelerar depois
Toda equipe de alto desempenho relatou que as coisas inicialmente desaceleraram enquanto aprendiam os modelos. Elas codificaram expertise multifuncional em documentos de direcionamento reutilizáveis para os agentes, reestruturaram repositórios para que os LLMs (Modelos de Linguagem de Grande Escala) pudessem raciocinar sobre eles, e adicionaram comentários e rearquitetaram divisões de código para consumo pela IA. As equipes que atravessaram essa curva de aprendizado e definiram os resultados esperados primeiro experimentaram aceleração composta. As que esperaram ganhos imediatos sem mudar seus fluxos ficaram desapontadas. Espere que as duas primeiras semanas pareçam mais lentas. Espere que as semanas seguintes pareçam dramaticamente mais rápidas. As equipes que desistem na segunda semana nunca veem o efeito composto.
3. Alimente os agentes em vez de babá-los
Equipes de ponta mantêm um backlog constante de tarefas bem delimitadas com resultados claros, rodando múltiplos agentes em paralelo e revisando o output de forma assíncrona. Desenvolvedores relatam concluir funcionalidades importantes em curtos períodos, com o trabalho avançando mesmo quando não estão ativamente aguardando o agente completar uma tarefa. Um engenheiro principal entregou uma mudança completa com apenas “algumas horas de tempo contíguo” porque o agente trabalhou enquanto ele se movia entre revisões de código, suporte operacional e reuniões.
4. Torne a intenção explícita antes de o código ser escrito
Seja por meio de especificações estruturadas, documentos de requisitos detalhados ou decomposição de tarefas bem delimitadas, as equipes de ponta garantem que os agentes tenham contexto claro sobre o que significa “pronto” antes de começarem a gerar código. Algumas equipes que usam essa abordagem relatam escrever manualmente apenas 1 a 2% do código, enquanto enviam significativamente mais commits por pessoa por semana do que antes.
5. Antecipe os testes (“shift testing left”)
Equipes de ponta constroem ferramentas para que os agentes possam rodar todos os testes de integração localmente e se autocorrigir antes de o código chegar ao pipeline. A equipe do Prime Video investiu em guardrails automatizados, testes de componentes, testes de performance e formatadores que detectavam problemas cedo. As revisões de código passaram a focar em definições de interface e decisões arquiteturais, em vez de estilo de código e convenções de nomenclatura.
Fonte
How frontier teams are reinventing AI-native development (https://aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development/)
Leave a Reply