Vibe Coding auf dem Mac: Das richtige Setup für Anfänger
Eine einzelne HTML-Datei aus einem Chatbot zu kopieren ist schnell. Schwieriger wird es, sobald dein Tool aus mehreren Dateien besteht, jeden Morgen automatisch laufen, auf einen ganzen Ordner zugreifen oder später von anderen Menschen genutzt werden soll. Dann reicht das Chatfenster nicht mehr als Entwicklungsumgebung.
Genau an diesem Übergang setzt Folge 005 von Kontext.FM an: Wie kommst du von einem kleinen Browser-Tool zu einem echten lokalen Projekt, ohne vorher eine Ausbildung zum Softwareentwickler zu machen?
Die gute Nachricht: Du brauchst keinen perfekt eingerichteten Entwicklerrechner und auch nicht zwölf neue Programme. Für den Anfang reichen ein Terminal, ein Paketmanager, eine Laufzeitumgebung, ein Code-Editor und ein Coding-Agent. Wichtiger als die konkrete Werkzeugwahl ist, dass du verstehst, welche Aufgabe jeder Baustein übernimmt.
Wann sich der Schritt aus dem Chatfenster lohnt
Für viele Aufgaben bleibt eine einzelne HTML-Datei die beste Lösung. Wenn du ein Tool nur gelegentlich selbst nutzt, es per Doppelklick starten kannst und keine komplizierten Integrationen brauchst, musst du daraus kein Softwareprojekt machen.
Ein lokales Entwicklungssetup lohnt sich, sobald mindestens einer dieser Punkte zutrifft:
- Dein Projekt besteht aus mehreren Dateien und soll weiter wachsen.
- Das Tool muss viele lokale Dateien oder ganze Verzeichnisse verarbeiten.
- Du möchtest fertige Bibliotheken und Pakete einbinden.
- Ein Skript soll regelmäßig oder zeitgesteuert laufen.
- Du willst externe APIs über eigene Zugangsdaten anbinden.
- Änderungen sollen nachvollziehbar und später rückgängig zu machen sein.
- Aus dem Prototyp soll irgendwann eine Anwendung für andere werden.
Der letzte Punkt gehört allerdings noch nicht zu diesem Setup. In diesem Artikel läuft alles auf deinem Rechner. Deployment, Hosting, Domains und der öffentliche Betrieb sind ein eigener Schritt.
Das mentale Modell: Vier Fragen statt zwanzig Tools
Bevor du etwas installierst, helfen vier Fragen dabei, den Werkzeugkasten zu sortieren:
- Wo liegt der Code? In einem Projektordner, den du mit einem Editor öffnest und später mit Git versionierst.
- Was führt den Code aus? Eine Laufzeitumgebung wie Node.js oder Python.
- Wie kommt Fremdcode dazu? Über Paketmanager wie npm für JavaScript oder uv für Python.
- Wie erreichen andere das Ergebnis? Über Hosting – darum kümmern wir uns erst später.
Ein Coding-Agent sitzt quer über den ersten drei Ebenen. Er kann Dateien lesen und verändern, Pakete einrichten, Befehle ausführen, Tests starten und Fehlermeldungen auswerten. Er ersetzt die Laufzeitumgebung aber nicht. Wenn dein Agent ein Python-Skript schreibt, braucht dein Rechner weiterhin ein passendes Python, um es auszuführen.
Diese Unterscheidung wirkt zunächst theoretisch. Sie hilft dir aber enorm bei Fehlern: Ist der Code kaputt? Fehlt die richtige Runtime? Wurde ein Paket nicht installiert? Oder läuft die App lokal, ist aber noch gar nicht veröffentlicht? Das sind vier verschiedene Probleme.
Schritt 1: Das Terminal kennenlernen
Das Terminal ist kein Hackerwerkzeug. Es ist eine Texteingabe für deinen Rechner. Statt auf einen Button zu klicken, schreibst du einen Befehl. Auf dem Mac findest du die vorinstallierte Anwendung einfach über Spotlight unter „Terminal“.
Für den Anfang reichen drei Befehle:
pwd
ls
cd ordnername
pwd zeigt, in welchem Ordner du dich befindest. ls listet den Inhalt auf. Mit cd wechselst du in einen anderen Ordner. Mehr musst du nicht auswendig lernen. Moderne Editoren wie VS Code besitzen außerdem ein integriertes Terminal. Dort laufen dieselben Befehle, nur direkt neben deinen Dateien.
Das Terminal tut ziemlich genau, was du ihm sagst – auch wenn der Befehl keine gute Idee war. Deshalb gilt eine einfache Regel: Führe keinen Befehl aus, den du nicht wenigstens grob verstehst.
Sei besonders aufmerksam bei:
sudo, weil der Befehl mit erweiterten Rechten ausgeführt wird;rm, weil Dateien dabei ohne Papierkorb gelöscht werden können;- Installationsbefehlen nach dem Muster
curl ... | bash, weil heruntergeladener Code unmittelbar ausgeführt wird; - Befehlen, die Zugangsdaten enthalten oder Konfigurationsdateien überschreiben.
Wenn dir ein Chatbot einen solchen Befehl gibt, frage zuerst: „Was macht jeder Teil dieses Befehls, welche Dateien verändert er und wie kann ich das Ergebnis rückgängig machen?“
Schritt 2: Homebrew installieren
Homebrew ist ein Paketmanager für macOS. Er installiert Kommandozeilenprogramme und auf Wunsch auch klassische Mac-Apps. Statt eine Website zu suchen, eine Datei herunterzuladen und einen Installer durchzuklicken, kannst du später beispielsweise brew install uv verwenden.
Nutze für die Installation ausschließlich die aktuelle offizielle Homebrew-Anleitung. Kopiere den Installationsbefehl nicht aus einem alten Blogartikel, weil sich Anforderungen und Details ändern können. Der offizielle Installer zeigt vor dem Start, was er tun wird, und verlangt eine Bestätigung.
Wichtig ist der letzte Teil der Installation: Homebrew gibt gegebenenfalls Befehle aus, mit denen es zur Shell-Konfiguration und damit zum Suchpfad deines Terminals hinzugefügt wird. Diese „Next steps“ sind nicht optional. Überspringst du sie, kann nach dem nächsten Terminalstart ein command not found: brew erscheinen, obwohl die Installation erfolgreich war.
Prüfe danach die Installation:
brew --version
Wenn eine Versionsnummer erscheint, ist Homebrew erreichbar.
Schritt 3: Node.js und Python sauber verwalten
Viele moderne Webprojekte verwenden JavaScript oder TypeScript und laufen lokal mit Node.js. Für Skripte, Datenverarbeitung und viele AI-Werkzeuge ist Python verbreitet. Du musst nicht beide Sprachen lernen. Es ist trotzdem praktisch, beide Laufzeitumgebungen verfügbar zu haben, weil Coding-Agenten und Projektvorlagen häufig eine davon voraussetzen.
Installiere nicht einfach irgendeine feste Version und vergiss sie anschließend. Projekte können unterschiedliche Versionen benötigen. Genau dafür gibt es Versionsmanager.
Node.js mit fnm
fnm steht für Fast Node Manager und verwaltet mehrere Node-Versionen auf demselben Rechner. Die offizielle fnm-Dokumentation empfiehlt auf macOS die Installation über Homebrew:
brew install fnm
Damit fnm bei jedem neuen Terminal verfügbar ist und beim Wechsel in einen Projektordner die passende Version auswählen kann, ergänzt du für die auf macOS übliche Zsh-Shell deine ~/.zshrc um:
eval "$(fnm env --use-on-cd --shell zsh)"
Öffne danach ein neues Terminal oder lade die Konfiguration mit source ~/.zshrc neu. Anschließend kannst du die aktuelle LTS-Version von Node installieren:
fnm install --lts
node --version
npm --version
Hier sind zwei Werkzeuge beteiligt: fnm verwaltet Node-Versionen. npm wird mit Node.js installiert und lädt später JavaScript-Pakete für dein Projekt. Das eine ersetzt das andere nicht.
Python mit uv
Beim vorinstallierten System-Python solltest du nicht anfangen, wahllos Pakete global zu installieren. Betriebssystem und Projekte würden dann denselben Topf benutzen. Ein Update für Projekt B kann plötzlich Projekt A beschädigen.
uv nimmt dir einen großen Teil dieses Versions- und Umgebungsmanagements ab. Es kann Python-Versionen installieren, virtuelle Umgebungen erzeugen und Projektabhängigkeiten verwalten. Laut offizieller Installationsanleitung ist uv direkt über Homebrew verfügbar:
brew install uv
uv python install
uv --version
Eine virtuelle Umgebung ist dabei wie ein eigener Werkzeugkoffer pro Projekt. Die dort installierten Python-Pakete bleiben von anderen Projekten getrennt. uv erstellt und verwendet solche Umgebungen bei projektbezogenen Befehlen automatisch beziehungsweise kann sie mit uv venv explizit anlegen.
Du musst dich am ersten Tag nicht tiefer mit Lockfiles, Python-Pins oder Paketauflösung beschäftigen. Merke dir nur: Versionen und Abhängigkeiten gehören zum Projekt. Installiere sie nicht unkontrolliert in eine gemeinsame Systemumgebung.
Schritt 4: Editor und Coding-Agent auswählen
Code besteht im Kern aus Textdateien. Ein Code-Editor stellt diese Dateien übersichtlich dar, markiert Fehler und verbindet Explorer, Suche, Terminal und Versionsverwaltung in einer Oberfläche.
Für den Einstieg sind zwei Wege sinnvoll.
Weg A: Cursor als integrierter Einstieg
Cursor kombiniert einen Code-Editor mit einem integrierten AI-Agenten. Der Agent kann den Projektordner durchsuchen, mehrere Dateien verändern und Befehle im Terminal ausführen. Vorgeschlagene Änderungen lassen sich als Diff prüfen. Dadurch ist der Übergang aus einem normalen Chatfenster relativ klein: Du beschreibst weiterhin in natürlicher Sprache, was du bauen möchtest, der Agent arbeitet aber direkt im Projekt.
Das ist für Einsteiger komfortabel, weil Dateien, Chat und Terminal an einem Ort liegen. Für die AI-Funktionen brauchst du ein Konto; kostenlose Kontingente, Abos und Limits können sich ändern. Prüfe deshalb die aktuellen Bedingungen direkt beim Anbieter, statt dich auf feste Preisangaben zu verlassen.
Weg B: VS Code plus Agent
Visual Studio Code ist ein kostenloser Code-Editor mit integriertem Terminal, Erweiterungen und eingebauter Git-Unterstützung. Dazu kannst du einen separaten Coding-Agenten verwenden, etwa Codex oder Claude Code.
Diese Agenten laufen typischerweise im Terminal innerhalb deines Projektordners. Sie können Dateien lesen und schreiben, Befehle starten und Testergebnisse auswerten. Welcher Agent „der beste“ ist, hängt von deinem Projekt, deinem vorhandenen Abo, den aktuellen Modellen und deinem bevorzugten Arbeitsstil ab. Für den Anfang ist wichtiger, dass du einen Agenten auswählst und seinen Freigabeprozess verstehst.
Starte möglichst mit Bestätigungen für Dateiänderungen und Terminalbefehle. Prüfe Diffs, bevor du Änderungen übernimmst. Vollautomatische Modi sind bequem, geben dem Agenten aber auch mehr Möglichkeiten, auf deinem Rechner Fehler zu machen.
Schritt 5: Einen sauberen Projektordner anlegen
Lege deine Projekte nicht lose auf dem Desktop und möglichst nicht in einen automatisch synchronisierten iCloud- oder Dropbox-Ordner. Entwicklungsprojekte enthalten viele kleine und teilweise jederzeit neu erzeugbare Dateien. Synchronisation kann dabei unnötige Konflikte produzieren.
Ein einfacher Start auf dem Mac:
mkdir -p ~/code/mein-erstes-tool
cd ~/code/mein-erstes-tool
pwd
Öffne genau diesen Ordner in Cursor oder VS Code. Der Projektordner ist die Arbeitsgrenze für deinen Coding-Agenten. Er sollte nicht pauschal Zugriff auf dein gesamtes Benutzerverzeichnis bekommen.
Sobald das Projekt mehr als ein Experiment ist, gehört es in eine Versionsverwaltung wie Git. Git macht Änderungen nachvollziehbar und kann einen funktionierenden Stand wiederherstellen. Ein entferntes Repository, beispielsweise bei GitHub, kann zusätzlich gegen den Verlust des Rechners helfen. Die Einrichtung davon ist ein eigener Schritt – aber warte damit nicht, bis dein Agent bereits hundert Dateien umgebaut hat.
Schritt 6: Das erste Projekt klein halten
Dein erstes lokales Projekt sollte nicht das ERP-System deiner Firma ersetzen. Nimm eine Aufgabe, die du bereits verstanden hast und deren Ergebnis du prüfen kannst: eine CSV filtern, Dateien umbenennen, Notizen strukturieren oder ein kleines persönliches Dashboard bauen.
Ein guter Start-Prompt für Cursor oder einen Coding-Agenten:
Ich möchte ein kleines lokales Tool bauen.
Aufgabe:
Ich wähle eine CSV-Datei aus. Das Tool zeigt nur die Zeilen an,
bei denen die Spalte "Status" den Wert "offen" enthält.
Anschließend kann ich das Ergebnis als neue CSV herunterladen.
Bevor du Code schreibst:
1. Stelle mir alle Fragen, die für einen kleinen ersten Prototyp fehlen.
2. Schlage den einfachsten passenden technischen Aufbau vor.
3. Erkläre mir kurz, warum wir Node.js oder Python benötigen.
4. Plane nur die kleinste funktionierende Version.
Arbeite danach Feature für Feature.
Erkläre jeden Terminalbefehl, bevor du ihn ausführst.
Verändere keine Dateien außerhalb dieses Projektordners.
Der entscheidende Satz ist nicht „Baue mir eine App“, sondern „Stelle mir zuerst Rückfragen“. Ein Agent kann fehlende Anforderungen sonst nur erraten. Wenn Input, Verarbeitung und Output klar sind, wird auch der erste Prototyp deutlich besser.
Der wichtigste Workflow: Fehler vollständig zurückgeben
Fehlermeldungen sind kein Zeichen dafür, dass Vibe Coding nicht funktioniert. Sie sind normale Rückmeldungen des Systems. Schneide nicht nur die letzte rote Zeile aus einem langen Fehler heraus. Gib dem Agenten den vollständigen Befehl, die komplette Ausgabe und den Kontext, was unmittelbar davor passiert ist.
Ein hilfreicher Debug-Prompt:
Ich bin Einsteiger und habe folgenden Befehl ausgeführt:
[BEFEHL]
Danach erschien diese vollständige Ausgabe:
[FEHLERMELDUNG]
Erkläre zuerst in einfachen Worten:
1. Was ist wahrscheinlich die Ursache?
2. Betrifft das meinen Code, die Runtime oder eine Abhängigkeit?
3. Was ist der kleinste sichere Prüfschritt?
Führe noch keine Änderung aus, bevor du den Plan erklärt hast.
So behandelst du die Fehlermeldung als Information statt als Katastrophe. Gleichzeitig zwingst du den Agenten, Diagnose und Änderung voneinander zu trennen.
Was localhost bedeutet
Viele Webprojekte werden mit einem Befehl wie npm run dev gestartet. Danach erscheint eine Adresse wie http://localhost:3000 oder http://localhost:4321.
Dein Rechner spielt in diesem Moment Webserver. localhost bezeichnet deinen eigenen Rechner, die Zahl hinter dem Doppelpunkt ist der Port – vereinfacht die Türnummer des laufenden Programms. Wenn ein Port bereits belegt ist, wählt das Werkzeug häufig einen anderen oder meldet port already in use.
Eine Localhost-Adresse ist keine veröffentlichte Website. Andere Menschen können sie nicht einfach über das Internet öffnen. Manche Entwicklungsserver lassen sich bewusst für das lokale Netzwerk freigeben; das sollte aber eine ausdrückliche Entscheidung sein und ist noch kein sicheres Hosting.
Lokal entwickeln heißt nicht automatisch lokale AI
Deine Dateien und die Programmausführung liegen bei diesem Setup auf deinem Mac. Das Sprachmodell hinter Cursor, Codex oder Claude Code läuft jedoch häufig in der Cloud. Damit der Agent helfen kann, überträgt er Prompts und je nach Arbeitsweise relevanten Projektkontext an den jeweiligen Anbieter.
Prüfe deshalb vor der Arbeit mit Kunden-, Personal- oder Gesundheitsdaten:
- Welche Dateien darf der Agent lesen?
- Welche Daten sendet das Werkzeug an den Modellanbieter?
- Welche Einstellungen und Vertragsbedingungen gelten für deinen Account?
- Liegen API-Schlüssel in Dateien, die der Agent oder ein Git-Repository sehen kann?
- Kannst du das Projekt mit anonymisierten Beispieldaten entwickeln?
„Lokal“ beschreibt hier in erster Linie den Projektordner und die Ausführung. Es ist kein automatisches Datenschutzversprechen.
Was du am Anfang noch nicht brauchst
Ein funktionierendes Vibe-Coding-Setup muss nicht vollständig sein. Docker, Datenbanken, Cloud-Accounts, CI-Pipelines und ein öffentliches Deployment können später sinnvoll werden. Installiere sie erst, wenn dein Projekt ein konkretes Problem damit löst.
Deine minimale Nachmach-Liste lautet:
- Terminal öffnen und
pwd,lsundcdausprobieren. - Homebrew über die offizielle Anleitung installieren.
fnmund die aktuelle Node-LTS-Version einrichten.uvinstallieren und Python darüber verwalten.- Cursor oder VS Code mit einem Coding-Agenten auswählen.
- Einen eigenen Projektordner unter
~/codeanlegen. - Ein kleines Tool in überprüfbaren Schritten bauen.
- Fehlermeldungen vollständig lesen und an den Agenten zurückgeben.
Wenn ein fertiger Dienst für wenige Euro im Monat dein Problem bereits zuverlässig löst, darf das Ergebnis der Übung übrigens auch lauten: nicht selbst bauen. Vibe Coding macht Softwareentwicklung zugänglicher, aber deine Zeit bleibt eine echte Kostenposition.
Häufige Fragen
Muss ich programmieren können, um mit Vibe Coding anzufangen?
Nein. Du solltest aber beschreiben können, welches Problem du lösen willst, und bereit sein, Ergebnisse zu testen. Ein Coding-Agent kann Code erzeugen und erklären. Die Verantwortung dafür, ob das Tool korrekt und sicher arbeitet, bleibt trotzdem bei dir.
Brauche ich Node.js und Python gleichzeitig?
Nicht für jedes Projekt. Eine Web-App kann vollständig mit Node.js auskommen, ein Datenskript nur mit Python. Beide sauber verfügbar zu haben verhindert jedoch viele Unterbrechungen, wenn du Vorlagen oder Werkzeuge ausprobierst. Lass den Agenten begründen, welche Runtime das konkrete Projekt braucht.
Soll ich mit Cursor oder einem Agenten im Terminal starten?
Cursor ist häufig der freundlichere Einstieg, weil du Dateien, Chat, Änderungen und Terminal gemeinsam siehst. VS Code plus Terminal-Agent bietet mehr Auswahl und passt gut, wenn du bereits einen bevorzugten Agenten oder ein passendes Abo hast. Entscheidend ist nicht das populärste Werkzeug, sondern ein Workflow, in dem du Änderungen prüfen kannst.
Funktioniert das Setup auch unter Windows?
Ja, aber Installation und Shell unterscheiden sich. Statt Homebrew kommen beispielsweise WinGet und für manche Entwicklungsworkflows WSL infrage. Dieser Artikel bleibt bewusst bei macOS, damit die Schritte konkret und nachvollziehbar bleiben.
Kann ich die fertige App danach an andere schicken?
Nicht automatisch. Eine Anwendung auf localhost läuft zunächst nur bei dir. Für andere Nutzer brauchst du je nach Projekt Hosting, eine abgesicherte Konfiguration, Datenhaltung und einen Weg für Updates. Das ist der nächste Schritt nach dem lokalen Prototyp.
Fazit
Das beste Vibe-Coding-Setup ist nicht das mit den meisten Tools. Es ist das kleinste Setup, bei dem du verstehst, wo dein Code liegt, welche Runtime ihn ausführt, wie Abhängigkeiten ins Projekt kommen und welche Rechte dein Agent besitzt.
Richte Terminal, Homebrew, fnm, Node.js, uv und einen Editor einmal sauber ein. Starte danach mit einem Projekt, dessen Ergebnis du selbst prüfen kannst. Arbeite in kleinen Schritten, lies Fehlermeldungen vollständig und gib deinem Agenten nicht mehr Zugriff als nötig.
Folge 005 von Kontext.FM liefert dafür den Einstieg aus der Praxis. Der nächste sinnvolle Meilenstein ist nicht sofort die große öffentliche Plattform, sondern ein kleines lokales Tool, das auf deinem Rechner zuverlässig genau eine Aufgabe erledigt.