IA tornou barato mudar software. E isso pode tornar a gestão de mudanças ainda mais importante

Num sistema novo, alterar uma regra custa horas. Num ERP com vinte anos, custa descobrir quantas outras coisas aprenderam a depender dela. A IA resolveu a primeira parte — a escrita do código. Não resolveu a segunda: a decisão. Quando implementar ficou quase grátis, o gargalo migrou de “como fazer” para “se deve fazer”. É aí que a gestão de mudanças deixa de ser burocracia e vira o mecanismo que impede velocidade de virar acidente.

Leitura: ~7 minutos · ~1.500 palavras

🎧 Ouvir resumo (1min08s) — voz gerada por IA, narração dos pontos principais do post.

A mudança ficou barata. A consequência não.

Uso agentes de IA no desenvolvimento do nosso ERP todos os dias. Codex, Claude, Hermes com ferramentas locais — a rotina mudou de verdade. O que levava um dia de digitação e pesquisa leva minutos de prompt e revisão. O custo de escrever uma mudança despencou.

E aqui está o erro em que quase caí: confundir custo de implementação com custo total. A mudança em software empresarial nunca foi caro só por causa do código. Era caro por causa do que envolve: avaliar impacto, avisar quem é afetado, planejar rollback, decidir se vale. Nenhuma dessas etapas ficou mais barata — só ficaram mais escondidas atrás de um diff de 40 arquivos.

O relatório DORA de 2025 mediu isso em escala. 90% dos profissionais de tecnologia já usam IA no trabalho e mais de 80% acreditam que ela aumentou a própria produtividade. Mas a adoção de IA está associada a aumento simultâneo de throughput e de instabilidade na entrega. Você produz mais e quebra mais. O relatório chama a IA de amplificador: magnifica as forças de quem tem processo bom e as disfunções de quem não tem.

Inferência minha a partir desse dado: a IA não mudou o preço da mudança — deslocou o custo da escrita para a verificação. O tempo economizado no code generation reaparece como overhead de auditoria. Dá pra pagar esse preço só se houver governança pra absorver.

Frequência explode — e impacto acumulado também

Quando cada mudança custa horas em vez de dias, o número de mudanças por sprint multiplica. Parece vitória. Problema: em sistema maduro, o risco de uma mudança não é linear no número de mudanças — é acumulado.

Duas mudanças independentes, cada uma aprovada isoladamente, podem interagir de forma que ninguém previu. Dez aprovadas sem coordenação viram um estado do sistema que nenhuma pessoa conhece inteiro. É o cenário que o PMI chama de controle integrado de mudanças: a decisão de aceitar uma mudança exige avaliar efeito combinado com as demais — nunca caso a caso.

Eu já vi isso num ERP de vinte anos: uma alteração aparentemente trivial na validação de um campo de pedido quebrou um relatório fiscal que ninguém lembrava que lia aquele campo. O diff tinha 3 linhas. O impacto atravessava módulos que o autor — humano, nessa época — não conhecia. Com agentes gerando diffs de 40 arquivos, a probabilidade desse tipo de colisão só aumenta.

A pergunta certa deixou de ser “o código funciona?” e passou a ser “o sistema como um todo continua fazendo sentido depois de somar todas as mudanças?” E essa pergunta ninguém delega pra máquina.

O que a IA não decide

Um agente de IA é excelente em responder “como implementar X”. Ele não responde — e não deve responder — três perguntas:

1. Esta mudança deveria existir? É decisão de negócio. Envolve prioridade, custo de oportunidade, cliente afetado, risco fiscal. Nenhum modelo tem contexto pra decidir. 2. Quem precisa saber? Em sistema que movimenta nota fiscal e dinheiro de cliente real, mudança sem comunicação a usuário é incidente, não feature. 3. O que acontece se der errado? Rollback, janela de deploy, dados que ficam inconsistentes. A IA não sabe que semana fiscal fecha sexta.

O que a IA faz de verdade: multiplica a quantidade de propostas de mudança. Dezenas de arquivos alterados em minutos, todos plausíveis, todos tecnicamente corretos, nenhum avaliado quanto à consequência. O gargalo deixa de ser produção e vira decisão — e decisão não escala com tokens.

Revisão humana: o novo papel do sênior

O papel do desenvolvedor sênior mudou de “escreve as partes difíceis” para “filtra o que a máquina propõe”. Isso não é promoção nem demição: é mudança de gargalo.

Na prática, a revisão deixou de ser “ler o diff pra ver se compila”. Virou três camadas:

• Camada técnica: o código está correto? Testes cobrem? É o que revisão sempre foi.
• Camada de contexto: o código está certo *para este sistema*? O agente não sabe que aquele campo é lido por um relatório antigo, que aquele endpoint tem SLA de cliente.
• Camada de decisão: essa mudança, agora, nessa ordem, com tudo o mais que está em voo? Isso é gestão de mudanças, não code review.

O senhor que só faz a camada técnica está sendo substituído pela própria IA. O que sobra de insubstituível é justamente o que a IA não tem: memória do sistema, dos clientes e das consequências. Em termos do PMI: o sênior virou o ponto de controle entre integração, stakeholders e qualidade — três áreas de conhecimento na mesma mudança.

Rastreabilidade e aprovação com agentes

Se o agente altera 40 arquivos, “o que mudou?” precisa de resposta auditável. Sem rastreabilidade, o histórico do repositório vira ruído que ninguém confia.

O mínimo que eu exijo hoje em mudança assistida por IA:

1. Um propósito declarado antes do código. O que a mudança resolve e por que existe. Se não cabe em duas frases, a mudança não está madura. 2. Diff revisado por humano antes de qualquer deploy. Sem exceção, sem “era só refactor”. 3. Rastreabilidade do agente: qual prompt, qual modelo, qual contexto. Quando algo quebrar, você precisa saber o que a máquina fez e por quê. 4. Aprovação separada da implementação. Quem implementa não aprova a si mesmo — nem quando quem implementa é um agente e quem implementou é você mesmo com ajuda dele.

Isso não é burocracia pra desacelerar. É o registro que permite velocidade com responsabilidade. Quem tem medo de registrar mudança é quem pretende negar que a fez.

Governança não é freio, é direção

A tentação com IA é cortar cerimônia: “agora que escrever é rápido, não preciso de processo”. Esse é exatamente o raciocínio que o DORA desmente — mais velocidade com governança fraca significa mais instabilidade, e instabilidade em ERP de cliente não é métrica, é ligação de cliente bravo.

A leitura de PMI completa o quadro: risco, qualidade, stakeholders, integração e controle integrado de mudanças deixaram de ser itens de formulário e viraram as cinco áreas onde a velocidade da IA concentra risco. O agente resolveu o custo de escrever a mudança. A governança resolve o problema de decidir se ela deveria existir — e continua sendo humana, porque consequência de negócio não compila.

Antes de aprovar a próxima mudança gerada por agente, três perguntas: o impacto foi avaliado contra o sistema inteiro, não só contra o diff? Alguém que não escreveu o código aprovou? Se tudo isso voltar pra trás, você sabe reverter sem inventar? Qualquer “não” é motivo pra pausar antes do deploy — não depois.

Leitura relacionada

• Estamos produzindo código mais rápido do que lemos — os limites da velocidade de leitura diante da velocidade de geração.
• Num software novo, você altera uma regra. Num software legado, você descobre quem dependia dela — o caso do impacto em cascata em ERP maduro que este post usa como base de risco.
• Por que não deleguei o desenvolvimento do ERP pro ChatGPT — o limite prático entre delegar tarefa e delegar decisão.