A melhor pessoa de operações com quem já trabalhei passava boa parte do tempo lendo um livro na mesa. Os deploys — releases automatizados de código novo para servidores em produção — saíam no horário. Ela resolvia incidentes antes de qualquer um perceber. O onboarding de novos funcionários funcionava como um relógio.

O gestor dela quase a demitiu por "não parecer ocupada o suficiente."

Ela não estava ociosa. Ela tinha terminado.

O gap que ninguém comenta

A cultura de trabalho recompensa esforço visível. O desenvolvedor digitando freneticamente parece produtivo. O que fica olhando pro teto por vinte minutos — pensando na arquitetura — parece preguiçoso. A pessoa respondendo e-mails às onze da noite ganha o rótulo de "dedicada." A que sai no horário ganha o de "não veste a camisa."

Um estudo de 2022 de pesquisadores da Columbia, Georgetown e Harvard confirmou o que gente de ops já sabia: gestores consistentemente avaliaram funcionários que "pareciam ocupados" como mais competentes, mesmo quando a entrega real ficava abaixo da de colegas mais tranquilos. A gente recompensa a aparência de trabalho, não o trabalho em si.

Em 12 de março, a PagerDuty apresentou seu SRE Agent como respondente virtual — um software que detecta quedas, roda diagnósticos e segue procedimentos de correção sem um humano tocar no teclado. Quatro dias depois, na GTC em 16 de março, a NVIDIA anunciou o Agent Toolkit com OpenShell — infraestrutura para rodar agentes autônomos de operações com segurança em produção. Em 24 de março, no YC Demo Day, startups como a IncidentFox apresentaram resposta autônoma a incidentes como produto principal. O sinal do mercado é claro: se uma tarefa segue um padrão previsível, um humano não deveria fazê-la na mão.

O que levanta uma pergunta que times de ops do mundo inteiro agora encaram: se agentes de IA — programas que agem por conta própria, tomando decisões e executando passos sem supervisão humana constante — cuidam do combate visível a incêndios, o que uma pessoa de ops faz o dia inteiro?

A resposta não mudou. Mas a urgência de entendê-la, sim.

Em operações, a velha estrutura de incentivos cria uma dinâmica perversa — um sistema que recompensa exatamente o comportamento errado. Se a empresa te valoriza por apagar incêndios, você tem zero motivação para preveni-los. Se seu gestor mede seu valor pela quantidade de mensagens urgentes no Slack que você responde, construir sistemas que eliminam essas mensagens te faz parecer dispensável. E agora agentes de IA também apagam incêndios. Mais rápido. Sem dormir. Sem reclamar.

O paradoxo no coração de ops

Quanto melhor você é em operações, menos parece que você faz. Um bombeiro que previne incêndios parece desempregado. Uma pessoa de ops cujos sistemas nunca quebram parece estar enrolando. O trabalho visível desaparece justamente porque alguém fez o trabalho invisível direito.

Eu vejo esse padrão se repetir há anos. A pessoa de ops que automatiza o próprio trabalho recebe a pergunta: "O que você faz o dia inteiro?" A que resolve tudo manualmente, trabalhando doze horas por dia, é promovida por "vestir a camisa."

Uma construiu um sistema. A outra construiu uma dependência em si mesma. Pergunte a si mesmo de qual a empresa realmente precisa — e qual delas um agente de IA substitui primeiro.

Como ops de verdade funciona na prática

Bom trabalho de operações acontece em duas fases.

Fase 1: Construir os sistemas. Essa parte é visível e tem prazo definido. Escrever runbooks — guias passo a passo para lidar com situações específicas. Configurar monitoramento — verificações automatizadas que detectam problemas antes dos usuários perceberem. Criar automações para tarefas repetitivas. Documentar processos para que qualquer pessoa consiga seguir. Essa fase é intensa: tipicamente de dois a seis meses de trabalho focado.

Fase 2: Manter os sistemas. É aqui que a confusão começa. Os sistemas rodam. Alertas disparam e runbooks os resolvem — cada vez mais, agentes de IA executam esses runbooks sem intervenção humana. Novos funcionários fazem onboarding sozinhos através de processos documentados. Deploys fluem por pipelines de CI/CD — sequências automatizadas que movem código do laptop do desenvolvedor para servidores de produção sem passos manuais.

O trabalho da pessoa de ops na Fase 2: observar padrões que indicam degradação de um sistema. Conduzir post-mortems — revisões estruturadas do que deu errado e por quê. Planejar capacidade futura. Decidir quais novos processos entregar para agentes e quais ainda exigem julgamento humano. Ler. Estudar. Pensar.

Essa última parte parece "não fazer nada." Mas uma pessoa de ops que não está estudando novas ferramentas, modelando cenários de falha, avaliando quais frameworks de agentes se encaixam na infraestrutura e planejando para situações que ainda não aconteceram vai ser pega desprevenida quando elas acontecerem. O handbook de Site Reliability Engineering do Google coloca de forma direta: o trabalho é engenheirar confiabilidade, não recuperar heroicamente da ausência dela.

Ocupado é um bug report

Vou falar a parte que ninguém quer ouvir: estar constantemente ocupado sinaliza sistemas quebrados, não dedicação.

Sempre apagando incêndio? Seus sistemas de prevenção falharam. Sempre trocando de contexto — pulando entre tarefas não relacionadas a cada poucos minutos? Sua priorização falhou. Sempre em reunião? Seus sistemas de comunicação falharam. Sempre treinando gente nova na mão? Seu onboarding falhou.

"Ocupado" não é um estado para se orgulhar. "Ocupado" é um bug report.

O objetivo de operações — e honestamente, da maioria do trabalho do conhecimento — é chegar a um estado onde os sistemas lidam com os noventa por cento previsíveis e você tem banda para os dez por cento imprevisíveis. Essa fatia imprevisível é onde o julgamento humano importa. Todo o resto deveria rodar sozinho. Em março de 2026, "rodar sozinho" cada vez mais significa que um agente de IA roda — e a pessoa de ops que construiu o sistema decide o que o agente deve e não deve tocar.

O caminho de saída

Se você está se afogando em trabalho operacional agora, aqui vai uma sequência prática.

Semanas 1–2: Registre tudo. Cada tarefa, cada interrupção, cada problema recorrente. Não conserte nada ainda. Apenas observe.

Semanas 3–4: Categorize. O que se repete? O que segue um padrão? O que um script — um pequeno programa que automatiza um passo manual — um checklist, ou um agente de IA conseguiria resolver? Tipicamente sessenta a setenta por cento do trabalho operacional se encaixa em "previsível e automatizável."

Semanas 5–8: Automatize ou documente os dez maiores consumidores de tempo. Um por semana. Comece pelo que mais te interrompe. Para resposta a incidentes — o processo de detectar e corrigir quedas — considere triagem orientada por agentes: ferramentas como o SRE Agent da PagerDuty ou alternativas open-source lidam com incidentes que seguem padrões e escalam os inéditos para você.

Mês 3: Agora você tem quarenta a cinquenta por cento mais banda. Invista no próximo nível de problemas.

Mês 6: Você está lendo um livro na mesa. Seus sistemas rodam. Seus agentes cuidam do previsível. Você parece ocioso. Não está ocioso. Você terminou.

Um recado para gestores

Se sua melhor pessoa de ops parece entediada, parabéns. Seus sistemas funcionam. Não invente tarefas para justificar o salário dela. Não a obrigue a fazer teatro de produtividade — aquela correria performática de parecer ocupado para satisfazer a expectativa de alguém sobre como "trabalhar duro" deveria ser.

Em vez disso, pergunte: "O que você construiria se tivesse três meses de tempo ininterrupto?" Depois dê esses três meses. O que essa pessoa construir vai economizar mais do que qualquer quantidade de ocupação visível jamais conseguiria.

A pessoa mais produtiva da sua empresa pode ser a que parece fazer menos. Isso não é um paradoxo. É assim que "terminei" se parece.