Vibe Coding oder nicht? Entscheidungsraster fürs Marketing
Inhaltsverzeichnis
Bauen wir uns das nicht einfach selbst? Diese Frage taucht gerade in fast jedem Marketingteam auf. Mit Claude Code oder Cursor wirkt plötzlich jedes Tool machbar. Aber: Ist das wirklich sinnvoll?
💡 In diesem Artikel bekommst Du eine Entscheidungshilfe, wann sich der KI-Eigenbau lohnt und wann besser nicht.
Lesezeit ca. 5 min
Was genau ist Vibe Coding
Der Begriff ist noch keine zwei Jahre alt. Andrej Karpathy, Mitgründer von OpenAI, prägt ihn im Februar 2025 in einem Post auf X. Seine eigene Beschreibung: Man gibt sich komplett den Vibes hin und vergisst irgendwann, dass der Code überhaupt existiert. Man sieht etwas, sagt etwas, lässt es laufen, kopiert das Ergebnis, und es funktioniert meistens.
Genau dieses Gefühl kennen wir aus eigener Erfahrung. Wer hat nicht schonmal mit Claude Code oder ChatGPT ein kleines Tool oder eine Marketing-Landingpage gebaut und war erstaunt über die Einfachheit. Plötzlich scheint alles möglich!
Doch genau hier fängt das Problem an.
Was beim Vibe Coding häufig übersehen wird
Gebaut heißt nicht betrieben
Normalerweise arbeiten Entwickler in Release-Zyklen. Ein Tool geht in einer Beta-Version live, danach kommen in Sprints Verbesserungen. Sobald ein Tool launcht, kommt sofort Userfeedback. Das Feld lässt sich nicht befüllen. Diese Funktion fehlt. Mit KI ist die Antwort darauf fast immer „ja klar, können wir einbauen“. Nur wer setzt das in einem kleinen Team ohne eigene IT tatsächlich um? Beim Vibe Coding wird oft vergessen, dass auch dafür Ressource da sein muss. Das Bauen an sich ist in großen IT-Projekten oft nur der kleinste Teil.
Der Owner, der nie einer sein wollte
Der zweite Punkt geht damit einher: Irgendjemand baut nebenbei ein Tool, es geht hintenrum live, wird zum Standard, ohne dass offiziell jemand die Verantwortung übernommen hat. Aus einem Wochenendprojekt wird über Nacht der Owner eines Kernprozesses, den eigentlich niemand verantworten wollte.
Datenschutz ist dabei kein Nebenthema. KI-generierter Code durchläuft selten dieselben Prüfschritte wie Software von Teams mit etablierten Testing-Routinen. Wie hoch das Risiko ausfällt, zeigt eine Studie, in der sich erfahrene Entwickler 50 reale KI-generierten GitHub-Projekte angeschaut haben: 88 Prozent hatten kritische Sicherheitslücken.
Nicht die Kernfeatures zählen, sondern die Ausnahmen
Der dritte Punkt lässt sich im Alltag am leichtesten übersehen. Etablierte Tools ziehen ihren Wert selten aus den Kernfunktionen. Er steckt in den Fällen drumherum: Was passiert bei einem vermeintlichen Duplikat? Wie läuft die Mailhygiene? Wie bildet das Tool unterschiedliche Hierarchien ab? Genau diese Fälle beschäftigen einen Toolanbieter jeden Tag, mit Kunden aus unterschiedlichsten Branchen. Ein Eigenbau hat diese Erfahrung nicht.
Dazu kommt ein Gedanke, der fast paradox klingt: Ein gutes Tool erzieht einen. Erscheint eine Warnung, weil zu viele Softbounces aufgelaufen sind, wird die eigene Datenpflege besser, ohne dass man aktiv darüber nachgedacht hätte. Ein selbst gebautes Tool tut das nicht. Niemand baut eine Warnung für ein Problem ein, das er selbst noch nie hatte.
🎧 Mehr dazu im Podcast
Vibe Coding oder nicht ist auch Thema in unserem Podcast „Marketing mal ehrlich“.
Yvonne und Philipp sprechen dort ausführlich darüber, warum Bauen und Betreiben zwei verschiedene Dinge sind und wann sich Eigenbau wirklich lohnt.
Entscheidungsraster: Wann baue ich selbst?
Ob Du Dich an den KI-Eigenbau wagst, solltest Du immer gründlich prüfen. Folgende fünf Kriterien helfen Dir dabei:
Komplexität
Ein Mini-Rechner oder ein Landingpage-Mockup sind unkritisch. Ein Tool mit Login und Datenverarbeitung ist eine andere Kategorie. Je komplexer ein Projekt, desto eher solltest Du es an deine IT abgeben, die Erfahrung hat und sich mit der Koordination solcher Projekte auskennt.
Wer arbeitet damit?
Ein Tool nur für dich selbst lässt sich jederzeit anpassen und optimieren. Sobald andere sich einloggen, mit unterschiedlichen Rollen, entstehen aber ganz andere Herausforderungen. Du bekommst Feedback und musst dich plötzlich auf unterschiedliche Nutzungsszenarien einstellen. Genau das ist der Unterschied von Bauen zu Betreiben.
Anwendungshorizont
Bei einer Kampagnen-Landingpage mit sechs Wochen Halbwertszeit beschwert sich niemand, wenn der Code nicht komplett sauber und nachvollziehbar ist. Ein Tool, das dauerhaft Daten strukturieren soll, braucht hingegen Zeit für Setup, Bereinigung und Schulung. Es dauert nicht nur länger zu bauen, sondern muss auch in Wochen noch nachvollziehbar sein, wenn Du Fehler beheben oder Optimierungen vornehmen willst.
Funktionsumfang
Wie viele Sonderfälle wie Duplikate, Berechtigungsstufen oder Schnittstellen muss das Tool abdecken? Je mehr davon zusammenkommen, desto eher lohnt sich ein eingekauftes Tool, das diese Fälle oft schon gelöst hat.
„Kritikalität“
Was passiert, wenn das Tool ausfällt oder falsche Daten produziert? Bei einer internen Liste: nichts Schlimmes. Bei einem System mit Kundendaten oder Rechnungslogik: potenziell viel. Herkömmliche Tools sind oft viel verlässlicher als KI-gebaute Lösungen – erst recht dann, wenn der Erbauer eigentlich nichts von Software Engineering versteht.
Fazit
Bei komplexer Software gilt nicht Human in the Loop, sondern Human in the Lead. Du musst selbst verstehen, was du baust. Verstehst du es nicht, ist es ein Experiment. Und ein Experiment gehört in die Hände von Leuten, die es verstehen.
Vibe Coding ist verlockend. Der größte Zeitgewinn liegt aber bei den Leuten, die den Code danach auch lesen, testen und reparieren können. Das sind Entwickler, nicht Marketing-Teams.
Deshalb die klare Grenze: Marketing-Teams sollten sich auf kleinere Dinge begrenzen. Ein HTML-Element auf der Landingpage, ein kleiner Generator, ein Tool nur für dich selbst. Sobald Login, mehrere Nutzende oder echte Daten dazukommen, ist es kein Wochenendprojekt mehr. Greif dann lieber auf bestehende Tools zurück oder lass es professionell bauen, um die Risiken und ungeplante Aufwände zu vermeiden.
Takeaways
- Gebaut heißt nicht betrieben. Wer ein Tool live stellt, übernimmt automatisch Verantwortung für Feedback, Fehler und Wartung.
- Der eigentliche Wert eines Tools steckt in den Ausnahmen, nicht in den Kernfunktionen. Tool-Anbieter haben hier oft jahrelange Erfahrung.
- Fünf Kriterien entscheiden über Bauen oder Kaufen: Komplexität, Nutzerkreis, Anwendungshorizont, Funktionsumfang und Kritikalität.
