Diário de vibe coding: do certificado Anthropic a uma plataforma de FinOps em dias

Marcel Boccato — Sun, 05 Apr 2026 22:08:13 +0000

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 /compact frequente
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.

DEV Community: Marcel Boccato