Manchmal passiert die interessanteste Diskussion über generative KI nicht auf einer Konferenz oder in einem LinkedIn-Thread. Manchmal passiert sie auf dem Handy, kurz nach sieben Uhr morgens, wenn der Sohn auf dem Weg zur Fachhochschule ist.
Mein Sohn studiert Web & Mobile-Development an der FH Salzburg in Puch-Urstein. Er schickte mir heute Früh per WhatsApp einen Link. Ein Stelleninserat eines großen deutschen Automobilkonzerns. Ausgeschrieben über die Tech-Innovation-Tochter des Unternehmens. Titel: Praktikant/Werkstudent Vibe Coding for AI Security.
Seine erste Botschaft dazu war knapp und auf den Punkt: „Das Prinzip ist nicht schlecht. Aber Vibe Coding auf Produktionsebene, vor allem in so einem großen Unternehmen, ist einfach unsinnig und teilweise sogar gefährlich.“
Ich habe widersprochen. Nicht weil ich überzeugt war, sondern weil ich wissen wollte, wie weit sein Argument trägt. Was folgte, war eine kurze, aber dichte Diskussion, die mich den Rest des Morgens beschäftigt hat. Und ich finde, sie verdient mehr als einen WhatsApp-Thread.
Was das Inserat konkret verlangt
Ich habe das Inserat selbst gelesen. Und ich muss sagen: Es ist sorgfältiger formuliert, als man auf den ersten Blick annehmen könnte.
Die Aufgaben lesen sich so: Der Praktikant soll schnelle Software-Prototypen und interne Tools mit modernen AI-Coding-Technologien entwickeln. Konkret genannt werden GitHub Copilot und Claude Code. Er soll neue Tools und Frameworks im Bereich AI-gestützter Softwareentwicklung recherchieren, testen und bewerten. Er soll SKILL.md- und ARCHITECTURE.md-Dateien erstellen und pflegen, um KI-Agenten gezielt mit Kontext zu versorgen. Und er soll Teil eines Teams sein, das sich mit AI Red Teaming, AI Governance und der Absicherung von KI-Systemen beschäftigt.
Das klingt nach echter Arbeit. Nicht nach Kaffeekochen.
Die Anforderungen sind ebenso klar: Studium in Informatik, Software Engineering oder Data Science. Fundierte Programmierkenntnisse in Python, TypeScript oder JavaScript. Sicherer Umgang mit Git und GitHub. Und: aktive Nutzung von AI-Coding-Assistenten, „sei es im Studium, in Nebenprojekten oder einfach aus Begeisterung.“
Soweit, so vernünftig. Aber dann ist da eben dieser Begriff. Vibe Coding. Im Titel, fettgedruckt, als zentrales Positionierungsmerkmal der Stelle.
Warum dieser Begriff im Kontext AI Security das Problem ist
Mein Sohn hat das Inserat gelesen. Seine Reaktion war nicht nur die eines Studenten, der einen Trend ablehnt. Sie war die eines angehenden Entwicklers, der versteht, was der Begriff impliziert.
„Das Prinzip ist nicht schlecht. Aber Vibe Coding auf Produktionsebene, vor allem in so einem großen Unternehmen, ist einfach unsinnig und teilweise sogar gefährlich. Und auch wenn der Praktikant nur interne Prototypen entwickeln soll, vermittelt das für mich das falsche Bild, nämlich dass man mit Vibe Coding bis zum Mond kommen kann.“
Das ist präzise formuliert. Und ich finde es bemerkenswert, dass ein Student im laufenden Studium diese Unterscheidung bereits so sauber zieht.
Kurz zur Einordnung: Vibe Coding ist das Programmieren durch natürlichsprachliche Beschreibungen an ein KI-Modell. Der Begriff wurde Anfang 2025 von Andrej Karpathy geprägt. Er meinte damit ursprünglich eine entspannte, explorative Art zu entwickeln, bei der man den Output der KI nimmt, ohne ihn im Detail zu verstehen oder zu hinterfragen. Der Name ist Programm: nicht analytisch, sondern intuitiv. Nicht kontrolliert, sondern fließend. Vertrau dem Vibe.
Das klingt nach einer guten Beschreibung für einen Freitagabend-Hack. Es klingt nicht nach einer guten Beschreibung für die Arbeit in einem Team, das sich mit AI Red Teaming und der Absicherung von KI-Systemen beschäftigt.
Der Kern des Problems: Security-Code vergibt keine zweiten Chancen
Lass mich das konkret machen.
Security-Code hat eine Eigenschaft, die ihn von den meisten anderen Entwicklungsbereichen unterscheidet: Fehler dort sind keine Bugs im üblichen Sinne. Sie sind Einfallstore. Eine unsauber implementierte Input-Validierung, ein übersehener Race Condition in einem Access-Control-Mechanismus, eine falsch konfigurierte Session-Verwaltung: all das kann in produktionsnahen Systemen Konsequenzen haben, die weit über einen Absturz hinausgehen.
KI-Modelle generieren Code, der syntaktisch korrekt ist und auf den ersten Blick das tut, was er soll. Aber sie denken nicht in Angreiferlogik. Sie kennen die konkrete Systemarchitektur nicht. Sie wissen nichts über die interne Infrastruktur des Unternehmens, über die spezifischen Schnittstellen, über bestehende Schwachstellen in angrenzenden Systemen. Und sie kennen keine Zero-Day-Vulnerabilities, die noch nicht in ihren Trainingsdaten auftauchen.
Ein erfahrener Security-Entwickler bringt genau dieses kontextuelle Wissen mit. Dieses Wissen, das weit über „der Code kompiliert und die Tests sind grün“ hinausgeht.
Mein Gegenargument war das Naheliegende: Was der Praktikant produziert, wird mit Sicherheit von einem professionellen Entwickler geprüft. Das ist doch der Workflow. KI generiert, Mensch reviewt, Mensch entscheidet.
Seine Antwort: „Bestimmt. Aber dann kann man es auch gleich ordentlich von einem Profi machen lassen.“
Das saß.
Das Paradox im Anforderungsprofil
Hier ist der Teil, den ich besonders interessant finde.
Das Inserat verlangt ein Studium in Informatik, Software Engineering oder Data Science. Das ist eine vernünftige Anforderung. Aber genau in diesen Studiengängen wird, nach Einschätzung meines Sohnes in etwa 95 Prozent der Lehrzeit, vermittelt, dass KI-gestütztes Coden ohne eigenes Verständnis eben keine solide Basis für professionelle Softwareentwicklung ist. Dass man KI als Werkzeug begreift, nicht als Ersatz für das eigene Urteilsvermögen. Dass man Code, den man deployt, verstehen muss.
Mit anderen Worten: Der Konzern sucht jemanden, dem in seiner Ausbildung beigebracht wird, dass er genau das, wofür er hier gesucht wird, nicht einfach so tun sollte.
Das ist kein Zufall. Das ist ein konzeptueller Widerspruch im Anforderungsprofil.
Ich sage das nicht, um das Unternehmen vorzuführen. Solche Mismatch-Situationen entstehen, wenn Begriffe aus der Tech-Presse in HR-Prozesse übernommen werden, ohne sie mit den technischen Teams oder dem Ausbildungskontext der Zielgruppe abzugleichen. „Vibe Coding“ klingt zugänglich, modern, kosteneffizient. Es klingt nach einem Begriff, mit dem man ein Inserat schreibt, das Aufmerksamkeit bekommt. Und das hat funktioniert: Es hat Diskussionen ausgelöst, und ich schreibe jetzt gerade darüber.
Aber Aufmerksamkeit ist nicht dasselbe wie Sinnhaftigkeit.
Eine kleine Ironie am Rande
Das Inserat erwähnt konkret, dass der Praktikant SKILL.md-Dateien erstellen und pflegen soll, um KI-Agenten gezielt mit Kontext zu versorgen.
Ich musste kurz schmunzeln. Denn ich arbeite selbst täglich mit solchen Dateien. In meinem eigenen Workflow habe ich Skills für Claude strukturiert, exakt nach diesem Muster: strukturierte Kontextdateien, die dem KI-Agenten beschreiben, wie er mit bestimmten Aufgaben umgehen soll. Das ist kein Vibe Coding. Das ist das Gegenteil davon. Das ist bewusste, strukturierte Steuerung eines KI-Systems durch klare Instruktionen, Konventionen und nachvollziehbare Architekturentscheidungen.
Die Stelle verlangt also einerseits „Vibe Coding“ im Titel, und andererseits genau die strukturierte, dokumentierte, nachvollziehbare Arbeitsweise, die Vibe Coding per Definition nicht ist.
Das ist kein kleiner Widerspruch. Das ist der Widerspruch.
Wo KI-gestütztes Entwickeln tatsächlich Sinn macht
Ich will fair sein, und ich will nicht den Eindruck erwecken, dass KI als Entwicklungswerkzeug das Problem ist. Das wäre falsch, und das ist nicht meine Position.
Ich selbst entwickle mit KI-Unterstützung täglich: Elementor-Widgets, WordPress-Plugins, n8n-Automatisierungsworkflows. Das geht. Das funktioniert. Claude Code ist ein ernstzunehmendes Werkzeug, und ich halte es für eines der nützlichsten, das mir in den letzten Jahren begegnet ist.
Aber ich weiß, was ich dabei tue. Ich kann den Output lesen. Ich bin in der Lage zu beurteilen, ob das, was die KI produziert hat, das tut, was es soll, und nichts anderes. Ich prüfe, ich hinterfrage, ich deploye nichts, das ich nicht grob nachvollziehen kann.
Das ist kein Vibe Coding im Sinne Karpathys. Das ist augmentiertes Entwickeln: ein Werkzeug intelligent einsetzen, ohne das eigene Urteilsvermögen abzugeben.
Es gibt Kontexte, in denen diese entspannte Herangehensweise durchaus funktioniert. Prototypen für interne Tools ohne Produktivbetrieb: ja. Kleine Automatisierungsskripte, die ein Entwickler mit Grundkenntnissen reviewen kann: ja. UI-Komponenten und statische Website-Elemente in kontrollierten Umgebungen: ja.
AI Security in einem Großkonzern: nein.
Das falsche Bild und seine Langzeitwirkung
Hier ist, was mich am meisten beschäftigt. Mein Sohn hat es mit dem Ausdruck „das falsche Bild“ sehr gut benannt.
Wenn ein Konzern Vibe Coding als zentrales Jobprofil ausschreibt, und das in einem Bereich wie AI Security, sendet er eine Botschaft: Das reicht. Das ist der Standard, den wir anlegen. Ein Student, der KI-Outputs produziert, ist Lösung genug für Fragen rund um die Absicherung von KI-Systemen.
Für Berufseinsteiger, die gerade herausfinden, was der Markt von ihnen erwartet, ist das eine gefährliche Orientierung. Nicht weil KI-Kenntnisse unwichtig wären. Im Gegenteil: Sie sind wichtig, sie werden immer wichtiger, und wer als Entwickler heute kein KI-Tooling einsetzt, verschenkt echte Effizienz und echte Qualität.
Aber es gibt einen erheblichen Unterschied zwischen „KI als Werkzeug beherrschen“ und „KI für mich coden lassen, ohne zu verstehen, was dabei herauskommt.“
Der erste Weg führt zu besseren Entwicklern. Der zweite Weg kann im falschen Kontext dazu führen, dass jemand glaubt, Entwicklung zu betreiben, und dabei blind durch Code navigiert, den er nicht lesen kann.
In einem Bereich wie AI Security ist das kein Risiko, das man in Kauf nehmen sollte. Es ist ein strukturelles Problem.
Was die Fachhochschule das lehrt und warum das richtig ist
Mein Sohn erzählt mir regelmäßig, was an der FH in Puch-Urstein im Unterricht passiert. Und ich höre gerne zu. Grundlagen werden ernst genommen. Algorithmen werden verstanden, nicht nur benutzt. Debugging ist Pflichtprogramm. Und KI-Tools werden thematisiert, aber eingebettet in eine Haltung: Du musst verstehen, was du tust, auch wenn dir ein Werkzeug dabei hilft.
Das ist die richtige Einstellung. Nicht reaktionär, nicht KI-feindlich, sondern realistisch.
Denn was kommt nach dem Studium? Produktionssysteme, echte Nutzerdaten, echte Angriffsflächen und echte Konsequenzen, wenn etwas schiefgeht. Dort entscheidet nicht der Prompt, den man ins Chatfeld tippt. Dort entscheidet das Verständnis, das man sich aufgebaut hat.
Und genau deshalb ist das Inserat so ein interessantes Dokument. Nicht weil dahinter schlechte Absichten stünden. Das glaube ich nicht. Das Team, das dort beschrieben wird, klingt nach einem, das ernsthaft an relevanten Themen arbeitet. Aber der Begriff im Titel sendet ein Signal, das nicht zu dem passt, was die Stelle tatsächlich verlangt, und schon gar nicht zu dem, was im Security-Umfeld verantwortungsvolles Arbeiten bedeutet.
Was dieser Morgenchat mir mitgegeben hat
Ich bin seit 1989 in der Kommunikationsbranche. Ich habe Technologiewellen kommen und gehen sehen. Desktop Publishing hat nicht jeden Grafiker ersetzt, aber es hat die Berufsbilder verändert. Das Internet hat nicht jeden Verleger ruiniert, aber es hat die Spielregeln neu geschrieben. Und generative KI wird nicht jeden Entwickler ersetzen, aber sie verändert, was gute Entwicklung bedeutet und was von einem Entwickler erwartet wird.
Was mich an diesem WhatsApp-Austausch mit meinem Sohn beeindruckt hat, ist nicht die Ablehnung von KI. Das wäre einfach und falsch. Beeindruckt hat mich die Fähigkeit, zwischen sinnvollem Werkzeugeinsatz und Cargo-Cult-Adoption zu unterscheiden.
Cargo-Cult-Adoption: Man übernimmt das Vokabular und die Oberfläche einer Methode, ohne ihren Kern zu verstehen. Man nennt eine Stelle „Vibe Coding“, weil der Begriff gerade durch die Tech-Presse geht und Aufmerksamkeit erzeugt. Man schreibt ihn fettgedruckt in den Titel. Und man übersieht dabei, dass die dahinter liegende Haltung, nämlich Output nehmen ohne vollständiges Verständnis, im konkreten Kontext entweder wirkungslos oder riskant ist.
Das ist kein Vorwurf an KI. Das ist ein Vorwurf an mangelndes Kontextbewusstsein.
Ein klares Bild statt eines falschen
Was ich mir wünsche, nicht als Utopie, sondern als konkrete Erwartung an Unternehmen, die KI in ihre Entwicklungsprozesse integrieren: mehr Präzision bei der Frage, wo welches Werkzeug in welcher Arbeitsweise Sinn macht.
KI-gestützte Entwicklung kann Produktivität erhöhen. Sie kann Einstiegshürden senken. Sie kann Prototyping beschleunigen und Ideen schneller sichtbar machen. All das stimmt, und ich erlebe es täglich in meiner eigenen Arbeit.
Aber sie ersetzt weder das Grundlagenverständnis noch die professionelle Urteilsfähigkeit. Und in einem Bereich wie AI Security ist diese Urteilsfähigkeit keine optionale Zusatzqualifikation. Sie ist die Voraussetzung dafür, dass das, was gebaut wird, nicht zur nächsten Schwachstelle wird.
Mein Sohn ist inzwischen an der FH angekommen. Er lernt weiter, wie man Code wirklich versteht. Und ich finde, das ist genau der richtige Weg. Nicht weil KI irrelevant wäre, sondern weil sie am meisten bringt, wenn man sie richtig einzusetzen weiß.
Die Frage ist nicht, ob Vibe Coding eine Rolle in der modernen Softwareentwicklung spielt. Sie spielt eine. Aber das richtige Bild davon zu vermitteln, was es kann, was es nicht kann, und wo es schlicht nichts verloren hat, das sollte nicht dem nächsten viral gehenden Stelleninserat überlassen bleiben.
Das ist meine ehrliche Einschätzung.
