Imagina o cenário: são 3 da manhã, o PagerDuty toca, e o dashboard mostra latência explodindo em 47 microserviços ao mesmo tempo. Seu agente de IA olha pros logs, sugere que é um problema de DNS, e você aprova a correção sem pensar duas vezes. Resolvido em 4 minutos. Volta a dormir.

Três meses depois, acontece um incidente que a IA nunca viu. Algo genuinamente novo. E aí você percebe que não lembra como ler um tcpdump, não sabe mais interpretar flame graphs, e a última vez que abriu um core dump foi em 2024.

Parabéns: você foi deskillado.

O Paradoxo que Ninguém Quer Admitir

Em 1983, a pesquisadora Lisanne Bainbridge publicou um paper chamado “Ironies of Automation” que virou referência em engenharia de sistemas. A tese é tão simples quanto incômoda: quanto mais você automatiza um processo, mais crítico o operador humano se torna nos raros momentos em que a automação falha. Só que, ao mesmo tempo, esse operador tem cada vez menos prática pra lidar com esses momentos.

Quarenta e três anos depois, a gente tá vivendo isso em tempo real na engenharia de software.

Um artigo publicado pela SigNoz no final de outubro de 2026 trouxe essa discussão pro universo de SRE (Site Reliability Engineering) e acertou em cheio. O argumento central é que a IA não está eliminando a profissão de SRE. Está fazendo algo potencialmente pior: corroendo silenciosamente a capacidade desses profissionais de resolver problemas complexos.

A Erosão Acontece nos Dois Sentidos

O problema se divide em duas frentes, e as duas são preocupantes.

Deskilling dos veteranos: SREs experientes que antes investigavam incidentes manualmente, liam logs brutos, formavam hipóteses e testavam teorias sobre o que quebrou, agora delegam tudo isso pra IA. O agente resume os logs. O agente sugere a root cause. O agente até executa o runbook. O SRE vira um aprovador de pull requests da IA.

Resultado? Depois de seis meses nesse modo, a pessoa para de construir modelos mentais de como o sistema funciona. Para de desenvolver aquela intuição de “isso aqui cheira mal” que só vem com horas analisando incidentes na mão.

Never-skilling dos juniors: essa é a parte que me preocupa mais. Junior SREs que entram no mercado hoje já encontram um ambiente onde a IA faz o trabalho pesado. Eles nunca aprendem a debugar de verdade. Nunca passam pela experiência formativa de ficar 4 horas num incidente sem saber o que tá acontecendo, tentando hipótese atrás de hipótese, até finalmente encontrar aquele ponteiro nulo escondido três camadas de abstração abaixo.

É como formar um piloto que nunca voou sem autopilot. No dia que o autopilot pifar a 10 mil metros de altitude, todo mundo no avião vai querer que ele tivesse praticado.

Os Dados que Provam o Ponto

Não é só teoria. Existem dados concretos de outras áreas que mostram exatamente esse padrão.

O caso da endoscopia é particularmente assustador. Médicos que usaram IA para detectar pólipos durante meses ficaram piores do que eram antes quando tiveram que fazer o procedimento sem assistência. A habilidade não ficou parada. Ela regrediu.

Na aviação, a FAA (Federal Aviation Administration) percebeu que pilotos com excesso de dependência do autopilot tinham consciência situacional degradada. A solução? Obrigar horas de voo manual. Ineficiente? Sim. Necessário? Absolutamente.

O Pipeline de Formação Está Quebrando

Vamos pensar em como um SRE se formava antes da era dos agentes de IA:

1. Ano 1: Monitora dashboards, lê alertas, começa a entender o que cada métrica significa
2. Ano 2: Participa de on-call, investiga incidentes simples, aprende a correlacionar logs com métricas
3. Ano 3: Lidera investigações de incidentes médios, escreve postmortems, começa a identificar padrões
4. Ano 4+: Resolve incidentes complexos com múltiplas causas raíz, projeta sistemas mais resilientes

Agora olha como é com IA:

1. Ano 1: A IA resume os dashboards. O junior aprova as sugestões.
2. Ano 2: A IA investiga incidentes. O junior acompanha o relatório gerado.
3. Ano 3: O junior nunca liderou uma investigação de verdade. Tem experiência zero com ambiguidade.
4. Ano 4+: Promovido a senior por tempo de casa, mas sem as habilidades que um senior deveria ter.

Isso é um desastre em câmera lenta. E o pior: vai parecer que tá tudo bem até o dia que não estiver.

63% das Tarefas Automatizadas: A Estatística que Engana

Segundo dados recentes, a IA já automatiza 63% das tarefas de DevOps. Na superfície, parece ótimo. Menos trabalho repetitivo, mais tempo pra pensar em arquitetura e estratégia.

Mas pensa comigo: se 63% do trabalho do dia a dia é automatizado, e esse trabalho era exatamente o que construía a expertise dos engenheiros, o que sobra?

Sobra o gerenciamento da IA. Configurar agentes. Revisar outputs. Aprovar sugestões. Isso não é engenharia de confiabilidade. Isso é supervisão passiva.

# O workflow do SRE em 2026
def handle_incident(alert):
    ai_analysis = ai_agent.analyze(alert)  # IA faz o trabalho
    ai_suggestion = ai_agent.suggest_fix(ai_analysis)  # IA sugere a fix

    # O humano só faz isso:
    if human.approves(ai_suggestion):
        ai_agent.execute(ai_suggestion)

    # Mas e quando isso acontece?
    if ai_agent.confidence < 0.3:
        # "Boa sorte, humano. Você lembra como debugar?"
        human.investigate_manually()  # <-- skill atrofiada

O código acima é uma simplificação, claro. Mas ilustra o ponto: o caminho feliz funciona lindamente. O caminho infeliz (quando a IA não sabe o que fazer) é onde a tragédia mora.

O Contra-Argumento: “Mas Antes Também Existiam Runbooks”

Alguém sempre levanta esse ponto: “Antes da IA, SREs também seguiam runbooks mecânicos. Qual a diferença?”

A diferença é sutil, porém enorme. Quando você segue um runbook manualmente, ainda está lendo os logs. Ainda está interpretando as métricas. Ainda está tomando micro-decisões a cada passo (“esse valor parece normal?”, “será que esse spike de CPU está relacionado?”). O runbook guia, mas não substitui o pensamento.

Quando a IA executa o runbook, você não vê nada disso. Recebe um resumo. E resumos, por definição, perdem informação.

A Solução Parece Idiota (e É Isso Que a Torna Boa)

O artigo da SigNoz propõe algo que vai contra toda a lógica de otimização do mercado: ineficiência deliberada.

A ideia é simples: nem todo incidente que a IA pode resolver deveria ser resolvido pela IA. Alguns incidentes precisam ser tratados como oportunidade de treino.

Na prática, funciona assim:

# Política de treinamento SRE
incident_routing:
  severity_critical:
    handler: ai_agent  # Severidade crítica: IA resolve
    human_role: observer

  severity_high:
    handler: ai_agent
    human_role: active_participant  # Humano investiga junto

  severity_medium:
    handler: human_primary  # Humano lidera, IA assiste
    ai_role: advisor

  severity_low:
    handler: human_only  # Sem IA. Treino puro.
    ai_role: none
    note: "Incidentes P3/P4 são gym sessions"

Isso significa resolver incidentes de baixa severidade mais devagar de propósito? Sim. Significa que o time vai gastar mais tempo em coisas que a IA resolveria em segundos? Sim. E isso é exatamente o ponto.

A FAA entendeu isso com pilotos. Hospitais estão começando a entender com médicos. A pergunta é: quando a indústria de tech vai entender?

O Modelo “Human-in-the-Loop” Não Basta

Muita empresa acha que está segura porque tem um “human-in-the-loop”. O humano revisa o que a IA faz antes de aplicar. Problema resolvido, certo?

Errado.

Human-in-the-loop, na maioria das implementações, é human-rubber-stamping-the-loop. Quando a IA acerta 95% das vezes, o humano para de prestar atenção nos 5% que ela erra. É o mesmo fenômeno do piloto que confia no autopilot: a vigilância humana degrada com o tempo quando as exceções são raras.

O que realmente funciona é “human-in-the-driver-seat”: a IA fornece dados e sugestões, mas o humano toma a decisão ativa. Não é “aprovar ou rejeitar”. É “investigar com assistência”.

A diferença entre aprovar a sugestão da IA e chegar à mesma conclusão com ajuda da IA parece semântica, mas na prática constrói habilidades completamente diferentes.

O Que Vai Acontecer Se Ninguém Agir

Vou fazer um exercício de projeção baseado no que estamos vendo:

2027: Empresas early-adopter de IA para SRE reportam redução de 70% no MTTR (Mean Time to Resolution). Todo mundo comemora. Ninguém pergunta o que aconteceu com as habilidades do time.

2028: Um incidente complexo (falha cascata envolvendo rede, storage e autenticação) atinge uma dessas empresas. A IA não consegue diagnosticar porque nunca viu esse padrão. O time de SRE, que não investiga manualmente há 2 anos, leva 14 horas pra resolver algo que um time skilled resolveria em 3.

2029: Empresas começam a buscar “SREs analógicos”, profissionais que cresceram antes da era da IA e ainda sabem debugar sem assistência. O salário desse perfil triplica. Juniors que nunca aprenderam ficam presos em roles de operador de IA.

Isso não é ficção científica. É a trajetória natural de qualquer tecnologia de automação que ignora o fator humano.

Pra Quem É SRE Hoje: 5 Coisas Pra Fazer Agora

Se você é SRE e está lendo isso, aqui vai um plano de ação concreto:

1. Desliga a IA uma vez por semana durante o on-call de P3/P4

Sério. Investiga os incidentes de baixa severidade na mão. Lê os logs. Forma hipóteses. É desconfortável? Ótimo. Desconforto é sinal de que você está aprendendo (ou reaprendendo).

2. Mantém um “incident journal” pessoal

Anota como você investigou cada incidente. Que hipóteses formou. Quais descartou e por quê. Isso força seu cérebro a processar ativamente em vez de delegar pro agente.

3. Faz chaos engineering manual

Não estou falando de rodar Chaos Monkey automatizado. Estou falando de injetar falhas manualmente e tentar diagnosticar sem IA. Game days onde a regra é: sem copiloto.

4. Lê postmortems de outras empresas

O Google, a Meta e a Cloudflare publicam postmortems detalhados. Cada um é um case study grátis. Leia e tente resolver mentalmente antes de ver a solução.

5. Ensina alguém junior sem IA

Pair programming de incidentes com juniors, onde vocês dois investigam sem assistência de IA. Isso força você a articular seu raciocínio e reforça os modelos mentais.

A Analogia do Músculo que Ninguém Quer Ouvir

Eu sei que parece clichê, mas é preciso: habilidade de debugging é um músculo. Se você não usa, atrofia. E a IA, da forma como está sendo implementada na maioria das empresas, é uma cadeira de rodas pra quem pode andar.

Não existe atalho. Não existe “eu deixo a IA fazer o dia a dia e quando precisar eu volto a debugar”. Não funciona assim. Pergunte pros endoscopistas que viram sua taxa de detecção cair 6 pontos percentuais.

A IA é uma ferramenta absurdamente poderosa. Eu uso e recomendo. Mas ferramenta poderosa nas mãos de alguém que não entende o que está fazendo é só um acidente esperando acontecer.

A pergunta não é se a IA vai substituir SREs. A resposta pra isso é não, pelo menos não nos próximos anos. A pergunta real, a que deveria tirar o sono de todo CTO e VP de Engineering, é: quando o próximo incidente complexo bater, seu time ainda vai saber o que fazer?

Porque a IA não sabe. E se você também não souber, aí sim vai precisar atualizar o LinkedIn.

—

Fonte de inspiração: AI isn’t replacing SREs, it’s deskilling them