Vibecoding und Sicherheit: Was Führungskräfte über Teams mit KI wissen müssen
KI-Wissensgefälle: Führungskräfte stehen vor Herausforderungen, wenn Teammitglieder ihnen bei KI-Tools und deren Fähigkeiten voraus sind.
Vibecoding erklärt: Nicht-technische Mitarbeitende erstellen durch Prompting funktionale Tools und überbrücken so die Lücke zwischen Idee und Umsetzung.
Sicherheitsbedenken: Unkontrollierte Vibecoding-Tools bergen Risiken im Umgang mit Daten und können insbesondere eine Gefahr für personenbezogene Daten darstellen.
Kostenfolgen: Nicht optimierter Einsatz von KI-Tools kann zu unerwarteten Kosten und finanziellen Risiken führen.
Skalierungsprobleme: Erfolgreiche vibecodierte Tools erfordern professionelle Betreuung, um Skalierbarkeit und Zuverlässigkeit sicherzustellen.
Seien wir ehrlich: Wir alle befinden uns an unterschiedlichen Punkten, wenn es um KI geht. Und für Führungskräfte kann das beunruhigend sein – mehr denn je überholen Mitarbeitende ihre Vorgesetzten in Sachen KI-Wissen und Umsetzung, 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 Mitarbeitende ohne technischen Hintergrund – ein Abenteuer mit unterschiedlich hohem Risiko, je nachdem, was gebaut wird, für wen es gebaut wird und welche Daten gespeichert und verwendet werden.
Dies wird besonders bei Projektmanagement- und Operationsteams immer häufiger, wo der Bau proprietärer Tools oft die naheliegende Antwort auf Prozessanforderungen ist – und mit KI-Coding-Agenten, war es noch nie einfacher, grünes Licht zu geben.
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 uns zu helfen zu verstehen, worauf man achten sollte, wenn Teams mit dem Bauen beginnen, habe ich Tim Fisher, den VP of AI von DPM, eingeladen, uns einen Überblick zu geben. Dieser Artikel ist für alle, die jemals die Nachricht bekommen haben: „Hey Chef, schau mal, was ich mit Claude gebaut habe!“ – wir hoffen, er hilft weiter.
Erstens: Was ist Vibecoding? Und warum ist es überhaupt wertvoll?
Für diesen Artikel bedeutet Vibecoding, durch Prompting zu programmieren – speziell von Personen ohne technische Vorkenntnisse. Das unterscheidet sich deutlich von einem Softwareentwickler, der ein Tool wie GitHub Copilot nutzt, bei dem der Mensch weiterhin nennenswertes technisches Wissen einbringt. Hier geht es um den CFO, die Operations-Koordinatorin, den Projektmanager, der noch nie eine Codezeile geschrieben hat und jetzt funktionale Tools nur mit Spracheingaben erstellt.
Und Fishers erste Einschätzung könnte überraschen: Er ist wirklich begeistert davon. „Ich liebe die Vorstellung, dass Menschen, die nicht programmieren können, jetzt die Möglichkeit haben, das, was sie im Kopf haben, in eine Form zu bringen, die alle sehen, ausprobieren und nutzen können“, sagt er. „Es ist eine neue Art der Kommunikation, die es bisher nicht gab.“ Er sieht es weniger als technische Fähigkeit und vielmehr als neues Kommunikationsmedium – eines, das die Lücke zwischen Vision und Umsetzung für Menschen schließt, die immer Ideen hatten, denen aber das technische Vokabular fehlte, um sie auszudrücken.
Vibecoding ist eine Art der Kommunikation, die es bisher nicht gab.
„Es ist ein bisschen wie die Herausforderungen, die manche Menschen im Umgang mit Design-Teams erleben“, erklärt Fisher. „Ich kann nicht einmal ein Strichmännchen zeichnen. Wenn ich also jemandem etwas Visuelles vermitteln möchte, bin ich extrem dankbar, dass es jetzt Tools gibt, mit denen ich etwas in viele wohlüberlegte Worte fassen kann – darin bin ich gut – und am Ende kommt dann etwas heraus, das jemand, der sich mit Design auskennt, anschaut und sofort versteht: ‚Ah, jetzt weiß ich, was du meinst.‘“
Für Führungskräfte ist diese neue Sichtweise entscheidend. Der Impuls, das Ganze sofort abzubrechen, verkennt, was hier wirklich nützlich ist: Vibecoding kann Abstimmungen beschleunigen, Ideen schneller sichtbar machen und nicht-technischen Teammitgliedern eine neue Art der Beteiligung bieten. Die Frage ist nicht, ob man es erlaubt. Die Frage ist, ob man versteht, was passiert, wenn das Tool gebaut wurde.
Wo der Wert endet – und das Risiko beginnt
Fisher unterscheidet ausdrücklich die „Kommunikations“-Phase des Vibecoding von dem, was häufig darauf folgt – und genau da ändert sich auch sein Tonfall: „Ich denke, der Wert der Methode hört meistens genau dort auf“, sagt er. „Es ist ein viel besserer Weg, um Ideen und Richtung zu vermitteln. Aber was wir sehen, ist, dass danach manchmal Dinge passieren, die über ein einfaches ‚Schau mal, ich habe dir eine Idee vermittelt, wir sprechen jetzt dieselbe Sprache‘ hinausgehen. Und genau das ist der Punkt, an dem es beängstigend wird.“
Das Problem ist nicht das Prompten. Es ist das Ausrollen. Es ist der Moment, in dem aus einem Prototyp ein echtes Tool wird, das von echten Menschen genutzt wird, das echte Daten speichert, das auf echter Infrastruktur läuft – und die Person, die es gebaut hat, weiß trotzdem nicht, was unter der Oberfläche passiert.
Die Sicherheitslücken, die Führungskräfte kennen sollten
PII und Datenverarbeitung
Das offensichtlichste Risiko für die meisten Führungskräfte betrifft personenbezogene Daten (PII). Fisher nutzt ein konkretes Beispiel, um zu verdeutlichen, wo die Grenze liegt: „Ich denke, die Komplexitätsgrenze verläuft genau dort, bevor Mitarbeiter- oder Kundendaten in ein System eingespeist werden, das diese Daten dann an andere Personen ausgibt. Ab dann hat man es auch mit PII-Problemen zu tun.“
Ich denke, die Komplexitätsgrenze liegt unmittelbar vor der Aufnahme von Mitarbeiter- oder Kundendaten in ein System, das diese Daten an andere weitergibt.
Das Risiko steigt mit der Sensibilität der Daten und dem Personenkreis, der darauf zugreifen kann – und in Operations- sowie Projektmanagement-Teams beinhalten diese Daten oft Kundeninformationen, Mitarbeiterakten, Gehaltsdaten oder Kontaktdetails, die echte rechtliche Risiken bergen.
Unkontrollierte Kosten und Token-Nutzung
Ein Risiko, das viele Führungskräfte überrascht, hat wenig mit Daten, sondern alles mit Geld zu tun. Fisher beschreibt ein Szenario, das häufiger vorkommt, als viele annehmen: "Stellen Sie sich vor, jemand gibt einem Agenten-Coder versehentlich eine falsche Anweisung, was dazu führt, dass er eine Endlosschleife erstellt, die dauerhaft läuft 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 hinter den Kulissen passiert, und davon ausgegangen ist, dass der agentische Coder das schon erkennt."
Nicht-technische Entwickler optimieren in der Regel auch seltener auf den Token-Verbrauch, was bedeutet, dass sich die Kosten leise und schnell summieren können. Ohne Einblick in die Infrastruktur, auf der ihre Tools laufen, merken Ihre Teammitglieder möglicherweise erst dann, dass es ein Problem gibt, wenn die Rechnung eintrifft.
API-Schlüssel und Informationssicherheit
Hier kommt Fisher zu dem Bereich, der Sicherheitsteams nachts wachhält. Das von ihm beschriebene Szenario ist ein Paradebeispiel dafür, was schiefgehen kann, wenn jemand gerade genug weiß, um gefährlich zu sein: "Ein häufiger Fehler ist, wenn jemand gerade so viel weiß, dass er erkennt und artikuliert, dass ein API-Schlüssel benötigt wird, um etwas umzusetzen. Dieser Schlüssel wird dann in einem Prompt angegeben, aber nicht an einem sicheren Ort gespeichert – stattdessen landet er in einer Datei oder wird direkt in das Skript geschrieben. Dann veröffentlicht jemand den Code auf GitHub, vergisst vielleicht, das Repository privat zu machen, und nun kann jeder, der Böses im Schilde führt, diesen API-Schlüssel missbrauchen und zum Beispiel eine $100K-Token-Rechnung verursachen.”a0
Es ist leicht, dieses Szenario zu lesen und zu denken, dass dafür eine lange Kette an Fehlern nötig wäre. Fisher widerspricht diesem Instinkt: "Es hört sich so an, als müsste eine ganze Reihe unwahrscheinlicher Dinge eintreten, aber tatsächlich ist es überhaupt nicht unwahrscheinlich. Es passiert außergewöhnlich häufig, besonders bei nicht-technischen Personen.”
Vielleicht ist das alarmierendste Risiko, das Fisher anspricht, eines, in das selbst erfahrene Entwickler schon geraten sind. "Ich habe schon Horrorgeschichten darüber gehört, dass erfahrene Entwickler den gesamten Codebestand eines Unternehmens in einen Agenten-Coder importiert und etwas daran geändert haben – und dann wurde der gesamte Codebestand völlig legal von einem anderen Unternehmen übernommen." Wenn selbst erfahrene Entwickler diesen Fehler machen können, ist das Risikoprofil bei nicht-technischen Mitarbeitenden, die schnell und ohne Aufsicht etwas bauen, deutlich höher.
Das Skalierungsproblem — Was passiert, wenn es wirklich funktioniert?
Eines der schwierigsten Gespräche für Führungskräfte ist die Frage, was zu tun ist, wenn ein vibecodiertes Tool tatsächlich ein Problem löst und Leute sich darauf verlassen. Der Erfolgsfall kann leise zum Risiko werden. Fisher benennt das strukturelle Problem klar: "Allgemein gesprochen sind alle vibecodierten Projekte nicht skalierbar, hauptsächlich deshalb, weil Sie den Agenten nicht dazu bringen, über Skalierung nachzudenken. Nicht-Entwickler fragen wahrscheinlich nicht einmal nach Dingen wie Fehlerbehandlung. Wenn man die Stellen, an denen Fehler auftreten, nicht kennt, weiß man auch nicht, wie man sicherstellt, dass der Agent diese erkennt und entsprechend damit umgeht."
Allgemein gesagt sind alle vibe-codierten Projekte nicht skalierbar, hauptsächlich weil Sie den Agenten nicht bitten, die Skalierung zu berücksichtigen.
Die Verantwortlichkeitslücke wird besonders unter Druck sichtbar. "Was meistens passiert, ist, dass jemand etwas vibe-codet, dann funktioniert es, aber ist diese Person jetzt rund um die Uhr der Tech-Support für dieses Produkt?" Für Leitende im Bereich Lieferung und Betrieb ist dies der Moment, in dem ein wohlmeinendes internes Tool zum Risiko für das Unternehmen wird — denn je mehr Teams sich darauf verlassen, desto wahrscheinlicher ist es, dass es ausfällt oder ständige technische Unterstützung benötigt.
Fishers Empfehlung für Tools, die an Fahrt aufnehmen, ist eine saubere Übergabe: "Wenn Sie etwas bauen, auf das sich Leute verlassen, dann muss es mehr werden als nur ein vibe-codiertes Projekt; es muss von Leuten übernommen werden, die das professionell machen und Dinge wissen, von denen Sie gar nicht wissen, dass man sie fragen sollte."
Was Führungskräfte tun können — Praktische Leitplanken
Das heißt nicht, dass die Lösung ein generelles Verbot ist. Fisher bleibt in diesem Punkt konsequent – der Wert von Vibe-Coding für Nicht-Techniker ist real, aber er bewegt sich in einem bestimmten Rahmen. "Der Wert dieser Tools für Nicht-Programmierer besteht darin, Dinge wie die Abstimmung zu einer Idee abzukürzen und die Frage 'wird das funktionieren?' schnell zu klären", sagt er. Die Prototypenphase, die Kommunikationsphase, die "Ist das überhaupt sinnvoll zu bauen?"-Phase — genau dort glänzt Vibe-Coding und das Risiko bleibt überschaubar.
Für Führungskräfte sieht das praktische Vorgehen etwa so aus: Ermutigen Sie Vibe-Coding als Prototyping- und Kommunikationswerkzeug, und legen Sie eine klare Schwelle fest, ab der ein Tool von jemandem mit technischer Expertise überprüft wird, bevor es in den breiteren Einsatz gelangt. Diese Gespräche mit dem Team zu führen – damit sie die Risiken verstehen und ihre Möglichkeiten kennen – ist der Unterschied zwischen einer Kultur kluger KI-Erforschung und einer, die einfach schnell handelt und das Beste hofft.
Das Ziel ist nicht, die Führungskraft zu sein, die immer Nein sagt. Sondern die, die dafür sorgt, dass das Team weiß, worauf es sich einlässt – damit etwas Großartiges auch wirklich umgesetzt werden kann.
Möchten Sie mehr Einblicke wie diese? Melden Sie sich für ein kostenloses DPM-Konto an, um weitere Expertenmeinungen wie diese zu erhalten.