Ich werde dir jetzt etwas gestehen, das mich als jemanden, der seit über 35 Jahren in der Kommunikationsbranche arbeitet und seit 2024 KI-Beratung macht, ein bisschen was kostet: Ich hatte ein Projekt, das mich genervt hat. Richtig genervt. Und ich habe eine ganze Weile gebraucht, um zu kapieren, warum.
Das Projekt heißt VINCI. Mein persönlicher KI-Assistent. Warum nennt man sowas VINCI? Wegen Leonardo da Vinci: Meine größte Bewunderung gilt einem Menschen der seit 500 Jahren tot ist. Er war Vordenker. Er hat immer zuerst gefragt: Was könnte sein? Ich bewundere diesen Ansatz. Steht auch so auf meiner privaten Webseite.
Der Ausgangspunkt: Eine Webapp, die kein Spaß mehr macht
VINCI war ursprünglich eine Webapp. Claude Code, FastAPI, Docker auf Hetzner mit Coolify. Ich habe darüber gebloggt, ich war stolz darauf, und es hat funktioniert. In gewissem Sinne.
Aber dann kam der Alltag.
Jedes Mal, wenn ich etwas anpassen wollte, fing die Prozession von vorne an. Umgebungsvariablen setzen. Docker-Container neu bauen. Coolify-Deployment anstoßen. Freigaben erneuern, wenn sich irgendein API-Token geändert hatte. OAuth-Flows erneut durchklicken, weil Google oder Microsoft wieder entschieden hatten, dass meine App „nicht vertrauenswürdig“ aussieht. Browser-Permissions. CORS-Einstellungen. Reverse-Proxy-Konfigurationen.
Das Ding lief auf einem Server. Irgendwo in Deutschland. Und ich habe es über einen Browser bedient.
Klingt simpel, ist aber das Problem: VINCI sollte mein persönlicher Assistent sein. Nicht ein Produkt, das ich warte. Nicht eine Infrastruktur, die ich pflege. Ein Werkzeug, das einfach da ist und funktioniert, wenn ich es brauche. Wie mein MacBook. Wie meine Kaffeemaschine.
Irgendwann, kurz vor dem letzten Wochenende, habe ich realisiert: Die Web-Architektur ist der falsche Ansatz für diesen Use Case. VINCI soll lokal laufen. Auf meinem Rechner. Mit Zugriff auf meine lokale Datenwelt. Und das nicht über einen umständlichen Server-Umweg.
Der Entschluss: Freitagmorgen, klarer Kopf
Ich bin Frühaufsteher. Um 6:00 Uhr bin ich im Büro, der Kaffee läuft, und ich denke nach. An diesem Freitag war die Entscheidung nach etwa zehn Minuten gefallen.
Ich mache aus VINCI eine echte Desktop-App. Für Mac und Windows.
Jetzt muss ich kurz erklären, was das bedeutet. Ich bin Kommunikationsdesigner. Kein Programmier-Profi, aber ich verstehe, was ich tue, wenn ich HTML schreibe, JavaScript entschlüssle oder eine REST API aufrufe. Von nativer App-Entwicklung für macOS oder Windows weiß ich hingegen: fast nichts. Ich kenne Swift nicht. Ich kenne Electron nur dem Namen nach. Ich habe noch nie eine .dmg-Datei selbst gebaut.
Macht nichts. Dafür habe ich Claude Code.
Was ist eigentlich Vibe Coding?
Falls du den Begriff noch nicht kennst (solltest du, wenn du mir schon etwas länger folgst): Vibe Coding bezeichnet eine Arbeitsweise, bei der du nicht selbst den Code schreibst, sondern mit einem KI-Modell gemeinsam entwickelst. Du beschreibst, was du willst. Die KI baut es. Du testest, gibst Feedback, korrigierst die Richtung. Keine Zeile Code entsteht ohne dein Zutun, aber du schreibst kaum selbst.
Der Begriff kommt von Andrej Karpathy, einem der bekanntesten KI-Forscher weltweit, und beschreibt präzise, wie sich diese Arbeitsweise anfühlt: Du bist im Flow. Du surfst auf einer Welle, die das Modell erzeugt. Du navigierst, du steuerst, du entscheidest. Aber du paddest nicht selbst.
Ich nutze Claude Code schon seit einigen Monaten intensiv. Für Webprojekte, für Automatisierungen, für Skripte. Aber Desktop-Apps? Das war Neuland.
Der Build-Prozess: Was in einem Tag entstanden ist
Ich habe Claude Code geöffnet, mein Terminal, und angefangen zu beschreiben, was ich will. Nicht in einem langen Dokument, nicht in einem Spezifikationsheft. Einfach Schritt für Schritt.
Das Ergebnis nach einigen Stunden:
Ollama-Integration für lokale Chats. Ich kann mit VINCI reden, und meine Konversationen verlassen meinen Rechner nicht. Ollama läuft lokal, das Modell läuft lokal, die Daten bleiben lokal. Kein API-Call zu OpenAI, kein Prompt, der über fremde Server geht. Das war mir wichtig, nicht aus Paranoia, sondern aus Prinzip. Persönliche Gedanken gehören nicht in die Cloud.
Obsidian als RAG-Quelle. Mein Obsidian-Vault fungiert als mein zweites Gehirn. Notizen, Ideen, Artikel-Drafts, Projektdokumentation. VINCI kann darin suchen und die Ergebnisse als Kontext für Antworten verwenden. Wenn ich frage: „Was habe ich letztes Monat über n8n notiert?“, bekomme ich eine sinnvolle Antwort aus meinem eigenen Wissensschatz.
Kalender lesen und schreiben. VINCI hat Zugriff auf meinen Kalender. Er sieht meine Termine, kann neue Einträge anlegen und mich darauf hinweisen, was heute noch ansteht. Das passiert lokal, über direkte Kalenderintegration, ohne Umweg über Google-APIs mit OAuth-Drama.
Aufgabenverwaltung. Tasks anlegen, abhaken, priorisieren. VINCI kennt meine offene To-do-Liste und kann aktiv darauf hinweisen, was liegengeblieben ist.
Mail-Hinweise. Wichtige Mails werden geflaggt. VINCI macht mich darauf aufmerksam, ohne dass ich permanent im Postfach schauen muss. Kein Push-Notification-Lärm, aber ein intelligenter Filter, der weiß, was meine Aufmerksamkeit verdient.
Cron Jobs für wiederkehrende Aufgaben. Das ist ein Feature, das ich besonders mag. Ich kann VINCI sagen: „Erinnere mich alle sechs Stunden an das morgige Wetter.“ Oder: „Erstelle jeden Montag früh automatisch eine Wochenplanung als Aufgabe.“ Das läuft im Hintergrund, ohne dass ich daran denken muss.
Stromverbrauch zu Hause. Ich habe eine Anbindung an die Salzburg Netz API. VINCI kann mir auf Nachfrage meinen aktuellen Stromverbrauch nennen. Das ist kein must-have Feature, aber es zeigt das Prinzip: lokale Datenquellen, die sonst niemand hat und niemand braucht außer mir.
MacBook-Status. Batteriestand, laufende Prozesse, Speichernutzung. VINCI weiß, wie es meinem Rechner geht. Klingt banal, ist aber nützlich, wenn man intensiv arbeitet und nicht permanent ins Systemmenü schauen will.
n8n Workflow-Status. Ich betreibe mehrere Automatisierungen auf meinem Hetzner-Server mit n8n. VINCI kann mir sagen, welche Workflows aktiv sind, welche zuletzt gelaufen sind und ob es Fehler gab. Das erspart mir den Login ins n8n-Dashboard für einfache Statuschecks.
Und damit sich auch visuell etwas tut, gibt’s eine coole 3D-Partikel Animation oben drauf, die richtig „Gas“ gibt, wenn VINCI zu mir spricht.
Das eigentlich Interessante: Was ich dabei gelernt habe
Jetzt wird es für dich als Leser vielleicht interessanter als die Feature-Liste.
Ich habe keine Desktop-App-Entwicklung gelernt. Ich habe keine Swift-Tutorials angeschaut. Ich habe kein Electron-Buch gelesen.
Was ich gemacht habe: Ich habe Claude Code beschrieben, was ich will. Und dann habe ich zugehört, was das Modell zurückgibt, nicht nur den Code, sondern auch die Erklärungen. Warum dieser Ansatz? Warum diese Bibliothek? Was ist der Trade-off zwischen Variante A und Variante B?
Das ist der Unterschied zwischen Vibe Coding als Abkürzung und Vibe Coding als Lernmethode.
Ich nutze es als Lernmethode.
Ja, ich hätte einfach sagen können: „Bau mir das, ich will nur das Ergebnis.“ Und das Ergebnis wäre trotzdem entstanden. Aber ich wäre dabei dümmer geblieben. Ich verstehe jetzt, warum eine Desktop-App anders mit dem Betriebssystem kommuniziert als eine Webapp. Ich verstehe, warum lokale Dateisystemzugriffe in einer nativen App fundamental anders funktionieren als über einen Browser. Ich verstehe, welche Fragen ich beim nächsten Mal früher stellen muss.
Das ist keine KI-Magie. Das ist Lernen in einem neuen Tempo.
Warum „alles lokal“ kein paranoider Sonderweg ist
Ein Punkt, der mir bei VINCI wichtig war und den ich nicht überfliegen möchte: Die Entscheidung, alles lokal zu halten.
Das ist keine Technikfeindlichkeit gegenüber Cloud-Diensten. Ich nutze Google Calendar, ich nutze Gmail, ich nutze n8n auf einem Hetzner-Server. Clouds sind nützlich.
Aber ein persönlicher KI-Assistent ist eine andere Kategorie.
Wenn VINCI meine Kalendereinträge kennt, meine Mails filtert, meine Notizen durchsucht und mein Nutzungsverhalten versteht, dann entsteht ein sehr detailliertes Bild von mir. Von meinen Gewohnheiten, meinen Prioritäten, meinen Projekten, meinen Gedanken.
Dieses Bild gehört mir. Nicht einem Anbieter. Nicht einem Rechenzentrum irgendwo.
Das ist kein ideologisches Statement. Das ist eine pragmatische Entscheidung über Datenhoheit. Als KI-Berater, der EPU und KMU in der DACH-Region betreut, bin ich in meiner eigenen Beratungspflicht: Was ich Kunden empfehle, muss ich selbst vorleben können.
Ollama läuft auf meinem MacBook. Die Daten bleiben auf meinem MacBook. Fertig.
Was das für dich bedeutet, auch wenn du kein Entwickler bist
Jetzt könnte man sagen: „Schön für dich, Alex, aber ich bin kein Programmierer. Was habe ich damit zu tun?“
Die Antwort ist eine, die mich selbst noch beschäftigt.
Die Schwelle für „ich kann das bauen“ hat sich in den letzten zwei Jahren dramatisch verschoben. Nicht graduell, sondern sprunghaft. Was ich an diesem Freitag gebaut habe, wäre vor drei Jahren ein mehrmonatiges Projekt für ein kleines Entwicklerteam gewesen. Mit Budget, mit Planung, mit Spezifikation.
Ich habe es an einem Freitag gemacht. Allein. Ohne App-Entwicklungserfahrung.
Das bedeutet nicht, dass du morgen anfangen solltest, Desktop-Apps zu bauen. Es bedeutet aber, dass der Satz „Das kann ich nicht, dafür brauche ich jemanden“ immer öfter hinterfragt werden sollte.
Vibe Coding ist kein Entwickler-Tool. Es ist ein Denkwerkzeug für alle, die wissen, was sie wollen, aber nicht wissen, wie man es technisch umsetzt.
Der Schlüssel ist nicht das technische Wissen. Der Schlüssel ist die Fähigkeit, präzise zu beschreiben, was du willst. Und das können die meisten Menschen besser, als sie denken.
Die ehrliche Bilanz: Was nicht so einfach war
Ich wäre kein fairer Erzähler, wenn ich hier nur die Erfolgsgeschichte abliefere.
Es gab Momente, in denen Claude Code etwas gebaut hat, das nicht funktioniert hat. Fehlermeldungen, die ich nicht auf Anhieb verstanden habe. Einen Moment, wo die Cron-Job-Implementierung auf Windows anders verhielt als auf macOS und ich das erst nach einer Weile gemerkt habe. Eine Integration, die ich dreimal neu formulieren musste, bis das Modell verstanden hat, was ich eigentlich meine.
Das ist normal. Vibe Coding ist keine Wünsch-dir-was-Maschine. Es ist ein iterativer Prozess. Du beschreibst, du testest, du korrigierst. Die KI macht keine Fehler aus Böswilligkeit, sondern aus Missverständnis. Und das ist letztlich deine Aufgabe als Pilot: sicherzustellen, dass du selbst klar weißt, was du willst, bevor du es beschreibst.
Die Qualität des Outputs ist direkt proportional zur Qualität des Inputs. Das war beim Prompting schon so, und beim Vibe Coding gilt es noch mehr.
Wo VINCI jetzt steht und wohin es geht
VINCI läuft. Stabil, lokal, ohne Serverkosten, ohne Update-Stress.
Ich nutze es täglich. Morgens beim ersten Kaffee bekomme ich einen kurzen Briefing-Überblick: Kalender, offene Tasks, wichtige Mails, Wetter. Kein Scrollen durch fünf verschiedene Apps. Keine Kontextwechsel. Eine Oberfläche.
Was kommt als nächstes? Ich denke über eine tiefere Obsidian-Integration nach, bei der VINCI nicht nur sucht, sondern auch neue Notizen strukturiert anlegt. Und über eine Sprachsteuerung, die wirklich gut funktioniert, nicht das halbgare Whisper-Experiment. Und mir fallen sicher noch ein paar andere spannende Dinge ein.
Aber das ist der nächste Freitag.
Was ich dir mitgeben möchte
Ich habe diesen Beitrag nicht geschrieben, um mit einer technischen Lösung anzugeben. Ich habe ihn geschrieben, weil mich die Erfahrung dieses Freitags etwas gelehrt hat, das ich für relevant halte.
Wir stehen an einem Punkt, wo die Frage nicht mehr ist: „Wer darf Tools bauen?“ Die Frage ist: „Was willst du eigentlich haben?“
Wenn du das weißt, ist der Weg dahin kürzer als du glaubst.
VINCI ist mein Assistent. Gebaut für mich. Auf meine Bedürfnisse zugeschnitten. Kein Abo, keine AGBs, keine Daten in fremden Händen.
Das ist das Versprechen von lokalem Vibe Coding, wenn man es ernst nimmt.
