Amazon mede IA dos devs por tokens e código: a métrica que vira alvo

Dois documentos sobre a mesma pergunta saíram em 27 de outubro de 2026, de autores sem relação declarada entre si. O primeiro é um memorando da liderança de engenharia da Amazon aos seus engenheiros, publicado na sala de imprensa da empresa. Ele diz que a Amazon mede a adoção de IA por uso de tokens, adoção de ferramenta, mudanças de código e revisões, e diz na frase seguinte que essas métricas são "profundamente falhas". O segundo é a revisão de um estudo acadêmico que acompanhou 802 desenvolvedores de uma empresa cujo CTO fez de uma métrica vizinha uma meta pública: dobrar os PRs mergeados por engenheiro em doze meses. A empresa chegou lá. O estudo conta o que aconteceu no caminho.

Para quem não é de engenharia, a tradução da pergunta é esta: a sua equipe de tecnologia usa IA, você paga por isso, e precisa saber se está funcionando. Os dois números mais fáceis de puxar são quanto a ferramenta consome e quanto código sai. O memorando da Amazon explica por que eles são tentadores e perigosos. O estudo mostra o que acontece quando viram alvo, e é essa leitura cruzada que interessa a quem vai decidir como medir isso no Brasil.

O que a Amazon escreveu, e o que deixou de fora

O texto é assinado por Terk Terkowitz, VP e Distinguished Engineer da Worldwide Amazon Stores, e reproduz um memorando que a liderança de engenharia (os Distinguished e Senior Principal Engineers) enviou a SDEs e SDMs, os engenheiros e os gerentes de desenvolvimento. O motivo foi a revisão do "role guideline", a descrição oficial do que se espera de um engenheiro na empresa, que tem "milhares" deles.

A decisão central foi não prescrever práticas de IA no guideline. O argumento consta no texto: qualquer definição escrita agora "vai parecer antiquada daqui a um ano", e definições antiquadas congelam a prática enquanto o mundo anda. O documento foca no que não muda, impacto em cliente, negócio e equipe, e pede que quem ainda não usa IA aprenda e aplique "o quanto antes".

A parte que interessa a quem gerencia vem depois, e vale ler devagar. A Amazon diz que prefere medir por resultado de longo prazo, mas que esses resultados "são atrasados, difíceis de medir e difíceis de isolar". Por isso, em alguns casos, usa métricas de entrada, como uso de tokens e adoção de ferramentas de IA, e métricas de vazão, como mudanças de código e revisões. Reconhece que são métricas desconectadas do que importa e que, usadas como alvo em vez de medida, aumentam custo ("tokenmaxxing é incompatível com frugalidade") e complexidade ("medir linhas de código é incompatível com invent and simplify").

E então afirma o que sustenta a prática: essas métricas de entrada "correlacionam bem" com os resultados que importam, e devem continuar correlacionando "por algum tempo". O memorando atribui isso a dois movimentos ao mesmo tempo: os times que mais adotaram IA, que ele chama de frontier teams, entregam mais; e times e pessoas que não adotam "ficam para trás". A recomendação operacional é olhar os extremos. No percentil 10 de adoção, achar os times que não estão usando IA de forma eficaz e entender por quê. No percentil 90, achar os que usam muito e conferir se a entrega acompanha.

Duas frases do memorando merecem ser citadas porque mudam a conversa com o time. A primeira: "se o seu trabalho não se beneficia das ferramentas de IA atuais, isso é um achado, não uma falha", e a instrução é documentar, compartilhar com os pares e levar ao gerente. A segunda é dirigida a quem lidera: entender suficiente significa ter usado as ferramentas no próprio trabalho de produção e conseguir "descrever uma tarefa em que ajudaram e uma em que não ajudaram".

O que o memorando não diz também importa. Não há nenhum número: nenhuma meta de uso, nenhum percentual, nenhum custo. Não há ferramenta nomeada. Não há vínculo com avaliação formal de desempenho, remuneração ou corte; o trecho que chega mais perto disso diz que usar essas métricas "com cuidado e julgamento" ao pensar "na sua carreira e no desempenho da sua organização" é apropriado, e para por aí. E não há data para a próxima revisão do guideline.

Tokens, PRs e percentis, para quem não é de engenharia

Token é a unidade em que os modelos de IA cobram: um pedaço de palavra. Uso de tokens é, na prática, a conta da ferramenta. PR é o pull request, o pacote de mudança de código que um desenvolvedor envia para ser revisado por outro antes de entrar no sistema; PRs por engenheiro por mês é uma medida de vazão comum em equipes que usam GitHub ou GitLab. Percentil 10 e percentil 90 são os dois extremos de uma lista ordenada: quem está entre os 10% que menos usam e quem está entre os 10% que mais usam.

O que a Amazon propõe, traduzido, é: olhe a conta da ferramenta e o volume de código como termômetro, não como meta; e gaste a sua atenção nos dois extremos da lista, não na média.

A empresa que fez da métrica uma meta

O estudo chama-se "AI Writes Faster Than Humans Can Review", de pesquisadores da Carnegie Mellon, de Stanford e da Microsoft, publicado como preprint em julho de 2026 e revisado em 27 de outubro. Preprint quer dizer que ainda não passou por revisão de pares. A empresa é anônima, descrita como de médio porte e "AI-forward", com mais de mil repositórios. Em junho de 2025 o CTO anunciou a meta de dobrar a produtividade de engenharia com IA em doze meses, e escolheu como medida os PRs mergeados por engenheiro por mês. Os autores acompanharam 802 desenvolvedores e 196.212 PRs em 364 repositórios ativos, de janeiro de 2024 a abril de 2026, com telemetria do Cursor (de fevereiro de 2025 a fevereiro de 2026) e do Claude Code (a partir de julho de 2025).

A meta foi atingida no décimo mês. Os números de antes e depois, todos da mesma empresa e na mesma unidade, por desenvolvedor ativo por mês:

arXiv 2607.01904v2, consultado em 28/10/2026. Valores de uma única empresa; os autores avisam que a adoção não foi sorteada, então a direção dos efeitos é mais confiável que o tamanho.

Pela nossa conta, 44,3 dividido por 21,2 dá 2,09 vezes, que é o que o estudo informa. Mas, segundo os autores, o salto não veio da meta: no mês do anúncio a vazão quase não mudou. Veio da adoção, dev a dev. No mês em que cada pessoa começa a usar IA, a vazão dela sobe cerca de 12%, e continua subindo com o uso acumulado; no modelo preferido dos autores, o nível de uso de abril de 2026 explica 1,46 vez, e o 2x só aparece depois de cerca de nove meses de uso. Dias extras de trabalho explicam no máximo um quinto do ganho. E os PRs ficaram maiores, não mais fatiados: a mediana foi de 35 para 61 linhas, com uma mistura ampla de funcionalidade, correção e manutenção. Os autores procuraram sinais de que o time estivesse só inflando o contador, e o que encontraram foi PR maior, não PR fatiado.

Onde o tempo foi parar: a revisão

O título do estudo é o achado principal. O volume de PRs cresceu 3,1 vezes enquanto o conjunto de pessoas que revisam cresceu 1,5 vez. Pela nossa conta, isso dá 2,07 vezes mais carga por revisor; o estudo diz "aproximadamente dobrou". A empresa não deu conta disso revisando mais rápido. Deu conta desviando o trabalho da revisão humana.

A cobertura de revisão humana caiu de 89% para 68% dos PRs. A revisão automática por IA subiu de 19% para 84% e ultrapassou a humana logo depois do mandato. O número que mais pesa é o da revisão humana substantiva, aquela em que alguém de fato comenta o código: caiu de 39% para 21% dos PRs, enquanto as aprovações silenciosas, sem comentário nenhum, ficaram perto de 50%. E, depois do mandato, os PRs escritos com IA demoraram mais, não menos: cerca de 20% a mais da primeira revisão humana até o merge, e cerca de 22% a mais no ciclo total.

Os indicadores de qualidade que o estudo consegue medir não desabaram. A taxa de merge ficou estável, a participação de reverts caiu levemente na empresa, e os reverts por desenvolvedor cresceram 1,4 vez contra 1,8 vez dos PRs. Depois de um PR de IA entrar, o autor não abriu mais correções do que funcionalidades nos 7 ou 14 dias seguintes. Mas os próprios autores avisam que são proxies de horizonte curto: além deles, não há dado de bug, de incidente nem de defeito. O que o estudo mostra é mais estreito e mais útil: naquela empresa, quando o volume dobrou, o gargalo mudou de lugar, e ela o resolveu olhando menos para o que entrava.

Tokens 20 vezes: a conta que o estudo não fez

Há um número no estudo que os autores registram e não cruzam com o ganho. O gasto com tokens do Claude Code por desenvolvedor por mês, entre os autores de PR, foi de US$ 42 em julho de 2025 para US$ 856 em abril de 2026. Pela nossa conta, 20,38 vezes. Os autores chamam isso de piso da intensidade de uso, porque mede uma única ferramenta.

Esse multiplicador não se divide pelo 2,09 dos PRs, e vale dizer por quê: as populações e as bases são diferentes. O gasto é dos autores de PR que usavam Claude Code, medido a partir de julho de 2025, que é o primeiro mês de telemetria da ferramenta na empresa, então a base parte de perto do zero e o multiplicador nasce inflado por construção. A vazão é de todos os desenvolvedores ativos, com base em janeiro a abril de 2025. O que os dois números mostram, lado a lado e sem divisão, é que a conta da ferramenta e o volume de código cresceram em ritmos muito diferentes. O memorando da Amazon tem uma palavra para o gasto de token que vira alvo, tokenmaxxing, e diz que ele é incompatível com frugalidade. Se a curva daquela empresa é adoção legítima ou é isso, o estudo não diz; e é por essa lacuna que a Amazon pede que a métrica de entrada seja lida junto com a saída.

Em reais, pela PTAX de venda de 27 de outubro de 2026 (R$ 5,3346), os US$ 856 por desenvolvedor por mês são R$ 4.566,42, e os US$ 42 do início eram R$ 224,05. A conversão usa o câmbio de hoje, não o da época, então serve para ordem de grandeza. Um time de dez pessoas no nível de uso de abril de 2026 daquela empresa gastaria em torno de R$ 45.664,20 por mês só em tokens de uma ferramenta, antes de licença, infraestrutura e da hora de quem revisa. É uma ilustração, não uma previsão: o seu time pode usar o dobro ou a metade.

A lista de custo total do caso, preenchida com o que o estudo e o memorando publicam:

Componentes com dado publicado pelo estudo ou pelo memorando; os demais não têm dado público.

De onde vêm os números

A leitura de que um documento descreve o risco que o outro mediu é nossa; os dois têm autores sem relação declarada entre si.

Para quem este número não serve

O estudo é de uma empresa, e uma empresa que já era "AI-forward", com telemetria por ferramenta, rótulo de IA nos PRs e um CTO disposto a anunciar meta em público. Os autores dizem que a estimativa deles é um teto, não uma média do mercado, e isso vale para o 12% do mês de adoção tanto quanto para o 2x em dez meses. Se a sua empresa está começando, o que viaja é a direção dos efeitos, não o tamanho deles.

O memorando é da Amazon, com milhares de engenheiros. Percentil 10 e percentil 90 fazem sentido numa população desse tamanho. Num time de oito ou dez pessoas, o percentil 10 é uma pessoa, e tratá-la como estatística é injusto com ela e inútil para você. Nesse tamanho, a unidade de análise é a conversa, não a distribuição.

Há setores em que PR por engenheiro não mede quase nada: firmware, sistemas regulados com validação formal, times de dados cuja entrega é um modelo e não um pacote de código. E há empresas sem telemetria nenhuma, em que a conta da ferramenta chega como uma fatura por assinatura e o volume de código não é contado. Para elas, antes de medir, o primeiro passo é ter o que medir.

Por fim, nenhum dos dois documentos diz que a IA não funciona. O estudo mediu ganho real de vazão; o memorando diz que a correlação com resultado existe hoje. O que os dois dizem, cada um do seu jeito, é que a métrica fácil mente quando vira alvo.

Medir sem virar alvo: o que fazemos e o que você decide esta semana

Na nossa operação, quando testamos uma esteira nova com agentes, o experimento compara tokens, custo, desempenho e qualidade do resultado ao mesmo tempo; já ajustamos skills e prompts especificamente para gastar menos token, e token sozinho nunca foi a medida. O que vemos nos projetos é que a conversa sobre usar IA no time chega como pergunta de custo e de velocidade, e a pergunta de quem revisa o que a IA produziu raramente vem escrita no pedido. É a pergunta que o estudo ajuda a responder, e que bate com o que vemos na operação: a revisão é para onde o tempo vai quando o volume sobe.

Dá para aplicar o memorando da Amazon num time brasileiro sem copiar a Amazon. Três regras que cabem em qualquer tamanho:

1. Toda métrica de entrada anda em par com uma de saída. Tokens por desenvolvedor ao lado de PRs por desenvolvedor, nunca sozinhos; e PRs por desenvolvedor ao lado da cobertura de revisão humana substantiva, que no estudo caiu de 39% para 21% e que não estava na meta.
2. Olhe os extremos, e leia o que eles produziram. No topo da lista de uso, abra os PRs antes de comemorar: o memorando pede exatamente isso, conferir se a entrega acompanha o uso. Na base da lista, pergunte antes de cobrar: o memorando chama a resposta de achado, não de falha.
3. Quem lidera usa a ferramenta no trabalho real. A régua da Amazon é concreta: descrever uma tarefa em que a IA ajudou e uma em que não ajudou. Quem não consegue descrever as duas ainda não tem opinião, tem palpite.

A decisão desta semana cabe em uma tarde. Puxe os dois números que você já tem, a fatura das ferramentas de IA por pessoa e os PRs mergeados por pessoa, dos últimos três meses. Coloque na mesma planilha. Acrescente uma terceira coluna que costuma faltar: quantos daqueles PRs receberam um comentário humano de verdade. Se essa coluna estiver caindo enquanto as outras duas sobem, você já sabe o que o estudo levou mais de dois anos e 196 mil PRs para mostrar.

A pergunta que fecha, e que só os seus dados respondem: no último mês, que fração dos PRs da sua equipe foi aprovada sem um único comentário?

Se a resposta exigir montar a esteira de medição, trocar a revisão silenciosa por revisão com critério, ou reforçar o time com gente que já opera agente de código com esse controle, é o trabalho que a X-Apps faz em desenvolvedores sob demanda e em squads com IA, com a régua combinada antes da primeira sprint.

Leia também

• Produtividade com IA no código: do pico ao abismo da complexidade
• Regressão em correção feita com agente de IA: 21 em mais de 130 PRs
• Fábrica de software com agentes de IA: a esteira do briefing ao deploy