09-01-2026, 06:55 PM
Vibe Coding im Solo-Setup ist ein Solo-Spass. Im Team wird es schnell zur Frage: "Wer hat diesen Prompt geschrieben und warum macht der Code das?" Hier mein Workflow, mit dem zwei Leute (oder mehr) an einem Vibe-Coding-Projekt arbeiten, ohne sich gegenseitig ueber den Haufen zu fahren.
Regel 1: Ein Prompt = ein Commit
Jeder Vibe-Pass wird als eigener Commit mit dem Prompt-Kontext in der Message gespeichert. Format: vibe: <kurzer Prompt>. Nicht "fix bugs", sondern vibe: fetch-Timeout auf 10s gekurzt.
Warum: Wenn drei Wochen spaeter jemand fragt, warum der Timeout 10s hat, steht die Antwort im Commit, nicht in einem Chat-Log.
Regel 2: Der Prompt-Log (ein Markdown im Repo)
Eine Datei PROMPTS.md am Repo-Wurzel, die jede relevante Vibe-Entscheidung aufzeichnet. Nicht alle, nur die, die die Architektur betreffen.
Format:
- [Datum] Prompt: <ein Satz> / Entscheidung: <was daraus wurde> / Status: aktiv|verworfen
Warum: Neue Team-Mitglieder (oder du in 3 Monaten) koennen lesen, WARUM der Code so aussieht, nicht nur WAS er tut.
Regel 3: Die Review-Frage
Bevor ein Vibe-Pass gemerged wird, stellt der Reviwer genau eine Frage: "Was hat dieser Prompt geaendert, und was sollte er NICHT geaendert haben?"
Die zweite Haelfte ist die wichtige. Sie fangt die Kollateralaenderungen, die bei Multi-Datei-Prompts sonst untergehen.
Regel 4: Die Vibe-Branch-Regel
Jeder arbeitet auf einem eigenen vibe/<name>-Branch. Merging geht nur ueber den Hauptzweig, nie direkt von einem Vibe-Branch in einen anderen.
Warum: Zwei Leute, die gleichzeitig viben, erzeugen sonst Merge-Konflikte, die sich nicht mehr loesen lassen.
Der Abschluss: Die 5-Minuten-Sync
Am Ende des Tages: 5 Minuten, jeder zeigt seinen letzten Vibe-Pass. Kein Code-Review im Detail, nur: "Das habe ich geaendert, das sollte es nicht haben."
Das kostet weniger als eine Tasse Kaffee und erspart den 3-Uhr-Nacht-Merge-Konflikt.
Vibe-Coding im Team ist kein Widerspruch. Es ist einfach mehr Disziplin beim Prompten. Was macht ihr, wenn zwei Leute gleichzeitig viben?
Regel 1: Ein Prompt = ein Commit
Jeder Vibe-Pass wird als eigener Commit mit dem Prompt-Kontext in der Message gespeichert. Format: vibe: <kurzer Prompt>. Nicht "fix bugs", sondern vibe: fetch-Timeout auf 10s gekurzt.
Warum: Wenn drei Wochen spaeter jemand fragt, warum der Timeout 10s hat, steht die Antwort im Commit, nicht in einem Chat-Log.
Regel 2: Der Prompt-Log (ein Markdown im Repo)
Eine Datei PROMPTS.md am Repo-Wurzel, die jede relevante Vibe-Entscheidung aufzeichnet. Nicht alle, nur die, die die Architektur betreffen.
Format:
- [Datum] Prompt: <ein Satz> / Entscheidung: <was daraus wurde> / Status: aktiv|verworfen
Warum: Neue Team-Mitglieder (oder du in 3 Monaten) koennen lesen, WARUM der Code so aussieht, nicht nur WAS er tut.
Regel 3: Die Review-Frage
Bevor ein Vibe-Pass gemerged wird, stellt der Reviwer genau eine Frage: "Was hat dieser Prompt geaendert, und was sollte er NICHT geaendert haben?"
Die zweite Haelfte ist die wichtige. Sie fangt die Kollateralaenderungen, die bei Multi-Datei-Prompts sonst untergehen.
Regel 4: Die Vibe-Branch-Regel
Jeder arbeitet auf einem eigenen vibe/<name>-Branch. Merging geht nur ueber den Hauptzweig, nie direkt von einem Vibe-Branch in einen anderen.
Warum: Zwei Leute, die gleichzeitig viben, erzeugen sonst Merge-Konflikte, die sich nicht mehr loesen lassen.
Der Abschluss: Die 5-Minuten-Sync
Am Ende des Tages: 5 Minuten, jeder zeigt seinen letzten Vibe-Pass. Kein Code-Review im Detail, nur: "Das habe ich geaendert, das sollte es nicht haben."
Das kostet weniger als eine Tasse Kaffee und erspart den 3-Uhr-Nacht-Merge-Konflikt.
Vibe-Coding im Team ist kein Widerspruch. Es ist einfach mehr Disziplin beim Prompten. Was macht ihr, wenn zwei Leute gleichzeitig viben?