01 / 20
oder Space zum Navigieren
Schulungsmodul • Aufbereitung für den Berater

Vibe Coding
für Shop-Betreiber

7 Module — vom Mindset-Shift bis zur sicheren Anwendung

AI Dynamics Schulung 2026

Übersicht — 7 Module

1
Was ist Vibe Coding?
Der Mindset-Shift — warum Sie nicht programmieren müssen
2
Denken vor dem Machen
Die vier Denkebenen & das PRD
3
Frameworks
Die KI in die richtige Richtung lenken
4
Versionskontrolle
Nie wieder Arbeit verlieren — Git erklärt
5
Debugging
Wenn etwas nicht funktioniert — systematisch Fehler finden
6
Kontext ist König
Die KI richtig füttern
7
Rules-Dateien
Die KI an die Leine nehmen — Sicherheit einbauen
Modul 1

Was ist Vibe Coding?

Vibe Coding bedeutet: Sie beschreiben in normaler Sprache, was Sie brauchen — und eine KI schreibt den Code dafür. Sie müssen keine Programmiersprache lernen. Aber: Je genauer und klarer Sie beschreiben, was Sie wollen, desto besser wird das Ergebnis.

Sie müssen nicht programmieren können — aber klar kommunizieren, was Sie wollen.

Kernbegriffe

Vibe Coding

Sie beschreiben in normaler Sprache, was Sie brauchen — die KI schreibt den Code dafür.

LLM

Die KI „hinter dem Vorhang“ — wie ChatGPT. Versteht Sprache und erzeugt daraus funktionierenden Code.

Prompt

Ihre Anweisung an die KI — wie eine Bestellung im Restaurant. Je genauer, desto besser das Ergebnis.

Typische Falle: „Das ist nichts für mich, ich kann nicht programmieren.“ — Genau darum geht es bei Vibe Coding!

Vibe Coding — So starten Sie

1

Überlegen Sie sich ein kleines Werkzeug für Ihr Tagesgeschäft, z.B. „Automatisch prüfen, ob meine Produktseiten gute SEO-Beschreibungen haben“

2

Beschreiben Sie dieses Werkzeug in 3–5 Sätzen in normaler Sprache

3

Geben Sie die Beschreibung an ein KI-Tool wie ChatGPT oder Replit

4

Schauen Sie, was die KI macht — und verfeinern Sie Schritt für Schritt

Niemals echte Kundendaten, Passwörter oder API-Keys in öffentliche KI-Tools eingeben!

Modul 2

Denken vor dem Machen

Je präziser Ihre Anweisung an die KI, desto besser das Ergebnis. Das Werkzeug dafür heißt PRD — ein Product Requirements Document. Es ist Ihre strukturierte „Bestellung“ an die KI: Was soll gebaut werden, für wen, und was ist das Minimum?

PRD

Product Requirements Document — eine strukturierte „Wunschliste“ für Ihr Tool. Wie ein detaillierter Bestellzettel.

MVP

Minimal Viable Product — die abgespeckte Version. Wie ein Pop-up-Store: Erst testen, dann ausbauen.

Die vier Denkebenen & PRD erstellen

1️⃣
Was will ich bauen?
Ziel und Zweck des Tools definieren
2️⃣
Wie soll es funktionieren?
Ablauf und Interaktion beschreiben
3️⃣
Welche Regeln gibt es?
Randbedingungen und Einschränkungen
4️⃣
Wie wird es richtig gut?
Optimierung für die Zielgruppe

Sie müssen das PRD nicht allein erstellen — es gibt Prompts, die mit Ihnen zusammenarbeiten und die richtigen Fragen stellen.

KI bitten: „Hilf mir, ein PRD zu erstellen. Stell mir die richtigen Fragen.“

PRD in ChatGPT erstellen, dann als Prompt an Replit/Windsurf übergeben

„Nice-to-haves“ entfernen — nur Kernfunktionen!

Signifikant viel Zeit in die PRD-Phase investieren! Es ist immer einfacher, eine klare Vision zu haben, als etwas halbfertig zu reparieren.

Der magische Trick: Die KI planen lassen

Sagen Sie der KI NICHT „mach das so“ — sondern fragen Sie: „Ich möchte eine Anwendung bauen, die X kann. Was brauche ich dafür alles? Kannst du mir einen Plan schreiben?“

Planungsmodi der Tools

💻
Claude Code
Planungsmodus via Shift + Tab (Toggle). Drei Modi: Plan, Accept-All, normaler Agent.
🖱
Cursor & Codex
Eigene Planungsmodi — gleiches Prinzip, andere Bedienung.

Kontextdateien

📄
CLAUDE.md / AGENTS.md
Dateien, die sich die KI selbst schreibt, um zu verstehen, was sie tun soll. Der Kern dessen, was diese Tools können.

Die KI erstellt sich ihren eigenen Kontext — je besser Ihr initialer Plan, desto besser diese Dateien.

MVP-Mindset: Klein starten, dann iterieren

Whatever it is that you’re creating, always think about the minimal viable product — what are the minimum amount of features for it to function. After you get the thing to work, then iterate.
1

Immer mit dem Minimum an Features starten, das die App funktionsfähig macht

2

Erst testen und validieren, dann iterativ Features hinzufügen

3

Features im PRD bewusst priorisieren — Disziplin ist entscheidend

Wenn Sie mit allen Features gleichzeitig starten, werden Sie sich die Haare raufen — Sie können nicht herausfinden, was schiefgeht.

Beispiel: Erst SEO-Check für 10 Produktseiten bauen. Funktioniert? Dann auf den ganzen Shop ausweiten.

Modul 3

Frameworks — Die KI lenken

Wenn Sie einem Handwerker sagen „Mach irgendwas Schönes“, bekommen Sie vielleicht Fliesen statt Parkett. Aber wenn Sie sagen: „Eichenparkett, Click-System, matt versiegelt“ — dann weiß er sofort, was zu tun ist. Frameworks sind die Marken und Materialien der Software-Welt.

Framework

Fertiges Baukasten-System — wie IKEA-Module statt Schreinerei

Frontend

Was der Nutzer sieht — die Schaufensterauslage

Backend

Was im Hintergrund passiert — Lager und Buchhaltung

React, Tailwind CSS

Populäre Frameworks — nennen Sie sie im Prompt!

Frameworks in der Praxis

1

Fragen Sie die KI: „Welche Frameworks eignen sich am besten für [Ihr Vorhaben]?“

2

Empfehlung in den Prompt / das PRD einfügen

3

Grundstruktur kennenlernen: Frontend vs. Backend, welche Datei macht was

4

„Explain“-Funktion im Tool nutzen, um während des Bauens zu lernen

Sie müssen nicht jede Codezeile verstehen — aber die Grundstruktur kennen.

Immer nachfragen: „Ist das die aktuellste, sichere Version?“

Modul 4

Versionskontrolle — Die Zeitmaschine

Sie arbeiten stundenlang an einer Tabelle, vergessen zu speichern — Rechner stürzt ab. Alles weg. Git ist wie eine Zeitmaschine: Bei jeder Änderung einen Schnappschuss machen und jederzeit zurückspulen.
💻
Lokal ändern
💾
Commit (Speicherpunkt)
☁️
Push (Cloud-Backup)
Rollback (Zeitmaschine)

Git in der Praxis

1

Sagen Sie der KI: „Initialisiere Git für Versionskontrolle in diesem Projekt“

2

Nach jeder Änderung: „Committe mit der Nachricht: [Beschreibung]“

3

Regelmäßig: „Pushe alles auf GitHub“ — Sicherheitskopie in der Cloud

4

Wenn etwas kaputt geht: „Rolle den letzten Commit zurück“

Faustregel: Nach jedem getesteten Feature → Commit!

NIEMALS API-Keys oder Passwörter in Code-Dateien auf GitHub pushen!

Modul 5

Debugging — Fehler systematisch finden

Ihr Kassensystem spinnt. Sie rufen den Techniker an: „Geht nicht.“ Der Techniker fragt: „Was genau? Welche Fehlermeldung? Seit wann? Was haben Sie zuletzt geändert?“ — Je mehr Sie sagen können, desto schneller ist das Problem gelöst.

Debugging

Fehlersuche wie Detektivarbeit: Wo liegt das Problem?

Fehlermeldung

Der „Hilferuf“ des Programms — einfach kopieren und weiterleiten

Iterativ

Schritt für Schritt testen — ein Problem auf einmal

Debugging — So gehen Sie vor

1

Nach jeder Änderung sofort testen

2

Fehlermeldung komplett kopieren + Screenshot machen

3

An die KI: „Folgender Fehler: [Meldung]. Hier ein Screenshot.“

4

Erster Fix klappt nicht? → „Funktioniert noch nicht“ + beschreiben, was anders ist

5

Nach 3–4 Versuchen: Problem eingrenzen — „Ich glaube, das Problem liegt in…“

Immer nur EIN Problem auf einmal lösen — nicht mehrere gleichzeitig!

Fehlermeldungen können sensible Daten enthalten — vor dem Kopieren prüfen!

Modul 6

Kontext ist König

Mehr Kontext = bessere Ergebnisse. Faustregel: So viel Information und Detail wie möglich an die KI liefern. Statt nur „das geht nicht“ — die vollständige Fehlermeldung kopieren und einen Screenshot des fehlerhaften Verhaltens mitliefern.

Detaillierter Prompt / PRD als Ausgangsbasis

Mockups / Bilder davon, wie das Ergebnis aussehen soll

Beispieldaten oder Referenz-Designs mitliefern

Details über App, Umgebung, persönliche Präferenzen

Vollständige Fehlermeldungen kopieren (nicht nur „es geht nicht“)

Screenshots des fehlerhaften Verhaltens beifügen

Beispieldaten immer anonymisieren! Keine echten Kundennamen, E-Mails oder Bestellnummern.

Modul 7

Rules-Dateien — Die KI an die Leine

Eine super motivierte Aushilfe, die manchmal übers Ziel hinausschießt — räumt das ganze Lager um statt nur ein Regal. Die Rules-Datei ist wie ein Leitfaden am Arbeitsplatz: „Immer erst fragen. Schlüssel im Tresor. Kundendaten nie auf Zettel.“

Rules-Datei

Anweisungsliste, die der KI bei jedem Schritt vorschreibt, was sie tun und lassen soll.

API-Key

Digitaler Zugangsschlüssel — muss geheim bleiben!

Rate Limiting

Begrenzung der Aufrufe pro Minute — wie ein Kreditkarten-Limit

🔒

API-Keys nur als Umgebungsvariablen

🔒

HTTPS erzwingen

🔒

Kundendaten verschlüsseln

🔒

Keine sensiblen Daten in Logs

🔒

CAPTCHA auf allen Formularen

Das Gelernte im Shop einsetzen

Konzept Shop-Anwendung Nutzen
PRD erstellen Retouren-Status-Checker spezifizieren 3–5 Std. gespart
MVP-Mindset Erst SEO-Check für 10 Seiten, dann ganzer Shop 1 Std. → fertiges Tool
Vibe Coding Dashboard: CSV → Top-10-Produkte der Woche 2–3 Std./Woche gespart
Frameworks „Nutze Tailwind CSS + Chart.js“ im Prompt Profi-Ergebnis beim 1. Versuch
Git Shop-Template: vor jeder Änderung committen Null Risiko beim Anpassen
Debugging Checkout defekt: Screenshot + Meldung → KI Minuten statt Stunden

Die wichtigsten Takeaways

💬
Klar kommunizieren
Je präziser der Prompt, desto besser das Ergebnis
📝
PRD schreiben
Immer erst denken, dann bauen — die 4 Denkebenen nutzen
🔧
Frameworks nennen
Geben Sie der KI „Materialien“ vor
Git nutzen
Nach jedem Feature committen — die Zeitmaschine
🔎
Systematisch debuggen
Fehlermeldung + Screenshot — ein Problem auf einmal
📚
Kontext liefern
Mockups, Beispieldaten, Umgebung — je mehr, desto besser
📜
Rules-Dateien pflegen
Sicherheit und Konsistenz von Anfang an
🔒
Sicherheit immer zuerst
Keine echten Daten in KI-Tools — niemals!

Fragen &
Diskussion

Vielen Dank für Ihre Aufmerksamkeit!

Welches Modul wollen Sie als Erstes mit Ihrem Kunden durchgehen?
Wo sehen Sie das größte Potenzial?