Vibecoding?

Ich habe in den letzten Wochen drei kleine Apps für meinen Homeserver gebaut: eine Kanban-To-Do-App, eine Einkaufsliste und zuletzt ein Brainstorming-Tool mit Canvas, Board und KI-Anbindung. Ohne Claude wären die nie entstanden — ich bin Hobby-Entwickler, kein Vollblut-Coder. Mit Claude war es ein paar Abende Arbeit pro App.

Die Apps sind kein Selbstzweck. Sie sind Teil eines größeren Vorhabens: meine Abhängigkeit von großen Diensten Stück für Stück zu reduzieren. Die Kanban-App hat bei mir die kleinen Post-its abgelöst, die ich vorher auf meinem Schreibtisch kanban-artig zu Spalten arrangiert hatte. Die Einkaufsliste ersetzt ein gemeinsames Google-Doc, das meine Frau und ich gepflegt haben. Bei Kanban und Einkaufsliste funktioniert das hervorragend, und ich bin guter Hoffnung, dass Brainstorm bald genauso produktiv läuft.

Hier ist, wie ich vorgegangen bin, was die wirklichen Stolpersteine waren und ob das, was ich da gemacht habe, nun „Vibe Coding" ist oder etwas anderes.

Was die Apps konkret leisten

Die Brainstorm-App ist das ambitionierteste der drei Projekte. Sie hat:

• Eine Canvas-Ansicht: frei platzierbare Karten mit Verbindungen, Pan und Zoom wie in Miro.
• Eine Board-Ansicht: Kanban-mäßig, sortiert nach Kategorien, mit Drag & Drop zur Priorisierung.
• Mehrere Sessions: pro Thema ein eigenes Brainstorming, mit Markdown-Beschreibung, archivierbar.
• KI-Integration über die Anthropic-API: Karten generieren oder weiterdenken lassen, mit der Session-Beschreibung als Kontext.
• Markdown-Export pro Session, sortiert nach der im Board festgelegten Priorität.
• Läuft als PWA, hinter Nginx, in Docker, persistent in SQLite — selbstgehostet, kein Konto, keine Subscription.

Die anderen beiden Apps sind funktional kleiner, aber im Alltag wichtiger. Die Kanban-App läuft als PWA auf Phone und Tablet, alle Geräte sehen denselben Stand — was die physischen Post-its nie konnten. Die Einkaufsliste teile ich mit meiner Frau: sie tippt unterwegs einen Joghurt rein, ich sehe das beim nächsten Öffnen. Beide sind so stabil, dass ich sie nicht mehr aktiv im Kopf habe. Genau das ist das Ziel. Brainstorm ist noch in der Erprobung — der unten beschriebene Stand ist das, womit ich jetzt erst anfange, ernsthaft zu arbeiten.

Wie das technisch läuft

Alle drei Apps laufen auf demselben Linux-Server zu Hause, jede in einem eigenen Docker-Container, mit eigenem SQLite-Volume. Davor schaltet ein Nginx Proxy Manager — er macht SSL-Terminierung intern, routet zur jeweiligen App und macht für die meisten Pfade Basic Auth.

Vor dem Heimserver steht Cloudflare. Es übernimmt DNS-Auflösung, schirmt meine Heim-IP ab, terminiert TLS am Edge und fängt Bot-Traffic ab, bevor er bei mir aufschlägt. Aus Sicht der App ändert das nichts — der Server bekommt schon entschlüsselten Traffic mit den richtigen X-Forwarded-Headern. Aus Sicht der Sicherheit verändert es viel: meine echte IP ist nicht öffentlich, Skript-Kiddies finden im Internet nur Cloudflare. Externe API-Calls — die KI-Funktion in Brainstorm — gehen vom Container direkt zur Anthropic-API. Der API-Key liegt nur server-seitig in der .env, niemals im Browser.

Parallel spiele ich gerade mit zwei Optionen für die KI-Funktion: ein Ollama, das auch auf meinem Homeserver liegt (langsam!) und einem Mistral, das ich bei Mittwald hoste (das ist ganz vielöversprechend).

Wie es lief — sieben Iterationen

Ich hatte keinen Plan. Nicht im Sinne von User Stories oder Sprints, sondern: ich hatte einen Bedarf und einen Stack, der schon stand. Was dann lief, war eine Folge von Iterationen, wobei jede aus einer Beobachtung beim tatsächlichen Benutzen entstand.

Iteration 1 — Basis. Ich beschrieb Claude meinen Setup (Node.js + Express + SQLite, Docker, Nginx vor jeder App), warf zwei Screenshots meiner Kanban-App rein und sagte „bau mir etwas Vergleichbares, aber als Brainstorming-Tool mit Canvas und Board". Eine Antwort später hatte ich ein Tarball: Server, Frontend, Docker-Compose, Nginx-Snippet, alles drin.

Iteration 2 — Verbindungen. Beim Benutzen merkte ich: Karten allein reichen nicht, ich will sie verknüpfen können. „Connect-Modus, klick-klick statt drag-to-connect, weil ich mobil arbeite." Klappte.

Iteration 3 — Canvas-UX. Pannen mit Scrollbars war unangenehm, Zoom fehlte, das Emoji auf den Karten war zu klein. „Pan auf leerer Fläche, Strg+Mausrad für Zoom unabhängig vom Browser-Zoom, Emoji größer und mittig. Außerdem: Karten klonen mit Strg+C/V." Lief beim ersten Versuch, inklusive cursor-stabilisiertem Zoom.

Iteration 4 — Mehrere Sessions. Hier wurde es interessant. Bisher gab es eine globale Pinnwand. Ich brauchte mehrere — Garten-Brainstorming, Geburtstagsfeier, Renovierung. Mit präziser Anforderung: Markdown-Beschreibung, archivieren, klonen, Markdown-Export mit definierter Struktur (H1, Beschreibung, H2 pro Kategorie, Karten nach Board-Priorität). Migration ohne Datenverlust. Das war kein Feature, das war ein Architektur-Umbau — Routing, DB-Schema, neue Views. Hat länger gedauert, brauchte zwei, drei Korrekturen.

Iteration 5 — Deploy-Hölle. „Ich habe das Paket neu installiert, manche Änderungen wirken, andere nicht — das Sessions-Feature finde ich gar nicht." Diagnose: Service Worker hatte alte HTML aus seinem Cache geliefert, Docker hatte den Layer-Cache benutzt, im Container war eine Mischung aus alt und neu. Lösung: SW auf network-first umgestellt, Cache-Control: no-cache für HTML/JS gesetzt, defensiver Check ins Frontend (wenn HTML zur JS nicht passt, klarer Hinweis statt leerer Bildschirm).

Iteration 6 — PWA installierbar. Chrome bot die Installation nicht an. Diagnose: das Manifest-Fetch bekam HTTP 401, weil mein Nginx Basic Auth davorhat und der Browser das Manifest ohne Credentials lädt. Lösung: crossorigin="use-credentials" im Link-Tag. Eine Zeile Code, anderthalb Stunden Diagnose.

Iteration 7 — Kosmetik. Emoji optional machen, eckige Karten statt abgerundete, dezente Hintergrundfarben in vier Tönen. Standardkram, in 15 Minuten erledigt.

Die Stolpersteine waren nie der Code

Was am meisten Zeit gefressen hat, war nicht das Bauen neuer Features, sondern das Drumherum: Service-Worker-Caching, Docker-Layer-Cache, Browser-Cache, Basic-Auth-Quirks, PWA-Installationsbedingungen. Nichts davon ist „Code" im engeren Sinn. Es sind Probleme an den Grenzen zwischen Komponenten — und genau dort ist die KI schwach, weil sie nicht in mein System hineinschauen kann.

Konkretes Beispiel: Als die neue Sessions-Version im Browser nicht ankam, konnte Claude mir zwar erklären, was wahrscheinlich schiefläuft, und mir Diagnose-Befehle geben. Aber ich musste sie ausführen, das Ergebnis lesen, interpretieren und entscheiden. Die KI war nützlich, aber ohne mich am Steuer wäre es nicht weitergegangen.

Das ist mein wichtigster Eindruck aus dem Projekt: Die KI kann Code schreiben, aber sie kann nicht für mich deployen. Sobald die Welt jenseits des Editors anfängt — Reverse-Proxy, Container-Build-Cache, Browser-Verhalten, Service Worker, Auth-Layer, Cloudflare-Settings — bin ich gefragt.

Ist das eigentlich Vibe Coding?

Andrej Karpathy hat den Begriff im Februar 2025 geprägt: Programmieren, indem man der KI „nachgibt", den Code nicht mehr im Detail anschaut, „Accept All" klickt und das Tool gewähren lässt. Bei ihm halb augenzwinkernd für kleine Wegwerf-Projekte beschrieben — der Begriff hat sich aber verselbständigt und wird heute oft als Sammelbezeichnung für „mit AI bauen" benutzt.

Wo liege ich? Irgendwo in der Mitte. Auf der einen Seite:

• Ich lese den generierten Code nicht zeilenweise. Ich entpacke das Tarball, ich starte den Container, ich klicke in der App rum und schaue, ob es funktioniert.
• Ich gebe Anforderungen in normalem Deutsch, nicht in formalen Specs.

Auf der anderen Seite:

• Ich liefere präzise Anforderungen: „Mehrere Sessions, jede mit Titel, Markdown-Beschreibung, Erstellungs- und Änderungsdatum. Archivieren möglich. Export als Markdown mit folgender Struktur: H1, dann Beschreibung, dann H2 pro Kategorie, dann Karten in der durch Board-Drag bestimmten Reihenfolge." Das ist eine kleine Story-Map, kein Vibe.
• Ich erkenne, wenn die KI in die falsche Richtung läuft, und korrigiere früh.
• Ich kann Systemprobleme einordnen (Cache, Auth, Build, Reverse Proxy) und Claude in die richtige Diagnose-Richtung schubsen.

Für mich passt eher: AI-augmented spec-driven development. Pair-Programming, bei dem die KI die Rolle des fleißigen Junior-Entwicklers übernimmt — schneller tippend als jeder Mensch, mit großem Bibliothekswissen, aber mit blinden Flecken beim Systemkontext. Ich bin Architekt, Reviewer und Deploymaster.

Pures Vibe Coding wäre: „Bau mir was, womit man Ideen sammeln kann." Klick, Klick, abgenickt. Mein Vorgehen ist näher an klassischer Software-Entwicklung, nur mit massiv beschleunigtem Tipp-Schritt.

Insgesamt drängt sich mir der Eindruck auf, dass auch mit KI Leute mit zumindest rudimentärer Ahnung von IT schneller zum Ziel kommen.

Andere Tools, andere Wege?

Wahrscheinlich hätte es schneller gehen können — je nach Phase. Mein Workflow war: Chat im Browser, am Ende ein Tarball, das ich auf den Server schiebe, dort entpacke und neu baue. Bei jeder Iteration. Das ist langsam.

Schneller wäre es vermutlich mit:

• Claude Code (das CLI von Anthropic): liest und schreibt Files direkt im Projekt-Ordner. Keine Tarball-Roundtrips. Für ein Projekt auf meinem Niveau das vermutlich beste Tool.
• Cursor oder Windsurf: IDE-integriert, Diff-View, kann ganze Codebases lesen. Stärker für größere Projekte mit viel bestehendem Code.
• v0.dev / Lovable / Bolt: hervorragend für UI-Prototypen mit Live-Preview, aber für eine selbstgehostete Backend-App mit Docker-Compose und Nginx eher Overkill in die falsche Richtung.

Was ich nicht missen möchte, ist die Chat-Form. Ich kann zwischen Iterationen denken, ohne dass mir ein Editor im Weg ist. Ich kann Screenshots reinwerfen („so soll das aussehen, das hier ist meine Kanban-App"). Ich kann lose Anforderungen formulieren („das Icon soll mittig, größer, und optional"). Für ein „Nebenbei-Projekt am Abend" ist das genau richtig.

Beim nächsten größeren Projekt würde ich vermutlich auf Claude Code umsteigen. Die Tarball-Akrobatik in dieser Form wäre für etwas mit zehnmal so viel Code zu mühsam.

Was ich daraus mitnehme

Iteration schlägt Spezifikation. Ich hätte zu Beginn nie alle Features so spezifizieren können, wie sie jetzt sind. Erst durch das Benutzen wurde klar, was fehlt. Das gilt für AI-Entwicklung wie für jede andere Software-Entwicklung — nur ist der Iterationszyklus jetzt so kurz, dass man es sich auch tatsächlich erlauben kann.

Iteratives Verbessern ist enorm motivierend. Das Gefühl, eine Idee am Sofa zu skizzieren und am übernächsten Abend in produktiver Nutzung zu haben, treibt mich. „Das nervt, mach es bitte so" — wenige Minuten später ist es behoben. Bei klassischer Softwareentwicklung kommt dieses Erfolgserlebnis alle paar Wochen; hier kommt es mehrmals pro Sitzung. Das ist nicht nur effizient, es macht auch sichtbar mehr Spaß.

Die KI ist gut, der Mensch macht den Unterschied. Beim Code-Schreiben ist Claude schnell — die Sessions-Umstellung mit Backend, Frontend, Routing und Markdown-Export war eine Iteration. Aber bei Cache-Problemen, Auth-Fallen und Deploy-Stolpern bin ich gefragt. Ohne ein Mindestmaß an System-Verständnis bleibt man stecken.

„Vibe Coding" ist ein zu eng definierter Begriff für ein breites Spektrum. Die meisten Leute, die heute „mit AI bauen", machen kein reines Vibe Coding. Sie machen AI-augmented development mit unterschiedlich viel Eigen-Einsatz. Es gibt nicht die AI-Entwicklung — es gibt einen Workflow, der zu jedem Menschen und jedem Projekt anders aussieht.

Selbstgehostete Tools machen unabhängiger. Drei eigene Apps haben drei externe Konstrukte abgelöst: das Post-it-Chaos auf meinem Schreibtisch, ein gemeinsames Google-Doc und gelegentliches Brainstormen in fremden SaaS-Diensten. Jede davon kostete kein Geld — aber jede davon hat mir auch nicht mehr genau das geboten, was ich brauchte. Mit Claude wird der Eigenbau für persönliche Tools wieder zur realistischen Option. Mein neuer Reflex bei jeder kommerziellen App, die mich nervt: erstmal fragen, ob ich es selbst bauen kann.