Radar Tech: quando a IA resolve o incidente, quem fica sem treino é você — o debate sobre a Ironia da Automação

O Radar Tech de hoje abre com uma discussão que dominou o Hacker News nas últimas 24 horas — mais de 330 comentários e crescendo — sobre um problema que não é de amanhã, é de hoje: quando a IA passa a resolver os incidentes rotineiros da sua operação, os seus engenheiros param de ganhar prática no lugar que mais precisam — o incidente raro e grave que a IA não sabe resolver.

O ponto de partida é o ensaio de Sylvain Kalache (hoje AI Labs lead e DevRel na Rootly, ex-engenheiro SRE do LinkedIn e fundador da Holberton School), "AI handles incidents, engineers lose touch with their systems", publicado em 04/09/2026.

O resumo do dia

Ferramentas chamadas de "AI-SRE" já fazem, na prática, o que ainda era protótipo quando Kalache era SRE em 2012: inspecionar alertas, formar hipóteses, consultar telemetria, correlacionar deploys e até aplicar o fix. Para casos rotineiros — um pico de latência, um throttle, uma capacity issue de madrugada — é quase mágico: o alerta toca e você não acorda.

O problema é exatamente aí. Esses casos rotineiros eram a forma "segura" de o humano desenvolver intuição sobre como o sistema se comporta e falha. Quando a IA absorve o rotineiro, o humano continua responsável — por contrato — pelos casos novos, ambíguos e de alta severidade. E chega neles com muito menos reps do que antes.

• Na média, melhora: o MTTR cai, porque a IA resolve o que é determinístico.
• Na cauda, piora: o p90 dos incidentes complexos sobe, porque quem assume o SEV0 que a IA não resolve está (re)aprendendo na hora, em produção, sob pressão e com o CEO no grupo.

Isso tem nome: Ironias da Automação

O fenômeno é antigo e bem documentado. A pesquisadora de fatores humanos Lisanne Bainbridge descreveu em 1983, no clássico The Ironies of Automation, o paradoxo: a automação reduz a prática do operador nas tarefas rotineiras justamente enquanto o deixa responsável pelas situações novas e anormais — o que significa que os humanos precisariam de mais treino, não menos. A frase de 1983 pousa perfeitamente em 2026 — e foi o nome mais citado no fio de comentários.

Quando o seu agente resolve tudo que pode, a decisão "deixar a IA assumir todo incidente que ela alcançar" é subótima por design: ela otimiza a média e aposta a sua cauda à medida que o time esfria.

A indústria que resolve isso há décadas: a aviação

Os pilotos raríssimo vivem uma falha real de motor em carreira — mas a FAA obriga treino recorrente a cada 6 meses em simulador, incluindo falha de motor na decolagem. Por quê? Porque o treino é separado do trabalho: no simulador você pode praticar o erro catastrófico quantas vezes precisar, sem custo em vidas. Software também deveria separar treino de trabalho — e é aí que entram os game days / simulacros de incidente / chaos direcionado: o "simulador de voo" do SRE.

O modelo operacional anti-deskilling (o que o pacote de hoje desenha)

Não existe ferramenta que "desligue o problema" — existe arquitetura do modelo que resolve, em 3 camadas:

• Trilha de autonomia por fases (shadow → copilot → autônomo-assistido com guardrail), em vez de "liga a IA geral e reza". Só classes SEV2/3 determinísticas ganham autonomia em 90 dias; SEV0/SEV1 nunca no primeiro ciclo.
• Tripwires objetivos de escalação IA → humano: condição testável (confiança < 0.7, 2 rollbacks na mesma janela, classe reservada tipo billing/contábil), nunca "quando o humano achar melhor".
• Mecânica de reps garantida: game day mensal + chaos em canário supervisionado + SLO de prática por engenheiro (≥1 simulacro a cada 30 dias) e um canário de competência — uma métrica que acende se a habilidade de diagnóstico cai, mesmo com tudo "verde" de MTTR.

E, no meio, o shadow mode ganha um papel duplo: além de calibrar a IA antes de qualquer autonomia, cada incidente resolvido vira um debrief de 1 página (sinais lidos, hipóteses descartadas, evidência) que alimenta o recreate — sem nunca substituir a prática real, porque explicação não é treino: você assiste à Serena Williams e não aprende a jogar tênis.

O que os engenheiros apontaram no debate

• "Shadow mode é o simulador" — o modo-sombra é, na prática, o banco de horas de treino do time antes de o agente agir sozinho.
• A analogia da aviação tem limites: software muda em produção, o operador e o autor são as mesmas pessoas, e poucas empresas fazem DR/restore mesmo sem IA — logo, "já fazemos game day" costuma ser mito. Vale modelar isso na decisão, não apenas citar piloto de avião.
• O risco organizacional é real: se treinar virar "tarefa extra", fracassa. O treino precisa entrar na carga, no card de plantão e na avaliação — senão "ela resolve rápido, eu não preciso treinar" vira o novo normal até o dia do SEV0.

O que levar para o seu projeto

• Não otimize só a média. Acompanhe MTTR médio E o p90 dos incidentes complexos lado a lado; a segunda é a que revela se o seu time está esfriando (ou já esfriou).
• Antes de deixar a IA agir, desenhe os reps. Game day/tabletop/chaos é obrigação do plano de autonomia, não "nice to have".
• Decida por política qual fração fica com humano, mesmo que a IA conseguisse resolver — é assim que você mantém o time quente para o que a IA não cobre.
• Nunca deixe IA agir em caixa-preta: se a telemetria não dá contexto ao modelo, primeiro eleve a observabilidade; automação sem contexto é risco, não ganho.

Se você quer transformar isso num processo repetível para o seu time — um ADR + modelo operacional (trilha de autonomia, tripwires, canário de competência e calendário de simulacros) com critérios objetivos de aceite para validar qualquer cenário — vale conferir o prompt-pacote ligado a este Radar: cinco arquivos (prompt-motor, guardrails, contexto com o caso difícil "legado caixa-preta + IA já autônoma", harness de verificação e variações) que rodam com o cenário da sua empresa e entregam a decisão auditável.

Rodapé do Radar: edição ancorada no ensaio "AI handles incidents, engineers lose touch with their systems" (Sylvain Kalache / Rootly, 04/09/2026) e na discussão registrada no Hacker News no dia 05–06/09/2026; autores citados no fio (Bainbridge 1983; apontamentos sobre limites da analogia aérea e sobre DR sem IA) são indicados por tema, não como citação literal. Confirme sempre na fonte primária antes de adotar a decisão na sua organização.