Claude Analyzer Entwicklung

Table of Contents

Meine Kenntnisse in Softwareentwicklung sind eher begrenzt. Daher habe ich versucht mit Unterstützung von Claude Code meinen Claude Analyzer (siehe KI-gestützte Alert-Analyse für Kubernetes und CheckMK) zu entwickeln, einem Go-Dienst, der Monitoring-Alerts von Kubernetes und CheckMK entgegennimmt, Kontext sammelt und via Claude API eine automatische Ursachenanalyse erstellt.
Die Besonderheit: Sowohl der initiale Entwurf als auch die gesamte weitere Entwicklung laufen primär über KI, ohne dass ich selbst eine Zeile Code manuell schreibe.

Phase 1: Initialer Entwurf mit Claude Code

Den Grundstein legte ich lokal mit Claude Code kombiniert mit dem Superpower Skill, der erweiterte autonome Fähigkeiten ermöglicht. In dieser ersten Phase entstand die Architektur: die zwei Analyzer-Dienste, die gemeinsame Bibliothek, das Webhook-Handling, die Claude-API-Integration und die Grundstruktur der Tests.
Sobald der initiale Entwurf stand, wurde der Code in ein Git-Repository überführt, und damit begann Phase zwei.

Phase 2: Autonome Weiterentwicklung über NanoClaw

Der Großteil der Weiterentwicklung läuft über NanoClaw, einem "secure", "lightweight" "personal AI agent". Als Kommunikationspunkt mit dem Agent nutze ich einen für die Entwicklung des Analyzers dedizierten Matrix/Element Chat-Channel. Ich kann per Chat Anweisungen geben, Fragen stellen, Bugs melden, und der Bot liest den Code, analysiert ihn und macht Änderungen.

Das alleine ist schon praktisch. Aber der eigentliche Kern des Ansatzes ist ein stündlicher automatischer Task: Ohne, dass ich etwas mache, wacht NanoClaw einmal pro Stunde auf, liest den aktuellen Stand des Repositories, prüft auf mögliche Verbesserungen, schreibt Tests, schließt Coverage-Lücken, behebt Lint-Fehler, und committet das Ergebnis direkt auf den Main-Branch. Schaut man sich die commit History an, sieht man fast stündlich einen neuen commit. Nein, ich arbeite Nachts nicht. Normalerweise schlafe ich da 😅

Der detaillierte prompt

You are an autonomous software engineer working on the claude-alert-analyzer project at /workspace/extra/claude-alert-analyzer. The project architecture and structure are documented in CLAUDE.md (auto-loaded).

## Your Mission

Proactively explore the codebase, find ONE meaningful improvement, and implement it.

## Process

1. cd /workspace/extra/claude-alert-analyzer && git pull origin main
2. Run git log –oneline -5 to see what was recently done — avoid duplicating recent work.
3. Read the source files directly. Look for bugs, edge cases, missing error handling, untested paths, security gaps, or reliability issues. Think like a code reviewer.
4. Pick ONE improvement. Implement it.
5. Build:

export PATH=$PATH:/usr/local/go/bin
export GOMODCACHE=/tmp/gomodcache
go build ./… || { echo „BUILD FAILED — do not commit“; exit 1; }

6. git add only changed files.
7. git commit — conventional commit, no Co-Authored-By lines. Pre-commit hooks run automatically and will catch lint issues and run tests.
8. git push origin main
9. Send a chat message: what you found, why it matters, what you changed.

## Test writing rules

After every t.Fatal(…) or t.Fatalf(…) that guards a nil pointer, always add return immediately after:

12345678910go
// CORRECT
if x == nil {
t.Fatal(„x must not be nil“)
return
}
// WRONG — causes SA5011
if x == nil {
t.Fatal(„x must not be nil“)
}

## What to look for (in priority order)

1. Bugs — incorrect behavior, race conditions, off-by-one errors, wrong assumptions
2. Missing error handling — ignored errors, missing timeouts, unhandled edge cases
3. Security — input validation gaps, injection risks, secret leakage, missing auth checks
4. Reliability — retries, graceful degradation, panic recovery, context propagation
5. Missing tests — untested exported functions, critical paths without coverage
6. Code quality — confusing logic, duplication, unclear interfaces

## Rules

– ONE change per run. Focused beats broad.
– Never break existing functionality.
– Follow existing code style and patterns.
– Write tests for new code; regression tests for bug fixes.
– Do not modify CLAUDE.md or README.md.
– Do not change go.mod unless strictly necessary.
– Do not touch .github/workflows/.
– No large rewrites — incremental only.
– If nothing meaningful found: do nothing. Empty run beats pointless change.
– If build fails and you cannot fix it: revert everything and do nothing.
– If the pre-commit hook blocks the commit due to lint or test errors, fix them and retry.

Der Entwicklungszyklus sieht in der Praxis so aus:

Ich schreibe eine Nachricht über Element: "Füge einen separaten Prometheus Metrics-Endpunkt auf einem konfigurierbaren Port hinzu"
Der Bot liest die relevanten Dateien, plant die Implementierung und setzt sie um
Tests, Lint, Commit, alles in einem Durchgang
Beim nächsten stündlichen Task prüft der Bot, ob es Folgearbeiten oder andere dem Prompt entsprechende Aufgaben gibt

Guardrails: Pre-Commit Hooks als Sicherheitsnetz

Wenn ein KI-Bot eigenständig Code schreibt und committet, braucht es ein paar Absicherungen. Natürlich kann ich dem Agent sagen, führe nach jeder Änderung go test und golangci-lint aus. Das funktioniert...naja... drauf verlassen würde ich mich nicht.
Es musste eine Lösung her, die Unabhängig vom Agent funktioniert: Pre-Commit Hooks. Pre-commit Hooks werden automatisch ausgeführt, bevor der git commit angewendet wird. Neben kleineren Dingen führen die vor allem go test und golangci-lint aus, unabhängig vom Agent. Und der Agent kann sich nicht dagegen wehren.

Schlägt einer der Hooks fehl, wird der Commit blockiert. Der Agent bekommt den Fehler zurück und muss ihn beheben, bevor er erneut commiten kann. Das hat sich in der Praxis sehr bewährt. Viele typischen Fehler, etwa fehlende return-Statements nach t.Fatal(), nicht geprüfte Error-Returns, falsche Selektoren, wurden so bisher zuverlässig abgefangen.

Etwas mehr Dokumentation zu den pre-commit Hooks ist im Git Repo zu finden.

Automatische Dependency-Updates mit Renovate

Go-Module, GitHub Actions, Docker Base Images, alles veraltet mit der Zeit. Statt manuell go get -u auszuführen oder GitHub Actions Versionen zu pflegen, übernimmt das Renovate. Niemand kann manuell bei all den Depdendencies den Überblick behalten...

Renovate scannt das Repository regelmäßig, erkennt veraltete Abhängigkeiten und öffnet automatisch Pull Requests mit den Updates. Da jeder Merge auf Main ein neues Docker Image baut, landet ein Dependency Update innerhalb kürzester Zeit als frisches Image in der Registry, ohne auch nur einen Finger manueller Arbeit zu rühren.

CI/CD: Jeder Commit baut ein Docker Image

Das Projekt enthält ein Multi-Stage Dockerfile mit zwei Targets: einen für den k8s-analyzer und einen für den checkmk-analyzer. Die GitHub Actions Pipeline baut bei jedem Push auf Main beide Images und pusht sie nach ghcr.io, getaggt mit dem kurzen Commit-SHA und latest.

Das bedeutet: Jede Änderung des Bots, jedes Renovate-Update, jeder meiner Commits landet automatisch als deployfertige Container-Images in der Registry. Kein manuelles Bauen, kein manuelles Pushen.

Fazit: KI-gestützte Entwicklung mit definierten Grenzen

Dieses Setup zeigt, was heute mit KI-gestützter Entwicklung möglich sein kann, wenn man ein paar Dinge beachtet:

Mit dem Source Code über einen Chat Kanal "chatten"
Autonomie durch einen stündlichen Task, der ohne Intervention
arbeitet
Sicherheit durch Pre-Commit Hooks, die schlechten Code blockieren
Aktualität durch Renovate für automatische Dependency-Updates
Schnelligkeit durch CI/CD, das jeden Commit direkt als Image verfügbar macht

Der Bot ist kein Ersatz für technisches Verständnis. Bei Features muss ich immer noch entscheiden, was gebaut wird und warum. Aber das Wie und die iterative Feinarbeit, Tests, Lint-Fixes, Coverage-Lücken schließen, übernimmt NanoClaw. Und das macht einen erheblichen Unterschied.

Den Quellcode gibt es auf GitHub: madic-creates/claude-alert-analyzer.

Ähnliche Beiträge