Você Não Ficou Mais Rápido. Você Deu Corda numa Catraca.

“Conformidade só gira para cima; nunca gira para baixo.” Paul Stovell, fundador e CEO da Octopus Deploy, escreveu isso em julho de 2026, e a imagem mecânica carrega o argumento inteiro. A lingueta cai no dente. A roda gira para um lado. Ali ela trava.

Isso soa como reclamação sobre burocracia. A contabilidade por trás é o que deveria preocupar. Todo controle que a sua organização adicionou depois de um incidente continua lá. O comitê de aprovação de mudanças que era para ser temporário. O segundo aprovador na configuração de produção. A revisão obrigatória de segurança que nasceu escopada em um serviço e silenciosamente passou a cobrir todos. Ninguém removeu nada disso, porque remover um controle exige alguém assinar embaixo da frase “esta salvaguarda não é mais necessária”, e ninguém quer essa assinatura arquivada quando o próximo incidente acontecer.

Velocidade de Conformidade É a Métrica que Ninguém Publica

A observação mais afiada de Stovell é sobre atenção. “Falamos o tempo todo de velocidade de desenvolvimento”, ele escreve, “mas raramente falamos de velocidade de conformidade.” Organizações acompanham frequência de deploy, lead time, taxa de falha em mudanças. Não acompanham a velocidade com que a própria máquina de aprovação e auditoria consegue absorver trabalho, que é o teto real.

Empurre mais mudanças por um pipeline cuja maquinaria de segurança não mudou, e ela responde do único jeito que sabe. Mais mudanças produzem mais incidentes em números absolutos mesmo com a taxa de falha por mudança estável. Mais incidentes produzem mais controles. Os controles desaceleram a vazão de volta para perto de onde ela começou. Nas palavras de Stovell: “Se a IA faz você entregar mais rápido sem fazer você entregar mais seguro, você não está ficando mais produtivo, está apenas apertando um pouco mais a catraca de conformidade, e essa não afrouxa.”

Essa última oração é a parte que merece discussão. É ela que torna tudo irreversível.

Já argumentamos que a revisão é a restrição que a IA não alivia e que geração barata carrega custo caro de qualidade lá na frente. Stovell acrescenta uma propriedade ausente nos dois: direção. O custo se trava no lugar em vez de chegar atrasado e se diluir.

Um trade-off pode ser reequilibrado depois. Você compra velocidade agora, descobre que ela custou estabilidade e recua no trimestre seguinte. A catraca opera por outra lógica. O ganho de vazão é temporário e o peso de processo é permanente. Dezoito meses depois de um programa de aceleração com IA, a organização que não investiu em segurança de mudança está de volta a mais ou menos a vazão antiga, carregando um processo de revisão sensivelmente mais pesado do que aquele com que começou. O investimento em IA comprou um procedimento.

Stovell também nomeia o modo de falha para o qual os times correm quando a dor chega: consertar localmente, com força bruta. O exemplo dele é o time que responde a um incidente de acesso decidindo que “ninguém tem acesso a produção, nunca, para nada”. Como ele diz, isso “resolve o problema imediato e cria uma dúzia de novos”. O conserto local está sempre disponível e sempre gira a roda mais um dente. Ele também costuma chegar com nome novo, que é como um time se convence de ter removido um controle enquanto adiciona outro.

O que Nenhum dos Dois Artigos Mediu

Os dois textos que sustentam esta análise valem a leitura, e ambos devem ser lidos pelo argumento, não pela evidência. Nenhum deles contém uma única estatística medida.

Todo número no ensaio de Stovell é uma ilustração hipotética que ele constrói para tornar a mecânica visível. As cem mudanças por dia que viram duzentas, os vazamentos por ano, as horas de teste de interface: são valores de um experimento mental, jamais observações da base instalada da Octopus Deploy. Ele deixa isso explícito. Quem citar esses números como dado de mercado está fabricando evidência que não existe.

A contribuição do GitHub é mais estranha. Dalia Abuadas, engenheira do time do Copilot Agent Control Plane no GitHub, publicou um argumento sobre a economia de aceitar mudanças geradas por IA sem citar um único número da telemetria do próprio Copilot. O GitHub tem mais dados sobre exatamente essa pergunta do que quase qualquer organização do planeta. Essa ausência faz parte da história, e vale manter em mente quando o argumento soar convincente.

Os dois autores também têm vínculo com fornecedores alinhados às próprias conclusões. A Octopus Deploy vende ferramental de deploy e conformidade; um mundo preocupado com velocidade de conformidade é um bom mundo para a Octopus. Abuadas constrói a camada de governança de subagentes do Copilot; um mundo que precisa de saída de agente restrita e governada é um bom mundo para essa camada. Os argumentos continuam de pé. Continuam de pé como argumentos.

Gerar É Barato. Ser Dono, Não.

Abuadas fornece o mecanismo que o ensaio de Stovell deixa implícito: “A IA reduz o custo de produzir um candidato. Ela não faz nada para reduzir o custo de ser dono de um.”

Ser dono de uma mudança significa revisá-la, entendê-la, defendê-la numa revisão de incidente às duas da manhã e alterá-la daqui a seis meses quando o requisito mudar. Nenhum desses custos se mexeu. A formulação dela é precisa: “Uma mudança não é barata só porque o código foi barato de gerar. Ela é barata apenas se um humano puder revisar e assumir o resultado com confiança.”

Isso redefine para que serve um patch gerado por IA. Abuadas chama a primeira tentativa de “uma consulta de preço, não o produto”. A função dela é revelar quanto resolver o problema custaria em propriedade, e o formato do que volta é a resposta. Um diff enxuto nos arquivos que você esperava significa que o trabalho era do tamanho que você imaginava. Um espalhamento por cinco pacotes com uma nova superfície de configuração significa que o pedido era maior do que o ticket admitia.

A categoria mais afiada dela é a mudança que se revela “uma decisão de produto vestida de fantasia de implementação”. Um agente encarregado de tratar um caso de borda vai alegremente inventar uma política para ele, codificar essa política num condicional e devolver aquilo como trabalho de engenharia. Ninguém na cadeia de revisão percebe que uma decisão de produto acabou de ser tomada por um modelo e ratificada por um revisor que achava estar aprovando a correção de um bug.

A Tentativa Restrita

O artefato que vale roubar do texto de Abuadas é o contrato que ela anexa a uma primeira tentativa. Cinco regras, entregues ao agente logo no início:

Faça o menor patch possível.
Mantenha tudo atrás da feature flag existente.
Não altere o contrato público.
Adicione ou atualize testes.
Liste todo arquivo tocado e sinalize qualquer coisa arriscada.

O mecanismo está no que acontece quando falha. Se o agente não consegue satisfazer o contrato, o pedido era maior do que você imaginava. O contrato deixa de ser guia de estilo e vira instrumento: uma sonda de dimensionamento barata e automática, executada antes que qualquer humano gaste atenção.

Atrás dele vem a lista de verificação de revisão, cinco perguntas dirigidas ao diff em vez de ao código:

Tocou os arquivos que você esperava ou se espalhou por cinco pacotes?
Os testes são óbvios ou a mudança resiste a ser testada?
Preserva as abstrações existentes?
Exige silenciosamente uma nova decisão de produto?
Você ficaria confortável sendo dono disso daqui a seis meses?

A última pergunta é o modelo de precificação. Todo o resto é instrumentação para respondê-la.

Faça Isto Agora

Pegue suas próximas dez mudanças assistidas por IA e passe todas por uma regra única: nenhum orçamento de revisão é gasto antes de a mudança passar por uma tentativa restrita. Escreva as cinco regras no prompt do seu agente ou no template de PR ainda esta semana. Quando uma mudança falhar o contrato, não conserte o patch. Divida o ticket.

Depois rode um número para a liderança. Pegue os controles adicionados nos últimos vinte e quatro meses, conte quantos foram removidos e coloque as duas cifras no mesmo slide. Na maioria das organizações a segunda é zero. Essa é a catraca, medida na sua própria maquinaria em vez de na ilustração de outra pessoa, e é a única versão deste argumento que o seu CFO vai achar convincente.

As organizações que saírem à frente nos próximos dois anos serão as que gastaram sua atenção escassa de revisão apenas onde a propriedade era de fato cara, e se recusaram a girar a roda pelo resto. Volume de código terá muito pouco a ver com isso.

Fontes

Octopus Deploy. “The Compliance Ratchet.” Julho de 2026.
GitHub. “The cost of saying yes has changed.” Julho de 2026.

A Victorino ajuda organizações de engenharia a precificar mudanças pelo custo de propriedade e a gastar capacidade de revisão onde ela de fato paga: contato@victorino.com.br | www.victorino.com.br