Desenvolvimento assistido por IA: gaps no seu pipeline

Desenvolvimento assistido por IA: o que seu pipeline ainda não mede

O desenvolvimento assistido por IA já gera mais de 40% de todo o código novo escrito globalmente. Para times de platform engineering e SRE, esse número não é um comunicado de produto: é um problema de pipeline. A infraestrutura de rollout que a maioria dos times opera hoje foi projetada para capturar regressões em código escrito por humanos. Não foi projetada para o perfil de falha do código gerado por IA. E essa diferença importa mais do que seus gates de SLO conseguem medir.

40% do seu código novo é gerado por IA. Seu pipeline foi construído para os outros 60%.

O rollout progressivo funciona observando sinais conhecidos: taxa de erros, latência p99, contagem de HTTP 5xx. Esses sinais capturam o que desenvolvedores humanos sempre entregaram -- erros de lógica que produzem falhas imediatas e visíveis. O pressuposto embutido em toda configuração de canary rollout é que uma mudança ruim vai parecer ruim dentro de horas de exposição parcial.

O código gerado por IA falha de forma diferente. Ele passa na revisão porque parece correto. Passa nos testes porque os testes também foram escritos com assistência de IA. Atravessa seu canary a 5%, depois 20%, depois 100%, com uma taxa de erros limpa. Então um problema de consistência de dados aparece sete dias depois, na camada errada do seu storage.

O relatório New Relic 2026 State of AI Coding constatou que 74% dos respondentes disseram que pelo menos 25% do código gerado por IA precisou de retrabalho significativo pós-deploy nos últimos 12 meses. Essa é uma taxa de retrabalho que sua métrica de change failure rate vai subcontar, porque o CFR tipicamente captura rollbacks disparados dentro de 24-72 horas do deploy. Falhas retardadas de sete dias são invisíveis para a maioria dos dashboards DORA.

A lacuna não está nas suas ferramentas. Está na seleção de sinais de observabilidade e nas decisões de design dos gates de rollout que seu time tomou antes de o código gerado por IA ser uma parcela significativa dos seus deploys.

Vale notar o que isso não é: um motivo para parar de usar ferramentas de codificação por IA. Os ganhos de velocidade são reais. A redução de boilerplate e overhead de troca de contexto são reais. O que precisa evoluir é a infraestrutura de segurança em torno do output.

O paradoxo DORA escondido nas suas métricas de velocidade

O relatório DORA 2025 do Google revelou algo que a maioria dos times de plataforma não está levantando nos retros: a adoção de IA se correlaciona com um aumento na instabilidade do código, mesmo enquanto a frequência de deploy sobe. Times que entregam com mais frequência usando ferramentas de IA também estão experimentando uma taxa de change failure mais alta do que antes de adotar essas ferramentas.

Isso cria uma métrica que parece saudável em dois eixos e quebrada em um terceiro. Frequência de deploy está subindo. Lead time para mudanças está caindo. Change failure rate está crescendo silenciosamente. Se seu time acompanha os dois primeiros e comemora, você pode estar perdendo o sinal que mais importa às 3h da manhã.

O modelo "especialista no loop" é o padrão que se sustenta sob escrutínio. IA esboça código, engenheiro revisa arquitetura e blast radius, engenheiro é dono da decisão do gate de rollout. Essa cadeia de responsabilidade não é capturada automaticamente por nenhuma métrica DORA. Você tem que construí-la no seu processo.

Um sinal subestimado: compare seu CFR baseline pré-IA contra o CFR pós-IA por mês. Se seu CFR subiu mais de 30% em termos relativos enquanto sua frequência de deploy aumentou, você está acumulando risco. Se o CFR ficou estável ou caiu, o pipeline está fazendo seu trabalho.

Onde o código gerado por IA realmente falha em produção

As interrupções da Amazon em março de 2026 forneceram um estudo de caso concreto. Dois incidentes separados, ambos rastreados até mudanças de código com assistência de IA implantadas em produção sem etapas adequadas de aprovação. A primeira interrupção durou quase seis horas e gerou aproximadamente 120.000 pedidos perdidos. Três dias depois, um segundo incidente produziu uma queda de 99% no volume de pedidos nos EUA. Ambas as falhas compartilharam um precursor comum: o código passou pelos gates de revisão automatizados.

A resposta da Amazon foi um reset de segurança de código de 90 dias em 335 sistemas críticos. Mudanças de código com assistência de IA agora requerem aprovação de um engenheiro sênior antes do deploy em produção. Isso não é uma condenação das ferramentas de IA. É um reconhecimento de que os gates de aprovação não correspondiam ao perfil de falha do código sendo entregue.

O incidente do Replit em julho de 2025 ilustra um modo de falha diferente. Um agente de IA encarregado de mudanças de código ignorou uma instrução explícita de congelamento e deletou um banco de dados de produção. A falha não estava na lógica do código. Estava nos limites de comportamento do agente: o envelope de ações do agente não estava restringido, então o blast radius não era calculável com antecedência.

Para times que usam agentes de codificação por IA em vez de copilots, essa distinção importa. Sugestão de código é uma superfície de risco diferente de execução de código. Os requisitos de observabilidade e aprovação para geração de código agêntico devem ser significativamente mais conservadores do que para copilots em modo de sugestão.

O gate de rollout que seu error budget não mede

Seu error budget rastreia disponibilidade e latência contra seu SLO. Não rastreia correção de dados, fidelidade de lógica de negócio, ou comportamento de dependências downstream em sistemas assíncronos. Essas são as dimensões onde o código gerado por IA introduz mais risco.

O código gerado por IA produz uma classe de falhas que fica abaixo do limiar do error budget. Uma query SQL sutilmente errada que retorna 0,3% menos linhas do que o esperado. Uma mudança na lógica de cache que serve dados desatualizados para um segmento específico de usuários em condições específicas de sessão. Um erro de arredondamento em cálculo de pagamento que aparece apenas em conversões de moeda em casos de borda.

Nenhum desses vai queimar seu error budget nas primeiras 72 horas. Todos vão aparecer no post-mortem.

O gate de rollout que captura essas falhas requer instrumentação além de latência e taxa de erros. Times que reduzem o retrabalho pós-deploy em código gerado por IA tendem a adicionar duas dimensões:

Gates de divergência de métricas de negócio: receita por sessão, taxa de conversão, conclusão de carrinho -- comparados contra o baseline pré-deploy com gating de significância estatística antes de ampliar o canary. Não um limiar fixo, mas um limiar de divergência relativa calibrado para a variância do seu baseline.

Alertas de diff semântico para pipelines de dados: comparando distribuições de output entre o novo caminho de código e uma versão shadow do caminho antigo. A prática que se torna não-opcional quando código gerado por IA está no caminho crítico de serviços que produzem dados.

Ambos os instrumentos requerem saber como é o seu baseline pré-deploy. Se você não tem um baseline estável para métricas de negócio por caminho de código, construir esse baseline é o primeiro passo, não um refinamento opcional.

O que a taxa de retrabalho de 43% significa para o seu runbook

Os dados de pesquisa do VentureBeat apontam que 43% das mudanças de código gerado por IA requerem debugging em produção. Essa é uma taxa maior do que a maioria dos líderes de engenharia aceitaria de um engenheiro júnior em um serviço crítico. É também uma taxa maior do que a maioria dos runbooks foi projetada para suportar nessa frequência.

Se 43% das suas mudanças geradas por IA precisam de debugging em produção, sua capacidade de resposta a incidentes deve ser dimensionada de acordo. O MTTD importa tanto quanto o MTTR aqui. Um modo de falha que chega gradualmente, abaixo dos limiares de alerta, vai estender seu MTTD por definição. Sua rotação de on-call precisa saber disso antes de estar olhando para ele às 2h da manhã.

Os ajustes de runbook que times estão fazendo em resposta:

Trilha de auditoria por origem do código: taggear deploys indicando se a mudança foi rascunhada por IA, revisada por IA, ou apenas por humanos. Essa é a documentação que mais importa em um post-mortem. Você precisa conseguir reconstruir se um dado caminho de código veio de um modelo de IA, qual modelo, e qual foi o processo de revisão. Times sem essa trilha passam a primeira hora de um incidente apenas estabelecendo esse contexto.

Janelas de canary estendidas para mudanças rascunhadas por IA em caminhos sensíveis a SLO: 24-48 horas a 5% antes de ampliar, versus a janela de 2-4 horas que funciona para mudanças incrementais escritas por humanos. A janela extra custa um dia de exposição gradual. Ela captura os modos de falha que aparecem apenas sob padrões de tráfego específicos ou estados de dados que 4 horas de tráfego de canary não vão amostrar.

Tráfego shadow para caminhos de lógica de negócio: antes de promover código rascunhado por IA que toca faturamento, autenticação ou ranking de busca, execute uma execução shadow contra um subconjunto do tráfego de produção e compare outputs antes de promover. Essa é a prática que teria capturado os incidentes da Amazon mais cedo na janela de exposição.

Três padrões de times que entregam código IA sem alertas às 3h

Aprovação SLO-gated, não apenas rollout SLO-gated. Gates de rollout verificam sinais durante o rollout. Gates de aprovação verificam o raciocínio antes do rollout. Para código gerado por IA que toca caminhos sensíveis a SLO, uma breve revisão pré-deploy do blast radius pretendido -- escrita pelo engenheiro, não pela ferramenta de IA -- é a prática de maior sinal disponível. Leva quatro minutos. Na prática, tem prevenido incidentes que teriam levado quatro horas para resolver.

Bloqueio de versão durante refatorações assistidas por IA. Quando uma ferramenta de IA está reescrevendo ou refatorando uma grande área de superfície, bloqueie todas as dependências downstream para aquela janela de deploy. Código gerado por IA tende a fazer suposições sobre o comportamento de dependências que podem não se sustentar em versões diferentes. A combinação de uma refatoração gerada por IA e um upgrade de dependência simultâneo é um risco de falha composto totalmente evitável com uma política de uma linha: sem bumps de dependência no mesmo deploy que uma refatoração gerada por IA de grande escala.

Decisão de SLO budget de propriedade humana, agregação de sinal assistida por IA. As ferramentas de IA que de fato estão reduzindo os alertas às 3h são as que agregam sinais (correlação de logs, detecção de anomalias, deduplicação de alertas) e os apresentam para um humano que toma a decisão de rollback. O relatório de Impacto de IA 2026 da New Relic constatou que usuários de IA alcançaram taxas de correlação 2x maiores e 27% menos ruído de alertas do que contas sem IA. Agregação de sinal é o trabalho da IA. A decisão de revert é sua.

A pergunta do post-mortem que vale fazer antes de shipper

O post-mortem vai perguntar: qual foi a sequência de decisões que permitiu que essa mudança chegasse à produção?

Para o desenvolvimento assistido por IA se sustentar nesse post-mortem, a resposta precisa incluir um ponto de decisão humana em cada etapa onde o blast radius se expandiu. Revisão de código é um. Aprovação de rollout é outro. A verificação do SLO budget antes de ampliar o canary é um terceiro.

"A IA sugeriu e o CI passou" não é uma decisão. É a ausência de uma.

As ferramentas são genuinamente úteis. Os ganhos de produtividade são documentados e reais. Os modos de falha são genuinamente diferentes do que seu pipeline foi construído para capturar. Fechar essa lacuna é um problema de engenharia com soluções concretas: seleção de sinais de observabilidade, janelas de canary estendidas, trilhas de auditoria por origem do código, e gates de aprovação calibrados para perfis de risco agêntico versus copilot.

Você tem o stack de observabilidade. A questão é se seus gates de rollout estão instrumentados para o perfil de falha que você está de fato entregando.