ROI de IA no desenvolvimento de software: como medir sem contar linha de código

O ROI de IA no desenvolvimento de software sai de quatro números que não exigem ler código, mais as cláusulas que você exige do fornecedor antes de assinar.

O custo de revisão aparece aqui, e quase nunca entra na conta de retorno da ferramenta

O ROI de IA no desenvolvimento de software cabe numa divisão de uma linha. Em cima, quantas mudanças chegaram em produção no mês e continuaram lá 30 dias depois, sem hotfix e sem rollback. Embaixo, tudo que você pagou para elas chegarem: licença da ferramenta, hora de quem escreveu, hora de quem revisou, hora de quem voltou para consertar. Linha de código não entra em lado nenhum da conta.

Para preencher essa divisão você precisa de quatro números, e nenhum deles exige ler código: o tempo entre o primeiro commit de uma mudança e ela estar no ar, a fração das mudanças que voltam em até 30 dias, o tempo que um revisor humano gasta por pull request e o custo total por mudança que sobreviveu. Mede uma vez por mês e compara com o trimestre anterior ao dia em que a ferramenta entrou no time. Se você não guardou esse trimestre, comece a medir hoje e aceite que o primeiro número com algum valor sai em perto de três meses.

27 empresas, muita compra e a pergunta chegando atrasada

Ninguém mede obra por metro cúbico lançado por dia, mede por estrutura que passa no teste de carga

O Pragmatic Engineer publicou na semana passada uma análise com dados de 27 empresas para responder exatamente isso: o gasto com IA subiu muito neste ano, e esse gasto mexeu na velocidade de entrega e na vazão de pull requests? O que me interessa ali não é o resultado, é a ordem dos acontecimentos. A compra veio primeiro. A pergunta sobre retorno veio um ano depois, quando a linha já estava no orçamento de todo mundo.

No Brasil o desenho é o mesmo. Uma pesquisa da Comp com a Barte e a Woba, com perto de 300 executivos, divulgada pelo TI Inside, mostra ferramenta de IA distribuída para quase todo o time e quase nenhuma régua de retorno do outro lado. Liberou licença para 40 pessoas, ninguém definiu o que mudaria se a licença fosse cancelada em março.

Eu já vi esse filme em outro contexto. Quando fui o responsável técnico das estruturas metálicas de um autódromo, ninguém media a obra por metro cúbico de concreto lançado por dia. Media por estrutura que passava no teste de carga. Volume de material consumido é informação de almoxarifado, e no software a gente passou dois anos tratando volume de código gerado como se fosse resultado de engenharia.

Os quatro números que cabem na mesma reunião

Nenhum dos quatro depende de você abrir um arquivo. Todos saem de ferramenta que o time já usa, e os três primeiros você consegue extrair do Git e do board em menos de uma manhã.

• Tempo de ponta a ponta por mudança: do primeiro commit de um branch até a mudança estar rodando para usuário real. É o número que a IA deveria derrubar, e é o número que mais teima em não cair, porque o gargalo migrou para a fila de revisão e não para a digitação. Se você nunca mediu, o nosso benchmark de tempo médio de PR review em time remoto dá a ordem de grandeza para comparar.
• Taxa de retorno em 30 dias: de cada 100 mudanças que entraram, quantas precisaram de um hotfix, de um revert ou de uma segunda passada no mesmo arquivo pelo mesmo motivo. É a métrica que denuncia ganho falso, porque entrega rápida que volta na semana seguinte foi contabilizada duas vezes como produtividade.
• Hora humana por pull request: quanto tempo um revisor gasta de verdade por PR, e quantos PRs ele revisa por dia. Pull request de 900 linhas aprovado em uns quatro minutos não é revisão, é assinatura. Esse número é o que transforma economia de digitação em custo de leitura, e ele é o mais ignorado dos quatro.
• Custo por mudança sobrevivente: soma a licença do mês, a hora de quem escreveu e a hora de quem revisou e consertou, e divide pelas mudanças que ficaram de pé 30 dias. Para a parte de hora, use o custo real da sua folha, que a faixa de mercado está no nosso levantamento de salário de desenvolvedor de software no Brasil.

O quarto número é o único que o financeiro entende sem tradução, e é o único que fecha a divisão do começo deste texto. Os outros três existem para você saber de onde ele veio quando piorar.

Painel colorido com dado vazio é o /health respondendo 200

Os quatro números cabem numa reunião mensal, e o quarto é o único que o financeiro lê sem tradução

Tem um padrão que eu encontro em quase todo sistema que assumo depois que o fornecedor anterior virou as costas: o endpoint de saúde responde 200, o dashboard tem seis caixinhas verdes e nenhuma delas está instrumentada. Por fora, monitoramento completo. Sob o capô, nada sendo observado.

O painel de produtividade com IA está indo pelo mesmo caminho. Aceitação de sugestão, linhas geradas, percentual de código escrito por agente: tudo isso é o 200 do /health. A métrica existe, a garantia não. Em janeiro o slide mostrava quantas linhas a IA gerou. Em julho o slide sumiu da apresentação, porque alguém perguntou o que aquilo tinha mudado na fatura ou no prazo e ninguém soube responder.

E a conta que esses painéis escondem não vence no mês da compra. Ela vence quando você precisa mexer naquele código. A gente escreveu um guia separado sobre como medir a dívida técnica gerada por agente de IA porque esse pedaço do passivo não cabe no cálculo de retorno mensal, e some do relatório justamente por isso.

"Isso é DORA requentado"

É, em parte. Dois dos quatro números são primos de métricas de entrega que existem há anos, e eu não vou fingir invenção onde não houve. A diferença está em duas coisas.

A primeira é o denominador. DORA mede o fluxo da entrega, não o custo dela. Quando a ferramenta custa 30 ou 40 dólares por pessoa por mês e o time tem 25 pessoas, o custo deixa de ser detalhe e passa a ser a metade da conta que importa.

A segunda é a sobrevivência de 30 dias. Frequência de deploy sozinha premia quem entrega rápido, independente do que entregou. Cruzar entrega com retorno em 30 dias é o que separa vazão de resultado, e foi sobre esse ponto que eu escrevi quando o problema era mais código entrando e o produto não andando.

Tem um custo que nenhuma dessas quatro contas pega, e vale dizer: o time passa a entender menos do sistema que mantém. Isso aparece em tempo de investigação de bug, em dependência de uma ou duas pessoas, em pergunta que ninguém no canal sabe responder. Chamamos isso de dívida cognitiva e a régua é outra.

O que exigir do fornecedor antes de assinar

Se quem escreve o seu software é uma empresa de desenvolvimento de software, e não a sua folha, você não consegue medir nada disso sozinho. O dado está no Git dele, no board dele e no cartão de crédito dele. Então entra no contrato, antes de assinar, não na primeira briga.

• Acesso de leitura ao repositório e ao board, do seu lado, desde o primeiro dia. Sem isso você vai receber os quatro números já cozidos em PDF, e número cozido por quem é avaliado por ele não serve de medição.
• Declaração do que é gerado por IA, por mudança. Pode ser uma etiqueta no PR. Não é para proibir nada, é para você conseguir comparar retorno em 30 dias entre o que foi gerado e o que foi escrito à mão.
• Política de revisão escrita, com tamanho máximo de PR e dois pares de olhos obrigatórios em mudança que toca pagamento, autenticação ou dado pessoal. Se a resposta for "a IA revisa", peça o relatório de uma semana e leia as aprovações.
• Repasse de ganho ou de custo. Se a ferramenta economiza hora, a hora economizada aparece na sua fatura ou vira escopo a mais. Se não aparece em nenhum dos dois, o ganho é do fornecedor e o risco continua sendo seu.

O quarto item é o que define o resto. Modelo de contratação sem previsão de continuidade premia entregar rápido e ir embora, e IA só acelerou o lado ruim disso. Com preço fechado e sem cláusula de ganho, o incentivo é usar o agente para fechar o escopo em menos tempo, faturar igual e deixar a manutenção para o próximo.

Onde essa régua falha

Em time de três pessoas, com dois ou três pull requests por semana, não tente. O ruído é maior que o sinal, a taxa de retorno em 30 dias oscila 30 pontos porque uma pessoa tirou férias, e você vai tomar decisão de 15 mil reais em cima de uma amostra de oito mudanças. Aí a medição honesta é qualitativa: pergunte ao time o que ficou mais fácil e o que ficou mais chato, e decida com isso.

Também não funciona no primeiro mês de uso. Toda ferramenta nova piora o tempo de ponta a ponta antes de melhorar, porque o time está aprendendo onde ela ajuda e onde ela mente. Dê um trimestre antes de olhar a divisão.

E tem o caso em que a conta dá negativa e a decisão certa é continuar pagando. Se o retorno não aparece no prazo mas aparece em quem fica, em quem aceita a vaga, em quem não pede para sair, isso é retorno. Só não é retorno de engenharia, e não deveria ser defendido como se fosse.

Se você não sabe fazer massa de cimento, tanto faz se vai misturar na enxada ou na betoneira: vai sair ruim, e a betoneira só faz sair ruim mais rápido. A pergunta que eu levaria para a próxima reunião de orçamento é a mais simples das quatro: quantas das mudanças que entraram no mês passado ainda estão de pé hoje, sem ninguém ter voltado para consertar? Se ninguém no time souber responder, cancelar a licença e manter a licença são a mesma aposta, feita no escuro.