Em 2018, quando escrevi sobre o Linux para discutir o poder da colaboração, a lição não era apenas sobre um software específico, mas sobre o aprimoramento da inteligência coletiva. O argumento era que o software open source demonstrava como uma rede descentralizada poderia mobilizar e multiplicar conhecimento em uma escala difícil de reproduzir dentro de uma única organização. Alguns anos depois, uma discussão semelhante agora está no centro da disputa dos modelos de inteligência artificial.

A engenharia de software foi uma das primeiras áreas a sentir o impacto da IA por uma razão simples: volume. Por mais de três décadas, desenvolvedores registraram seu raciocínio em fóruns e repositórios abertos. Quando os modelos chegaram, encontraram essa montanha de conhecimento pronta. Nasce então um ciclo virtuoso em que o conhecimento público treina os modelos, os modelos aceleraram a escrita de código e esse código alimenta o ecossistema.

A colaboração 1.0 do open source produziu uma quantidade extraordinária de conhecimento público. Agora esse conhecimento está sendo usado em modelos de IA que, em sua maioria, permanecem fechados.

É nesse cenário que a ascensão dos modelos de pesos abertos (open weights), como DeepSeek, Mistral e Kimi, ganha relevância. O mecanismo é diferente do open source tradicional. Quem baixa um modelo recebe os pesos (os parâmetros numéricos que representam o que o modelo aprendeu durante o treinamento) mas não necessariamente os dados originais usados no treinamento. Ainda assim, existe uma semelhança fundamental: ambos reduzem a distância entre aquilo que alguém construiu e aquilo que a próxima pessoa consegue construir sobre essa base.

Um modelo aberto pode ser executado, adaptado e especializado por outras empresas e pesquisadores, sem que eles precisem começar do zero. A colaboração, portanto, muda de camada. No open source, pessoas constroem software sobre software, com os open weights, as pessoas e organizações começam a construir inteligência sobre modelos que outros já desenvolveram.

Existe também o lado político. Atualmente, a liderança em modelos open weights está associada à China. Com o lançamento do DeepSeek no início de 2025, ficou evidente que modelos abertos também poderiam ser uma estratégia para competir com os grandes laboratórios de IA dos Estados Unidos. E ao disponibilizar seus modelos abertamente, eles fazem com que mais pessoas e empresas usem a sua base, criando uma presença global difícil de combater, exatamente o mesmo caminho que fez o software open source ganhar espaço e se tornar indispensável.

No Ocidente, uma carta em defesa dos modelos open weights foi publicada no site da Microsoft (ironicamente, a mesma empresa que em 2001 chamou o Linux de “câncer”) e logo passou de 270 signatários, incluindo Nvidia, Meta e IBM. O aceno ao governo americano não é por ideologia, mas por mercado. A Nvidia vende os chips de processamento, a Meta não ganha dinheiro vendendo modelos e a Microsoft precisa desse ecossistema aberto para alimentar seus produtos. Para defender seus lucros, agora elas recorrem ao histórico argumento de liberdade do software open source.

Se a primeira fase da colaboração uniu pessoas para criar software, a atual une pessoas e modelos de inteligência artificial, mas ainda depende de uma comunidade disposta a alimentar a nossa base de dados de sofware. A trajetória do open source já nos ensinou essa lição: o futuro não pertence a quem trancar a tecnologia em um cofre, mas a quem souber dominar o poder da colaboração para manter o conhecimento vivo.

Continuar lendo

Escrever costumava dar trabalho. Exigia sentar, organizar o pensamento, escolher as palavras e cortar os excessos para que a ideia fizesse sentido dentro de um espaço limitado. Havia um custo óbvio de energia física e mental envolvido na produção de qualquer linha.

A inteligência artificial mudou essa dinâmica ao reduzir drasticamente o custo da escrita. Hoje, produzir páginas inteiras de um texto bem estruturado virou algo trivial e acessível. O problema é que passamos a testemunhar um efeito colateral: quando escrever fica barato demais, ler se torna extremamente caro.

No século XVII, Blaise Pascal resumiu a economia da escrita em uma frase célebre: “Fiz esta carta mais longa porque não tive tempo de fazê-la mais curta”. Ele compreendia que a concisão exige esforço, reflexão e tempo, enquanto a prolixidade é o caminho mais fácil. A tecnologia atual inverteu essa lógica profunda. Como gerar volume não custa mais nada para quem escreve, também deixou de existir um incentivo para cortar excessos. O ambiente acabou sendo inundado por uma enxurrada de textões.

Agora, ideias ridiculamente simples aparecem embrulhadas em páginas e páginas de um texto perfeitamente construído, mas completamente redundante. Transformamos conceitos banais em grandes dissertações corporativas apenas porque preencher a tela deixou de ser doloroso.

O recurso escasso deixou de ser a capacidade de produzir texto e passou a ser conquistar e merecer a atenção de quem lê. Afinal, a leitura exige um esforço cognitivo ativo. Cada texto demanda alguns minutos de atenção exclusiva para que o leitor acompanhe o raciocínio e construa uma compreensão do que está sendo apresentado. Diante de feeds saturados de textos inflados, quem lê simplesmente cansa.

Para piorar, a facilidade de produção trouxe um elemento perverso: os modelos de IA atuais são excelentes em produzir textos que soam confiáveis, mesmo quando a informação por trás é superficial ou incorreta.

No passado, um argumento ruim vinha acompanhado de sinais claros, como erros de digitação, falta de coesão ou uma estrutura capenga. Havia um alerta natural para o leitor. Agora, a inconsistência vem perfeitamente revisada e coerente. Hoje não basta apenas entender um texto, também precisamos decidir se podemos confiar nele.

A solução seria usar a própria IA para resumir esse excesso de linhas? Quando uma máquina resume o que outra escreveu, criamos um ciclo absurdo. O resultado é uma informação de segunda mão, que perde toda a nuance original. Pior ainda, o sistema apenas comprime os erros, tornando uma ideia ruim mais rápida de engolir.

Em um mundo onde qualquer sistema gera mil palavras em segundos, o verdadeiro mérito migrou para quem investe o próprio tempo para enxugar a ideia, demonstrando respeito pelo tempo alheio e a coragem de ser conciso. Quando escrever era caro, valorizávamos quem produzia bons textos. Agora, talvez devêssemos valorizar quem sabe parar de escrever na hora certa.

Continuar lendo

A internet mudou o valor do que guardamos na cabeça. Quando o conhecimento saiu dos livros e foi parar na rede, decorar dados perdeu o sentido. O diferencial não era mais acumular respostas, mas ter o critério necessário para filtrar o que realmente importava no meio do excesso de informações.

Durante muito tempo, saber usar o Google funcionou exatamente assim. Não era uma habilidade que definia carreiras, mas favorecia bastante quem conhecia o caminho das pedras. E essa fluência não vinha de dominar comandos avançados, mas de acumular quilometragem refinando buscas, lidando com resultados ruins e aprendendo a encontrar o dado correto.

Com a inteligência artificial, o cenário é parecido, só que o terreno agora é bem mais instável. Hoje, costuma-se usar ferramentas como o ChatGPT ou o Claude quase no piloto automático. Pedimos um resumo, geramos um rascunho de e-mail, revisamos um código e seguimos para a próxima tarefa. O prazo é cumprido e o problema é resolvido. Mas usar a IA apenas para resolver tarefas rápidas significa que estamos aprendendo a trabalhar com ela?

Quando o foco está apenas no resultado final, paramos de prestar atenção em como o sistema se comporta. E a experiência de acompanhar de perto esses acertos e erros é a bagagem que realmente vai fazer a diferença. Afinal, fluência em IA não é sobre saber dar ordens. É sobre ter o julgamento necessário para decidir o que delegar, fornecer contexto relevante e avaliar criticamente aquilo que a IA devolve.

O pesquisador Ethan Mollick usa um termo excelente para essa dinâmica: a fronteira irregular da inteligência artificial. Os modelos não são bons ou ruins de forma linear. Eles resolvem problemas complexos de lógica em segundos, mas podem falhar em uma conta básica ou na interpretação de uma frase. Para piorar, ela muda o tempo todo dependendo do contexto.

E não adianta muito ler manuais ou decorar listas de comandos para entender esse limite. A única saída é trazer a ferramenta para a nossa rotina, mesmo nas tarefas menores. Não porque a IA seja infalível, mas porque é preciso acumular experiência para desenvolver intuição. Só com o tempo é possível notar onde ela preenche lacunas com respostas que parecem convincentes, mas incorretas.

Profissionais experientes não extraem mais valor da IA porque usam palavras mágicas. Eles se destacam porque têm o repertório necessário para bater o olho e perceber quando a máquina está errada. O especialista sabe separar o que a IA entregou do que ele precisava de fato.

No fim das contas, ninguém virava mestre em pesquisa no Google fazendo curso teórico. Com a IA é a mesma coisa. A vantagem real não será de quem conhece todos os conceitos, mas de quem passou tempo suficiente trabalhando de forma crítica com a ferramenta para entender, na prática, até onde ela consegue ir.

Continuar lendo

Por anos, construímos observabilidade para olhos humanos. Dashboards pensados para quem está de plantão, alertas feitos para acordar alguém, logs formatados para serem lidos linha por linha durante um incidente. AIOps abriu um novo capítulo nessa história. Agora temos agentes autônomos capazes de raciocinar sobre falhas, correlacionar sinais e propor caminhos de investigação. Eles consomem a mesma telemetria que produzimos — mas com requisitos muito diferentes dos nossos.

Essa transição não depende apenas do modelo de linguagem. Depende da qualidade do que o alimenta.

O verdadeiro gargalo não é o modelo

Um agente de triagem opera sobre contexto. E contexto vem de um lugar: a telemetria do seu ambiente.

Métricas, logs e traces são a matéria-prima. Se essa matéria-prima é ruidosa, inconsistente ou mal estruturada, o agente vai raciocinar sobre ruído. Esse problema aparece em dois cenários: em agentes autônomos, que iniciam investigações a partir de alertas sem intervenção humana; e em agentes interativos, que auxiliam o SRE durante uma investigação ativa no terminal.

Em ambos os casos, o limite do que o agente consegue fazer é definido antes da primeira chamada ao modelo. Ele é definido na instrumentação.

OpenTelemetry como base semântica

Para que um agente consiga navegar entre métricas, logs e traces sem perder a cadeia causal, esses sinais precisam compartilhar o mesmo contexto de rastreamento. O OpenTelemetry torna isso possível de forma padronizada e independente de fornecedor.

Considere um cenário simples. Um pico de latência aparece na sua API. Sem correlação de traces, o agente enxerga sinais isolados:

• a latência aumentou
• a taxa de erro subiu levemente

Com instrumentação adequada:

• um trace_id conecta a requisição a uma query lenta no banco
• a query se conecta a uma mudança recente de schema

Mesmo incidente. Capacidade de análise completamente diferente.

É por isso que projetos de migração para OpenTelemetry têm um impacto operacional tão profundo. Não se trata apenas de trocar um coletor. É a construção de uma linguagem comum entre serviços que antes emitiam sinais em formatos incompatíveis. Sem essa consistência semântica, qualquer agente opera “cego” em partes do sistema.

O problema da janela de contexto

A qualidade da telemetria está diretamente ligada a outro desafio: a gestão da janela de contexto. O problema não é o volume de dados. É a seleção dos tokens relevantes.

Um agente que recebe telemetria não filtrada durante um incidente tende a perder o sinal no meio do ruído. Logs redundantes, métricas sem atributos de contexto, traces incompletos — tudo isso consome janela sem contribuir para o raciocínio. Uma boa instrumentação resolve parte desse problema antes mesmo de chegar ao modelo: dados semanticamente ricos, com atributos consistentes e rastreamento propagado, chegam em um formato que já favorece o raciocínio.

Modelos melhores não vão corrigir telemetria ruim.

Dois modos de operação, um mesmo pré-requisito

No modo autônomo, o agente monitora continuamente alertas e constrói hipóteses sem intervenção humana. Os principais provedores já lançaram suas implementações nesse modelo, como Azure SRE Agent, AWS DevOps Agent e Datadog AI SRE. Como já discuti em outro artigo, o sucesso dessas ferramentas em produção não é garantido pelo modelo em si. Ele depende de guardrails bem definidos e, acima de tudo, de um bom contexto. E esse contexto começa na telemetria.

No modo assistido, o agente atua ao lado do SRE no terminal, próximo das ferramentas reais. Aqui também, a utilidade depende da qualidade dos dados que ele consegue inspecionar em tempo real. Um trace sem propagação de contexto, analisado durante um incidente, oferece ao agente exatamente o mesmo que oferece a um humano: uma visão parcial.

Conhecimento operacional como complemento

A qualidade da telemetria resolve o problema dos dados. O problema do contexto operacional permanece: padrões de falha do ambiente, procedimentos conhecidos, pontos cegos históricos. Encapsular esse conhecimento em Skills reutilizáveis (procedimentos estruturados e playbooks operacionais que o agente pode utilizar) é o que permite que ele opere de forma consistente, combinando dados estruturados com o conhecimento acumulado do time.

Duas camadas complementares. A telemetria diz o que está acontecendo. O conhecimento operacional ajuda a entender o que isso provavelmente significa.

Conclusão

Antes de qualquer conversa sobre AIOps, a pergunta mais honesta é: sua observabilidade está pronta para ser interpretada por uma máquina?

Serviços sem traces propagados, logs sem atributos de contexto e métricas sem cardinalidade adequada não vão se beneficiar de agentes mais sofisticados. Vão apenas gerar respostas erradas — mais rápidas e mais confiantes.

Observabilidade foi construída para humanos. Agora ela também precisa funcionar para máquinas. Times que entendem essa diferença terão uma vantagem real — não por escolherem modelos melhores, mas por construírem entradas melhores.

Continuar lendo

Reiniciar serviços de forma automatizada ou utilizar scripts de auto-healing para limpar espaço em disco aos 90% não são novidade para um SRE. Temos utilizado esse tipo de automação básica e determinística há muito tempo.

O real desafio, e o objetivo final de qualquer time de plataforma, é a resolução de incidentes complexos: aqueles problemas multidimensionais que exigem navegar por dezenas de dashboards para entender que uma mudança no esquema do banco de dados está causando gargalos de conexão em um microsserviço.

Com a ascensão dos agentes de IA, essa visão de remediação inteligente deixou de ser especulativa. No entanto, entre a promessa da tecnologia e a realidade dos sistemas de produção, existe uma lacuna fundamental: o contexto.

Mais precisamente, a capacidade de agir dentro de limites seguros mesmo quando você não tem a visão completa do cenário.

A Nova Onda: Triagem Inteligente

Estamos vendo uma tendência clara com ferramentas como o Azure SRE Agent e o AWS DevOps Agent. Esses agentes não servem apenas para executar comandos; eles atuam como uma camada de inteligência sobre o caos.

Seu impacto mais imediato e mensurável está na triagem assistida.

Ao correlacionar logs, métricas e traces em sistemas distribuídos, esses agentes conseguem identificar rapidamente a causa provável de um incidente. Em vez de alertas brutos, os SREs recebem insights sintetizados:

A latência aumentou após o deploy X; as taxas de erro estão concentradas no serviço Y.

Isso reduz significativamente o MTTD (Mean Time To Detect) e diminui a carga cognitiva durante a resposta a incidentes. Mas passar da triagem para a remediação não é um passo linear. É uma mudança na classe do problema.

Riscos da Janela de Contexto e Improviso

Como discuti anteriormente em meu artigo Gerenciamento da Janela de Contexto para Agentes de IA, um agente de IA é tão bom quanto a informação que ele consegue processar sem se perder. Para um SRE, isso é um desafio crítico: o volume de logs, métricas e metadados gerados durante um incidente pode facilmente saturar a janela de contexto de um modelo.

Quando o tratamento de contexto degrada, os agentes podem:

• Ignorar sinais críticos
• Dar peso errado a correlações
• Gerar inferências tecnicamente plausíveis, mas incorretas

Isso introduz o risco de alucinação durante a remediação.

Imagine um agente que decide escalar um serviço stateful para conter uma alta latência, sem perceber — devido à saturação de contexto — que o problema real é uma contenção de locks no banco de dados. Essa ação de auto-healing poderia simplesmente amplificar o problema, gerando um thundering herd que derruba o que restava da infraestrutura.

Guardrails

Para mitigar esses riscos, introduzimos guardrails, que são restrições sobre quais ações um agente está autorizado a realizar. Eles definem a superfície de controle do sistema.

Mas enfrentamos um paradoxo técnico:

1. Se os guardrails forem muito rígidos, a IA não consegue resolver nada fora de um script básico.
2. Se damos liberdade para deduzir soluções em sistemas complexos com um contexto mal gerido, o risco de um resultado inesperado cresce exponencialmente.

A Segurança dos Runbooks Consolidados

A prática mais madura no mercado hoje é usar esses agentes como orquestradores de runbooks validados.

IA para a decisão. Sistemas determinísticos para a execução.

Se o agente executa uma ação automaticamente, precisamos ter certeza de que ela pode ser desfeita e que não causará efeitos colaterais se for repetida. A inteligência pertence à análise, mas a execução permanece em trilhos seguros.

A Lição da Aviação: Automation Surprise

Gosto de usar a analogia da aviação moderna.

Uma aeronave comercial hoje consegue lidar com quase todas as fases de um voo sozinha. No entanto, pilotos humanos continuam essenciais. Não para a operação rotineira, mas para casos extremos (edge cases).

Na engenharia de fatores humanos, existe um conceito chamado automation surprise (surpresa da automação). Isso acontece quando o sistema automático toma uma decisão que o operador não esperava. Se o seu agente de auto-healing decide isolar uma região inteira do provedor cloud sem uma explicação clara, o engenheiro de plantão é forçado a mudar o foco da recuperação para a interpretação.

Conclusão

O auto-healing totalmente autônomo não é apenas um desafio de engenharia de software; é uma questão de gerenciamento de risco.

Ferramentas como o Azure SRE Agent ou o AWS DevOps Agent são multiplicadores de força incríveis para diagnóstico e automação de tarefas repetitivas. No entanto, quando se trata dos controles de um sistema crítico, o julgamento humano ainda é a última linha de defesa.

Por enquanto, o modelo mais eficaz é claro: a IA opera como um copiloto. Humanos retêm a autoridade sobre decisões de alto impacto.

Não porque a IA não seja capaz, mas porque sistemas de produção oferecem margem zero para erro.

Continuar lendo