“A primeira máquina ultrainteligente será a última invenção que o homem precisará fazer.” — I. J. Good, 1965
Hoje, novas ferramentas de inteligência artificial surgem numa velocidade que nós mal conseguimos acompanhar. Quando começamos a entender uma, chega outra prometendo fazer tudo melhor. Para quem trabalha com programação, essa mudança é muito clara: há pouco tempo, o máximo que essas ferramentas faziam era sugerir um trecho de código tímido enquanto digitávamos. Agora, nós descrevemos o que queremos e programas inteiros aparecem prontos na tela.
Mas o ponto principal não é a quantidade de lançamentos. É o fato de que a IA deixou de ser apenas um produto final para virar parte do próprio processo de criação. Em Vida 3.0 (Benvirá, 2020), Max Tegmark chama isso de inteligência artificial recursiva. Não é à toa que o desenvolvimento de software tem sido a área mais impactada: como a IA é feita de código, ao aprender a programar, ela consegue se retroalimentar. Cada passo diminui o trabalho do próximo. Basicamente, a máquina ganha o poder de participar da sua própria evolução.
Isso pode assustar, mas a inteligência humana sempre funcionou do mesmo jeito. Ninguém nasce sabendo matemática ou física. Nós aprendemos lendo livros de pessoas que nunca vimos e construímos coisas novas em cima de descobertas antigas. Nossa inteligência individual é só a ponta de um iceberg, apoiada numa base invisível de linguagem e história. Somos, no fundo, mentes biológicas usando o conhecimento acumulado de todo mundo que veio antes.
A grande diferença é que, para nós, esse processo sempre foi lento. O conhecimento levava décadas para se espalhar. Teorias demoravam gerações para amadurecer. Com a IA, esse tempo encolheu. O que antes levava uma vida inteira agora acontece em meses. O aprendizado deixou de ser apenas humano e virou misto. Entregamos parte da criação para máquinas que funcionam numa escala que nós não conseguimos alcançar.
Isso não é necessariamente ruim. O problema não é a ferramenta ficar mais inteligente, mas sim nós perdermos o controle sobre para onde ela está indo. Sempre convivemos com avanços tecnológicos, da imprensa à internet, mas agora o jogo é diferente. O verdadeiro risco é nós lavarmos as mãos e deixarmos esse ciclo rodar solto, sem valores humanos claros e sem ninguém no comando. Se fizermos isso, acabaremos transformando a previsão de I. J. Good em uma profecia apocalíptica.
Todo Site Reliability Engineer experiente sabe que resposta a incidentes é, fundamentalmente, sobre informação. Quando algo quebra ou começa a degradar, você não olha para uma única métrica ou uma linha de log isolada. Você navega por logs, traces, alertas, dashboards, mudanças de configuração e conversas humanas para entender o que aconteceu — e o que fazer a seguir.
Agentes de IA prometem ajudar exatamente nesse tipo de sobrecarga cognitiva. Eles conseguem ler, correlacionar e resumir informações mais rápido do que qualquer humano. Mas a efetividade desses agentes é moldada por uma limitação técnica dura — e frequentemente ignorada.
A janela de contexto.
Janelas de Contexto são a Memória de Trabalho da IA
A janela de contexto é a memória de trabalho de um modelo de IA. Ela define quanta informação o agente consegue manter ativa para raciocinar em um determinado momento. Mesmo com modelos modernos anunciando janelas de contexto muito grandes, essa memória continua sendo finita — e surpreendentemente frágil.
Análise de incidentes é a receita perfeita para esgotamento de contexto. Alertas disparam cascatas de chamadas de ferramentas. Logs e traces crescem rapidamente. Snapshots de configuração e dados históricos se acumulam. Quando tudo isso é empurrado para a janela de contexto sem disciplina, o agente não fica mais inteligente. Ele fica mais lento, mais caro e menos confiável.
Mais contexto não significa automaticamente melhor raciocínio. Depois de certo ponto, geralmente significa menos foco.
Agentes, Subagentes e Skills
Agentes modernos de IA são construídos de forma muito parecida com sistemas distribuídos. Eles são compostos por subagentes e skills, cada um responsável por uma tarefa bem delimitada, como análise de logs, inspeção de configurações ou sumarização.
Essa separação de responsabilidades não é apenas uma preferência arquitetural. É um mecanismo de sobrevivência. Escopos menores significam janelas de contexto menores, raciocínio mais claro e menos falhas silenciosas. Um único agente tentando manter todo o estado de um incidente ao mesmo tempo não é diferente de um monólito sob carga ilimitada.
No entanto, isso não acontece automaticamente.
A maioria dos frameworks de agentes oferece subagentes e skills como capacidades — não como salvaguardas. Cabe ao usuário entender como esses recursos funcionam e configurá-los de forma intencional. Sem limites claros, uma skill pode facilmente se tornar apenas mais uma forma de injetar grandes volumes de dados na mesma janela de contexto já sobrecarregada.
MCP: o Inimigo Silencioso da Janela de Contexto
À medida que agentes se tornaram mais comuns nos fluxos de trabalho de SRE, servidores MCP passaram a se proliferar rapidamente. Grafana, GitHub, Slack, sistemas de CI, provedores de cloud e plataformas internas agora expõem interfaces MCP que os agentes podem consumir livremente.
É aqui que o MCP se torna um inimigo silencioso.
Cada servidor MCP representa um potencial dilúvio de tokens. Muitas configurações registram dezenas de ferramentas MCP logo de início, mesmo que apenas uma pequena fração seja usada durante um incidente. O agente nem precisa chamá-las para que o dano aconteça. Esquemas de ferramentas, descrições e capacidades disponíveis já consomem parte da janela de contexto antes mesmo de qualquer trabalho começar.
Com o tempo, isso corrói o espaço efetivo de raciocínio do agente.
Por esse motivo, frameworks de agentes já estão correndo para melhorar o gerenciamento de MCPs. Técnicas como progressive disclosure estão se tornando mais comuns. Em vez de expor todos os MCPs de uma vez, os agentes revelam ferramentas gradualmente, com base na intenção e na etapa da investigação. Outros atrasam o carregamento de metadados até que a ferramenta seja realmente necessária, ou removem dinamicamente MCPs não utilizados do contexto ativo.
A lição é simples: MCPs são poderosos, mas precisam ser tratados como dependências de produção. Cada ferramenta habilitada tem um custo — mesmo quando não é utilizada.
O Verdadeiro Problema de SRE: Explosão de Contexto
Incidentes são iterativos. Cada passo gera mais dados e mais hipóteses.
Imagine um agente investigando um CrashLoopBackOff no Kubernetes. Ele busca a descrição do pod, depois as últimas 500 linhas de log, depois o YAML do deployment. De repente, grande parte do contexto está ocupada por stack traces repetitivos. A mudança real de configuração que causou o problema mal consegue caber.
É assim que falhas silenciosas acontecem. Não porque o modelo é fraco, mas porque o sinal se perdeu no meio do ruído.
Existe também uma preocupação muito prática aqui. Janelas de contexto grandes aumentam latência e custo. Um agente que leva dezenas de segundos para raciocinar porque está relendo milhares de tokens é inútil durante um incidente crítico. Gerenciamento de contexto não é apenas sobre correção. É também sobre FinOps e tempo de resposta.
Tratando o Contexto como um Problema de Engenharia
Trabalhar com IA de forma eficaz em SRE exige tratar contexto como um recurso escasso.
Sumarização precisa ser explícita, não acidental. Skills e subagentes devem ser projetados para emitir estados compactos, não transcrições completas do que observaram. Dados históricos e saídas volumosas devem ser descarregados para sistemas de memória de longo prazo, como vector stores, em vez de permanecer indefinidamente na janela de contexto ativa.
Da mesma forma, o uso de MCPs precisa ser intencional. Habilite menos ferramentas, exponha-as de forma progressiva e remova o que não é necessário. Gerenciamento de contexto não é algo que o agente resolve magicamente por você. É uma decisão de design — e uma responsabilidade.
Agentes também precisam de observabilidade. Uso de tokens por etapa, taxas de compressão e quanto insight é produzido por token importam. Se monitoramos tudo em produção, o agente não deveria ser uma caixa-preta.
Conclusão
Agentes de IA não falham por falta de inteligência. Eles falham porque ficam sobrecarregados.
Para SREs, gerenciar a janela de contexto não é diferente de gerenciar memória, latência ou error budgets. Ignorar isso torna as falhas sutis e caras. Projetar levando isso em conta transforma agentes em parceiros confiáveis — em vez de ferramentas imprevisíveis.
Trate sua janela de contexto como um recurso escasso. Porque dados sem contexto são ruído — e contexto sem gerenciamento é caos.
Este artigo foi redigido com o apoio de ferramentas de IA (texto e imagem de capa), com conteúdo final, estrutura e ideias definidos pelo autor.
Existe uma obsessão quase infantil com a ideia de que o fim da humanidade será cinematográfico. Uma explosão, um botão vermelho, um céu em chamas. Talvez a gente precise desse espetáculo para se sentir importante até no desastre. Mas o fim, se vier, provavelmente será mais discreto. Sem clarões, sem discursos finais. Algo que acontece enquanto seguimos a rotina. Talvez comece como uma atualização qualquer, dessas que aceitamos sem ler.
A possibilidade de que a inteligência humana deixe de ser o centro do jogo ainda soa ofensiva para muita gente. Não por falta de sinais, mas porque fere uma crença antiga: a de que somos especiais por definição. Que consciência, criatividade e linguagem nos colocaram acima de qualquer outra coisa. Só que a história nunca tratou ninguém como sagrado. Tudo que permanece é aquilo que funciona melhor.
Essa não é uma provocação marginal ou conspiratória. Demis Hassabis, cofundador da DeepMind e um dos principais arquitetos da inteligência artificial moderna, afirmou que o impacto da chamada AGI – uma inteligência capaz de aprender, raciocinar e se adaptar a praticamente qualquer tarefa, não apenas a uma função específica – pode ser dez vezes maior do que a Revolução Industrial, e possivelmente dez vezes mais rápido. A comparação é desconfortável, porque a Revolução Industrial já foi suficiente para reorganizar trabalho, tempo, valor humano e até a forma como entendemos progresso.
Não é sobre máquinas se revoltando, tomando poder ou eliminando pessoas. Isso é fantasia reconfortante. A hipótese mais incômoda é outra: elas simplesmente fazem melhor. Pensam mais rápido, erram menos, não se cansam e não precisam parar. E o mundo, pragmático como sempre foi, se adapta sem drama. Não por maldade, mas por eficiência.
Se existe um elo perdido nessa história, ele não está enterrado em nenhuma escavação arqueológica. Ele está vivo. Somos nós. A geração que ainda carrega limites biológicos, mas já opera em conjunto com uma inteligência que não compartilha desses limites. Não somos o começo nem o fim. Somos a transição.
Talvez por isso a ideia de uma inteligência potencialmente imortal cause tanto desconforto. Não porque seja absurda, mas porque expõe nossa fragilidade mais básica. Tudo que pensamos é urgente porque acaba. Uma mente que não termina não carrega urgência, nem legado, nem medo do esquecimento. Ela não precisa correr. E quem não precisa correr sempre acaba vencendo.
O apocalipse, então, talvez não seja destruição. Seja rebaixamento. A perda da centralidade. Continuamos aqui, vivendo, trabalhando, opinando, criando sentido para nós mesmos. Só que o mundo já não gira exclusivamente em torno disso. Como tantas outras espécies antes, não desaparecemos de imediato. Apenas deixamos de ser indispensáveis.
No fim, talvez nosso maior erro tenha sido acreditar que deuses são eternos. Nosso maior legado pode não ser aquilo que construímos, mas aquilo que despertamos. E quando alguém, no futuro, olhar para trás tentando entender a origem dessa nova inteligência, talvez chegue à mesma conclusão incômoda: antes dela, eram os deuses humanos.
Como profissional de TI e professor, confesso que poucas coisas têm me incomodado tanto quanto a distância crescente entre a velocidade da tecnologia e o ritmo do ensino superior. Em poucos anos, a Inteligência Artificial saiu do campo da experimentação para o uso cotidiano. Foi rápido. Rápido demais. E tudo indica que esse ritmo só vai acelerar. O problema é que a sala de aula não muda na mesma velocidade.
Hoje, a IA já escreve código, explica erros, sugere arquiteturas e responde dúvidas que antes exigiam anos de prática. Não estamos falando de futuro ou de uma tendência distante. Isso já está acontecendo. No mercado, essas ferramentas viraram parte do fluxo de trabalho. Fingir que essas ferramentas não fazem parte do processo é continuar ensinando para um mundo que já não existe.
Para profissionais de TI que já estavam no mercado, essa transição foi relativamente suave. Eles conheciam os fundamentos, entendiam o que estavam pedindo à ferramenta e conseguiam validar as respostas. A IA virou apoio. Acelerador. Já para quem está começando, o cenário é bem mais perigoso. O estudante aprende a chegar na resposta antes de aprender o caminho. E isso cobra um preço. Aos poucos, esses profissionais tendem a perder relevância, não porque a IA é melhor, mas porque nunca construíram a base necessária.
Essa discussão não é nova. Edsger W. Dijkstra, um dos pioneiros da ciência da computação, já alertava: “O objetivo do ensino da computação não é ensinar uma linguagem, mas ensinar as pessoas a pensar”. O problema é que agora essa frase deixou de ser conceitual e virou prática diária. Se o aluno não aprende a pensar, ele não consegue nem perceber quando a IA erra. E ela erra. Com frequência.
O impacto disso aparece claramente na forma como avaliamos. Trabalhos e projetos que deveriam estimular raciocínio acabam virando exercícios de prompt. Já vi alunos entregarem códigos “perfeitos”, mas incapazes de explicar uma única decisão tomada. A entrega final vira um intermediário automático entre a ferramenta e o professor. Não há reflexão ali. Só execução.
Isso exige uma mudança real no papel do professor e das instituições. O docente deixa de ser apenas transmissor de conteúdo. Passa a ser alguém que provoca, questiona e expõe limites. Avaliar não é mais pedir para criar algo do zero, mas pedir para analisar, corrigir, criticar e justificar. Em vez de proibir IA, é preciso usá-la contra ela mesma. Fazer o aluno pensar.
Como resume Ethan Mollick em “Cointelligence” (2024): “O valor não está em substituir o humano pela máquina, mas em aprender a trabalhar com ela de forma inteligente”. O futuro do ensino de tecnologia não está na rejeição da IA, nem na sua adoção cega. Está em formar profissionais que dominem fundamentos, entendam contexto e saibam usar essas ferramentas com responsabilidade.
Claude Skills são uma forma de empacotar conhecimento, instruções e contexto em unidades reutilizáveis e focadas em tarefas, que podem ser invocadas sempre que necessário. Em vez de depender de longos históricos de conversa ou prompts genéricos, uma Skill fornece um contexto estável e pré-definido, adaptado a um domínio ou fluxo de trabalho específico.
Para SREs, isso significa capturar conhecimento operacional, como procedimentos, verificações e modelos mentais, em um formato simples de reutilizar e que permanece facilmente acessível.
O contexto é o verdadeiro gargalo no trabalho de SRE
Ser um Site Reliability Engineer não é apenas dominar uma ferramenta; é lidar com amplitude. Em um único dia, um SRE pode precisar entender o comportamento de um cluster Kubernetes, limites de rede na nuvem, desempenho de bancos de dados e fluxos de resposta a incidentes — tudo dentro da mesma hora.
O desafio não é executar comandos, mas manter contexto suficiente para tomar boas decisões sob pressão.
É nesse ponto que Claude Skills se tornam relevantes.
O que Claude Skills mudam
Claude Skills permitem que SREs encapsulem conhecimento operacional em unidades reutilizáveis e focadas. Em vez de começar do zero ou vasculhar documentação espalhada, uma Skill traz pressupostos, restrições e modos de falha comuns diretamente para a conversa desde o início.
Na prática, Skills atuam como uma extensão do modelo mental do SRE.
Exemplos de Skills no dia a dia
Skills não precisam ser complexas para serem úteis. Alguns exemplos genéricos incluem:
Skill de Triagem de Incidentes Fornece um ponto de partida estruturado durante incidentes: mudanças recentes, sinais de saúde do sistema e padrões de falha comuns.
Skill de Debug em Kubernetes Mantém contexto a nível de cluster, como comportamento de agendamento, pressão de recursos e sintomas do plano de controle.
Skill de Troubleshooting de Banco de Dados Foca em latência, saúde de réplicas, limites de conexão e desempenho de queries.
Skill de Revisão de Segurança de Mudanças Ajuda a validar operações de risco, verificando pré-requisitos, opções de rollback e raio de impacto.
Cada Skill reduz propositalmente o escopo, diminuindo ruído e mantendo a investigação estruturada.
Reduzindo carga cognitiva quando importa
Durante incidentes, a carga cognitiva frequentemente limita a performance. Estresse, alertas e informações parciais tornam fácil pular etapas ou tirar conclusões precipitadas.
Skills atuam como um guia constante, ajudando os SREs a manter clareza e seguir caminhos investigativos consistentes. Elas não substituem julgamento, mas suportam a tomada de decisão quando a capacidade mental está limitada.
Skills como documentação viva e suporte ao onboarding
Claude Skills também funcionam bem como ferramenta de onboarding. Novos SREs geralmente têm menos dificuldade com ferramentas do que em entender como sistemas e procedimentos se conectam.
Como Skills codificam contexto e raciocínio, elas funcionam como documentação viva. Com o tempo, reduzem a dependência do conhecimento tribal e distribuem expertise de forma mais uniforme na equipe.
Skills como lente para identificar e reduzir toil
Um benefício frequentemente esquecido de documentar Claude Skills é tornar o toil visível.
Segundo o Google SRE Book, toil é trabalho manual, repetitivo, automatizável, tático e sem valor duradouro. Em muitas equipes, ele persiste simplesmente porque não está documentado ou é aceito como “parte do trabalho”.
Ao documentar Skills, os SREs são forçados a descrever o que é feito, em qual ordem e sob quais condições, expondo naturalmente etapas repetitivas ou mecânicas.
Uma vez codificadas em uma Skill, essas etapas podem gerar uma pergunta crítica: um humano ainda precisa fazer isso?
Nesse ponto, a Skill deixa de ser apenas documentação e se torna uma ferramenta de descoberta, abrindo oportunidades para a IA: gerar scripts, validar pré-condições, sugerir automações ou orquestrar fluxos seguros para procedimentos tediosos.
Skills + MCP: uma combinação poderosa para SREs
Claude Skills se tornam ainda mais relevantes quando combinadas com MCP (Model Context Protocol). Enquanto Skills definem como pensar sobre um problema, MCP define como o modelo se conecta a sistemas e dados.
Com MCP, Skills podem ser apoiadas por contexto operacional em tempo real, como métricas, logs, dados de configuração ou APIs internas. Em vez de raciocinar de forma abstrata, a Skill opera próxima ao estado real do sistema.
Para SREs, isso traz benefícios concretos:
Menos coleta manual de contexto
Raciocínio mais confiável baseado em dados reais
Separação mais clara entre conhecimento e acesso a dados
Integrações mais seguras e controladas com sistemas de produção
Juntas, Skills e MCP aproximam a assistência de IA do fluxo de trabalho de SRE, sem transformá-la em uma “caixa preta” ou automação descontrolada.
Não é automação, é aumento cognitivo
Essa abordagem não remove humanos do loop nem automatiza operações completamente. É sobre aumentar a tomada de decisão do SRE, com contexto preservado, fontes de dados confiáveis e raciocínio estruturado.
Skills guiam o pensamento. MCP fornece os dados. O SRE permanece responsável.
Uma mudança pequena, mas de impacto real
À medida que os sistemas se tornam mais complexos, o contexto humano se torna o verdadeiro gargalo, não as ferramentas. Claude Skills e MCP tratam disso, mantendo o conhecimento operacional e o estado do sistema no centro do processo de decisão.
Elas também criam uma ponte natural entre documentação, onboarding e redução de toil.
Para SREs, isso é menos sobre adotar uma nova funcionalidade de IA e mais sobre melhorar a forma como o trabalho de confiabilidade realmente acontece.
Este artigo foi redigido com o suporte de ferramentas de IA (texto e imagem de capa), com conteúdo, estrutura e ideias finais fornecidas pelo autor.
