Vibecoding und Sicherheit: Was Führungskräfte wissen müssen, wenn Teams mit KI bauen
KI-Wissenslücke: Führungskräfte stehen vor Herausforderungen, wenn Teammitglieder ihnen bei KI-Tools und -Fähigkeiten voraus sind.
Vibecoding erklärt: Nicht-technische Mitarbeitende erstellen funktionale Tools durch gezieltes Prompten und überbrücken so die Lücke zwischen Idee und Umsetzung.
Sicherheitsbedenken: Unverwaltete Vibecoding-Tools bergen Risiken bei der Datenverarbeitung und -offenlegung, insbesondere im Hinblick auf personenbezogene Daten (PII).
Kostenaspekte: Nicht optimierte Nutzung von KI-Tools kann zu unerwarteten Ausgaben und finanziellen Risiken führen.
Skalierbarkeitsprobleme: Erfolgreiche Vibecoding-Tools benötigen professionelle Begleitung, um Skalierbarkeit und Zuverlässigkeit zu gewährleisten.
Seien wir ehrlich: Wir alle stehen an unterschiedlichen Punkten, wenn es um KI geht. Und für Führungskräfte kann das beunruhigend sein – mehr denn je überholen Mitarbeitende ihre Manager hinsichtlich KI-Kenntnissen und -Befähigung, bewegen sich schnell und machen dabei oft Fehler.
Während viele Organisationen die offene Erkundung von KI-Tools fördern, ist Vibecoding – die nächste Phase der KI-Befähigung für viele nicht-technische Mitarbeitende – ein Abenteuer, das je nach dem, was gebaut wird, für wen es gebaut wird und welche Daten gespeichert und verwendet werden, mit unterschiedlich hohem Risiko verbunden ist.
Dies wird vor allem in Projektmanagement- und Operationsteams immer häufiger, wo der Bau eigener Tools häufig die offensichtliche Antwort auf Prozessanforderungen ist – und mit KI-Coding-Agenten war es nie einfacher, Projekte zu genehmigen.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Um zu verstehen, worauf man achten sollte, wenn Teams anfangen zu bauen, habe ich Tim Fisher, DPMs Vizepräsident für KI, hinzugezogen, um uns einen Überblick zu geben. Dieser Artikel richtet sich an alle, die schon einmal die Nachricht „Hey Chef, schau dir mal an, was ich mit Claude gebaut habe!“ bekommen haben – wir hoffen, er hilft weiter.
Erstens: Was ist Vibecoding? Und warum ist es wirklich wertvoll?
Für die Zwecke dieses Artikels bedeutet Vibecoding Programmieren per Prompting – und zwar explizit von nicht-technischen Personen. Das unterscheidet sich von einem Softwareentwickler, der ein Tool wie GitHub Copilot verwendet, bei dem der Mensch immer noch erhebliches technisches Wissen einbringt. Es geht um den CFO, die Operations-Koordinatorin, den Projektmanager, der noch nie eine Zeile Code geschrieben hat und nun mit reinen Spracheingaben funktionale Tools erstellt.
Und Fishers erste Einschätzung könnte überraschen: Er ist davon ehrlich begeistert. „Ich liebe die Vorstellung, dass Menschen, die nicht programmieren können, jetzt eine Möglichkeit haben, das, was sie im Kopf haben, in eine Form zu bringen, die jeder sehen, ausprobieren und nutzen kann“, sagt er. „Es ist eine Kommunikationsart, die es vorher nicht gab.“ Er betrachtet es weniger als technische Fähigkeit und mehr als völlig neues Kommunikationsmedium – eines, das die Lücke zwischen Vision und Umsetzung für diejenigen schließt, die schon immer Ideen hatten, aber nie das technische Vokabular besaßen, um sie auszudrücken.
Vibecoding ist eine Kommunikationsform, die es vorher nicht gab.
„Es ist ein wenig wie die Herausforderungen, die Menschen erleben, wenn sie mit Designteams zusammenarbeiten“, erklärt Fisher. „Ich kann keinen Strichmännchen zeichnen. Und wenn ich jemandem etwas Visuelles vermitteln möchte, bin ich umso glücklicher, dass es jetzt Werkzeuge gibt, mit denen ich etwas in vielen durchdachten Worten erklären kann – was ich gut kann – und am Ende kommt etwas raus, wobei jemand, der sich mit Design auskennt, direkt versteht: ‚Ah, ich weiß, worauf du hinauswillst.‘“
Für Führungskräfte ist diese neue Sichtweise entscheidend. Der Impuls, das Ganze von vornherein zu verbieten, verkennt das wirklich Wertvolle daran: Vibecoding kann die Abstimmung beschleunigen, Ideen schneller sichtbar machen und nicht-technischen Teammitgliedern eine neue Möglichkeit geben, beizutragen. Die Frage ist nicht, ob man es zulassen sollte. Die Frage ist, ob man versteht, was passiert, nachdem das Tool gebaut wurde.
Wo der Wert endet – und das Risiko beginnt
Fisher trennt sorgfältig die „Kommunikationsphase“ des Vibecodings von dem, was danach folgt – und hier ändert sich sein Ton. „Ich glaube, der Nutzen endet meistens genau dort“, sagt er. „Es ist ein viel besserer Weg, um Ideen und Richtungen zu kommunizieren. Aber wir stellen fest, dass danach Dinge passieren können, die über das hinausgehen, was mit ‚Hey, schau, ich habe eine Idee kommuniziert, wir teilen jetzt eine Sprache‘ beginnt. Und genau dann wird es beängstigend.“
Das Problem ist nicht das Prompten. Es ist die Umsetzung. Es ist der Moment, in dem aus einem Prototyp ein Werkzeug wird, das reale Menschen benutzen, in dem echte Daten gespeichert werden, das auf echter Infrastruktur im Hintergrund läuft – und die Person, die es gebaut hat, weiß immer noch nicht, was unter der Haube passiert.
Die Sicherheitslücken, die Führungskräfte kennen sollten
Personenbezogene Daten (PII) und Datenverarbeitung
Das naheliegendste Risiko für die meisten Führungskräfte wird im Bereich personenbezogener Daten (PII) liegen. Fisher veranschaulicht anschaulich, wo die Grenze verläuft: „Ich denke, die Komplexitätsgrenze wäre dort, wo Mitarbeiter- oder Kundendaten in ein System eingespielt werden, das diese Daten an andere weitergibt. Dann stößt man auf PII-Probleme.“
Ich denke, die Grenze der Komplexität liegt genau vor der Erfassung von Mitarbeiter- oder Kundendaten in ein System, das diese Daten an andere Personen weitergibt.
Das Risiko steigt mit der Sensibilität der Daten und dem Personenkreis, der darauf zugreifen kann – und in Operations- sowie Projektmanagement-Teams umfassen diese Daten oft Kundeninformationen, Mitarbeiterdaten, Vergütungsdaten oder Kontaktdetails, die echte rechtliche Risiken mit sich bringen.
Unkontrollierte Kosten und Token-Nutzung
Ein Risiko, das viele Führungskräfte überrascht, hat nichts mit Daten, sondern alles mit finanziellen Aspekten zu tun. Fisher beschreibt ein Szenario, das häufiger vorkommt, als die meisten glauben: "Nehmen wir an, jemand gibt einem Agenten-Coder versehentlich eine falsche Anweisung, was dazu führt, dass dieser in eine Endlosschleife gerät und ständig hohe Gebühren verursacht. Und ehe man sich versieht, kostet ein Projekt, das eigentlich 5.000 $ kosten sollte, plötzlich 50.000 $, weil man nicht wusste, was im Hintergrund passiert, und angenommen hat, der agentische Coder würde das erkennen."
Nicht-technische Ersteller optimieren zudem seltener die Token-Nutzung, sodass Kosten still und schnell anwachsen können. Ohne Einblick in die Infrastruktur, auf der ihre Tools laufen, merken Teammitglieder womöglich erst, dass es ein Problem gibt, wenn die Rechnung ins Haus flattert.
API-Schlüssel und Informationssicherheit
Hier betritt Fisher das Terrain, das Sicherheitsteams nachts wach hält. Das von ihm beschriebene Szenario ist ein Paradebeispiel dafür, was passiert, wenn jemand gerade genug weiß, um gefährlich zu sein: "Ein häufiger Fehler ist, wenn jemand gerade so viel weiß, dass er sagen kann, er brauche einen API-Key, damit etwas funktioniert. Er gibt den Schlüssel in einer Eingabeaufforderung an, dieser wird aber nicht an einem geheimen Ort abgelegt – sondern einfach in eine Datei geschrieben oder direkt ins Skript eingefügt. Dann stellt jemand den Code auf GitHub, vergisst vielleicht, ihn privat zu machen, und jetzt kann dieser API-Schlüssel von jedem missbraucht werden, der bereit ist, etwas Böswilliges zu tun, etwa eine Token-Rechnung von 100.000 $ zu verursachen."
Es erscheint leicht zu glauben, dass für solch ein Szenario eine lange Fehlerkette nötig wäre. Fisher widerspricht diesem Instinkt: "Es klingt, als ob eine lange Kette unwahrscheinlicher Ereignisse nötig wäre – aber das stimmt überhaupt nicht. Es ist tatsächlich ausgesprochen häufig, gerade bei nicht-technischen Leuten."
Das vielleicht alarmierendste Risiko, das Fisher anspricht, ist eines, in das sogar erfahrene Entwickler schon getappt sind. "Ich habe Horrorgeschichten darüber gehört, wie erfahrene Entwickler den kompletten Code der Firma in einen Agenten-Coder laden, etwas daran verändern und dann der gesamte Code im Rahmen des Gesetzes an eine andere Firma weitergegeben wird." Wenn schon versierte Entwickler diesen Fehler machen können, ist das Risiko für einen nicht-technischen Mitarbeitenden, der ohne Aufsicht schnell etwas baut, um einiges höher.
Das Skalierungsproblem — Was passiert, wenn es tatsächlich funktioniert?
Eines der schwierigeren Gespräche für Führungskräfte dreht sich darum, was zu tun ist, wenn ein vibecodiertes Tool tatsächlich ein Problem löst und sich die Nutzer darauf verlassen. Dann kann aus dem Erfolg schnell ein Risiko werden. Fisher benennt das strukturelle Problem klar: "Allgemein sind vibrational-codierte Projekte grundsätzlich nicht skalierbar – vor allem, weil man den Agenten gar nicht zu Skalierung auffordert. Nicht-Entwickler fragen vermutlich auch nicht nach so etwas wie Fehlerbehandlung. Wer die Orte, an denen Fehler auftreten können, nicht kennt, weiß auch nicht, was man tun muss, damit der Agent diese erkennt und entsprechend verarbeitet."
Allgemein gesagt sind alle Vibe-Code-Projekte nicht skalierbar, hauptsächlich weil Sie den Agenten nicht bitten, die Skalierung zu berücksichtigen.
Die Verantwortungslücke wird unter Druck am sichtbarsten. „Was typischerweise passiert ist, dass jemand etwas per Vibe-Code erstellt, und dann funktioniert es, aber ist diese Person dann rund um die Uhr technischer Support für dieses Produkt?“ Für Verantwortliche in Delivery und Betrieb ist das der Moment, in dem ein gut gemeintes Intern-Tool zum organisatorischen Risiko wird – denn je mehr Teams darauf angewiesen sind, desto wahrscheinlicher ist es, dass es ausfällt oder ständigen technischen Support benötigt.
Fishers Empfehlung für Tools, die Anklang finden, ist eine saubere Übergabe: „Wenn Sie etwas bauen, auf das sich Leute verlassen, muss es mehr werden als nur ein Vibe-Coded-Projekt; es muss von Menschen übernommen werden, die das professionell machen und Dinge wissen, von denen Sie nicht einmal wissen, dass Sie sie fragen sollten.“
Was Führungskräfte tun können – Praktische Leitplanken
All das bedeutet nicht, dass ein generelles Verbot die Antwort ist. Fisher bleibt in diesem Punkt konsistent – der Wert von Vibe-Coding für Nicht-Techniker ist real, aber er hat seinen speziellen Platz. „Der Wert dieser Tools für Nicht-Programmierer besteht darin, Dinge wie die Ausrichtung auf eine Idee abzukürzen und die ‚Wird das funktionieren?‘-Phase zu überwinden“, sagt er. Die Prototypenphase, die Kommunikationsphase, die Phase „Lohnt es sich überhaupt, das zu bauen?“ – da glänzt das Vibe-Coding und das Risiko bleibt überschaubar.
Für Führungskräfte sieht das praktische Vorgehen in etwa so aus: Ermutigen Sie Vibe-Coding als Prototyp- und Kommunikationstool und legen Sie eine klare Schwelle fest, ab der ein Tool von jemandem mit technischer Expertise geprüft wird, bevor es breiter eingesetzt wird. Solche Gespräche mit dem Team zu führen – damit sie die Risiken verstehen und ihre Optionen kennen – unterscheidet eine Kultur kluger KI-Experimentierfreude von einer, die einfach nur schnell vorankommen und hoffen will, dass alles gut geht.
Ziel ist es nicht, die Führungskraft zu sein, die Nein sagt. Ziel ist es, dafür zu sorgen, dass das Team weiß, worauf es sich einlässt – damit, wenn jemand tatsächlich etwas Großartiges baut, daraus auch wirklich etwas werden kann.
Möchten Sie mehr Einblicke wie diese? Melden Sie sich für ein kostenloses DPM-Konto an, um von noch mehr Experten wie diesen zu hören.