Vibe Coding im Marketing: Interne Tools ohne Entwicklerteam

Sie sind hier, um Vibe Coding im Marketing zu lernen. Bevor Sie anfangen, sollten Sie wissen, worauf Sie sich einlassen. Ich bin Marketer, kein Entwickler, und ich habe vier funktionierende interne Tools ohne Entwicklerteam gebaut. So habe ich es gemacht, das hat es gekostet, und hier höre ich auf.

Vibe Coding heisst, Software in einfacher Sprache zu beschreiben und eine KI den Code schreiben zu lassen. Sie steuern. Das Modell tippt. Sie öffnen nie ein Lehrbuch. Der Begriff ist gerade heiss, und wie jeder heisse Begriff wird er überdehnt, um Kurse zu verkaufen.

Das meiste, was Sie darüber lesen, kommt aus zwei Lagern. Entwickler, die bereits programmieren können und erklären, warum das Neue gefährlich ist. Oder Anbieter, die erklären, warum das Neue Magie ist. Ich bin in keinem der beiden Lager. Ich bin ein Praktiker, der Tools baut, weil das Warten auf ein Dev-Ticket aus kleinen Aufgaben Quartalsprojekte macht.

Das Wichtigste vorab

• Sie müssen kein Entwickler sein. Sie brauchen Geschmack, einen Stack, den Sie erklären können, und Regeln, die Sie nicht brechen.
• Der Begriff übertreibt die Einfachheit. Vibe Coding ist real, aber die eigentliche Arbeit ist, KI-Output so hart zu prüfen, dass Sie ihm in Produktion vertrauen können.
• Ich habe vier funktionierende Tools ohne Entwicklerteam gebaut: ein Task-Dashboard, ein Lead-Attribution-Kit, einen Content-Ingestion-Service und ein 900-seitiges Verzeichnis.
• Die echten Kosten sind nicht das Abo. Es ist Ihre Aufmerksamkeit beim Prüfen, und die Stunden, die Sie verbrennen, wenn Sie das Prüfen überspringen.
• Drei Regeln sind nicht optional: niemals Zugangsdaten im Klartext speichern, niemals Kundendaten an ein Modell geben, immer prüfen, bevor Sie deployen.

Vibe Coding für Marketer ist nicht, was Sie denken

Die Anbieter erzählen Ihnen, Vibe Coding bedeute, die nächste grosse App zu bauen. Sie zeigen einen Marketer, der an einem Wochenende ein SaaS-Produkt launcht. Das ist die Fantasie-Version, und sie zielt auf Ihre Kreditkarte.

Für einen Marketer bedeutet Vibe Coding etwas Kleineres und Nützlicheres. Es bedeutet, die internen Tools zu bauen, für die Ihnen niemand Priorität einräumt. Ein Dashboard, das Aufgaben über fünf Projekte hinweg trackt. Ein Skript, das Leads der richtigen Quelle zuordnet. Ein Service, der RSS-Feeds in saubere Artikel verwandelt. Ein Verzeichnis, das neunhundert Aussteller auflistet.

Sie bauen kein Produkt zum Verkaufen. Sie bauen die Maschine, die Sie brauchen, um Ihren Job zu machen. Diese Unterscheidung verändert alles, denn interne Tools haben zwei Eigenschaften, die viel verzeihen. Erstens: Der Nutzer sind Sie, also ist der Einsatz niedriger und die Feedback-Schleife sofort da. Zweitens: Niemand auditiert Ihren Code. Der einzige Richter ist, ob das Tool funktioniert, wenn Sie es brauchen.

Hier ist der Teil, den der Hype übersieht. Der Flaschenhals beim Vibe Coding war nie das Schreiben des Codes. Es war immer, zu wissen, was Sie wollen, so präzise, dass eine Maschine es produzieren kann. Eine vage Anfrage produziert vagen Code. Eine präzise Anfrage produziert ein funktionierendes Tool. Die Fähigkeit, die Sie lernen, ist zu spezifizieren, nicht zu tippen.

Das ist die echte Lücke zwischen der Fantasie und den Belegen. Kurse verkaufen das Tippen. Die Arbeit ist das Spezifizieren. Und das Spezifizieren ist eine Marketing-Fähigkeit, die Sie schon haben, weil es derselbe Muskel ist, den Sie nutzen, um einen Freelancer zu briefen oder ein Kreativ-Briefing zu schreiben.

Vibe Coding im Marketing: mein exakter Ablauf, Schritt für Schritt

Das ist der Prozess, dem ich folge, verfeinert über die Tools im nächsten Abschnitt. Er funktioniert, egal ob Ihr Modell Claude, ChatGPT oder was auch immer als Nächstes kommt ist. Das Modell wechselt. Die Schleife nicht.

Schritt 1. Starten Sie beim Schmerz, nicht beim Tool. Schreiben Sie die Aufgabe auf, die Ihre Zeit frisst. Nicht die Software, die Sie sich vorstellen. Wenn die Aufgabe «Ich verliere zwanzig Minuten pro Woche, weil ich manuell fünf Dashboards prüfe» ist, ist das das Briefing. Das Tool ist die Antwort, nicht die Frage. Bauen Sie vom Schmerz aus, und Sie werden das Ergebnis nutzen. Bauen Sie von einer coolen Idee aus, und Sie lassen es in einer Woche fallen.

Schritt 2. Schreiben Sie die Spec in einem Absatz. Beschreiben Sie, was das Tool tut, was es aufnimmt, was es zurückgibt und was es niemals tun darf. Ein Absatz. Wenn Sie es nicht in einen Absatz bringen, sind Sie nicht bereit zu bauen. Der Absatz ist der Vertrag. Das Modell folgt ihm, und Sie messen das Ergebnis daran. Sobald Sie mehr als ein Tool bauen, halten Sie die festen Regeln in einer kurzen Anweisungsdatei fest. Was hineingehört, behandeln die CLAUDE.md Best Practices nach Claude 5.

Schritt 3. Schneiden Sie es auf den kleinsten funktionierenden Slice. Nehmen Sie den Absatz und reduzieren Sie ihn auf eine Sache, die das Tool zuerst tun muss. Bauen Sie genau das. Der Slice für mein Task-Dashboard war eine einzige Seite, die offene Aufgaben auflistet. Nicht fünf Views, nicht Alert-Regeln. Eine Liste. Ein kleiner Slice, der heute funktioniert, schlägt ein grosses Design, das nie funktioniert.

Schritt 4. Lassen Sie das Modell es Datei für Datei bauen. Fragen Sie nach kleinen, prüfbaren Stücken. Eine einzelne Datei oder eine einzelne Funktion. Wenn Sie alles auf einmal verlangen, baut das Modell alles auf einmal, und Sie bekommen ein Chaos, das Sie nicht auditieren können. Kleine Stücke halten das Prüfen ehrlich, und das Prüfen ist der ganze Job.

Schritt 5. Führen Sie es aus und lesen Sie die Fehler. Hier hören die meisten auf, und hier passiert das Lernen. Die Fehlermeldung ist das Modell, das Ihnen eine Frage stellt. Lesen Sie sie, fügen Sie sie wieder ein und lassen Sie sich vom Modell in einfacher Sprache erklären. Wiederhole, bis es läuft. Jede Schleife lehrt Sie, was das Modell tut, und das ist die Fähigkeit, für die Sie hier sind.

Schritt 6. Fügen Sie Tests für die Teile hinzu, die zählen. Für ein Wegwerf-Skript brauchen Sie keine Test-Suite. Sie brauchen eine für alles, was echte Daten berührt oder ohne Sie läuft. Mein Task-Dashboard ging mit 34 Tests live, und sie fingen 3 echte Bugs, bevor sie Produktion erreichten. Die Tests sind die Linie zwischen einem Tool und einer Haftung.

Schritt 7. Prüfen Sie, bevor Sie deployen. Öffnen Sie die Datei, die das Modell geschrieben hat. Lesen Sie sie. Nicht Zeile für Zeile wie ein Entwickler, aber genug, um eine Frage zu beantworten: Verstehe ich, was das tut? Wenn die Antwort nein ist, deployen Sie nicht. Sie wetten. Das Modell ist ein schneller Tipper ohne Urteilsvermögen. Das Urteil ist Ihres, bei jeder Datei.

Vier interne Marketing-Tools, die ich ohne Entwicklerteam gebaut habe

Die hier sind real. Keine Demos, keine Nebenexperimente, die nach einem Wochenende gestorben sind. Tools, die ich nutze, und die Belege hinter jedem.

The Nexus. Ein Python-Task-Dashboard mit null Abhängigkeiten. Fünf Views, sieben Alert-Regeln, ein SSE-Watcher für Live-Updates und atomare Dateischreibvorgänge, damit ein Crash nie den Zustand korrumpiert. Vierunddreissig Tests. Drei echte Bugs gefangen, bevor sie live gingen. Das ist das Tool, das mein wöchentliches Zwanzig-Minuten-Dashboard-Ritual beendet hat, und es begann als die einzelne Liste aus Schritt 3.

Ein Lead-Attribution-Kit. Vierundvierzig Attributions-Vektoren, die tracken, woher ein Lead über Kanäle hinweg kommt. Es läuft in Node und PHP, beide grün, also passt es in ein Projekt, egal worauf dieses Projekt gebaut ist. Attribution ist die Art langweiliger Klempnerarbeit, die nie ein Dev-Ticket bekommt, weil sie unsichtbar ist, bis die Zahlen falsch sind. Jetzt ist es meins, und die Zahlen stimmen.

Ein Corpus-RSS-zu-Artikeln-Ingestion-Service. Er zieht Feeds, säubert den Inhalt und verwandelt sie in nutzbare Artikel. Hunderteinundsechzig Tests, alle grün. Das ist der, der mir den Wert des Test-Schritts beigebracht hat, weil die erste Version bei fehlerhaften Feeds stillschweigend scheiterte und ich es erst eine Woche später bemerkte. Die grüne Suite ist keine Angeberei. Sie ist die Narbe aus dieser Woche, verwandelt in eine Leitplanke.

Ein 900-seitiges KI-Messe-Verzeichnis auf Astro. Eine statische Site, aus Daten generiert, die neunhundert Aussteller über Events hinweg auflistet. Astro hat die Schwerarbeit bei der Performance gemacht. Das Modell hat die Datenformung gemacht. Das Ergebnis rankt, lädt schnell und kostet fast nichts im Hosting. Neunhundert Seiten von Hand hätten einen Monat gedauert. Mit Vibe Coding waren es ein paar Abende Prüfen.

Das Muster über alle vier ist dasselbe. Kleiner Scope. Ein Stack, den ich erklären kann. Tests auf den Teilen, die echte Daten berühren. Und ein hartes Prüfen, bevor irgendetwas live geht. Keiner davon brauchte einen Tag formaler Ausbildung. Alle brauchten diesen Prüf-Schritt, jedes Mal.

Der Stack, der wirklich funktioniert (und was er wirklich kostet)

Leute fragen, welchen Stack man nutzen soll. Hier ist meiner, und er ist mit Absicht langweilig. Langweilig ist ein Feature, denn langweilig ist, was ein Modell sauber schreibt und was Sie später einem Entwickler erklären können.

Für Skripte und interne Tools: Python. Es liest sich wie Englisch, hat für alles eine Bibliothek, und ein Modell schreibt es sauber. The Nexus ist Python mit null Abhängigkeiten, was heisst, es gibt nichts, das kaputtgeht, wenn Sie es verschieben. Diese Wahl war Absicht: Je weniger Abhängigkeiten ein Tool hat, desto weniger müssen Sie später reparieren.

Für alles, was in einer Website lebt, funktionieren Node und PHP beide, deshalb wird das Attribution-Kit in beiden ausgeliefert. Passen Sie das Tool dem an, worauf die Site bereits läuft. Führen Sie keine neue Laufzeitumgebung für ein Tool ein, das auf der laufen könnte, die Sie schon haben.

Für statische Sites und Verzeichnisse: Astro. Es ist schnell, einfach, und das Modell kennt es gut. Das Messe-Verzeichnis ist Astro, und neunhundert Seiten rendern in einem Bruchteil einer Sekunde.

Jetzt die Kosten, denn die Preisseite verrät Ihnen nie die echten. Das Abo ist die kleine Zeile. Mein eigenes KI-Abo liegt bei intensiver Nutzung bei rund 200 im Monat. Ein Power-User, der jedes Tool ans Limit treibt, liegt bei 400 bis 600. Die teure Zeile ist eine andere. Es sind die Stunden, die Sie mit dem Prüfen des Outputs verbringen, und die Tage, die Sie damit verbringen, zu reparieren, was Sie übersprungen haben. Es gibt kein Tool, das das Prüfen entfernt. Wer Ihnen eines verkauft, verkauft wieder die Fantasie-Version.

Wenn Sie die komplette Übersicht von allem wollen, was ich sonst noch betreibe, habe ich das separat aufgeschrieben. Hier ist mein Marketing-Tech-Stack.

Vibe Coding Beispiele: ein Erfolg und ein teures Chaos

Lassen Sie mich Ihnen beide Seiten zeigen, denn eine Liste von Erfolgen ohne das Chaos wäre unehrlich. Die Erfolge sind real. Genauso real ist die Rechnung, wenn Sie die Regeln überspringen.

Der Erfolg. The Nexus begann als eine einzelne Liste offener Aufgaben. Das war das ganze Ding. Es funktionierte am ersten Tag, was mir das Vertrauen gab, eine zweite View hinzuzufügen, dann Alert-Regeln, dann den SSE-Watcher. Jeder Slice ging klein und geprüft live. Die Tests kamen später, nachdem ich es lange genug genutzt hatte, um zu wissen, was zählt, und sie fingen drei Bugs, die ich von Hand ausgeliefert hätte. Das ist die ganze Methode in einem Tool: klein starten, hart prüfen, die Tests mit dem Tool wachsen lassen.

Das teure Chaos. Früher habe ich ein Modell gebeten, ein Skript umzustrukturieren, das echte Daten berührte, liess es laufen und las den Diff nicht. Es funktionierte in der Demo und scheiterte in Produktion, und ich verbrannte den Grossteil eines Tages damit, zurückzuverfolgen, was es geändert hatte. Die Lektion war nicht, dass Vibe Coding gefährlich ist. Sie lautete: Der Prüf-Schritt ist nicht optional, und Überspringen wird nie billiger. Die Lösung war derselbe Prüf-Schritt, den ich heute als harte Regel behandle.

Das Chaos war meine Schuld, nicht die des Modells. Das Modell tat genau das, was ein schneller Tipper ohne Urteilsvermögen tut: Es produzierte etwas, das richtig aussah und es nicht war. Ich habe über die tiefere Version dieses Scheiterns schon geschrieben, die ganze KI-Projekte in Firmen versenkt. Sie scheitern auf vier vorhersehbare Arten. Die meisten davon sind derselbe Fehler in grossem Massstab: den Output des Modells als fertig zu behandeln.

Vibe Coding Security: die Regeln, die ich nie breche

Das ist der Abschnitt, den die Kursverkäufer überspringen, und er ist der, der am meisten zählt. Vibe Coding Security ist kein Feature, das Sie später anschrauben. Es ist ein Satz Regeln, dem Sie folgen, bevor Sie einen einzigen Prompt schreiben.

Niemals Zugangsdaten im Klartext speichern. Keine API-Keys im Skript. Keine Passwörter in einer Config-Datei, die Sie committen. Nutzen Sie eine Environment-Datei oder einen Secret-Manager und halten Sie sie aus der Versionskontrolle heraus. Ein Modell schreibt Ihnen gerne ein Skript mit dem eingefügten Key, wenn Sie es zulassen. Lassen Sie es nicht zu. Diese Regel hat keine Ausnahme, nicht einmal für ein internes Tool, das «nur ich nutze».

Niemals Kundendaten an ein Modell geben. Kundenlisten, Umsatzzahlen, unveröffentlichte Produktspecs, alles, was Sie bei einem Leak in Verlegenheit bringen würde. Nichts davon geht in einen öffentlichen Chat. Wenn die Daten in den Händen eines Fremden ein Problem wären, fügen Sie sie nicht in den Chat eines solchen ein. Mein Arbeitgeber verbietet Frontier-Modelle für Firmendaten, und das ist keine Rückständigkeit. Es ist der einzige vertretbare Standard.

Immer prüfen, bevor Sie deployen. Das Modell kennt Ihre Produktionsumgebung nicht. Es weiss nicht, welche Datei geschäftskritisch ist. Es schreibt Code, der isoliert funktioniert und im Kontext bricht. Die einzige Person, die das fangen kann, sind Sie, beim Lesen des Diffs. Genau so ist das teure Chaos im letzten Abschnitt passiert.

Es gibt drei weitere, die ich als Gesetz behandle. Machen Sie von allem, was das Skript berührt, ein Backup. Lassen Sie neue Tools zuerst auf einer Kopie der Daten laufen, niemals auf der Live-Datei. Und wenn Sie einen Code-Block nicht verstehen, führen Sie ihn nicht aus, egal wie selbstsicher das Modell klingt. Selbstsicherheit bedeutet nicht Richtigkeit. Diese besondere hässliche Wahrheit habe ich im Detail in meinem Artikel über ChatGPT im Marketing behandelt.

Vibe Coding lernen, ohne sechs Monate zu verschwenden

Kaufen Sie nicht den Sechs-Monats-Kurs. Sie brauchen ihn nicht, und das meiste davon ist Füllmaterial um die sieben Schritte oben. Hier ist der Weg, der funktioniert hat, verdichtet in drei Meilensteine.

Bauen Sie sich diese Woche ein kleines Tool. Ein Skript, das Dateien umbenennt, eine Seite, die Ihre offenen Tabs auflistet, ein Formular, das Ihnen eine Zusammenfassung mailt. Das Ziel ist nicht das Tool. Es ist, eine Schleife zu Ende zu bringen: anfragen, ausführen, den Fehler lesen, reparieren, erneut ausführen. Diese Schleife ist die ganze Fähigkeit. Alles danach ist Wiederholung mit höherem Einsatz.

Lassen Sie das zweite Tool Ihre echte Arbeit berühren. Automatisiere etwas, das Sie von Hand machen. Einen Report, den Sie zusammenbauen, eine Liste, die Sie aktualisieren, eine Benachrichtigung, die Sie prüfen. Jetzt ist der Einsatz real und das Feedback sofort da, genau das, was Sie brauchen, um den Prüf-Schritt zu lernen. Beim zweiten Tool stirbt die Fantasie, und die Disziplin beginnt.

Füg dem dritten Tests hinzu. Beim dritten Tool werden Sie den Schmerz eines stillen Scheiterns gespürt haben. Dieser Schmerz ist der beste Lehrer dafür, warum es Tests gibt. Fügen Sie ein paar für die Teile hinzu, die Daten berühren, und beobachte, wie anders Sie den Output des Modells danach behandeln. Bei den Tests geht es nicht um Engineering-Reinheit. Es geht darum, nicht zweimal verbrannt zu werden.

Die Schleife lernst Sie an einem Wochenende. Das Urteilsvermögen, der Teil, der weiss, wann der Output falsch ist, braucht Monate, in denen echte Tools scheitern. Die gute Nachricht: Das Scheitern ist der Lehrplan. Die schlechte Nachricht: Es passiert auf Ihre Zeit. Es gibt keinen Weg daran vorbei, egal was der Kurs sagt.

Wann Sie aufhören und einen Entwickler holen solltest (und woran Sie es erkennst)

Vibe Coding hat eine Obergrenze, und der ehrliche Teil dieses Artikels sagt Ihnen, wo sie ist. Ich habe Dinge ohne Entwicklerteam gebaut. Ich habe auch Dinge zurückgegeben und gesagt: «das hier ist deins». Die Grenze verläuft nicht beim Können, sondern beim Explosionsradius.

Machen Sie es selbst, wenn das Tool intern ist, Sie der einzige Nutzer sind, der Explosionsradius Ihr eigener Nachmittag ist und Sie vollständig erklären können, was es tut. Ein Dashboard, ein Attributions-Skript, ein Ingestion-Service, ein statisches Verzeichnis. Alle diese fielen darunter. Der Fehlermodus ist eine verlorene Stunde, kein verlorener Kunde.

Holen Sie einen Entwickler, wenn das Tool Kundendaten in grossem Massstab berührt, Zahlungen abwickelt, dem öffentlichen Internet ausgesetzt ist, gegen Leute gesichert sein muss, die es knacken wollen, oder laufen muss, wenn Sie nicht hinschaust. Ein Checkout-Flow. Ein Kundenportal. Alles, wo ein Bug bedeutet, Geld zu verlieren oder Daten zu leaken. Das sind keine Vibe-Coding-Projekte. Das sind Engineering-Projekte.

Es gibt eine dritte Kategorie, und sie ist die, über die niemand spricht. Der Moment, in dem Sie der Flaschenhals sind, weil das Tool, das Sie gebaut haben, jetzt für andere Menschen zählt. Wenn drei Kollegen von Ihrem Skript abhängen und es an einem Sonntag bricht, sind Sie nicht mehr der Held der internen Tools. Sie sind der Single Point of Failure. Das ist das Signal, es einem Entwickler mit richtigen Tests und richtigem Deployment zu übergeben.

Der Test, den ich nutze, ist einfach. Fragen Sie, was passiert, wenn das im schlimmstmöglichen Moment bricht. Wenn die Antwort «Ich verliere eine Stunde» ist, bauen Sie es selbst. Wenn die Antwort «Jemand verliert Geld oder Daten» ist, holen Sie den Entwickler. Alles andere ist das Einplanen des Schmerzes.

Vibe Coding: mein Fazit nach zwei Jahren

Nach zwei Jahren, in denen ich so gebaut habe, ist hier mein Fazit zum Vibe Coding im Marketing. Es ist die nützlichste Fähigkeit, die ich meiner Marketing-Arbeit in einem Jahrzehnt hinzugefügt habe, und die am meisten missverstandene.

Es macht Sie nicht zum Entwickler. Es macht Sie auf die beste Art gefährlich: fähig, die langweiligen Tools auszuliefern, die Ihre Arbeit voranbringen, ohne auf ein Ticket zu warten, das nie kommt. Die vier Tools, die ich beschrieben habe, haben mir Wochen manueller Arbeit erspart, und keiner von ihnen brauchte einen einzigen Tag formaler Ausbildung.

Die Leute, sich beim Vibe Coding die Finger verbrennen, sind die, die das Prüfen überspringen, Secrets in Chats einfügen und das Modell frei auf Produktionsdaten loslassen. Die Leute, die aufblühen, sind die, die das Modell wie einen schnellen Tipper ohne Urteilsvermögen behandeln. Sie treffen immer noch jede Entscheidung, die zählt. Sie treffen dieselben Entscheidungen, zehnmal schneller.

Ich habe die längere Version dessen, was mich zweieinhalb Jahre tägliche KI-Nutzung gelehrt hat, an anderer Stelle aufgeschrieben. Dieser Artikel ist die Bau-Seite derselben Geschichte. Starten Sie mit einem Tool, das einen echten Schmerz löst. Schneiden Sie es klein. Testen Sie die Teile, die Daten berühren. Prüfen Sie, bevor Sie deployen. Das ist die ganze Methode, und sie gehört Ihnen für den Preis eines Wochenendes.

Wenn Sie das andere Ende des KI-gestützten Bauens sehen wollen: Ein kleines Team hat gerade zwölf Open-Source-Apps in neun Tagen ausgeliefert. Ich habe den Code geprüft, um zu sehen, was davon trägt.

Häufige Fragen

Muss ich programmieren können, um Vibe Coding zu nutzen?

Nein. Sie müssen beschreiben können, was Sie wollen, in einfacher Sprache, eine Fehlermeldung lesen können, ohne in Panik zu geraten, und in kleinen Schritten denken. Alles andere macht das Modell. Was Sie nicht überspringen dürfen, ist das Urteilsvermögen: zu wissen, wann der Output falsch ist, und zu prüfen, bevor Sie ihm vertrauen.

Ist Vibe Coding sicher für die Arbeit?

Nur unter Regeln. Niemals Zugangsdaten im Klartext speichern. Niemals Kunden- oder Firmendaten an ein öffentliches Modell geben. Immer prüfen, bevor Sie deployen, und neue Tools zuerst auf einer Kopie der Daten laufen lassen. Wenn Ihr Arbeitgeber Frontier-Modelle für Firmendaten verbietet, gibt es diese Richtlinie aus gutem Grund. Respektiere sie.

Womit fange ich am besten an, um Vibe Coding zu lernen?

Mit dem, wofür Sie schon zahlen. Die Fähigkeit überträgt sich über Modelle hinweg, also starten Sie mit dem, was Sie haben, wählen Sie ein kleines internes Tool und bringen Sie die Schleife zu Ende: anfragen, ausführen, den Fehler lesen, reparieren, erneut ausführen. Das Tool zählt weniger als die Prüf-Gewohnheit. Diese Gewohnheit ist der ganze Unterschied zwischen einem Tool, dem Sie vertrauen, und einer Haftung, die Sie ausliefern. Diese Schleife, nicht das Tool, ist Vibe Coding.