Líderes de pensamento

O AI Está Escrevendo Código, Mas a Sua Infraestrutura Consegue Manter o Ritmo?

mm
Adicione Unite.AI às suas fontes preferidas no Google

Estamos vivendo uma das inversões mais estranhas na história da engenharia de software. Por décadas, o objetivo era o determinismo; construir sistemas que se comportam da mesma maneira todos os dias. Agora, estamos adicionando agentes de IA probabilísticos em cima dessa base, gerando código em uma escala e velocidade alarmantes. E, honestamente? A maioria da nossa infraestrutura não foi projetada para isso.

Eu passei anos trabalhando em ferramentas de DevOps, co-autorando pesquisas e ajudando equipes de engenharia a atingir seu melhor desempenho. O que estou vendo agora com o desenvolvimento impulsionado por IA é mais do que apenas uma evolução. Está exposto todos os problemas em nossos fluxos de trabalho existentes.

O Problema Já Está Aqui

Um estudo de 2025 da GitClear descobriu que quase 7% dos commits agora contêm código gerado por IA. Sua análise anterior de 153 milhões de linhas de código alterado revelou o custo: “code churn” – código reescrito ou excluído dentro de duas semanas – dobrou em 2024 em comparação com os padrões pré-IA.

As implicações de segurança são igualmente graves. Análise recente de 80 tarefas de codificação curadas em mais de 100 grandes modelos de linguagem encontrou que o código gerado por IA introduz vulnerabilidades de segurança em 45% dos casos. O impacto no mundo real? Um em cada cinco CISOs agora relata incidentes importantes causados diretamente pelo código gerado por IA.

Os ganhos de velocidade são reais, mas também são os custos de estabilidade.

O Efeito de Amplificação

Uma coisa que eu aprendi é que a IA amplifica tudo. Se você tem boas práticas, a IA as torna melhores e mais rápidas. Se seus processos são confusos, a IA exacerba essa confusão também. Isso espelha um padrão que aparece ano após ano nos relatórios anuais de DevOps da DORA: menos variáveis levam a melhores resultados. Equipes bem-sucedidas padronizam em menos sistemas operacionais, menos linguagens de programação, menos maneiras de fazer as coisas. Eles reduzem a complexidade deliberadamente.

Os agentes de IA seguem o mesmo padrão. Dê-lhes um ambiente consistente onde Python significa a mesma versão em cada máquina de desenvolvedor, onde as dependências são bloqueadas e rastreadas, e eles excelentes. Force-os a navegar 17 configurações diferentes, cada uma com diferenças sutis, e você está queimando tokens para descobrir peculiaridades ambientais em vez de resolver problemas reais.

O Paradoxo do Determinismo

Isso cria uma tensão fascinante. Por anos, a ciência da computação perseguiu o determinismo como o objetivo final. Agora, estamos executando cargas de trabalho probabilísticas, modelos de IA que literalmente não podem garantir a mesma saída duas vezes, em cima de sistemas projetados para previsibilidade.

Minha resposta? Mantenha o máximo da pilha determinística possível. Se você pode manter 80% da sua infraestrutura em um nível determinístico, os agentes de IA têm menos variáveis para gerenciar. Eles não estão gastando janelas de contexto em “Por que essa dependência não foi instalada?” ou “Vou tentar esse comando de compilação novamente.” Eles estão focados no trabalho real que você está pedindo que eles façam.

Pense sobre isso: quando um agente tenta compilar algo e as ligações nativas falham porque o ImageMagick não está instalado, isso é um desvio caro em tokens. Se o ambiente já inclui tudo o que é necessário (compiladores, bibliotecas, a árvore de dependência completa até o libc), o agente simplesmente funciona. Nenhum depuração, nenhum erro e acerto, apenas progresso.

Especificação e Validação São Chave

O que está se tornando claro é que o desenvolvimento impulsionado por IA nos obriga a pensar mais sobre duas habilidades historicamente subestimadas: especificação e validação. Você precisa articular o que está realmente construindo, e você precisa de maneiras robustas para verificar se você o obteve.

Eu notei algo interessante: pessoas com experiência em gerenciamento de produtos ou engenharia de produtos são frequentemente mais bem-sucedidas com agentes de IA agora. Eles já estão treinados para pensar em termos de requisitos, critérios de sucesso e compensações. Eles estão confortáveis perguntando “Por que você fez essa escolha?” e ajustando com base no raciocínio.

A validação, sabendo se a coisa é realmente correta, sempre foi o problema mais difícil da engenharia de software. A QA foi subestimada por décadas, mas é a parte mais desafiadora: determinar se o software resolve a necessidade real do usuário. A IA não resolve isso. Se algo, ela o torna mais crítico, porque agora você está validando saídas probabilísticas contra requisitos determinísticos.

Confie, Mas Verifique (E Controle)

Há um sentimento que estou começando a abraçar: devemos assumir que o código gerado por IA é hostil até que seja provado o contrário. Não porque a IA é maliciosa, mas porque simplesmente não sabemos. Não podemos auditar cada linha quando os agentes estão gerando milhares de linhas por dia.

Isso significa mudar os pontos de controle. Se não podemos bloquear tudo no tempo de desenvolvimento, precisamos de controles mais fortes no tempo de execução. Operadores, SREs, equipes de plataforma, quem quer que seja responsável pela produção, precisam de melhor visibilidade do que está executando, rastreamento de dependência completo e provação clara para cada artifact.

Aqui é onde a reprodutibilidade se torna essencial. Quando você pode provar matematicamente que o artifact que você testou localmente é idêntico ao que está executando em produção – mesmos inputs, mesmos outputs, mesma closure de dependência – você pode começar a tomar decisões inteligentes. Talvez você não precise executar testes de unidade em CI se você já os executou localmente e nada mudou. Talvez você possa mapear a cobertura de testes para alterações de código e pular conjuntos de testes irrelevantes.

O Que Vem a Seguir

Estamos em um ponto de inflexão. As equipes que já tinham boas práticas estão vendo ganhos de produtividade massivos com a IA. As equipes que estavam lutando agora estão lutando mais rápido.

A infraestrutura que impulsiona o desenvolvimento orientado a IA precisa ser construída para reprodutibilidade desde o início. Não apenas adicionada posteriormente com ferramentas de digitalização e auditorias, mas incorporada em como os desenvolvedores trabalham desde o primeiro dia. Quando o ambiente de desenvolvimento é idêntico em Mac e Linux, quando cada dependência é rastreada e bloqueada, quando você tem provação completa para cada artifact, os agentes de IA se tornam multiplicadores de força em vez de geradores de caos.

Aqui está o meu maior conselho para as equipes que estão tentando ter sucesso na era da IA:

  • Padronize implacavelmente. Menos variáveis correlacionam com melhor desempenho. Bloqueie sua pilha de tecnologia, force ambientes consistentes em todas as plataformas e elimine a deriva de configuração antes que a IA a amplifique. Se as incompatibilidades de versão do Python causam problemas agora, elas causarão 10x mais problemas quando a IA estiver gerando código em escala.

  • Construa a validação em seu fluxo de trabalho, não no final. Com a IA gerando código mais rápido do que os humanos podem revisar, você não pode confiar apenas na revisão de código manual. Implemente testes automatizados que validam não apenas se o código é executado, mas se ele resolve o requisito real. Faça sua pipeline de CI/CD sua rede de segurança, com portas fortes no tempo de execução para implantações de produção.

  • Invista em reprodutibilidade como infraestrutura. Trate a consistência do ambiente como uma preocupação de infraestrutura de primeira classe. Quando você pode provar matematicamente que o ambiente local, o ambiente de CI e o ambiente de produção são idênticos, você elimina uma classe inteira de problemas “funciona na minha máquina”. Essa base determinística é o que permite que você adicione cargas de trabalho de IA probabilísticas em cima.

A pergunta não é se a IA vai escrever a maioria do nosso código. Ela já o faz para muitas equipes. A pergunta é se a nossa infraestrutura consegue manter o ritmo.

Michael Stahnke é um executivo de engenharia experiente, tendo passado os últimos 15+ anos trabalhando no desenvolvimento e operacional de ferramentas, onde também fez pesquisas e foi autor dos Relatórios de Estado de DevOps da Puppet.

Michael é atualmente VP de Engenharia da Flox. Ele foi anteriormente líder de engenharia sênior na CircleCI e Puppet, onde cresceu equipes de engenharia por 5x ou mais. Ele passou tempo construindo equipes de alto desempenho, organizações e pesquisando a eficácia da engenharia, além de trabalhar em sistemas de embalagem e lançamento. Ele tem falado em eventos de DevOps e Automação desde 2007. Ele fundou o repositório de pacotes Extra Packages for Enterprise Linux (EPEL) e escreveu um livro sobre OpenSSH em 2005.