Agentes de IA reduziram drasticamente o custo de produzir mudanças de software, mas o custo de entender uma mudança que se comporta mal não acompanhou essa queda. É o que aponta Sanjay Gidwani, CEO e fundador da KOSMOS, em artigo publicado no Forbes Technology Council.
Gidwani descreve um cenário recorrente em empresas no último ano: uma alteração entra em produção na terça à tarde, construída em cerca de uma hora. Na quarta, os tickets começam a chegar. Na sexta, ninguém consegue afirmar com certeza se os dois fatos estão relacionados.
A capacidade de produzir mudanças evoluiu, mas a capacidade de explicá-las depois permanece estagnada há uma década.
O custo oculto do desenvolvimento mais rápido
As ferramentas agênticas colapsaram o custo de produzir uma mudança funcional. Tarefas que antes consumiam boa parte de uma sprint agora podem ser concluídas em uma tarde, permitindo que equipes menores gerem significativamente mais mudanças. No entanto, nada disso afetou o custo de compreender uma mudança que apresenta mau comportamento.
São duas curvas se movendo em velocidades completamente diferentes. Quase todo mundo observa a que parece progresso: o volume de entregas. A curva que permanece estável, a do entendimento pós-incidente, raramente aparece em dashboards. O argumento do volume é tentador: mais releases significam mais superfície de ataque, logo mais coisas podem quebrar. Se a taxa de erro permanecer constante, o volume de investigações sobe junto com a frequência de deploy.
# publicidade
Atenção: a defesa de que o volume é o vilão tem uma falha. As ferramentas que escrevem o código também escrevem os testes. As taxas de defeito podem melhorar. Se melhorarem o suficiente, o argumento do volume perde força. O problema real está em outro lugar: na ausência de memória sobre a intenção da mudança.
Quando não há ninguém para chamar
Investigações sempre tiveram um atalho: encontrar a pessoa que fez a mudança e perguntar o que ela pretendia. Essa conversa vale mais que qualquer arquivo de log. Ela reduz horas de reconstrução a cerca de cinco minutos, porque a pessoa carrega informações que nunca chegaram a um sistema. Ela sabe qual problema estava resolvendo, quais abordagens descartou e qual parte a deixava nervosa no momento do deploy.
Quando um agente escreve a mudança, não há ninguém para chamar. O commit e o diff continuam existindo. O que pode não existir é um registro durável da intenção. Um engenheiro pode ter revisado e aprovado o pull request sem carregar o mesmo contexto que teria se tivesse construído a mudança do zero. Seis semanas depois, quando a integração apresenta problemas novamente, a memória institucional que encurtava a investigação pode simplesmente não estar lá.
Intenção é o contexto não estruturado que um desenvolvedor carrega sobre o problema que estava resolvendo, as soluções que descartou e os riscos que identificou antes do deploy. O agente de IA raramente produz esse registro.
Esse problema permanece invisível por mais tempo do que deveria, por razões que nada têm a ver com competência individual. O tempo de investigação não tem relógio próprio: fica escondido dentro da janela de resolução, uma fatia não medida do tempo total. Relatórios de nível de serviço mostram o intervalo completo, mas nunca revelam quanto daquele tempo foi gasto apenas para descobrir o que realmente aconteceu antes de alguém poder corrigir.
Info: escalonamentos são contabilizados, mas investigações reais, aquelas em que alguém reconstrói uma linha do tempo através de quatro sistemas, são um subconjunto bem menor que quase ninguém separa nos relatórios.
Há ainda a recorrência, que chega disfarçada de trabalho novo. Um problema que a equipe resolveu em março volta em setembro sob um número de caso diferente, e nada na fila sinaliza que aquele padrão já foi visto antes. A soma de tudo isso forma o que Gidwani chama de economia da investigação: a quantidade crescente de tempo de engenharia e esforço organizacional gastos para reconstruir o que aconteceu, por que aconteceu e se já foi visto antes.
Comece a medir a investigação
Para quem gerencia tecnologia em uma empresa prestes a entregar muito mais software do que antes, a instrumentação importa mais que a estratégia. O primeiro passo é contar escalonamentos e investigações separadamente. O segundo número é menor e muito mais caro, e a proporção entre eles pode surpreender.
Retire o tempo até a causa raiz do tempo total de resolução. Se você acompanhar apenas o segundo indicador, pode passar um ano melhorando-o enquanto o primeiro permanece completamente estável. A métrica dirá que as coisas estão indo bem, mas a investigação continuará lenta. A pergunta desconfortável vem em seguida: quando alguém finalmente descobre por que um incidente aconteceu, para onde vai esse entendimento? Se a resposta honesta for um comentário em ticket, um thread de chat ou a cabeça de uma pessoa, você está operando uma organização incapaz de capitalizar o que aprende.
Isso era sobrevivível quando a mudança era cara e lenta. Não sobreviverá ao volume que está chegando. A restrição mudou de lugar: durante 20 anos, ficou no lado da produção, e foi para lá que o dinheiro em ferramentas foi direcionado. Esse lado está sendo resolvido diante de nós. O que sobra é o lado que ninguém instrumentou: reconstruir o que aconteceu, vinculá-lo ao que mudou e manter a resposta em algum lugar onde a próxima pessoa possa encontrá-la.
Na avaliação do Mercado de TI, equipes que adotam IA agentic no desenvolvimento de software precisam tratar a documentação de intenção como artefato de primeira classe. Sem isso, a velocidade de entrega vira dívida operacional invisível. O gargalo silencioso dos pull requests gigantes gerados por IA é um sintoma precoce desse descompasso.
Principais pontos
Curvas divergentes: o custo de produzir mudanças caiu com agentes de IA, mas o custo de entender falhas permaneceu praticamente estável por uma década.
Perda de intenção: quando o agente escreve o código, o registro durável de intenção pode não existir, eliminando o atalho clássico de perguntar ao autor.
Métricas cegas: o tempo de investigação fica embutido na janela de resolução e não é medido separadamente.
Economia da investigação: tempo e esforço crescentes para reconstruir o que aconteceu, por que aconteceu e se o problema é recorrente.
Organizações que não acumulam aprendizado: se o entendimento pós-incidente fica em ticket, chat ou na cabeça de alguém, a empresa não capitaliza o que aprende.
Dica: instrumente agora a separação entre escalonamento e investigação no seu time. A proporção entre esses dois números costuma revelar um custo oculto que nenhum dashboard de nível de serviço captura.
Para equipes que operam em ciclos acelerados de entrega, a lição é direta: a velocidade de produção não elimina a necessidade de memória organizacional. As empresas que vencerem a próxima década serão aquelas capazes de explicar o que aconteceu quando o código quebrou, não apenas as que entregam mais rápido.
Fonte: Forbes Technology Council
