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.

Continuar lendo

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.

Continuar lendo

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.

Continuar lendo

O que são Claude Skills?

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.

Continuar lendo

Virou passatempo nas redes sociais compartilhar as “alucinações” das novas Inteligências Artificiais. A gente ri quando o algoritmo sugere colar queijo na pizza com cola escolar ou inventa fatos históricos com uma confiança inabalável. O nome técnico para isso é alucinação, quando a máquina gera informações falsas que parecem verdadeiras. Mas rir da máquina pode ser só uma desculpa para não encarar algo bem desconfortável: ela se parece muito com a gente.

Antes de julgar o silício, precisamos olhar para o carbono. O jeito que a IA erra não é nada de outro mundo. Na verdade, é uma cópia quase perfeita de como a mente humana funciona quando está isolada ou mal informada. O algoritmo tenta preencher os buracos, e nós fazemos o mesmo. Quando nosso cérebro é treinado com poucos dados, ou seja, quando lemos pouco, viajamos pouco e conversamos apenas com quem concorda conosco, ele também começa a inventar conexões que não existem.

O cérebro humano detesta o vácuo. Sem explicação para um evento complexo e na falta de dados confiáveis, nós criamos histórias. É assim que nascem as teorias da conspiração. Quando alguém jura que a Terra é plana ou que existem chips de controle em vacinas, essa pessoa está tecnicamente alucinando. Ela pegou pedaços soltos de informação e, sem um banco de dados decente sobre a realidade, costurou uma história que faz sentido para ela.

Basicamente, teorias da conspiração são alucinações coletivas geradas por cérebros treinados com dados ruins. A IA faz isso porque foi programada para responder a qualquer custo e agradar o usuário. Nós fazemos isso porque buscamos conforto e pertencimento. A diferença é que, quando a IA erra, chamamos de “bug”. Quando nós erramos, chamamos de “minha opinião”.

Vale lembrar uma das regras mais antigas da computação: Garbage In, Garbage Out (Lixo entra, lixo sai). É simples: se você alimenta um sistema com dados ruins, o resultado vai ser ruim. Só esquecemos que essa regra não vale apenas para computadores. Se alimentamos nosso cérebro todo dia com manchetes sensacionalistas, fofocas e correntes de WhatsApp, não dá para esperar que nossa mente produza pensamentos críticos de qualidade ou soluções criativas.

No fim das contas, exigir que a IA pare de alucinar enquanto a humanidade continua inundando o mundo com desinformação é uma batalha perdida. A máquina não tem culpa de aprender com nossos maus exemplos; ela apenas processa o que nós fornecemos. O verdadeiro desafio aqui não é técnico, mas de autocrítica. Enquanto não assumirmos a responsabilidade pelo lixo que produzimos, continuaremos apontando o dedo para os erros da Inteligência Artificial, sem perceber que ela é apenas o aluno mais aplicado da nossa escola de incoerências.

Continuar lendo