Die Code-Falle: Warum Vibe Coding zur teuersten Entscheidung in Ihrem MarTech-Stack werden kann

„Wir bauen das intern" – ein Satz mit Konsequenzen

Mit dem Aufkommen immer leistungsfähigerer KI-Agenten und Vibe-Coding-Tools hören wir diesen Satz häufiger denn je: „Das können wir auch selbst bauen." Und meistens stimmt das – zumindest für den Anfang.

Ein Prototyp entsteht heute in Stunden statt Wochen. Er läuft, er überzeugt intern, und er macht genau das, was er soll. Das Ergebnis wirkt maßgeschneidert, das Team ist motiviert, das Budget erscheint überschaubar.

Was danach kommt, ist die eigentliche Frage.

Dieser Artikel ist keine Kritik an technischem Können oder interner Entwicklung. Er ist eine nüchterne Bestandsaufnahme dessen, was es bedeutet, Marketing-Technologie im Unternehmenskontext selbst zu entwickeln und dauerhaft zu betreiben – und warum die Lücke zwischen einem funktionierenden Demo und einem produktionstauglichen System erheblich größer ist, als sie in der Planung meistens aussieht.

Was Vibe Coding so verführerisch macht – und wo die Grenze liegt

Vibe Coding – also das promptbasierte Entwickeln mit KI-Tools wie Cursor, Replit oder Lovable – hat die Schwelle zur Softwareentwicklung deutlich gesenkt. Designer, Produktmanager und Marketingteams können heute Applikationen bauen, ohne klassische Entwicklungsprozesse zu durchlaufen. Die Geschwindigkeit ist real, der Reiz enorm.

Das Problem ist nicht die Technologie. Das Problem ist der Moment, in dem ein „guter genug"-Prototyp unter Druck in Produktion geht, ohne dass die dafür notwendige Grundlage gelegt wurde.

Gartner schätzt, dass bis 2028 rund 75 Prozent der Enterprise-Entwickler KI-Coding-Assistenten nutzen werden. Das ist kein Trend mehr – das ist eine Verschiebung der gesamten Entwicklungslandschaft. Und sie bringt ein strukturelles Risiko mit sich, das besonders im MarTech-Umfeld unterschätzt wird: Vibe-coded applications, so das Fazit mehrerer Sicherheitsstudien, werden durch Iteration nicht automatisch compliant. Sie benötigen fundamentale Architekturänderungen, sobald echte Enterprise-Anforderungen greifen.

Die 95-Prozent-Rechnung

Ein Prototyp bildet ungefähr fünf Prozent einer vollständigen Softwarelösung ab. Die verbleibenden 95 Prozent sind das, was ihn zu einem Produkt macht, das in einem Unternehmen verlässlich, sicher und rechtssicher läuft. Und genau diese 95 Prozent binden dauerhaft Zeit, Budget und Aufmerksamkeit.

Was Produktionsbetrieb im Enterprise-Kontext konkret bedeutet:

Verfügbarkeit und Uptime
Eine 99,9%-Uptime bedeutet maximal 8,7 Stunden Ausfall pro Jahr. Dahinter stehen Monitoring-Infrastruktur, definierte Incident-Response-Prozesse, redundante Systeme und ein Team, das rund um die Uhr eingreifen kann. Das ist kein einmaliger Aufwand – das ist operativer Betrieb.

DSGVO und Datenschutz-Compliance
DSGVO-Konformität ist kein Häkchen auf einer Liste. Die Implementierungskosten lagen bereits bei Einführung der Verordnung 2018 bei durchschnittlich 1,5 Millionen Euro für kleinere Unternehmen – und bei bis zu 65 Millionen Euro für größere Organisationen. Der durchschnittliche Bußgeldbescheid lag 2024 bei rund 2,8 Millionen Euro – ein Anstieg von 30 Prozent gegenüber dem Vorjahr. Seit 2018 wurden insgesamt über 6,2 Milliarden Euro an DSGVO-Bußgeldern verhängt, mehr als 60 Prozent davon allein seit Januar 2023. Die Durchsetzung nimmt zu, nicht ab.

Besonders relevant für Vibe-Coding-Projekte: Compliance lässt sich nicht nachträglich aufpromten. Wer DSGVO-Anforderungen wie Datenhaltung, Löschpflichten oder Audit-Trails nicht von Beginn an in die Architektur einbaut, steht vor einem strukturellen Umbau – kein Patch, kein Update löst das.

Security-Zertifizierungen
Enterprise-Kunden verlangen Nachweise: ISO 27001, SOC 2, rollenbasierte Zugriffskontrolle, vollständige Audit-Trails. Ein Bericht aus August 2025 zeigte, dass 45 Prozent des KI-generierten Codes Sicherheitslücken enthält – bei Java-Code lag der Anteil sogar über 70 Prozent. Sicherheit entsteht nicht automatisch durch schnelles Bauen. Sie muss von Anfang an Bestandteil der Architektur sein.

API-Stabilität und Integrations-Management
Wer Drittsysteme anbindet – und jeder moderne MarTech-Stack tut das –, braucht stabile, versionierte Schnittstellen. API-Versionierung, Changelogs, Abwärtskompatibilität: Das ist Engineering-Arbeit, die sich nicht einmalig erledigen lässt.

Technical Debt und laufende Wartungskosten
Branchen-Studien zeigen übereinstimmend: 50 bis 80 Prozent der gesamten Softwarekosten entfallen auf die Wartungsphase – nicht auf die initiale Entwicklung. McKinsey beziffert allein die jährlichen Wartungskosten auf durchschnittlich 20 Prozent der ursprünglichen Entwicklungskosten. Hinzu kommen Abhängigkeitsupdates, Breaking Changes externer APIs und neue regulatorische Anforderungen.

Die versteckten Kosten im MarTech-Stack

Das Problem liegt nicht darin, dass In-House-Entwicklung grundsätzlich teuer ist. Das Problem ist, dass die entscheidenden Kosten systematisch zu spät sichtbar werden.

Ein bekanntes Muster: Ein Unternehmen investiert 300.000 bis 400.000 Euro in ein MVP, das intern überzeugt und erste Kunden gewinnt. Zwei bis drei Jahre später müssen häufig mehr als das Doppelte dieser Summe in einen Teilumbau gesteckt werden – um Architekturprobleme zu beheben, die erst unter echten Enterprise-Anforderungen sichtbar wurden.

Dazu kommt der Opportunitätskostenaspekt: Jede Stunde, die ein internes Team mit Infrastructure Maintenance, Security Patches und Dependency Management verbringt, ist eine Stunde, die nicht in Produkt, Strategie oder Kundenprojekte fließt. Das ist keine buchhalterische Kleinigkeit – das ist eine strategische Weichenstellung.

Im MarTech-Kontext schärft sich dieses Problem noch einmal. Marketing-Technologien verarbeiten sensible Kampagnen- und Kundendaten. Sie sind eng mit Drittplattformen verzahnt: CRM-Systeme, Analytics-Tools, Demand-Side-Platforms, Adserver, Buchhaltungssysteme. Und sie laufen in einem regulatorischen Umfeld, das sich verändert – neue Datenschutzanforderungen, neue Plattform-APIs, neue Compliance-Vorgaben.

Wer den Stack selbst betreibt, trägt jeden dieser Veränderungsschritte alleine.

Was das speziell für Media Operations bedeutet

Im Media-Umfeld kommen weitere Anforderungen hinzu, die den Betrieb einer eigenen Plattform besonders komplex machen.

Plattformen wie Mercury bilden komplexe Agentur- und Advertiser-Strukturen ab, verbinden sich mit zahlreichen Systemen in Echtzeit und müssen dabei Datenintegrität, Transparenz und Compliance gleichzeitig sicherstellen. Kampagnendaten sind die Grundlage für Budgetentscheidungen – Ausfälle oder Inkonsistenzen haben direkte geschäftliche Konsequenzen. Granulare Rollenkonzepte, Reconciliation-Prozesse, Echtzeit-Reporting: Das alles lässt sich aufbauen. Die Frage ist, ob das der beste Einsatz der eigenen Ressourcen ist.

Build vs. Buy: Die richtige Frage stellen

„Build vs. Buy" ist keine Frage des technischen Könnens. Es ist eine Frage der strategischen Priorität.

Was soll Ihr Team in den nächsten zwölf Monaten voranbringen? Bessere Kampagnensteuerung, präziseres Media Planning, robustere Marketing Attribution, engere Kundenbeziehungen? Dann ist jede Stunde, die stattdessen in Infrastrukturaufbau, SLA-Management und Compliance-Dokumentation fließt, eine Stunde, die von diesen Zielen abzieht.

Etablierte MarTech-Plattformen bringen die operative Grundlage bereits mit: Betrieb, DSGVO-Compliance, Security-Zertifizierungen, stabile API-Integrationen, Wartung. Was bleibt, ist die Arbeit, für die das eigene Team tatsächlich da ist: Strategie, Planung, Wachstum.

Die Infrastruktur ist gebaut. Die Frage ist nur, ob man sie selbst bauen und betreiben will.

Fazit

Der Prototyp ist der einfache Teil. Er funktioniert, er überzeugt, er zeigt, was möglich ist.

Die eigentliche Arbeit kommt danach – und taucht selten vollständig in der ursprünglichen Planung auf: 99,9% Uptime. DSGVO. ISO-Zertifizierung. API-Versionierung. Audit-Trails. Rollenkonzepte. Datenhaltung. Sicherheitslücken im KI-generierten Code. Und das alles nicht einmalig, sondern dauerhaft.

Vibe Coding ist ein mächtiges Werkzeug für Exploration und Prototyping. Als Fundament für produktionskritische Marketing-Technologie ist es eine Falle – nicht weil die Technologie schlecht ist, sondern weil der Schritt von „es läuft auf meinem Laptop" zu „es läuft für Enterprise-Kunden, unter Last, mit echten Daten, rechtskonform" kein Deployment ist. Es ist ein anderes Produkt.

Mercury Media Technology entwickelt und betreibt eine cloudbasierte Marketing-Management-Plattform für Agenturen, Advertiser und Publisher – mit ISO-zertifizierter Security, DSGVO-konformer Infrastruktur und produktionserprobten API-Integrationen. Mehr unter mercurymediatechnology.com