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

Para nós, Site Reliability Engineers (SREs), a maior parte do trabalho real ainda acontece no terminal. Fazer troubleshooting em um cluster Kubernetes, analisar logs durante uma interrupção ou trocar entre vários provedores de nuvem — essas tarefas raramente envolvem um IDE ou uma interface de usuário. O console é onde passamos nosso tempo. É por isso que ferramentas como gemini-cli e Claude Code são tão interessantes: elas trazem os Large Language Models (LLMs) diretamente para a linha de comando, perto do local onde o trabalho de SRE realmente acontece.

Um dos benefícios mais claros dos agentes baseados em console é a proximidade com o ambiente operacional. Ao contrário de uma janela de chat no navegador, um agente CLI pode ser executado imediatamente lado a lado com as mesmas ferramentas que você já usa: kubectl, aws, gcloud, terraform, e assim por diante. Em vez de copiar e colar logs de erro em uma interface de chat e tentar descrever a configuração, você pode simplesmente alimentar a saída diretamente. Essa pequena mudança reduz a fricção e pode fazer uma grande diferença durante um incidente, quando cada minuto conta.

A integração é outra grande vantagem. Na prática, um agente de IA baseado em console pode acessar APIs para verificar o status de um pull request, executar um pipeline para obter o estado do sistema ou até mesmo correlacionar sinais em vários serviços. Para sistemas distribuídos, onde uma única ferramenta não lhe dá a imagem completa, isso é poderoso. O agente efetivamente junta informações de painéis de monitoramento, saídas de CLIs e scripts internos, transformando saídas dispersas em algo que se parece mais com uma narrativa sobre a qual você pode agir.

Em comparação com os IDE copilots, os agentes focados no console se alinham muito melhor com a forma como os engenheiros de infraestrutura realmente trabalham. Os copilotos são fantásticos para desenvolvedores que escrevem código de aplicativo, mas um SRE geralmente não passa horas em um editor. Estamos orquestrando serviços, escrevendo scripts pontuais ou rastreando uma requisição com falha em vários sistemas. Nesses casos, um agente de IA que vive no console parece natural e evita a troca de contexto que muitas vezes nos atrasa.

As equipes também podem usar esses agentes para compartilhar conhecimento de forma mais eficaz. Em vez de todos reinventarem os passos de troubleshooting, os playbooks podem ser incorporados em prompts ou comandos, e consultas comuns podem ser reutilizadas por toda a equipe. Dessa forma, quando um sistema falha de uma maneira já conhecida, a IA pode lembrá-lo das verificações habituais, detalhar as saídas de comando ou apontar para a próxima causa provável. Isso diminui a carga mental durante momentos estressantes e ajuda novos engenheiros a se atualizarem sem precisar de meses de conhecimento sobre o ambiente.

Segurança e privacidade também so beneficiadas. Muitas vezes elas são ignoradas durante o uso de IA. Executar um assistente no console torna mais fácil manter o controle sobre o que sai do seu ambiente. Configurações ou credenciais podem permanecer locais, em vez de serem coladas em um aplicativo de chat. Para empresas com requisitos de compliance ou auditoria, esse pequeno detalhe pode fazer uma grande diferença.

A mudança maior, no entanto, é como esses agentes alteram a relação entre SREs e IA. Eles não são mais “uma ferramenta que você abre em outra aba”, mas algo que é executado junto com seus comandos do dia a dia. Isso significa menos troca de contexto, uma integração mais suave com as ferramentas em que você já confia e um apoio que parece parte do fluxo de trabalho, em vez de algo que usamos separadamente.

Embora a IA no console ainda esteja em seus estágios iniciais, ela tem grande potencial. Esses agentes de IA podem evoluir para identificar proativamente problemas, propor soluções rápidas ou gerenciar autonomamente tarefas de rotina, dependendo da aprovação humana. Para as equipes de SRE, o benefício principal vai além de apenas reduzir o tempo de troubleshooting; ele reside em inaugurar uma abordagem transformadora para o gerenciamento de incidentes e a confiabilidade geral.

Este artigo foi redigido com o apoio de ferramentas de IA (texto e imagem de capa), com o conteúdo final, estrutura e ideias fornecidos pelo autor.

Continuar lendo