Localizar onde o ganho de velocidade vira prejuízo

O padrão se repete em empresa depois de empresa, com uma regularidade que já cansou de surpreender. O time adota agentes de código, a velocidade aparente sobe na primeira semana, e três meses depois a operação está pior do que antes. Mais entregas chegam, mais entregas voltam, o plantão fica mais movimentado e ninguém consegue apontar o que quebrou.

A tentação é atribuir isso à ferramenta e cancelar o contrato. A leitura correta é mais chata e mais útil: essa queda é esperada, tem três causas conhecidas e tem fim. O que não é esperado é ela durar mais do que deveria porque ninguém mediu qual das três está pesando.

O nome disso é curva em J. A produtividade cai abaixo do ponto em que estava antes da adoção e só depois sobe acima dele, e o desenho da série lembra a letra.

O relatório de retorno do DORA, que é a fonte metodologicamente mais séria sobre engenharia de software em escala, modela essa curva explicitamente e nomeia as três causas do fundo do vale: a curva de aprendizado de quem está usando a ferramenta, o imposto de verificação, que é o custo de conferir o que a IA entregou, e a necessidade de adaptar teste e aprovação de mudança a um volume de código maior. O próprio relatório chama esse período de custo de matrícula da transformação, e alerta que ler a queda como fracasso leva a cortar orçamento na hora errada.

Guardar as três causas separadas é o que dá poder de decisão. Elas têm donos diferentes, prazos diferentes e preços diferentes.

Cada uma das três causas se anuncia por um sintoma diferente, e é por aí que se faz o diagnóstico sem contratar estudo nenhum.

A primeira é temporária e barata: gente aprendendo a usar. Ela passa sozinha em poucos meses e o sintoma é retrabalho concentrado em quem adotou mais recentemente. A segunda é permanente e cara: alguém precisa conferir tudo o que chega, e esse alguém é a pessoa mais experiente do time. A terceira é estrutural: o processo que existe depois da escrita, revisão, teste e aprovação de mudança, foi dimensionado para o volume antigo e agora recebe o volume novo.

Confundir as três é o que produz a decisão errada. Investir em treinamento quando o problema é a fila de conferência não resolve nada, e trocar de ferramenta quando o problema é o processo a jusante repete o incidente com outro fornecedor.

Um ponto percentual de aumento na taxa de falha de mudança soa desprezível na apresentação e não é. No cenário-exemplo do próprio calculador do DORA, a taxa subindo de 5% para 6% depois da adoção produz um impacto negativo de 344 mil dólares em indisponibilidade. É cenário modelado, não medição de campo, e serve para calibrar ordem de grandeza: a terceira causa é a única das três que cobra do cliente.

A segunda causa também deixa rastro em outro lugar, e esse rastro é medível sem perguntar nada a ninguém. Ele aparece no próprio código, na forma de dívida de manutenibilidade: o quanto o sistema fica mais difícil e mais caro de mudar depois, mesmo funcionando hoje.

Peça ao time a série mensal de três números desde o início da adoção: taxa de falha de mudança, horas de revisão por entrega e entregas devolvidas. Marque na série o mês da adoção. Se a curva ainda estiver abaixo do ponto de partida no sexto mês, a próxima reunião discute processo antes de orçamento.