Ich habe ein Full-Stack Proxmox Dashboard per Vibe-Coding gebaut: Was wirklich zählt

14 Commits, 11K Zeilen, ein KI-Agent

Vor ein paar Wochen habe ich PVE Pilot veröffentlicht, ein Full-Stack Proxmox VE Management Dashboard mit einem Go/Gin Backend, einem Next.js 16 Frontend und einer NATS Message Queue für asynchrones Provisioning. Es hat 123 Tests. Das Ganze wurde durch “Vibe Coding” mit Claude Code gebaut, Anthropics CLI-Agent.

Ich möchte präzise erklären, was das bedeutet, denn der Begriff “Vibe Coding” ist ziemlich aufgeladen. Ich habe nicht einfach “bau mir ein Proxmox Dashboard” getippt und zugeschaut. Was ich tatsächlich gemacht habe, war ein System zu entwerfen. Ich habe Go fürs Backend gewählt, weil ich starke Typisierung, exzellente Concurrency-Primitives und ein einzelnes Binary wollte. NATS für asynchrone Job-Verarbeitung, weil das Provisioning einer VM mehrere langsame Proxmox API-Aufrufe erfordert, die keinen HTTP-Handler blockieren sollten. Ein proxmox.API Interface mit 40 Methoden designt, damit jeder Handler und Worker von einer Abstraktion abhängt, nicht von einem konkreten Client, was das Ganze mit Mocks testbar macht.

Die KI hat meine architektonische Vision umgesetzt. Sie hat die Vision nicht erschaffen.

Wie Vibe Coding tatsächlich aussieht

Der Workflow ähnelte Pair Programming mit einem sehr schnellen, aber manchmal übermütigen Junior-Entwickler. Ich habe auf hoher Ebene beschrieben, was ich wollte, und die KI hat einen funktionierenden ersten Entwurf über den gesamten Stack produziert. Ich habe den Backup-Flow in drei Sätzen beschrieben (“Proxmox nutzt vzdump mit Snapshot-Modus und zstd-Komprimierung, Backups gehen auf den NFS-Speicher, ich brauche sofortige und geplante Optionen”) und hatte vierzig Minuten später eine funktionierende UI mit Echtzeit-SSE-Progress-Streaming. Go Handler, Proxmox API-Aufrufe, React-Komponenten, alles dabei.

Diese Breite ist, wo KI wirklich glänzt. Kontextwechsel zwischen Go, TypeScript, Docker Compose und Shell-Skripten in einer einzigen Konversation, ohne den mentalen Overhead, der normalerweise mit polyglotter Entwicklung einhergeht. Boilerplate und Verkabelung kamen bemerkenswert schnell zusammen. Und nachdem ich das interface-basierte Muster mit proxmox.API etabliert hatte, generierte die KI 93 Go-Tests und 30 Frontend-Tests mit passenden Mocks und tabellengesteuerten Testfällen. Das Muster war klar genug, um es konsistent zu replizieren.

Aber hier wird die Geschichte interessanter.

Wo tiefes Verständnis das Projekt gerettet hat

Das UPID-Problem

Proxmox’ Clone- und Start-Operationen werden nicht synchron abgeschlossen. Sie geben UPIDs zurück (eindeutige Prozess-IDs für Hintergrund-Tasks). Die erste Implementierung der KI versuchte, einen erfolgreichen Clone zu verifizieren, indem sie prüfte, ob die Ziel-VM existierte. Das funktionierte… meistens. Außer wenn nicht, weil das Disk-Kopieren noch lief und die VM gesperrt war. Stille Race Conditions, die schlimmste Art.

Es brauchte drei Iterationen, bis es richtig war. Nicht weil die KI den Polling-Code nicht schreiben konnte, sondern weil ich verstehen musste, warum der Clone intermittierend fehlschlug. Die Disk wurde noch kopiert. Die VM war im gesperrten Zustand. Man kann cloud-init auf einer gesperrten VM nicht konfigurieren. Sobald ich die Ursache verstanden hatte, war der Fix einfach: WaitForTask(upid) benutzen, um den Task-Status-Endpoint bis zur Fertigstellung abzufragen. Die KI schrieb die Implementierung in Minuten. Aber die Diagnose erforderte das Verständnis, wie Proxmox tatsächlich unter der Haube funktioniert.

LXC vs QEMU: Grundlegend verschiedene Welten

Das war architektonisch am bedeutsamsten. Die KI versuchte immer wieder, VM-Muster auf LXC-Container anzuwenden, und es ging jedes Mal kaputt. LXC-Container haben keinen Guest Agent. Der /config-Endpoint akzeptiert kein password oder ssh-public-keys nach der Erstellung, nur beim initialen POST /lxc. Restore verwendet andere Parameternamen (ostemplate mit restore=1 statt archive). Storage-Filterung nutzt rootdir statt images.

Kein noch so häufiges Wiederholen würde das lösen. Ich musste einen komplett separaten Code-Pfad entwerfen: SSH vom Backend zum Proxmox-Host, dann pct exec nutzen, um Befehle im Container auszuführen. Das bedeutete einen SSH-Client (golang.org/x/crypto/ssh), neue Umgebungsvariablen, Docker Volume Mounts für den privaten Schlüssel und Base64-Kodierung für Skripte, um Shell-Escaping-Probleme zu vermeiden.

Die KI schrieb den gesamten Code, sobald ich den Ansatz designt hatte. Aber der Ansatz selbst entstand aus dem Verständnis der Proxmox-Architektur, tief genug um zu wissen, dass LXC und QEMU grundlegend verschiedene Virtualisierungstechnologien mit grundlegend verschiedenen Management-APIs sind.

Die Guest Agent Falle

Der /agent/exec-Endpoint des Proxmox Guest Agents erfordert einen JSON-Body mit command: "bash" und input-data als stdin. Die KI schickte form-encodierte Requests. Proxmox antwortete mit Statuscode 596 und “Broken pipe.” Das war’s. Keine hilfreiche Fehlermeldung, kein Hinweis auf Content-Types.

Die KI riet. Sie probierte verschiedene Encodings, verschiedene Parameter, verschiedene Endpoints. Ich diagnostizierte es, indem ich das Muster erkannte: “Broken pipe” bei einem POST bedeutet meist, dass der Server den Body abgelehnt hat, bevor er ihn vollständig gelesen hat, was nach Content-Type-Mismatch schreit. Umschalten auf JSON mit den richtigen Feldnamen löste es sofort.

Die gleiche Dynamik sah ich bei der SSH-Key-Kodierung. Proxmox braucht %20 für Leerzeichen, nicht +, und Go’s url.QueryEscape produziert +. Die KI probierte drei Ansätze; ich verstand RFC 3986 vs HTML-Form-Encoding und verschrieb den Fix in einem Zug. Wenn das Problem “zwei gültige Standards und diese API hat den selteneren gewählt” lautet, schlägt Verständnis der Standards Brute-Force-Iteration jedes Mal.

Wenn keine Dokumentation existiert

Manche Probleme kann die KI einfach nicht lösen. Beim Einrichten der statischen IP-Unterstützung konnten VMs mit IPs außerhalb des DHCP-Bereichs das Internet nicht erreichen. Die KI probierte verschiedene Cloud-Init-Konfigurationen, verschiedene Gateway-Einstellungen, verschiedene Subnetzmasken. Nichts funktionierte, weil mit der Konfiguration nichts falsch war. Mein Consumer-Router macht einfach kein NAT für IPs, die er nicht per DHCP vergeben hat. Das erfährt man nur, wenn man echte Hardware in einem echten Netzwerk betreibt. Der Fix war, statische IPs innerhalb des DHCP-Bereichs aber außerhalb des dynamischen Pools zuzuweisen, etwas, das keine Dokumentation erwähnt, weil Enterprise-Router diese Einschränkung nicht haben.

Dieses Muster wiederholte sich. Debian 12 LXC-Container haben ein ssh.socket vs ssh.service Problem, bei dem SSH als “running” erscheint, aber keine Verbindungen annimmt. Grafanas Sandbox versagt lautlos in unprivilegierten LXC-Containern. Das sind keine Bugs der KI. Das ist Wissen, das aus dem Betrieb von Infrastruktur kommt, nicht aus dem Lesen darüber.

Was jetzt wirklich knapp ist

Hier ist die These, zu der ich immer wieder zurückkehre: Code schreiben wird zur Massenware. KI kann syntaktisch korrekten, gut strukturierten, idiomatisch passenden Code schneller produzieren als jeder Mensch. Aber der Code war immer der einfache Teil. Die schwierigen Teile waren immer die Teile um den Code herum, und die sind nicht einfacher geworden.

Systemdenken. Debugging jenseits der Fehlermeldung. Domänenwissen aus dem Betrieb echter Infrastruktur. Architektonisches Urteilsvermögen darüber, welche Abstraktionen die Investition wert sind und welche undicht sind. Jede Geschichte in diesem Beitrag ist ein Beispiel dafür, und in jedem Fall steckte die KI fest, bis ich das Verständnis einbrachte, das sie nicht selbst generieren konnte.

Informatik-Grundlagen (Concurrency, Netzwerke, Systemdesign, API-Design-Patterns) werden durch KI nicht obsolet. Sie werden zum Unterscheidungsmerkmal zwischen jemandem, der eine KI prompten kann, und jemandem, der tatsächlich funktionierende Software ausliefert.

Ausprobieren, kaputtmachen, verbessern

PVE Pilot ist Open Source unter github.com/ashkankamyab/pve-pilot. Wenn du ein Homelab mit Proxmox betreibst, probier es aus. Es bietet VM- und Container-Provisioning mit Echtzeit-Progress-Streaming, Backup und Restore (sofort oder geplant), vertikales Skalieren, Disk-Management und statische oder DHCP-Netzwerkkonfiguration, alles über eine saubere Dark-Theme-Oberfläche.

Die Codebase ist gut getestet (123 Tests über Backend und Frontend) und die Architektur ist bewusst sauber gehalten. Schau dir CONTRIBUTING.md an, wenn du mitmachen willst. PRs sind willkommen, egal ob du tiefe Proxmox-Expertise, Go- oder Next.js-Kenntnisse mitbringst, oder ein echtes Projekt suchst, um deinen eigenen Vibe-Coding-Workflow zu üben.

Wenn du Bugs findest oder Features willst, erstelle ein Issue. So funktioniert Open Source. Ein Commit nach dem anderen, jeder macht die Sache ein bisschen besser als vorher. Mit oder ohne KI.