Vibe Coding im Unternehmen: Was es ist und was danach fehlt

Vibe Coding, im professionellen Sprachgebrauch inzwischen auch agentisches Programmieren, ist 2026 Alltag: Man beschreibt, was eine App können soll, und die KI schreibt den Code. Ob dabei produktionsreife Software entstehen kann, ist inzwischen klar mit Ja beantwortet.

Offen ist eine andere Frage, und für Unternehmen ist sie die wichtigere: Was muss um eine App herum stehen, damit echte Menschen sie mit echten Daten nutzen können? Wer darf hinein, wer sieht was, wo liegen die Daten, wer ist zuständig, wenn etwas nicht funktioniert? Und wie wird das zuverlässig und kontrolliert umgesetzt? Dieser Beitrag erklärt, was Vibe Coding ist, worauf die KI nicht von selbst achtet und wie Unternehmen das für jede App verlässlich regeln.

Was ist Vibe Coding?

Vibe Coding heißt: Man beschreibt einer KI in natürlicher Sprache, was eine Software tun soll, und die KI schreibt den Code. Man beurteilt das Ergebnis an dem, was die Software tut, nicht am Quelltext, und steuert per Anweisung nach, bis es passt. Auf Deutsch trifft es „Programmieren nach Gefühl“ ganz gut, durchgesetzt hat sich aber der englische Begriff.

Woher der Begriff kommt

Geprägt hat ihn der KI-Forscher Andrej Karpathy, Mitgründer von OpenAI und früher KI-Chef bei Tesla, im Februar 2025 in einem Beitrag auf X. Er beschrieb dort eine Art zu programmieren, bei der man sich ganz der KI überlässt und „vergisst, dass der Code überhaupt existiert“. Der Begriff verbreitete sich so schnell, dass Collins Dictionary „vibe coding“ zum Wort des Jahres 2025 wählte.

Karpathy selbst hielt die Methode damals für „not too bad for throwaway weekend projects“, also für brauchbar bei Wochenendprojekten, die man danach wegwirft. Keine zwei Jahre später ist davon wenig übrig.

Vibe Coding, agentisches Programmieren, KI-Entwicklung

Im Alltag verschwimmen die Begriffe. Ursprünglich meinte Vibe Coding das lockere Ausprobieren ohne Blick in den Code. In der professionellen Entwicklung spricht man eher von agentischem Programmieren: KI-Agenten bekommen eine Aufgabe, schreiben Code, testen ihn, eröffnen Pull Requests und reagieren auf Prüfkommentare. Der gemeinsame Kern ist derselbe: Menschen beschreiben und entscheiden, die KI schreibt. In diesem Beitrag steht Vibe Coding für beides.

Vom Wochenendprojekt zum Standard

Wie schnell sich das Bild gedreht hat, zeigt kaum jemand so deutlich wie David Heinemeier Hansson, kurz DHH.

Sinnbild für die Branche: der Sinneswandel von David Heinemeier Hansson

Hansson hat Ruby on Rails erfunden, eines der einflussreichsten Web-Frameworks, und ist Mitgründer von 37signals, der Firma hinter Basecamp und HEY. Er galt lange als einer der prominentesten Skeptiker. Im Juli 2025 sagte er im Podcast von Lex Fridman, die Freude am Programmieren liege für ihn darin, den Code selbst zu tippen. Statt sich zum Projektmanager einer KI-Schar zu machen, würde er „lieber in Rente gehen, als das aufzugeben“.

Ein halbes Jahr später, im Januar 2026, schrieb er in seinem Blog, die aktuellen KI-Agenten seien „voll in der Lage, produktionsreife Beiträge zu echten Codebasen zu liefern“, der Paradigmenwechsel fühle sich endlich real an. Im September 2026 eröffnete er die Rails World in Austin mit einer Keynote, die viel Aufsehen erregte: Bei 37signals werde kein Code mehr von Hand geschrieben, handgeschriebener Code sei dort jetzt ein Ausnahmezustand, vergleichbar mit einer Fehlermeldung im Monitoring. Für die große Mehrheit der Entwicklerinnen und Entwickler rechne sich das Schreiben von Hand schon heute nicht mehr, bis Jahresende gelte das praktisch für alle. Seinen eigenen Satz von 2025 spielte er dabei ein und kommentierte ihn trocken: Er habe sich als professioneller Programmierer tatsächlich zur Ruhe gesetzt.

Omarchy: ein Betriebssystem, geschrieben von Agenten

Wie das praktisch aussieht, zeigt Hanssons Nebenprojekt Omarchy, eine vorkonfigurierte Linux-Distribution auf Basis von Arch Linux. Die ersten Versionen 2025 hat er nach eigener Aussage noch von Hand geschrieben. Für die vierte Version, erschienen im Sommer 2026, gilt das Gegenteil: Nichts vom ausgelieferten Code habe er selbst geschrieben, alles stamme von Agenten, die er gesteuert habe. Er habe die Gesamtform geprüft und kritische Stellen Zeile für Zeile, den Rest nicht. Omarchy beschreibt sich inzwischen selbst als „das formbare Betriebssystem für das Zeitalter der Agenten“: Nutzer passen ihr System an, indem sie einem mitgelieferten Agenten sagen, was sie wollen.

Was die großen Unternehmen berichten

Hansson ist kein Einzelfall. Die Zahlen, die Unternehmen 2026 selbst veröffentlichen, zeigen in dieselbe Richtung:

• Google: 75 Prozent des neuen Codes sind KI-generiert und von Entwicklern freigegeben, im Herbst 2025 waren es noch 50 Prozent (April 2026).
• Anthropic: Mehr als 80 Prozent des Codes, der in die eigene Codebasis übernommen wird, schreibt Claude (Stand Mai 2026). Die Prüfung übernehmen zunehmend ebenfalls Agenten.
• Coinbase: Nahezu der gesamte Code entsteht durch oder mit Sprachmodellen, nach Aussage des Plattformverantwortlichen zwischen 95 und 100 Prozent (Juli 2026).

Diese Zahlen sind Selbstauskünfte, und „mit KI“ ist nicht immer „von KI“. Die Richtung ist trotzdem eindeutig. Wer 2026 eine Anwendung mit KI bauen lässt, bekommt keinen Klickdummy mehr, sondern Software, die in Produktion gehen kann.

Worauf die KI nicht von selbst achtet

Wenn die Technik so weit ist, warum gehen dann immer noch Apps schief? Die bekannt gewordenen Fälle haben eines gemeinsam: Die KI hat gebaut, was man ihr aufgetragen hat. Was niemand erwähnt hat, fehlte. Eine KI richtet ihre Aufmerksamkeit auf den Auftrag, und Zugriffsregeln, Rechte oder Backups, nach denen keiner fragt, bleiben dabei leicht auf der Strecke.

Anfang 2026 wurde bekannt, dass die Datenbank einer sozialen Plattform, deren Gründer stolz erklärt hatte, keine einzige Zeile selbst geschrieben zu haben, für jeden offen lesbar und beschreibbar war: Es waren schlicht keine Zugriffsregeln eingerichtet. Im September 2026 fanden Sicherheitsforscher über 16.000 Datenbanken von Apps, deren Tabellen öffentlich lesbar waren, in mehr als der Hälfte davon mit Hinweisen auf personenbezogene Daten. Der Anbieter der Datenbank verwies darauf, dass die Kunden selbst festlegen, wie ihre Projekte konfiguriert sind. Er hat recht, und genau darin liegt der Punkt.

Selbst bei 37signals, einem der erfahrensten Softwarehäuser überhaupt, lief nicht alles glatt: Als dort Designer 2026 selbst per KI an Basecamp mitbauten, entstanden viele Änderungen, die einzeln vertretbar waren, zusammen aber die Architektur beschädigten. Jede einzelne Änderung tat, was verlangt war. Dass sie auch zur bestehenden Architektur passen musste, stand in keinem Auftrag.

Zu wissen, worauf eine professionelle Anwendung achten muss, und es der KI vollständig mitzugeben, ist deshalb eine Frage von Erfahrung. Fünf Themen gehören zu jeder App, die echte Menschen mit echten Daten nutzen.

Nutzer und Zugänge

Wer darf die App öffnen, und wie kommt man hinein? Eine Anwendung braucht eine Personenverwaltung: Listen importieren, Personen anlegen und wieder entfernen, Einladungen verschicken, Zugänge sperren, wenn jemand das Unternehmen verlässt. Welche Personen das sind, weiß die KI nicht. Das weiß nur Ihre Organisation.

Dazu kommt die Art des Zugangs. Beschäftigte mit Firmenkonto melden sich anders an als Beschäftigte ohne eigene E-Mail-Adresse, und beide anders als Externe: Kundinnen, Teilnehmende einer Schulung, Bewerberinnen, Mieter. Persönliche Links, Zugangscodes, Login-Links per E-Mail, Anmeldung über das Firmenkonto: Jede Variante hat ihre Sicherheitsfragen, und jede App, die sie neu erfindet, erfindet auch neue Fehlerquellen.

Rollen und Rechte

Sobald mehr als eine Gruppe die App nutzt, braucht sie Rollen. Wer stellt einen Antrag, wer gibt ihn frei, wer sieht alle Anträge, wer nur die eigenen? Wer darf die App verändern, wer nur benutzen? Das ist Organisationswissen, kein Programmierwissen.

Entscheidend ist, wo diese Regeln durchgesetzt werden. Eine Schaltfläche auszublenden, ist keine Berechtigung. Rechte müssen auf dem Server geprüft werden, bei jeder einzelnen Anfrage, und sie müssen für alle Apps nach denselben Regeln funktionieren. Die offenen Datenbanken aus den Beispielen oben sind genau an dieser Stelle gescheitert.

Ein Sonderfall sind Auswertungen. Wer Rückmeldungen einsammelt, etwa zu einer Führungskraft oder einem Team, braucht Regeln, ab wie vielen Antworten ein Ergebnis angezeigt wird. Wie aufwendig das richtig gemacht ist, zeigt unser Beitrag zur anonymen Mitarbeiterbefragung.

Daten und DSGVO: die kompakte Checkliste

Sobald eine App personenbezogene Daten verarbeitet, und das tut fast jede mit Namen oder E-Mail-Adressen, gilt die DSGVO. Sie fragt nicht, wie eine App entstanden ist, sondern wie sie Daten verarbeitet. Die folgenden Punkte sollten geklärt sein, bevor die App an echte Personen geht.

1. Zweck und Datenumfang. Welche Daten braucht die App wirklich? Jedes Feld, das nicht nötig ist, fällt weg (Datenminimierung, Art. 5 DSGVO).
2. Verzeichnis der Verarbeitungstätigkeiten. Die App gehört ins Verzeichnis nach Art. 30 DSGVO, mit Zweck, Datenkategorien, Empfängern und Löschfristen.
3. Auftragsverarbeitung. Jeder Dienst, der Daten für Sie verarbeitet, braucht einen Vertrag nach Art. 28 DSGVO. Das betrifft das Hosting, die Datenbank, den E-Mail-Versand und gegebenenfalls die KI selbst.
4. Serverstandort und Drittland. Liegen Daten außerhalb der EU oder hat ein Dienstleister Zugriff aus einem Drittland, gelten die Regeln der Art. 44 ff. DSGVO. Das sollte bekannt sein, nicht vermutet.
5. Technische und organisatorische Maßnahmen. Verschlüsselung, Zugriffskontrolle, Protokollierung, Wiederherstellbarkeit (Art. 32 DSGVO). Bei einer selbst gebauten App müssen Sie diese Maßnahmen selbst benennen können.
6. Datenschutz durch Technikgestaltung. Voreinstellungen, die möglichst wenig preisgeben (Art. 25 DSGVO): Wer nichts sehen muss, sieht nichts.
7. Löschung und Auskunft. Wie werden Daten nach Ablauf gelöscht? Wie beantworten Sie eine Auskunftsanfrage zu einer Person, deren Daten in der App liegen?
8. Datenschutz-Folgenabschätzung. Bei sensiblen Daten oder systematischer Bewertung von Personen ist sie nach Art. 35 DSGVO Pflicht. Die Datenschutzbeauftragte sollte früh einbezogen werden.
9. Mitbestimmung. Eignet sich die App dazu, Verhalten oder Leistung von Beschäftigten zu überwachen, hat der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG mitzubestimmen. Das gilt unabhängig davon, ob die Überwachung beabsichtigt ist.
10. Die KI als Empfänger. Welche Daten gehen beim Bauen und im Betrieb an ein KI-Modell, und bei welchem Anbieter landen sie? Beispieldaten zum Bauen sind fast immer die bessere Wahl als echte Personendaten.

Hosting und Sicherheit

Viele Werkzeuge veröffentlichen eine App mit einem Klick. Für eine Anwendung im Unternehmen stellen sich andere Fragen: Wo steht der Server, und wer betreibt ihn? Welche Zertifizierung hat das Rechenzentrum? Mit welchen anderen Diensten spricht die App, und wer hat diese Verbindungen erlaubt? Die KI kann jede dieser Varianten umsetzen. Welche davon Ihre Organisation zulässt, muss vorher jemand festlegen.

Betrieb: Verantwortung, Änderungen, Backups, Eigentum

Eine Anwendung im Betrieb braucht jemanden, der sich kümmert, auch in einem Jahr noch.

• Verantwortung. Wer ist für die App zuständig, wenn die Person, die sie gebaut hat, die Abteilung wechselt? An wen wenden sich Nutzerinnen und Nutzer, wenn der Login-Link nicht ankommt?
• Änderungen. Die Fachabteilung will ein neues Feld. Bleibt beim Umbau alles andere, wie es war? Lässt sich ein Stand zurückholen, wenn eine Änderung schiefgeht?
• Updates. Bibliotheken und Abhängigkeiten bekommen Sicherheitsupdates. Ein Agent kann sie einspielen, aber jemand muss dafür sorgen, dass es passiert.
• Backups. Werden die Daten regelmäßig gesichert, und wurde die Wiederherstellung einmal ausprobiert?
• Eigentum. Wem gehören App und Daten? Lassen sich die Daten vollständig exportieren? Was passiert, wenn sich Preise oder Bedingungen eines Werkzeugs ändern oder ein KI-Modell nicht mehr angeboten wird?

Neu ist keine dieser Fragen. Neu ist, dass Apps heute in Stunden entstehen, und die Fragen deshalb oft erst gestellt werden, wenn die App längst in Gebrauch ist.

Eine App oder viele: Warum die Grundlagen zentral stehen sollten

Wenn Apps so leicht entstehen, entstehen viele davon. Jede Fachabteilung hat Ideen, und jede kann sie jetzt umsetzen. Das ist die eigentliche Chance von Vibe Coding im Unternehmen. Es ist aber auch der Punkt, an dem es kippen kann: Beantwortet jede App die Fragen nach Nutzern, Rechten, Daten und Betrieb für sich allein, gibt es nach einem Jahr zwanzig selbst gebaute Personenverwaltungen, zwanzig Rechtekonzepte und zwanzig Serverstandorte, von denen die IT die Hälfte nicht kennt.

Thema	Jede App regelt alles selbst	Apps auf einer gemeinsamen Grundlage
Nutzer	je App selbst gebaute Listen, Austritte werden vergessen	in jeder App dieselbe erprobte Personenverwaltung: Gruppen, Rollen, Zugänge sperren
Zugang	je App ein selbst gebautes Login-Verfahren	erprobte Zugangswege (persönlicher Link, Zugangscode, Login-Link per E-Mail), je App passend gewählt
Rechte	je App neu erfunden, schwer zu prüfen	gleiche Rollenlogik, serverseitig durchgesetzt
Daten	verteilt, Standorte teils unbekannt	bekannter Standort, einheitliche Löschung und Exporte
Datenschutz	Verzeichnis, AV-Verträge und TOM für jede App einzeln	einmal geregelt, jede App übernimmt es
Überblick der IT	Apps tauchen auf, wenn etwas schiefgeht	Übersicht, welche Apps es gibt und wer worauf Zugriff hat
Betrieb	abhängig von der Person, die gebaut hat	Stände und Backups je Projekt nach demselben Verfahren, Zuständige und Zugriffe je Projekt festgelegt

Nicht jede App braucht das. Ein Rechner, den nur Sie selbst nutzen, oder ein Entwurf, der eine Idee zeigen soll, kommt ohne gemeinsame Grundlage aus. Sobald aber Personen außerhalb des Bauteams die App nutzen, verschiedene Gruppen verschiedene Dinge sehen dürfen oder personenbezogene Daten gespeichert werden, sollte die App auf einem Fundament stehen, das nicht mit jeder App neu erfunden wird.

Was die IT daraus machen kann

Verbieten hilft wenig. Wer Vibe Coding untersagt, bekommt die Apps trotzdem, nur ohne Überblick. Wirksamer ist es, den Fachabteilungen einen Weg anzubieten, auf dem sie mit KI bauen können und die Grundlagen trotzdem stimmen: erprobte Bausteine für Personen und Zugänge, einheitliche Regeln für Rechte und Daten, ein bekannter Serverstandort und eine Übersicht, welche Apps es gibt. Die IT wird damit vom Engpass zum Plattformgeber.

Wie Survkit das löst

Survkit nimmt die KI beim Wort: Sie baut die App, schnell und vollständig. Aber sie baut sie auf einer Plattform, auf der Nutzer, Rechte und Datenhaltung schon stehen, bevor die erste Zeile generiert ist. Diese Grundlage wurde einmal sorgfältig aufgesetzt, und jedes Projekt nutzt sie. Niemand muss der KI bei jeder neuen App wieder erklären, worauf sie achten muss. Entstanden ist diese Plattform bei Mitarbeiterbefragungen in Konzernen und Ministerien, also dort, wo die Frage „Wer darf was sehen?“ am heikelsten ist.

Drei Dinge unterscheiden den Ansatz:

1. Daten, Rechte und Nutzerstruktur ab dem ersten Tag. Personen kommen per persönlichem Link, offenem Link, Zugangscode oder Login-Link per E-Mail in die App, ohne eigenes Konto. Wer vorab feststeht, lässt sich einzeln oder als Liste anlegen und in Gruppen und Rollen einteilen; für viele Apps ist das gar nicht nötig. Wer baut, wer Daten sieht und wer Personen verwaltet, ist einzeln einstellbar. Das gilt für Apps im eigenen Haus genauso wie für Apps, die nach außen gehen, etwa an Kundinnen oder Teilnehmende.
2. KI Ihrer Wahl. Sie binden Ihr eigenes Modell oder Ihren eigenen KI-Zugang an oder starten mit dem Survkit-Standard. Survkit verdient an der Plattform, nicht am Weiterverkauf von KI-Tokens. Welche Daten der Agent beim Bauen sieht, legen Sie fest wie für jede andere Person im Projekt.
3. Hosting in Deutschland. Die Apps laufen auf Servern in Deutschland, in ISO/IEC-27001-zertifizierten Rechenzentren, mit Auftragsverarbeitungsvertrag. Jede App läuft isoliert, Verbindungen nach außen gibt es nur mit Ihrer Freigabe. Self-Hosting ist möglich.

Für den Betrieb heißt das: Jeder Stand einer App wird als Savepoint gesichert, Änderungen sind auch im laufenden Betrieb möglich, die Daten lassen sich jederzeit exportieren. Und wenn der Agent nicht weiterkommt, übernimmt das Entwicklungsteam, das Survkit selbst baut und betreibt. Beispiele von Lernpfaden über Antragsabläufe bis zu Meldungen per QR-Code zeigt die Seite Apps mit KI bauen: Survkit Agent.

Häufige Fragen zu Vibe Coding im Unternehmen

Ist Vibe Coding sicher?

Die Methode selbst ist weder sicher noch unsicher. Die KI schreibt heute Code, der mit dem von erfahrenen Entwicklerinnen und Entwicklern mithalten kann. Die bekannt gewordenen Sicherheitsvorfälle gingen fast immer auf fehlende Zugriffsregeln, offene Datenbanken oder ungeklärte Zuständigkeiten zurück. Sicher wird eine App, wenn Zugänge, Rechte und Datenhaltung nicht bei jeder App neu entstehen, sondern verlässlich vorgegeben sind.

Brauche ich Programmierkenntnisse, um eine App mit KI zu erstellen?

Nein. Wichtiger als Programmierkenntnisse ist die Klarheit darüber, wer die App nutzt, wer was sehen darf und wer sie betreut. Das ist Organisationswissen, und das bringen Fachabteilungen mit. Die technische Grundlage für Hosting, Datenbank und Rechte muss dann allerdings jemand stellen: das eigene Team oder eine Plattform.

Ist Vibe Coding DSGVO-konform?

Die DSGVO fragt nicht, wie eine App entstanden ist, sondern wie sie Daten verarbeitet. Eine mit KI gebaute App kann also konform sein. Die Punkte der Checkliste oben müssen aber für jede App beantwortet werden, einschließlich der Frage, welche Daten an das KI-Modell gehen.

Wer ist verantwortlich, wenn eine mit KI gebaute App Fehler macht?

Datenschutzrechtlich die Organisation, die die App einsetzt. Praktisch sollte für jede App eine Person benannt sein, die sich um Änderungen, Nutzerfragen und Updates kümmert. Fehlt diese Person, fehlt der Betrieb, ganz gleich, wie gut der Code ist.