Os Quatro Pilares do Software na Era da IA Não São Iguais

O desenvolvimento de software moderno costuma ser descrito como quatro pilares interligados: velocidade e agilidade, automação por IA, visibilidade ampliada por testes e observabilidade, e segurança e governança embutidas. O enquadramento é útil, e quase todo mundo trata os pilares como itens equivalentes, quatro coisas para financiar em medida parecida. Essa simetria é o erro. Três dos quatro pilares fazem o mesmo trabalho: multiplicam a velocidade com que o código chega à produção. Só um aumenta a taxa com que você consegue verificar que esse código é seguro de manter.

Conte as entradas. A IA generativa escreve funções, testes e documentação. A McKinsey constatou que ela cortou pela metade, aproximadamente, o tempo de documentação de código e reduziu de forma relevante o tempo de geração e refatoração (McKinsey, junho de 2023). Plataformas low-code permitem que desenvolvedores cidadãos entreguem aplicações funcionais em dias, onde antes levavam sprints. A automação de DevOps remove as etapas manuais de aprovação que antes freavam os lançamentos: na pesquisa de 2024 da CD Foundation, 83% dos desenvolvedores estavam envolvidos em atividades de DevOps, e o uso mais amplo dessas tecnologias acompanhou um lead time de mudança menor e uma restauração de serviço mais rápida (CD Foundation, 2024). Três pilares, uma direção. Mais código, mais rápido, vindo de mais gente.

Agora conte o que escala a revisão. O quarto pilar, visibilidade mais governança, é o único cujo trabalho é absorver essa enxurrada: testá-la, observá-la em produção, provar conformidade e pegar a mudança que não deveria ter entrado. Financie a governança como um quarto item equivalente e ela disputa o mesmo orçamento com a velocidade. Sob pressão de prazo, a velocidade vence todo trimestre. Construa-a como o piso sobre o qual os outros três se apoiam, e ela vira aquilo que torna a velocidade sustentável.

A assimetria é estrutural

A assimetria vem da aritmética, antes de qualquer juízo de valor sobre segurança. Se três dos seus quatro investimentos elevam o volume de código que entra no sistema e só um eleva a capacidade de revisar o que entrou, então, com financiamento igual, sua capacidade de revisão fica para trás por construção. As entradas se acumulam. Um time que dobra sua vazão de geração dobrou a carga sobre a mesma esteira de revisão, a menos que essa esteira também tenha escalado.

A narrativa clássica de produtividade do desenvolvedor escondia isso porque media o eixo errado. Já escrevemos sobre como o tempo-até-merge favorece o lado da geração e ignora o custo que ele empurra rio abaixo (veja por que a McKinsey mediu a coisa errada). O enquadramento dos quatro pilares torna a mesma omissão estrutural. Três pilares são pilares de vazão. Um é verificação. Chame-os de equivalentes e você vai, em silêncio, subfinanciar o único que alivia o problema em vez de agravá-lo.

O que “capacidade de verificação” significa de fato

Capacidade de verificação vai muito além de um número de revisores. É o conjunto inteiro de mecanismos que deixam você confiar na saída sem ler cada linha dela. Testes automatizados que falham alto. Observabilidade que expõe uma regressão em produção antes de um cliente abrir um chamado. Verificações de política que bloqueiam uma mudança não conforme no portão. Linhagem que diz qual agente ou qual pessoa produziu um determinado diff, para que um padrão ruim possa ser rastreado e interrompido na origem.

Quando saíram os números de satisfação da McKinsey, a manchete foi que 87% dos desenvolvedores usando IA generativa conseguiam focar em trabalho significativo, contra 50% dos que não usavam (McKinsey, junho de 2023). Ganho real, que vale a pena ter. A condição silenciosa por baixo dele: esse foco só se mantém enquanto alguém, ou algo, ainda está pegando a saída que não deveria ir para produção. Tire a camada de verificação e a mesma vazão que libertou o desenvolvedor vira aquilo que soterra o revisor. O número de satisfação é um efeito a jusante do piso aguentar.

A parede de revisão que seu gráfico de velocidade não vê

Gráficos de velocidade medem entrada. Histórias fechadas, PRs mesclados, deploys por dia. Eles sobem para a direita exatamente como você esperaria enquanto você financia os três pilares de vazão. O gráfico não mostra nada sobre se sua capacidade de verificar acompanhou o ritmo, porque a falha de verificação não aparece como velocidade menor. Ela aparece depois, como incidentes, como um achado de conformidade, como uma regressão em produção que ninguém pegou porque a observabilidade daquele caminho nunca foi construída, como o acúmulo lento de código que funciona hoje e que ninguém entende amanhã.

Essa é a armadilha de tratar a governança como o quarto pilar equivalente. O custo de subfinanciá-la é invisível no painel que os outros três pilares acendem. Quando o custo fica visível, ele já chegou em forma de incidente, depois que a janela de orçamento fechou. Os times que bateram nessa parede foram pegos de surpresa, porque o instrumento em que confiavam só media a metade do sistema que estava funcionando.

Construa o piso primeiro

A correção mora na ordem das decisões, antes de qualquer aumento de orçamento. Antes de escalar qualquer pilar de vazão, pergunte qual mecanismo de verificação absorve a saída dele. Ligar um assistente de código por IA para o time eleva a vazão de geração agora. A pergunta correspondente é se sua cobertura de testes, sua observabilidade em produção e seus portões de política conseguem pegar o que esse assistente vai produzir em volume. Se não conseguem, você financiou a entrada sem financiar o piso, e iniciou uma contagem regressiva até a parede de revisão.

Na prática, isso conecta com o trabalho de medição ao qual sempre voltamos. Instrumente o par inteiro, modelo e pessoa (meça o time, não o modelo). Feche o laço entre o que os agentes produzem e o que a governança observa (o laço de observabilidade e governança). Mantenha humanos sobre a malha onde a verificação ainda exige julgamento (on the loop, não in the loop). Trate-as como o piso, em vez de iniciativas separadas parafusadas na entrega. Os três pilares de vazão só são seguros até a altura que esse piso aguenta.

Faça isso agora

Pegue seu roadmap atual de entrega com IA e rotule cada iniciativa como vazão ou verificação. Ferramentas de geração, adoção de low-code, automação de CI/CD: vazão. Infraestrutura de testes, observabilidade em produção, portões de política, linhagem: verificação. Depois some o investimento de cada lado. Se a vazão pesa mais que a verificação por uma margem relevante, você está financiando a entrada e deixando o piso faminto, e seu gráfico de velocidade vai continuar subindo até o dia em que não consegue mais. Reequilibre antes da parede, enquanto a correção ainda é uma linha de orçamento e não uma autópsia de incidente. A restrição que aperta na entrega da era da IA mudou de lugar: saiu da velocidade com que você gera código e foi parar na velocidade com que você consegue confiar nele.

Fontes

McKinsey & Company. “Unleashing developer productivity with generative AI.” Junho de 2023.
CD Foundation. “State of CI/CD Report 2024.” 2024.

A Victorino ajuda equipes a construir capacidade de verificação na entrega com IA antes que a parede de revisão chegue: contato@victorino.com.br | www.victorino.com.br