Como avaliar se o seu time deve adotar IA — e como medir se deu certo

A conversa sobre IA em time de tecnologia costuma acontecer em dois modos, ambos ruins. No primeiro, alguém da liderança leu que a produtividade aumenta 40%, compra licença para todo mundo e cobra o resultado no trimestre. No segundo, o time resiste em bloco e o assunto morre. Nos dois casos, ninguém mediu nada.

Este texto é sobre o caminho do meio, que dá mais trabalho e é o único que produz decisão defensável: escolher onde a IA entra, estimar o custo real e definir antes como você vai saber se funcionou.

Primeiro: a promessa de "X% mais produtivo" não sobrevive ao contato

Vale começar desarmando o número que circula. Os ganhos anunciados vêm quase sempre de tarefas isoladas e bem definidas — escrever uma função com especificação clara, gerar teste para código existente. São condições de laboratório.

O trabalho real de um time não é isso. É esperar review, descobrir que o requisito mudou, entender por que o ambiente de homologação caiu, negociar escopo. Escrever código nunca foi o gargalo na maioria dos times — e acelerar o que não é gargalo não acelera a entrega. É a lei mais velha de otimização de sistemas, e ela vale aqui igual.

Se o seu ciclo trava em revisão e alinhamento, gerar código duas vezes mais rápido só faz a fila de revisão crescer duas vezes mais rápido.

Isso não é argumento contra adotar. É argumento contra prometer número antes de olhar onde o tempo do seu time realmente vai.

Passo 1: descubra onde o tempo é gasto de verdade

Antes de escolher ferramenta, faça o levantamento chato. Duas semanas bastam. Você quer saber, grosseiramente, quanto do tempo do time vai para:

• Escrever código novo
• Entender código existente (seu ou de terceiros)
• Revisar
• Investigar bug
• Escrever documento, ata, especificação, mensagem
• Esperar — build, deploy, resposta de alguém
• Reunião

Não precisa de ferramenta de rastreamento nem de precisão de minuto; uma estimativa honesta de cada pessoa resolve. O objetivo é achar a fatia grande, porque é lá que qualquer melhoria vale a pena.

Nos times que acompanhei, as duas fatias que mais surpreendem são "entender código existente" e "escrever documento". E são, não por acaso, duas em que a IA rende muito. Já "escrever código novo" costuma ser menor do que todo mundo imagina.

Passo 2: escolha um problema, não uma ferramenta

Adoção que começa por "vamos usar a ferramenta X" quase sempre morre em três meses, porque não havia critério para dizer se estava funcionando. Comece pelo problema específico, escolhido a partir do levantamento anterior.

Exemplos de recorte bom: "ninguém entende o módulo de faturamento e toda mudança nele leva o triplo do tempo". "Nossa documentação de API está seis meses desatualizada." "As reuniões de alinhamento não geram tarefa e a gente refaz a mesma discussão."

Recorte ruim: "aumentar a produtividade do time de engenharia". Não é acionável e não é mensurável — você não vai conseguir dizer se deu certo, e sem isso o piloto vira questão de opinião.

Passo 3: some o custo inteiro, não só a licença

A licença é a parte visível e geralmente a menor. O custo real inclui:

• Curva de aprendizado. As primeiras semanas são mais lentas, não mais rápidas. Orce isso.
• Revisão adicional. Código gerado precisa de leitura atenta. Se você não orçar esse tempo, ele sai do lugar errado — do teste.
• Configuração. Regras de projeto, contexto, integração. É trabalho de gente sênior e não é pequeno.
• Avaliação de segurança e contrato. Onde o código vai parar, o que é retido, o que o contrato com o cliente permite. Em empresa com cliente corporativo, isso costuma ser o item mais demorado de todos.

Uma regra de bolso que tem se mostrado razoável: no primeiro trimestre, o custo de adoção supera o ganho. Se a sua expectativa é de retorno no mês um, você vai declarar fracasso antes de o experimento terminar.

Passo 4: defina a métrica ANTES de começar

Este é o passo que separa piloto sério de entusiasmo. Escolha a métrica antes, por escrito, e prefira medir fluxo, não volume:

• Tempo entre abrir e fechar uma tarefa (lead time) — a métrica mais honesta que existe para "estamos entregando mais rápido?".
• Tempo em revisão. Se subiu, você empurrou o gargalo para frente em vez de resolvê-lo.
• Taxa de retrabalho: quanto do que entrou em produção voltou como correção nas duas semanas seguintes. É o contrapeso essencial — velocidade que gera bug não é velocidade.
• Uma pergunta qualitativa mensal: "o que a IA te economizou nesta semana? o que ela te custou?" Duas linhas por pessoa. É onde aparece o que o número não mostra.

E as métricas que não servem, por mais tentadoras que sejam: linhas de código, número de commits, quantidade de pull requests. Todas sobem com IA por construção, e nenhuma delas mede valor entregue. Medir isso é garantir que o piloto "dê certo" sem que nada tenha melhorado.

Passo 5: rode com um grupo pequeno e voluntário

Escolha três a cinco pessoas que querem testar, dê a elas tempo explícito para aprender e um canal para relatar o que funcionou e o que não funcionou. Rode por um trimestre.

Voluntário importa mais do que parece. Quem foi obrigado testa mal, encontra a primeira frustração e conclui que não presta — e esse relato contamina a avaliação. Você quer saber se a ferramenta ajuda quando bem usada; obrigar todo mundo no dia um mede outra coisa.

Ao fim do trimestre, o grupo apresenta ao time o que aprendeu — inclusive os casos em que atrapalhou. Esse relato honesto é o que faz a adoção seguinte funcionar, porque as pessoas confiam em colega mais do que em apresentação de fornecedor.

O sinal de que está dando errado

Preste atenção em três sintomas, porque eles aparecem antes de qualquer métrica piorar:

1. Pull requests grandes demais. Quando o volume gerado cresce e o cuidado não acompanha, a revisão vira carimbo — e aí você importou bug com aprovação formal.
2. Ninguém sabe explicar o próprio código. Se na review a resposta é "foi a IA que escreveu", você tem um problema de manutenção com data marcada.
3. Uso escondido. Se as pessoas usam mas não falam, é sinal de que a política não está clara — e a decisão de risco está sendo tomada individualmente, sem você saber.

A decisão honesta

Para a maioria dos times de tecnologia hoje, a resposta é sim, adote — com recorte e com medição. Não porque seja moda, mas porque as tarefas em que ela mais rende (entender código alheio, escrever documento, gerar teste, traduzir erro obscuro) são grandes fatias do tempo real, e o custo de entrada é baixo comparado a outras iniciativas.

O que muda o resultado não é a ferramenta que você escolheu — as principais são boas e vão continuar mudando. É o método: um problema específico, o custo inteiro na conta, a métrica definida antes e um grupo pequeno que relata a verdade. Sem isso você não adotou IA. Você comprou licença e torceu.