Vibe-Coding-Regeln: Baue Nebenprojekte von deinem Handy aus mit Claude Code, ohne Code zu lesen

Ein erfahrener Softwareentwickler mit zehn Jahren Berufserfahrung hat einen detaillierten Workflow für das veröffentlicht, was er „Vibe Coding“ nennt – das Erstellen von Nebenprojekten mit Claude Code, komplett vom Handy aus, ohne den generierten Code zu lesen. Der Beitrag skizziert einen strukturierten Prozess, der Planung und Sicherheitschecks priorisiert, um diesen ansatzfreien Ansatz praktikabel zu machen.
Kern-Workflow
- Im Plan-Modus starten. Den Plan lesen und so gut wie möglich verstehen. Bei Unklarheiten nachfragen. Der Autor verwendet den Befehl
4. Tell Claude what to changewiederholt, um Fragen zu stellen wie „Worum geht es in? Was bedeutet das?“ - Hin und her gehen mit dem Agenten. Der Plan-Modus ist die wichtigste Phase – gute und schlechte Entscheidungen haben weitreichende Folgen.
- Pläne in kleine Häppchen aufteilen. Wenn der Plan zu groß ist, um ihn zu verstehen, den Agenten bitten, ihn in kleinere, verdauliche Teile zu zerlegen und diese nacheinander zu bearbeiten.
- Alles in Git committen nach Abschluss jedes Plans. Der Autor schlägt vor, eine Fertigkeit oder Erinnerung zu erstellen, die automatisch committed. Dies ermöglicht ein Zurücksetzen bei Fehlern. Hinweis: Datenbank-Backups sind getrennt.
- Testfälle generieren, die im Plan sichtbar sind. Man muss den Testcode nicht lesen, aber eine Liste wie
es prüft zwei positive ganze Zahlen,es prüft die Übergabe eines negativen Werts,es prüft die Übergabe keines Wertsgibt Sicherheit und verhindert Regressionen.
Erweiterte Sicherheit: Drei Subagenten
Bei komplexen Änderungen drei Subagenten einsetzen, um:
- den Plan kritisch zu überprüfen
- eine Sicherheitsüberprüfung durchzuführen
- ein Test-Audit zu machen
Vorsicht bei der Datenbank
Der Autor empfiehlt, immer ein Datenbank-Backup zu machen (oder geplante Backups zu haben), bevor der Agent an Produktionsdaten geht. Rollbacks verhindern Katastrophen wie versehentliches Löschen.
Auto-Modus
Sobald die Vorarbeit (Planung, Git, Tests, Reviews) erledigt ist, aktiviert der Autor den Auto-Modus und lässt den Agenten laufen. Außerdem gibt er dem Agenten Zugriff auf Chrome DevTools MCP (oder Ähnliches) für End-to-End-Tests nach dem Deployment.
Das Ergebnis: „Du kannst etwas bauen, das niemand nutzt.“
📖 Lies die vollständige Quelle: r/ClaudeAI
👀 Siehe auch

Praktische OpenClaw-Ratschläge: Klein anfangen, häufige Fehler vermeiden
Ein Entwickler teilt Erfahrungen aus dem Aufbau eines persönlichen Gesundheits-Trackers mit OpenClaw und betont einen engen Fokus, deterministische Workflows und die Verwendung eines einzigen LLM. Der Beitrag enthält spezifische Modellbeobachtungen, die ChatGPT und Gemini vergleichen.

Praktischer Rahmen für die Auswahl zwischen Claudes Haiku-, Sonnet- und Opus-Modellen
Ein Entwickler testete Claudes drei Modelle an einer 400-Zeilen-Express.js-Refactoring-Aufgabe und stellte fest, dass der entscheidende Unterschied die Tiefe der Argumentation ist, nicht die Intelligenz. Haiku 4.5 bewältigte einfache Teile, verpasste jedoch die Reihenfolge der Middleware, Sonnet 4.6 erkannte das Reihenfolgeproblem und fügte TypeScript-Typen hinzu, während Opus 4.6 eine Sicherheitslücke in der Auth-Middleware identifizierte.

Claude für Bewegungsgrafiken: Prompt-Muster für animierte HTML-Visuals, die Sie als Video aufnehmen können
Ein r/ClaudeAI-Nutzer teilt eine zuverlässige Prompt-Struktur, um animierte Bewegungsgrafiken und interaktive Diagramme als HTML-Widgets von Claude zu generieren und sie dann mit Playwright + ffmpeg als MP4 aufzunehmen.

Erstellen von API-Endpunkten mit Claude: Praktische Prompt-Engineering-Lektionen aus einem 70+-Endpunkte-Projekt
Ein Entwickler baute über 70 LinkedIn-Automatisierungs-API-Endpunkte mit Claude, der 80 % des Codes schrieb, und entdeckte, dass das Behandeln von Prompts wie Verträgen mit expliziten Einschränkungen besser funktioniert als natürliche Sprachbefehle für handelnde Agenten.