Dev com IA não se mede por token: o que eu olharia num time de engenharia

Se você quer saber se um time está usando IA bem, não olhe quantos tokens ele gastou nem quantas linhas ele entregou. Olhe o que chegou no usuário, quanto daquilo voltou como bug e quanto tempo o time levou para entender o próprio código depois. Essa é a minha tese, e ela vem de um ano usando Cursor e Claude Code todo dia em projeto de verdade, não de um slide.

Escrevo isso porque a Amazon publicou um memorando sobre a nova diretriz do papel de engenheiro de software na era da IA. Não vou resumir o texto, ele é curto e vale a leitura no original. Quero usar algumas ideias dele como gancho para discutir o que eu acho que importa, onde eu concordo, onde eu discordo e o que eu mudaria amanhã num time de engenharia.

O resultado importa mais que a ferramenta (e isso é óbvio só no papel)

A frase central do memorando é que o que importa é o resultado, não qual ferramenta de IA você usa. Concordo. Mas, na prática, quase todo time que eu vejo faz o contrário: discute se o certo é Cursor, Copilot ou Claude Code, cria canal no Slack para comparar modelo, e ninguém pergunta se o último mês de entregas foi melhor que o anterior.

No meu caso, a escolha de ferramenta virou uma pergunta de ergonomia, não de identidade. Eu explico isso com detalhe no meu setup Cursor + Claude Code em 2026: quando preciso ver e guiar a mudança, fico no Cursor; quando consigo descrever o resultado e verificar no fim, mando para o Claude Code no terminal. Se amanhã outra ferramenta fizer isso melhor, eu troco sem drama. O que eu não troco é o critério de “está pronto”.

E esse critério é o ponto. “Resultado” não é “o PR foi mergeado”. Resultado é:

• a funcionalidade resolveu o problema de quem pediu;
• não voltou como incidente nas semanas seguintes;
• outra pessoa do time consegue mexer naquele código sem chamar o autor (ou o agente) para explicar.

Esse terceiro item é o que mais sofre com IA, e quase ninguém mede.

Tokenmaxxing: quando a métrica vira o alvo

O memorando faz uma autocrítica que eu achei rara vindo de uma empresa grande: admite que métricas como uso de tokens, adoção de ferramenta e volume de mudanças de código são profundamente falhas, e que usá-las como alvo leva a custo maior e complexidade maior. Eles chamam o primeiro problema de tokenmaxxing.

Aqui eu vou um passo além do texto. O memorando diz que essas métricas de entrada ainda se correlacionam bem com resultado e que dá para usá-las “com cuidado”. Eu discordo da parte do “com cuidado” na maioria dos times. Correlação vale enquanto ninguém está olhando para o número. No dia em que o número aparece num dashboard de gestor, as pessoas aprendem a mexer nele. É a lei de Goodhart, e IA deixa ela muito mais barata de explorar.

Pense no que é fácil fazer com um agente de código:

• Gerar mais linhas? Trivial. Peça “testes abrangentes” e você ganha 600 linhas de teste que verificam se o mock retorna o que o mock foi configurado para retornar.
• Gastar mais tokens? Trivial. Deixe o agente iterar em loop num erro que ele não entende.
• Abrir mais PRs? Trivial. Quebre uma mudança em dez sem pensar se elas fazem sentido separadas.

Eu já me peguei fazendo uma versão disso sem ninguém me cobrar. Teve semana em que eu senti que estava “voando” porque o Claude Code estava mexendo em muitos arquivos, e quando parei para revisar o conjunto, metade era refatoração que ninguém tinha pedido. Gasto alto, diff enorme, valor baixo. Se alguém medisse minha produtividade naquela semana por volume, eu teria sido um destaque.

Então minha posição é: métrica de entrada serve para diagnóstico individual e para descobrir quem precisa de ajuda. Nunca para meta, nunca para avaliação de desempenho, nunca em ranking.

O que eu mediria no lugar

Se eu estivesse liderando um time agora, eu acompanharia poucas coisas, todas ligadas a resultado:

1. Taxa de retrabalho: quantos PRs precisaram de correção (hotfix, revert, PR de “ajuste”) nas duas semanas seguintes ao merge.
2. Tempo até o primeiro feedback real: não até o merge, até alguém de fora do time de engenharia (cliente, suporte, produto) usar a mudança.
3. Tamanho médio do PR: como alerta, não como meta. Se subir muito depois que o time adotou agente, a revisão está ficando superficial.
4. Custo por entrega: gasto com IA dividido por funcionalidades que chegaram ao usuário. Isso pega o tokenmaxxing sem transformar token em vilão.
5. Teste de “quem entende isso”: de vez em quando, peça para alguém que não escreveu o código explicar um trecho recente. Se ninguém consegue, a dívida já começou.

Nenhuma dessas é perfeita. Mas todas puxam o comportamento para o lado certo, que é entregar menos coisa melhor, em vez de mais coisa qualquer.

“Renaissance Developer” é um nome bonito para algo antigo

O texto da Amazon fala em “Renaissance Developer”, o dev que combina IA com julgamento humano e conhecimento de domínio. Acho o rótulo marketing, mas a ideia por trás é a mais importante do memorando inteiro, e não é nova.

O que a IA mudou foi o custo de escrever código, que despencou. O custo de saber o que escrever continua igual. Na minha experiência, o agente é excelente quando eu sei exatamente o que quero e péssimo quando eu não sei. E ele não avisa que está no segundo caso: ele produz algo bem formatado, com nomes bons, que passa nos testes que ele mesmo escreveu.

Por isso eu concordo muito com outro ponto do memorando: quem está mais perto do produto e do cliente tira mais proveito de IA. Faz sentido. Se você sabe que o usuário do sistema de agendamento cancela consulta pelo celular às 23h, você escreve um pedido melhor para o agente e reconhece na hora quando ele ignora fuso horário. Se você só recebe ticket, você aceita o que vier.

Meu conselho para quem está começando: invista menos tempo comparando modelo e mais tempo entendendo o negócio em que você trabalha. É isso que vai separar quem revisa de quem carimba.

“A IA não ajudou aqui” é uma resposta válida

Essa é a parte do memorando de que eu mais gostei: se a IA não ajuda no seu trabalho, isso é uma descoberta, não um fracasso, e você deve documentar o porquê. Um engenheiro que consegue explicar onde a IA ainda não ajuda está demonstrando exatamente o julgamento que se espera dele.

Eu tenho uma lista dessas. Alguns exemplos do meu dia a dia:

• Migração de banco com dado legado sujo: o agente escreve a migração rápido, mas não conhece as exceções que só existem em produção. Eu gasto mais tempo corrigindo do que gastaria escrevendo.
• Bug de concorrência intermitente: o agente propõe correções plausíveis que mudam o sintoma sem atacar a causa.
• Código de autenticação e permissão: ele ajuda a escrever, mas eu não confio sem passar pelo meu checklist de segurança antes de colocar código de IA em produção. O ganho de tempo ali é pequeno.

Se eu fosse implantar isso num time, criaria um documento simples, compartilhado, com este modelo:

Tarefa: (o que eu tentei fazer)
Ferramenta/modelo: (Cursor, Claude Code, etc.)
O que aconteceu: (onde a IA errou ou atrapalhou)
Por que acho que errou: (falta de contexto? domínio? dado de produção?)
O que funcionou no lugar:
Vale tentar de novo daqui a 3 meses? (sim/não)

Esse último campo é importante. O memorando diz que qualquer definição de boa prática com IA vai parecer ultrapassada daqui a um ano, e que congelar práticas é um risco. Eu concordo, e por isso a lista de “onde não ajuda” também precisa ter prazo de validade. O que não funcionava em janeiro às vezes funciona em julho.

Revisão de PR é onde tudo isso vira prática

Toda essa conversa sobre resultado e julgamento morre se a revisão de código continuar igual. Com IA, o PR chega mais rápido, maior e com cara de pronto. É a receita para o revisor virar borracha.

Eu escrevi um guia inteiro sobre como eu reviso PR gerado por IA sem virar borracha. Aqui vão as mudanças que eu faria no template de PR de qualquer time que adotou agente de código:

• [ ] Como foi feito: manual, com assistência de IA ou majoritariamente gerado por agente. Não é para punir, é para o revisor saber onde olhar.
• [ ] Pedido original linkado: issue, ticket ou prompt. Sem isso, não dá para checar se o agente resolveu o problema certo.
• [ ] Arquivos fora do escopo explicados: se mexeu em algo que a tarefa não pedia, por quê.
• [ ] Teste quebrado de propósito: o autor confirma que quebrou o código e o teste falhou.
• [ ] Autor consegue explicar cada trecho: se não consegue, o PR não está pronto, mesmo que passe no CI.

Esse último item é o meu filtro principal. Quem abre o PR é dono dele, não importa quem digitou.

Líder que não usa a ferramenta não deveria definir a regra

O memorando pede que líderes técnicos e gestores usem as ferramentas na mão, em trabalho de produção, e consigam descrever uma tarefa em que a IA ajudou e outra em que não ajudou. Assino embaixo, e acho que deveria ser pré-requisito.

Já vi decisão de “todo mundo tem que usar agente” vinda de quem nunca rodou um, e decisão de “IA está proibida no repositório” vinda de quem testou uma vez em 2023. As duas são ruins pelo mesmo motivo: são opinião sem experiência.

Minha régua para um tech lead é simples: no último mês, você mergeou pelo menos um PR feito com agente, num código que vai para produção, e passou pela mesma revisão que o resto do time? Se não, você ainda não tem base para definir a política.

O que eu faria num time amanhã

Juntando tudo, este é o plano que eu levaria para uma equipe:

1. Tirar qualquer meta de tokens, linhas ou adoção de dashboard de desempenho.
2. Medir retrabalho, custo por entrega e tamanho de PR como sinais de alerta.
3. Adicionar ao template de PR os campos de origem, escopo e “teste quebrado de propósito”.
4. Criar o documento de “onde a IA não ajudou”, com revisão a cada trimestre.
5. Exigir que quem define a política use a ferramenta em produção.
6. Colocar devs mais perto de cliente e produto: uma call de suporte por mês já muda muito.
7. Manter o checklist de segurança obrigatório para qualquer código de IA que toque autenticação, dados pessoais ou pagamento.

Perguntas frequentes

Medir uso de IA no time é sempre ruim?

Não. Saber quem não está usando ajuda a descobrir quem precisa de apoio ou quem tem um bom motivo para não usar. O problema é transformar isso em meta ou em critério de avaliação.

Como saber se a IA está realmente deixando meu time mais produtivo?

Compare entregas que chegaram ao usuário e taxa de retrabalho antes e depois da adoção. Se o volume de código subiu e o retrabalho também, você não ganhou produtividade, só ganhou volume.

Dev júnior deveria usar agente de código?

Sim, mas com a mesma regra de todo mundo: tem que conseguir explicar o que entrou no PR. Para quem está começando, o agente é ótimo para aprender lendo, e ruim para pular a parte de entender.

Se você chegou agora no Visão Binária, comece pelos três guias da seção “Comece por aqui”. Quer saber quem escreve e por quê? Está tudo na página Sobre. E se o seu time mede IA de um jeito diferente, eu quero ouvir: me chama pela página de contato.