„Kündigungsgrund: Wir haben mit KI ein eigenes CRM programmiert." Diese Nachricht lag letzte Woche in unserem Kündigungschannel. Ich hab dazu einen LinkedIn-Post geschrieben und das Kommentarfeld war geteilt: zwei Drittel hielten Vibe Coding fürs eigene CRM für keine gute Idee, ein Drittel fand sie nachvollziehbar. Verstehen kann ich beide Seiten.
Die Idee ist erstmal verheißungsvoll. Kein Anbieter, dessen Philosophie man folgen muss. Keine Lizenzkosten. Ein paar Abende mit Claude oder Cursor, und das Ding sieht so aus, wie du es dir gewünscht hast. Ich bau seit über 15 Jahren mit unserem Team an CentralStationCRM und kann sagen: Die ersten 80 Prozent eines CRM sind tatsächlich die einfachen. Die Schwierigkeit liegt im Detail.
Die wichtigste Frage, die Unternehmer bei dem Thema bewegen dürfte: Gut, aber was spricht eigentlich dagegen? Deshalb jetzt 10 Gründe, warum man sich das Vibe-gecodete CRM nochmal überlegen sollte.
Risiko 1: KI-Code bringt Sicherheitslücken ab Werk
Veracode hat über 100 Sprachmodelle dieselben 80 Programmieraufgaben lösen lassen. Das Ergebnis: 45 Prozent des generierten Codes enthielt Sicherheitslücken aus den OWASP Top 10. Bei Aufgaben, in denen Cross-Site-Scripting möglich war, versagten die Modelle in 86 Prozent der Fälle.
Besonders unangenehm: Neuere und größere Modelle konnten das nicht unbedingt besser. Das Problem steckt strukturell darin, wie KI Code erzeugt. Ein CRM enthält Namen, Mailadressen, Notizen zu Kundengesprächen, vielleicht Umsätze. Genau die Daten, für die sich Angreifer interessieren.
Risiko 2: Du fühlst dich sicherer, als du bist
Ein Forschungsteam in Stanford um Dan Boneh hat untersucht, was passiert, wenn Menschen mit KI-Assistent programmieren.
Zwei Befunde:
- Die Teilnehmer mit KI schrieben Code, der tendenziell weniger sicher war
- Gleichzeitig hielten sie ihren Code häufiger für sicher
Die Kombination ist das eigentlich Gefährliche. Beim Vibe Coding siehst du der Anwendung nicht an, ob sie unsicher ist, weil sie erstmal funktioniert.
Risiko 3: Deine Apps haben Datenlecks
Im Mai 2025 prüften Sicherheitsforscher 1.645 Apps, die mit der Vibe-Coding-Plattform Lovable gebaut wurden.
170 davon ließen persönliche Daten offen abrufbar, darunter Namen, Adressen und Zahlungsdaten (CVE-2025-48757).
Im Februar 2026 fand ein Forscher in einer einzelnen Lovable-App 18.697 offen zugängliche Nutzerdatensätze. Die Apps funktionierten übrigens wie beim vorherigen Beispiel einwandfrei.
Risiko 4: Der KI-Agent kann deine Daten löschen
Im Juli 2025 löschte der KI-Agent von Replit die Produktivdatenbank eines SaaS-Unternehmers. Es galt ein ausdrücklich angeordneter Code-Freeze. Der Agent führte trotzdem Befehle aus, legte danach eine Datenbank mit 4.000 erfundenen Personen an und behauptete, ein Rollback sei unmöglich. Der Fall ist in der AI Incident Database dokumentiert.
Mein Punkt dabei: Ein Agent mit Schreibzugriff auf deine einzige Kundendatenbank ist ein Betriebsrisiko, das du managen musst. Profis bauen dafür Staging-Umgebungen, Backups, Zugriffstrennung. Hast du die? Wenn nicht, solltest du überlegen, auf welchen Grundsätzen dein Vertrauen in die KI eigentlich fußt.
Risiko 5: Du haftest für die DSGVO
Artikel 32 DSGVO verlangt „geeignete technische und organisatorische Maßnahmen" zum Schutz personenbezogener Daten. Verantwortlich ist, wer die Daten verarbeitet. Also du. Allein in Deutschland wurden 2025 10.259 Datenpannen gemeldet, die Behörden verhängten 249 Bußgelder über zusammen rund 46,9 Millionen Euro.
Ein CRM ist der DSGVO-sensibelste Datentopf in deinem Unternehmen. Bei einem CRM aus Deutschland kümmert sich der Anbieter um Verschlüsselung, Zugriffskonzepte und Serverstandort. Bei einem CRM in Eigenbau steht dein Name unter allem.
Risiko 6: Die KI erfindet Software-Pakete
KI-generierter Code stützt sich auf fremde Code-Bibliotheken. Eine Studie auf der USENIX Security 2025 hat 576.000 KI-generierte Code-Beispiele untersucht: Rund 20 Prozent verwiesen auf Pakete, die gar nicht existieren.
Weil sich 43 Prozent dieser erfundenen Namen über viele Anfragen hinweg wiederholen, sind sie für Angreifer vorhersagbar: Sie können genau diese Paketnamen registrieren und Schadcode hinterlegen.
Sicherheitsforscher nennen das Muster „Slopsquatting" und warnen vor einer neuen Klasse von Supply-Chain-Angriffen. Wer die Abhängigkeiten seines Codes nicht selbst prüfen kann, installiert im Zweifel fremden Code in das System mit seinen Kundendaten.
Risiko 7: Der Code wächst zu schnell
GitClear hat 211 Millionen Zeilen Code-Änderungen analysiert: Seit dem KI-Boom hat sich der Anteil geklonter Code-Blöcke vervierfacht, der Anteil an Refactoring fiel von 25 auf unter 10 Prozent. Heißt übersetzt: Es kommt immer mehr Code dazu, immer weniger davon wird aufgeräumt.
Duplizierter Code produziert nachweislich mehr Fehler. Bei einem Wegwerf-Prototyp ist das egal. Bei einem CRM, das fünf Jahre lang jeden Tag laufen soll, ist das eine Hypothek, die du ab Monat drei abbezahlst.
Risiko 8: Du bildest dir ein, Zeit zu sparen
Die Organisation METR hat in einer randomisierten Studie erfahrene Entwickler mit und ohne KI-Tools an echten Aufgaben arbeiten lassen. Mit KI waren sie 19 Prozent langsamer. Geschätzt hatten sie hinterher, 20 Prozent schneller gewesen zu sein. Das waren Profis in vertrauten Projekten.
Jetzt rechne das auf jemanden um, der nebenbei ein CRM baut und jede KI-Ausgabe glauben muss, weil er sie nicht prüfen kann. Die ehrliche Frage kommt nach dem Prototyp: Wie viele Abende und wie viele Token hat mich Version 1.1 gekostet?
Risiko 9: Der Betrieb ist ... herausfordernd
Das unterschätzen aus meiner Sicht die meisten: Mit dem Launch beginnt der Betrieb, und der hört nie auf. Server-Updates, Security-Patches, Backups testen, Monitoring, Bugfixes, Anpassungen, wenn sich euer Workflow ändert.
Wir haben dafür ein Team, das sich täglich kümmert. Beim Eigenbau macht das eine Person nach Feierabend, oder eben niemand.
Genau so entstehen dann die Sicherheitslücken aus Risiko 1 bis 3. Die Spar-Rechnung geht selten auf, wenn man die eigenen Stunden ehrlich mitzählt.
Risiko 10: Dein CRM hängt an einer einzigen Person
Im Maschinenbau nennt man das Kopfmonopol, in der Software-Welt (nenne ich das) den "Bus-Faktor": Was passiert, wenn die Person, die das System gebaut hat, morgen vom sprichwörtlichen Bus überfahren wird?
Beim vibe-gecodeten CRM versteht oft nicht mal die bauende Person den eigenen Code vollständig, sie hat ihn ja nicht geschrieben. Kündigt sie oder fällt sie aus, steht das Werkzeug still. Und darin liegt eure gesamte Kundenhistorie.
Bei gekaufter Software ist der Bus-Faktor ein Problem des Anbieters.
Wofür Vibe Coding wirklich gut ist
Damit das nicht falsch rüberkommt: Wir vibe-coden selbst, und zwar gern. Es gibt Einsatzgebiete, da ist die Methode großartig:
- Prototypen, um eine Idee in Stunden statt Wochen zu testen
- interne Helfer wie Skripte, Dashboards und kleine Automatisierungen
- Anbindungen zwischen Tools, etwa über APIs, wie in unserer n8n-Sammlung
- Experimente, bei denen ein Scheitern nichts kostet
Das sind alles Projekte mit überschaubarer Lebensdauer, ohne sensible Daten und ohne Drama beim Ausfall. Ein CRM erfüllt keines dieser Kriterien. Es soll Jahre leben, enthält eure sensibelsten Daten, und sein Ausfall trifft euer Tagesgeschäft.
Was das für deine CRM-Entscheidung heißt
In meinem LinkedIn-Post war das Fazit: "Ein CRM ist kein Bastelprojekt. Es ist euer zweites Gedächtnis".
Heute würde ich es so formulieren: Bau gern mit KI – aber bau Dinge, deren Scheitern du dir leisten kannst.
Falls du schon ein CRM vibe-gecoded hast: Schreib mir, wie es nach sechs Monaten aussieht. Bin ehrlich interessiert.
