Esse artigo não é um tutorial. É um diário :)
Estou fazendo o curso de certificação CKA, Certified Kubernetes Administrator através da plataforma KodeKloud, e assim gostaria de iniciar no mundo "agêntico" de IA com o Claude e terminei com uma plataforma de observabilidade e FinOps para Kubernetes rodando Go, PostgreSQL e um dashboard em tempo real — sem ter planejado nada disso.
Dia 1: o certificado e os $5 de crédito
Decidi fazer o curso oficial da Anthropic (Skilljar): Claude Code in Action. Gratuito, com certificado, e levei algumas horas para concluir.
O curso pede uma API key do Anthropic Platform para rodar os exemplos. Criei a chave, subi o servidor local, e recebi:
error: Your credit balance is too low to access the Anthropic API.
"Mas o curso é gratuito..."
Não é bem assim. O curso é gratuito. As chamadas de API consomem créditos reais. São duas coisas separadas — e a plataforma não deixa isso claro o suficiente. Comprei $5 de crédito, deletei cache e sessões, recriei a key, e funcionou.
Lição 1: o capitalismo sempre vence. Mas $5 dura bastante com o Haiku, o modelo de "entrada" digamos assim.
Com o certificado em mãos no mesmo dia, parti para a prática.
Ainda no Dia 1: criação da v1.0
A ideia era simples: um agente Claude Code que monitorasse um cluster Kubernetes e gerasse runbooks automaticamente. Sem código manual. Só diretivas.
Eu utilizo o Linux Fedora 43 KDE em um Notebook Acer Predator PHN16-72.
Instalei o minikube, subi o kube-prometheus-stack via Helm:
helm install prometheus-stack prometheus-community/kube-prometheus-stack \
--namespace monitoring \
--set grafana.adminPassword=admin123
Seis pods subindo de uma vez. Grafana com dashboards prontos. Prometheus coletando métricas reais do Minikube.
Então criei a estrutura base com slash commands em Markdown dentro de .claude/commands/:
| Comando | Função |
|---|---|
/sentinel |
Orquestrador principal |
/collect-metrics |
Sub-agent A — consulta Prometheus via PromQL |
/analyze-pods |
Sub-agent B — verifica pods via kubectl |
/correlate |
Sub-agent C — classifica severidade |
O CLAUDE.md virou a memória operacional do agente: endpoints, thresholds, namespaces, template de runbook.
Rodei /sentinel pela primeira vez e ele gerou isso:
Severidade: WARNING
CPU: 11.4% ✅ | Memória: 45.1% ✅ | Disco: 17.65% ✅
64 Warning events identificados como residuais de restart anterior do nó
storage-provisioner: BackOff recente — requer monitoramento
O agente separou ruído de sinal sozinho. Identificou que os 64 eventos de Warning eram residuais de um reboot do Minikube — não anomalias reais. Isso não estava no prompt. Foi raciocínio do modelo.
v1.0 no GitHub. Mesmo dia do certificado.
Dia 2: a v1.1 e o startup automático
O maior atrito da v1.0 era operacional: toda vez que abria o Claude Code, precisava lembrar de subir os três port-forwards manualmente antes de rodar qualquer comando.
Criei o /startup — um agente que verifica se Prometheus, Grafana e AlertManager estão acessíveis e sobe apenas os port-forwards ausentes, em background, com retry de até 10 tentativas:
╔══════════════════════════════════════════╗
║ Sentinel — Startup ║
╚══════════════════════════════════════════╝
Prometheus (localhost:9090) → ✅ STARTED
Grafana (localhost:3000) → ✅ STARTED
AlertManager (localhost:9093) → ✅ STARTED
Também expandi o /analyze-pods para monitorar múltiplos namespaces em paralelo: default, monitoring e kube-system — com resultados agrupados por namespace e correlação de causa raiz cruzada.
O resultado ficou assim:
| Namespace | Total | Unhealthy |
|---|---|---|
| default | 0 | 0 |
| monitoring | 6 | 0 (todos Running) |
| kube-system | 8 | 0 (todos Running) |
E o agente ainda identificou o storage-provisioner com 21 restarts versus média de 8 dos outros pods — sinalizando o componente realmente anômalo sem nenhuma instrução explícita sobre isso.
v1.1 no GitHub. Dia 2.
A semana do Gemini: quando o Claude Code saiu do ar
Na semana seguinte, senti uma grande dificuldade de utilizar o Claude, seja via web ou Code via terminal. Os tokens estavam sendo consumidos muito mais rápido, mesmo seguindo todas as boas práticas recomendadas da própria Anthropic. Reclamações começaram a se multiplicar no Reddit, X, Stack etc. Aparentemente a demanda estava sendo alta demais para absorverem. Eu uso o plano pro R$20 dólares, sei que não é grande coisa, mas mesmo para estudos estava inviável.
Migrei para o Gemini. Funcionou por um bom tempo — e foi nesse período que o Sentinel começou a ganhar as features mais complexas: o Go agent, a integração com PostgreSQL, o dashboard.
Mas à medida que o projeto crescia, os problemas apareceram:
- UI do dashboard: o Gemini gerava HTML funcional mas com inconsistências visuais que eu precisava corrigir manualmente
- Segurança no código: Utilizei o Claude Code rapidamente para ser um code review e encontrei padrões no código gerado que me preocuparam — falta de validação de input, headers de segurança ausentes, queries SQL sem sanitização adequada
Quando o Claude Code voltou a funcionar (deram um crédito adicional de R$ 110), migrei de volta. O custo por sessão é maior e a janela de contexto é menor — mas a qualidade e confiabilidade do código gerado, especialmente em questões de segurança, compensam.
O Sentinel nasceu no Gemini. Mas cresceu no Claude Code.
A v2.0: quando virou plataforma
A virada aconteceu com uma pergunta: "e se eu tiver os dados já coletados antes de chamar o Claude?"
Ou sejam queria uma plataforma em RealTime e entrar de cabeça no vibecoding.
Os slash commands consultavam Prometheus e kubectl em tempo real a cada execução. Isso funcionava, mas era lento e stateless — sem histórico, sem tendência, sem FinOps real.
A solução: um Go agent rodando continuamente em background.
// Coleta a cada 10 segundos
// Persiste no PostgreSQL
// Expõe API REST para o Claude consumir
Com client-go nativo, o agent coleta métricas de CPU, memória e waste por pod, persiste em transação batch no PostgreSQL e expõe três endpoints:
| Endpoint | Descrição |
|---|---|
GET /api/summary |
Estado do cluster: nodes, pods, CPU |
GET /api/metrics |
Métricas por pod: CPU usage, waste |
GET /api/history |
Histórico de custo dos últimos 30min |
O Claude Code passou a consumir esses endpoints via /incident em vez de fazer as queries diretamente. Separação de camadas real: Go coleta, Claude analisa.
Node Health Map com honeycomb, Pod Distribution com donut chart, Waste Intelligence com savings opportunities por pod, ROI Timeline financeiro com Budget vs Actual nos últimos 30 minutos.
O harness: tratando output de LLM como untrusted input
Bem, entre publicações no Linkedin, meu irmão me enviou um artigo interessante sobre Harness Engineering, basicamente ter segurança e confiabilidade ao redor do modelo, com infraestrutura adequada, revisões de segurança e padrões de ReACT constante (Review, ACT) além de feedback.
Segue artigo: Harness Engineering — Martin Fowler
Uma decisão de arquitetura muito importante para colocar o conceito em prática: o harness/validador_saida.py.
Todo relatório gerado pelo Claude Code passa por um gatekeeper antes de ser gravado em disco. O validador bloqueia:
| Regra | Exemplos bloqueados |
|---|---|
| Comandos destrutivos |
rm -rf, kubectl delete, DROP TABLE, fork bomb |
| Estrutura obrigatória | Relatórios sem ## Resumo Executivo são rejeitados |
| Tamanho mínimo | Conteúdo menor que 100 chars é rejeitado |
if result.returncode != 0:
return {
"status": "error",
"message": f"Validador bloqueou a gravação: {result.stderr.strip()}",
"file": None,
}
Se o validador rejeitar, o arquivo não é criado. Ponto.
Isso não é paranoia — é arquitetura de produção. Qualquer sistema que usa LLM para gerar ações sobre infraestrutura precisa de um gatekeeper.
O que o vibe coding significa na prática
Vibe coding não é "deixar a AI fazer tudo". É uma forma específica de trabalho:
Você define o quê. A AI decide o como.
Em cada etapa, eu sabia o resultado que queria e agia como SRE, tomador de decisões:
- "Quero que o startup verifique os serviços e suba os port-forwards ausentes"
- "Quero análise agrupada por namespace com correlação de causa raiz"
- "Quero um gatekeeper que bloqueie comandos destrutivos antes de gravar"
O agente implementava. Eu revisava, questionava, redirecionava.
O que me surpreendeu: em nenhum momento eu escrevi uma linha de código do Go agent, do dashboard, ou do harness. Mas cada decisão de arquitetura foi minha. A AI foi o meu software engineer sênior.
O que ficou claro sobre Claude Code
Pontos fortes:
- Qualidade e consistência do código gerado, especialmente em Go
- Raciocínio sobre segurança — headers HTTP corretos, sanitização, permissões de arquivo
- Capacidade de manter contexto de projeto via
CLAUDE.md - Sub-agents paralelos que genuinamente executam em paralelo
- Capacidade de criação UI otimizada
Limitações reais:
- Janela de contexto menor que concorrentes — projetos grandes exigem
/compactfrequente - Custo por token mais elevado — relevante em sessões longas
- A instabilidade de tokens que aconteceu na semana passada mostrou que dependência total de um único provider é risco real
Timeline da jornada
| Data | Marco |
|---|---|
| 8 mar 2026 | Certificado Claude Code in Action — Anthropic/Skilljar |
| 8 mar 2026 | v1.0: slash commands + Prometheus + K8s |
| 9 mar 2026 | v1.1: startup automático + múltiplos namespaces |
| Semana 2 | Migração temporária para Gemini — restrição global de tokens Anthropic |
| Semana 2-3 | v2.0: Go agent + PostgreSQL + dashboard + harness |
| Semana 3 | Retorno ao Claude Code + renomeação para Sentinel |
Onde está hoje
O projeto é open source, Apache 2.0:
👉 github.com/boccato85/Sentinel
Stack completa:
- Minikube / Kubernetes v1.35.1
- kube-prometheus-stack
- Go agent com
client-go - PostgreSQL
- Claude Code 2.1.76
- MCP Servers (Prometheus + kubectl)
Se você trabalha com SRE, CloudOps ou FinOps e quer explorar Claude Code na prática, esse é um ponto de partida real — não um hello world.
Esse projeto faz parte de uma trilha pessoal: CKA → Claude Code → MLOps. Se quiser acompanhar, me segue aqui no dev.to.
Top comments (0)