# Vibe Coding sicher: ein praktischer Workflow

URL: https://agentvera.dev/de/blog/how-to-vibe-code/ · Veröffentlicht: 2026-10-22

Vibe Coding ohne Kontrollverlust: Idee, Spec, kleine Schritte, Tests, Git-Commits, Review und Deploy, dazu Tool-Wahl, funktionierende Prompts und wann Schluss ist.

**Kurz gesagt:**

- Sicheres Vibe Coding legt Struktur um die Prompt-Schleife: eine Idee in einem Absatz mit „Nicht in v1“-Liste, eine kurze SPEC.md mit nummerierten Aufgaben und eine Aufgabe pro Prompt.
- Committe nach jedem funktionierenden Schritt und lass den Agenten Tests ausführen und die Ausgabe zeigen; ein Rollback schlägt es, ihn seinen eigenen Fix erneut reparieren zu lassen.
- Logins, Zahlungen, personenbezogene Daten, Datenbankmigrationen und alles Öffentliche brauchen einen menschlichen Blick auf den Code, bevor echte Nutzer damit in Berührung kommen.

Beim Vibe Coding beschreibst du einem Coding-Agenten in normaler Sprache, was du willst, lässt ihn den Code schreiben und ausführen, prüfst das Ergebnis selbst und steuerst mit kurzen Folgenachrichten weiter. *Sicher* geht das, wenn du dieser Schleife ein wenig Struktur gibst: eine kurze Spec, kleine Schritte, Tests, einen Git-Commit nach jedem funktionierenden Schritt und ein Review, bevor etwas live geht.

Der Begriff stammt aus Andrej Karpathys Post vom Februar 2025 darüber, die KI den Code schreiben zu lassen, während man „vergisst, dass der Code überhaupt existiert“; das Collins Dictionary kürte ihn später zum Wort des Jahres 2025. Definition, Geschichte und Risiken findest du unter [was ist Vibe Coding](/de/glossary/vibe-coding/ "Was ist Vibe Coding?"). Dieser Beitrag handelt vom Wie.

## Der Workflow auf einen Blick

| Schritt | Was du tust | Was du bekommst |
| --- | --- | --- |
| 1. Idee | Schreibe einen Absatz: für wen es ist, was es tut | Einen Umfang, zu dem du Nein sagen kannst |
| 2. Spec | Lass den Agenten daraus einen kurzen Plan machen | Eine Liste kleiner, geordneter Aufgaben |
| 3. Kleine Schritte | Eine Aufgabe pro Prompt | Änderungen, die klein genug zum Prüfen sind |
| 4. Tests | Bitte um Tests für alles, was zählt | Eine Möglichkeit zu wissen, dass es noch läuft |
| 5. Commit | `git commit` nach jedem funktionierenden Schritt | Ein sicherer Punkt zum Zurückgehen |
| 6. Review | Lies den Diff oder lass ein anderes Modell ihn lesen | Weniger Überraschungen später |
| 7. Deploy | Auf einen Host mit Preview-Builds ausliefern | Ein Live-Link zum Teilen |

Aufgeschrieben wirken die Schritte selbstverständlich. Sie zu überspringen macht aus einem schönen Nachmittag ein Wochenende voller „vor einer Stunde ging es noch“.

## Schritt 1: Mit einer kleinen Idee anfangen

Schreibe die Idee in ein paar Sätzen auf, bevor du ein Tool öffnest. Nenne die Nutzer, das eine, was die App können muss, und was in der ersten Version nicht dazugehört.

> Eine Seite, auf der mein Laufverein wöchentliche Distanzen einträgt. Mitglieder melden sich per Magic Link an, fügen einen Lauf hinzu und sehen eine Rangliste für den Monat. Keine Zahlungen, keine mobile App, kein Admin-Bereich in v1.

Der letzte Satz zählt am meisten. Agenten bauen gern Funktionen, nach denen du nicht gefragt hast; eine klare „Nicht in v1“-Liste hält das Projekt klein genug, um es fertigzustellen.

## Schritt 2: In eine kurze Spec verwandeln

Bitte noch nicht um die App. Bitte um einen Plan:

> Lies diese Idee. Schlage einen Stack, eine Ordnerstruktur und eine nummerierte Liste von 6–10 kleinen Aufgaben vor, um v1 zu bauen. Jede Aufgabe soll in einer Session machbar und einzeln testbar sein. Schreibe noch keinen Code.

Lies den Plan und widersprich. Lässt sich der Stack kostenlos hosten? Sind manche Aufgaben in Wahrheit drei? Speichere die endgültige Fassung als `SPEC.md` (oder `PLAN.md`) im Repo, damit jede spätere Session sie lesen kann. Nutzt du mehr als einen Agenten, hilft auch eine kurze CLAUDE.md oder AGENTS.md mit den Befehlen und Regeln; [agentisches Coding](/de/glossary/agentic-coding/ "Agentic Coding") funktioniert am besten, wenn der Agent jedes Mal denselben Kontext hat.

## Schritt 3: In kleinen Schritten bauen

Nimm jetzt Aufgabe 1 und nur Aufgabe 1:

> Erledige Aufgabe 1 aus SPEC.md: Richte das Projekt und eine Startseite ein, die „Hello“ sagt. Starte es und nenne mir die URL.

Öffne es dann, prüfe es und gehe zu Aufgabe 2. Ein guter Rhythmus ist eine Aufgabe, eine Prüfung, ein Commit. Erzeugt ein Schritt mehr als ein paar hundert Zeilen Änderungen, war er wahrscheinlich zu groß; bitte den Agenten, ihn beim nächsten Mal aufzuteilen.

Wenn etwas kaputtgeht, füge den genauen Fehler ein, nicht eine Beschreibung davon. „Es geht nicht“ lässt den Agenten raten; der vollständige Stack Trace meist nicht.

## Schritt 4: Tests für das Wichtige anfordern

Auf einem Nebenprojekt brauchst du keine 100 % Abdeckung. Du brauchst aber Tests für die Teile, die wehtun würden, wenn sie unbemerkt kaputtgingen: die Rechnung der Rangliste, den Anmeldeablauf, alles, was Geld oder Daten berührt.

> Füge Tests für die Monatsrangliste hinzu: Gleichstände, ein Mitglied ohne Läufe, Läufe am letzten Tag des Monats. Führe sie aus und zeig mir die Ausgabe.

Bitte den Agenten, die Tests *auszuführen* und die Ausgabe zu zeigen, nicht nur sie zu schreiben. Wenn du später etwas änderst, wird „führe die Tests aus“ dein einzeiliger Sicherheitscheck.

## Schritt 5: Nach jedem funktionierenden Schritt committen

Git ist der Rückgängig-Knopf des Vibe Codings. Nach jedem Schritt, der funktioniert:

```bash
git add -A
git commit -m "Add monthly leaderboard with tests"
```

Oder sag dem Agenten einfach: „Committe das mit einer kurzen Nachricht.“ Geht eine spätere Änderung schief, zeigt `git diff`, was sich geändert hat, und `git restore .` (oder ein Reset auf den letzten Commit) bringt dich zurück. Das ist besser, als den Agenten zum vierten Mal seinen eigenen Fix reparieren zu lassen, was dazu neigt, einen Patch auf den anderen zu stapeln.

## Schritt 6: Vor dem Livegang prüfen

Vibe Coding funktioniert, weil du beim Bauen nicht jede Zeile liest. Vor dem Deploy muss es jemand tun. Mindestens:

- Überfliege den Diff von allem seit dem letzten Deploy.
- Lass einen zweiten Agenten oder ein zweites Modell ihn auf Bugs und Sicherheitsprobleme prüfen, ohne den Chatverlauf des ersten Agenten. Ein frischer Leser findet, was der Autor nicht sieht.
- Klicke dich selbst auf einem Handy und einem Laptop durch die App.

Der [Leitfaden zum KI-Code-Review](/de/blog/ai-code-review/ "KI-Code-Review") geht tiefer darauf ein, worauf du achten und wie du es einrichten kannst.

## Schritt 7: Deployen

Für die meisten Vibe-Coding-Webprojekte ist ein Host, der aus einem GitHub-Repo baut, der einfache Weg: Vercel, Netlify oder Cloudflare Pages für statische Seiten und Frameworks wie Next.js oder Astro. Pushe auf einen Branch, bekomme einen Preview-Link, prüfe ihn, dann merge zum Deployen. Halte Secrets in den Umgebungseinstellungen des Hosts, nie im Repo.

## Ein Tool wählen

| Typ | Beispiele | Gut für |
| --- | --- | --- |
| Terminal-Agenten | Claude Code, Codex, Gemini CLI | Ganze Projekte auf deinem Rechner, Befehle ausführen, echte Repos |
| Editor-Agenten | Cursor | Nah am Code bleiben, während die KI bearbeitet |
| Browser-App-Builder | Verschiedene gehostete Builder | Eine schnelle Demo mit Hosting inklusive |

Terminal- und Editor-Agenten hinterlassen dir ein normales Code-Repo, das dir gehört; gehostete Builder sind schneller gestartet, behalten den Code aber auf ihrer Plattform. Bist du unsicher, fang mit einem Terminal-Agenten an, etwa [Claude Code](/de/agents/claude-code/ "Claude Code"), und nutze ihn für ein ganzes kleines Projekt, bevor du andere ausprobierst.

## Prompts, die funktionieren

Gute Vibe-Coding-Prompts haben eine gemeinsame Form: ein Ziel, die Randbedingungen und wie du es prüfst.

| Statt | Versuche |
| --- | --- |
| „Bau mir einen Habit Tracker“ | „Erledige Aufgabe 3 aus SPEC.md: das Formular zum Hinzufügen einer Gewohnheit. Prüfe, dass der Name nicht leer ist. Führe am Ende die Tests aus.“ |
| „Es ist kaputt, repariere es“ | „Ein Klick auf Save zeigt diesen Fehler: (einfügen). Finde die Ursache, bevor du Code änderst, und erkläre den Fix dann in zwei Sätzen.“ |
| „Mach es schöner“ | „Übernimm Abstände und Schriftgrößen dieses Screenshots. Ändere das Layout auf dem Handy nicht.“ |
| „Füge Login hinzu“ | „Füge Magic-Link-Login mit der Auth-Bibliothek aus SPEC.md hinzu. Speichere keine Passwörter. Liste jede Datei auf, die du geändert hast.“ |

Drei Formulierungen lohnen sich zur Wiederverwendung:

- **„Schreibe noch keinen Code.“** Für Pläne und Untersuchungen.
- **„Führe es aus und zeig mir die Ausgabe.“** Damit du Belege siehst, keine Behauptungen.
- **„Liste die Dateien auf, die du geändert hast.“** Damit der Diff keine Überraschungen hat.

## Wann du aufhören solltest zu vibe-coden

Vibe Coding ist großartig für Prototypen, interne Tools und private Projekte. Werde langsamer und lies den Code selbst, oder hol jemanden, der es kann, wenn die Arbeit Folgendes berührt:

- **Logins und Berechtigungen.** Eine vergessene Prüfung legt die Daten aller offen.
- **Zahlungen.** Webhooks, Erstattungen und Randfälle brauchen echte Tests.
- **Personenbezogene Daten.** Das Datenschutzrecht interessiert sich nicht dafür, wer den Code geschrieben hat.
- **Datenbankmigrationen.** Ein `DROP` oder ein `UPDATE` ohne `WHERE` ist in der Produktion schwer rückgängig zu machen.
- **Alles Öffentliche mit echten Nutzern.** Rate Limits, Eingabevalidierung, Umgang mit Secrets.

Ein weiteres Signal: Hast du den Agenten dreimal gebeten, denselben Bug zu beheben, und er kommt immer wieder, hör auf. Rolle auf den letzten guten Commit zurück, beschreibe das Problem von Grund auf neu oder lies diesen Teil des Codes selbst.

## Baue etwas

Jeder dieser Leitfäden folgt demselben Workflow an einem konkreten Projekt:

- [Eine Website mit KI bauen](/de/blog/build-website-with-ai/ "Eine Website mit KI bauen")
- [Ein SaaS-MVP mit KI bauen](/de/blog/build-saas-mvp-with-ai/ "Ein SaaS-MVP mit KI bauen")
- [Eine Mobile-App mit KI bauen](/de/blog/build-mobile-app-with-ai/ "Eine Mobile-App mit KI bauen")
- [Eine Chrome-Extension mit KI bauen](/de/blog/build-chrome-extension-with-ai/ "Eine Chrome-Extension mit KI bauen")
- [Einen Telegram-Bot mit KI bauen](/de/blog/build-telegram-bot-with-ai/ "Einen Telegram-Bot mit KI bauen")
- [Eine Automatisierung oder einen Scraper mit KI bauen](/de/blog/build-automation-scraper-with-ai/ "Eine Automatisierung oder einen Scraper mit KI bauen")
- [Ein Daten-Dashboard mit KI bauen](/de/blog/build-data-dashboard-with-ai/ "Ein Daten-Dashboard mit KI bauen")
- [Einen E-Commerce-Shop mit KI bauen](/de/blog/build-ecommerce-store-with-ai/ "Einen E-Commerce-Shop mit KI bauen")
- [Ein Spiel mit KI machen](/de/blog/make-a-game-with-ai/ "Ein Spiel mit KI machen")

## Mit AgentVera umsetzen

Alles oben funktioniert mit einem Terminal und Git. [AgentVera](/de/download/ "AgentVera herunterladen") führt deine Coding-Agenten (Claude Code, Codex, Gemini CLI und andere, mit deinen eigenen Logins) in echten Terminals nebeneinander aus und spannt ein paar Sicherheitsnetze um dieselbe Schleife:

- **Rückgängig pro Turn.** [Checkpoints](/de/features/checkpoints-and-replay/ "Checkpoints und Replay") sichern den Arbeitsordner zu Beginn jedes Turns, sodass du einen Turn über das Menü des Bereichs rückgängig machen kannst, und auch das Rückgängigmachen. Das ist ein schnellerer Schritt zurück als ein Git-Reset, kein Ersatz für Commits.
- **Automatisches Review.** Ist das [Code-Review](/de/features/code-review/ "Code-Review") in den Projekteinstellungen eingeschaltet, liest ein von dir gewähltes Claude-Modell die Änderungen, wenn ein Turn endet, und meldet Befunde mit Schweregrad und file:line-Links; du kannst sie an den Agenten zurückschicken.
- **Prüfung gegen deine Anforderung.** [AgentVera Verify](/de/features/verify/ "AgentVera Verify") (Pro und Team) zieht die Akzeptanzkriterien aus deiner Nachricht, und wenn der Turn endet, führt ein separater Verifier Tests aus und markiert jedes Kriterium mit Beleg als bestanden oder fehlgeschlagen.
- **Migrationsprüfungen.** [DB Guard](/de/features/db-guard/ "DB Guard") durchsucht neue Migrationen am Ende eines Turns nach riskanten Anweisungen wie `DROP` oder `UPDATE` ohne `WHERE`.
- **Previews.** [Preview-Umgebungen](/de/features/preview-environments/ "Preview-Umgebungen") geben jedem Branch eine eigene lokale Adresse und können Screenshots für Handy, Tablet und Desktop aufnehmen.
- **Ein Ort zum Freigeben.** Die Review-Inbox sammelt die fertige Arbeit jedes Agenten, sodass du sie freigeben oder mit einer Notiz zurückschicken kannst.

## Checkliste

- [ ] Die Idee passt in einen Absatz, mit einer „Nicht in v1“-Liste.
- [ ] Eine kurze SPEC.md mit nummerierten Aufgaben liegt im Repo.
- [ ] Eine Aufgabe pro Prompt; jede geprüft, bevor die nächste kommt.
- [ ] Für die Teile, die wehtun würden, wenn sie kaputtgingen, gibt es Tests.
- [ ] Ein Commit nach jedem funktionierenden Schritt.
- [ ] Der Diff wurde vor dem Deploy geprüft, am besten von einem frischen Modell und einem Menschen.
- [ ] Secrets liegen in Umgebungsvariablen, nicht im Repo.
- [ ] Logins, Zahlungen, personenbezogene Daten und Migrationen wurden sorgfältig von einem Menschen gelesen.

## Fazit

Vibe Coding ist heute ein echter Weg, Software zu bauen, nicht nur ein Witz darüber. Der Unterschied zwischen einem Prototyp, den du behältst, und einem, den du wegwirfst, ist selten das Modell; es ist, ob du in kleinen Schritten gearbeitet, oft committet, getestet hast, was zählte, und vor dem Ausliefern geprüft hast. Heb dir die Vibes fürs Bauen auf und die Disziplin für die Ränder.

## Häufige Fragen

**Muss ich programmieren können, um Vibe Coding zu betreiben?** Für ein kleines privates Projekt nicht. Du musst aber ein paar Befehle ausführen, dem Agenten eine Fehlermeldung vorlesen und das Ergebnis selbst testen können. Je wichtiger das Projekt, desto mehr brauchst du jemanden, der den Code lesen kann.

**Was ist das beste Tool für Vibe Coding?** Es gibt kein einzelnes bestes. Terminal-Agenten wie Claude Code, Codex oder Gemini CLI geben dir ein echtes Projekt auf deinem Rechner; Editor-Agenten wie Cursor halten dich näher am Code. Wähle eines, lerne seine Eigenheiten und nimm ein zweites erst dazu, wenn du eine zweite Meinung brauchst.

**Wie verhindere ich, dass die KI funktionierenden Code kaputt macht?** Arbeite in kleinen Schritten, committe nach jedem funktionierenden Schritt und lass bei allem Wichtigen Tests schreiben. Geht eine Änderung schief, rolle auf den letzten Commit zurück, statt den Agenten dreimal hintereinander seinen Fix reparieren zu lassen.

**Ist Vibe-Coding-Software sicher genug für die Produktion?** Erst, nachdem jemand sie geprüft hat. Logins, Zahlungen, personenbezogene Daten, Datenbankmigrationen und alles, was im Internet erreichbar ist, brauchen einen menschlichen Blick auf den Code, echte Tests und einen einfachen Sicherheitscheck, bevor echte Nutzer damit in Berührung kommen.

**Wie lang sollte ein Vibe-Coding-Prompt sein?** Lang genug, um ein Ziel, die Randbedingungen und die Prüfung zu nennen, meist drei bis acht Zeilen. Ein einziger riesiger Prompt für die ganze App erzeugt tendenziell viel Code, der schwer zu prüfen ist.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/