Vibe-Coding im Enterprise-Kontext

Vibe-Coding beschleunigt die Umsetzung enorm – doch im Enterprise-Umfeld zeigt sich schnell, dass Geschwindigkeit allein nicht reicht. Warum expliziter Kontext, echte Zusammenarbeit und bewusste Designentscheidungen wichtiger werden als je zuvor, und weshalb die grundlegenden Prinzipien der Softwareentwicklung nicht verschwinden, sondern an Bedeutung gewinnen.

In den letzten Monaten hab ich mich intensiv mit Vibe-Coding beschäftigt. Zunächst nur in kleinen Experimenten, bald aber bereits in Projekten, bei denen es nicht nur darum geht, ob Software funktioniert – sondern ob sie tragfähig ist.

Bei den anfänglichen Experimenten ging es mir wie den meisten: Es fühlt sich an wie Magie. Man beschreibt eine Idee, und in sehr kurzer Zeit entsteht funktionierender Code, lauffähige Prototypen. Dinge, die früher mehrere Iterationen gebraucht hätten, sind plötzlich direkt sichtbar. Das fühlt sich erst einmal wie ein gigantischer Fortschritt an. Und natürlich ist es das auch.

Aber diese Geschwindigkeit verliert sich schnell, sobald es um Software im produktiven Umfeld geht. Compliance, Datenschutz, IT-Sicherheit, gewachsene Bestandssysteme, infrastrukturelle Abhängigkeiten zwischen Services und Service-Versionen – all das verschwindet nicht, nur weil der Code schneller entsteht.

Konzept schlägt Geschwindigkeit

Was ich relativ früh gelernt habe: Vibe-Coding funktioniert hervorragend, solange es um Prototypen geht. Sobald man aber versucht, daraus ein belastbares System zu machen, tauchen bekannte Muster wieder auf.

Unklarer Kontext führt zu unklaren Ergebnissen. Unvollständige Anforderungen führen zu Fehlinterpretationen.

Der Unterschied ist wie gehabt: Komplexität und Chaos verschwinden nicht durch Automatisierung – sie werden durch sie nur sehr viel schneller. Das Ergebnis: Man bekommt früher und günstiger etwas Sichtbares. Aber eine grobe Idee reicht nicht als Grundlage. Was ein System im produktiven Umfeld tatsächlich braucht, geht weit über eine High-Level-Beschreibung hinaus:

• Warum bauen wir diese Software überhaupt?
• Welchen Geschäftsprozess soll sie verbessern?
• Welche Entscheidung soll sie dem Nutzer abnehmen?
• Welchen konkreten Mehrwert liefert sie?

Sobald diese Fragen nicht sauber beantwortet sind, beginnt das Modell – genau wie ein menschlicher Entwickler – zu interpretieren. Und genau hier wird der Unterschied zwischen Tacit Knowing und Explicit Knowing relevant.

• Tacit Knowing: Implizites Wissen, das im Kopf vorhanden ist, aber nicht ausgesprochen wird
• Explicit Knowing: Klar formuliertes, dokumentiertes Wissen

In klassischen Projekten funktioniert vieles auf Basis von implizitem Verständnis. Teams entwickeln über Zeit ein Gefühl für den Kontext. Für das Business. Für die Nutzer. Für die Probleme, die gelöst werden sollen. Im Vibe-Coding funktioniert das so aber nicht. Alles, was nicht explizit formuliert ist, existiert für das Modell nicht; bzw. genauer gesagt: Das Modell ersetzt implizites Verständnis durch Wahrscheinlichkeiten.

Diese Beobachtung deckt sich mit aktueller Forschung, die Vibe-Coding als Verschiebung von Implementation hin zu Intent-Formulierung beschreibt.

Kontext entsteht nicht im luftleeren Raum

Ein Punkt, der oft unterschätzt wird: Der Kontext eines IT Vorhabens entsteht nicht durch einen einzelnen Prompt. Und er entsteht auch nicht alleine im Kopf einer Person. In klassischen Softwareprojekten wird ein System im Team entwickelt:

• Der Requirements Engineer übersetzt Geschäftsprozesse in fachliche Anforderungen
• Der Product Owner bringt die Perspektive des Nutzers ein und priorisiert nach Mehrwert
• Der Architekt definiert technische Rahmenbedingungen, Schnittstellen und Systemgrenzen
• Entwickler stoßen in der konkreten Umsetzung auf Edge-Cases, die vorher niemand gesehen hat
• Tester decken Lücken auf, die in der Konzeption unsichtbar waren
• Im Security-Review werden Angriffsvektoren identifiziert, die im Feature-Denken untergehen
• Ops und Infrastruktur bringen Realitäten wie Skalierung, Monitoring und Deployment-Abhängigkeiten ein
• Und oft genug ist es der Fachbereich selbst, der im Gespräch eine Anforderung korrigiert, die alle für verstanden hielten

Beim Vibe-Coding ist das nicht anders. Die Zusammenarbeit verändert sich – aber sie verschwindet nicht. Ich habe das konkret in einem eigenen Projekt erlebt: Einer Desktop-Applikation zur geführten Definition und automatisierten Provisionierung hochverfügbarer Cluster.

Die Idee klingt simpel:

Ein Nutzer soll mit möglichst wenig Vorwissen einen stabilen, produktionsreifen Cluster aufsetzen können – ohne sich in Details zu verlieren. Der Fokus liegt auf europäischen Rechenzentrumsbetreibern mit Terraform-Unterstützung. Bewährte Infrastrukturdienste, Betriebssysteme, Backup-Strategien, Hochverfügbarkeitskonzepte, Sicherheitsmechanismen und ein durchgängiges GitOps-Paradigma sollen automatisch und nach De-facto-Standards integriert werden. Der Nutzer soll sich auf das konzentrieren können, was eigentlich zählt – das Problem, das er mit dem Cluster lösen will.

Dahinter steckt allerdings eine ganze Reihe bewusster Designentscheidungen:

• sinnvolle Defaults setzen, statt dem Nutzer jede Wahl zu überlassen
• Komplexität verbergen, ohne Kontrolle zu nehmen
• Hochverfügbarkeit sicherstellen, auch wenn der Nutzer sie nicht explizit anfordert
• Backup-Strategien integrieren, bevor jemand danach fragt
• Sicherheitsmechanismen implementieren, bevor sie zum Problem werden
• Ein konsistentes, nachvollziehbares System schaffen, das nicht nur funktioniert, sondern auch verständliche Rückmeldungen gibt
• Rollback-Strategien und Fehlerbehandlung integrieren, damit der Nutzer nicht in einem unverständlichen Zustand landet, wenn etwas schief läuft
• Ein Provider Plugin entwickeln, das die Provisionierung von Clustern in verschiedenen Rechenzentren ermöglicht, ohne dass der Nutzer sich mit den Details jedes Anbieters beschäftigen muss

Der eigentliche Mehrwert dieser Software liegt nicht im Code. Er liegt darin, dem Nutzer Entscheidungen abzunehmen, die er sonst selbst treffen müsste – häufig ohne die nötige Erfahrung, die Tragweite jeder einzelnen Wahl einschätzen zu können. Und genau dieser Zweck muss explizit beschrieben sein.

Wenn das sauber passiert, entsteht im Vibe-Coding eine Anwendung, die konsistent auf dieses Ziel hinarbeitet. Wenn nicht, entsteht etwas Generisches, das sicher am Ziel vorbei führt.

Zusammenarbeit mit KI ist trotzdem Zusammenarbeit

Was sich verändert hat, ist die Art der Zusammenarbeit. Neben menschlichen Kollegen arbeitet man jetzt zusätzlich mit LLMs und Agenten. Viele Dinge lassen sich im Dialog schneller klären, Varianten entstehen früher, erste Ergebnisse sind schneller sichtbar. Das führt zu ernormem Geschwindigkeitsgewinn.

Aber eine Sache bleibt: Die entscheidenden Fragen kommen nicht aus dem Modell. Ein LLM trägt zwar das generalisierte Wissen unzähliger Entwickler in sich – aber genau das ist der Punkt: Es arbeitet zunächst immer generisch. Die Fragen, die ein konkretes Projekt voranbringen, entstehen aus den spezifischen Erfahrungen der Menschen im Projektumfeld.

Ich habe mehrfach erlebt, dass entscheidende Impulse aus Gesprächen mit Kollegen und Fachbereichen kamen:

• Hinweise auf fehlende Backup-Strategien
• Potentielle Angriffsvektoren und daraus hervorgehende Sicherheitsanforderungen
• Diskussionen über Kosten vs. Sicherheit
• Erfahrungswerte aus anderen Projekten

Das Modell kann diese Fragen oft gut beantworten und Lösungen anbieten. Aber es bringt sie selten von selbst ein. In der Praxis wird genau das bestätigt: Erfolgreiches Vibe-Coding erfordert strukturierte Kontextarbeit, klare Rahmenbedingungen und menschliche Steuerung.

Wenn Systeme wieder Realität berühren

Ein interessanter Effekt entsteht zu dem Zeitpunkt, an dem die Software nicht mehr nur in einem Prototypen- oder Testumfeld existiert, sondern tatsächlich von Nutzern verwendet wird. Weil die technische Umsetzung schneller wird, verschiebt sich der Fokus. Weniger Zeit geht in Implementierung – mehr in Verständnis, Zieldefinition und die Frage, was die Software eigentlich für wen leisten soll. Und die Antworten darauf kommen nicht aus der IT. Sie kommen aus Geschäftsmodellen, aus Prozessen, aus tatsächlichen Nutzerproblemen – kurz: aus der Realität.

Genau das sieht man auch in aktuellen Enterprise-Initiativen rund um Vibe-Coding: Unternehmen versuchen gezielt, Business-Teams stärker einzubinden und Software näher an reale Anforderungen zu bringen. Das ist kein Zufall. Wenn Software schneller entsteht, wird es plötzlich schneller relevant, dass sie das Richtige tut – nicht nur, dass sie funktioniert.

Was sich nicht verändert hat

Vielleicht die wichtigste Erkenntnis aus meinen bisherigen Projekten: Die grundlegenden Prinzipien der Softwareentwicklung bleiben unverändert. Iteratives Vorgehen, saubere Architektur, bewusste Kontextarbeit, echte Zusammenarbeit – nichts davon wird durch Vibe-Coding obsolet.

Die Werkzeuge sind neu. Die Verantwortung nicht.

Rollen wie Product Owner, Programmmanager oder Architekt verändern sich weniger, als man zunächst denkt. Ihre Kernaufgabe bleibt dieselbe: Ziele klar formulieren, Entscheidungen treffen, Komplexität reduzieren und dafür sorgen, dass alle Beteiligten dasselbe Verständnis vom Vorhaben haben. Technische Abhängigkeiten, Schnittstellen, Sicherheitsanforderungen, Nutzerbedürfnisse – all das muss weiterhin berücksichtigt werden.

Nur dass „alle Beteiligten" heute nicht mehr ausschließlich menschliche Kollegen sind – sondern zusätzlich KI-Systeme, die auf genau diese Klarheit angewiesen sind; und die im Gegenzug schneller und flexibler auf diese Klarheit reagieren können.

Fazit

Vibe-Coding ersetzt keine Softwareentwicklungs-Prozesse – aber es beschleunigt die Umsetzung so erheblich, dass plötzlich Vorhaben realistisch werden, für die zuvor weder Zeit noch Ressourcen da waren. Genau diese Beschleunigung macht allerdings etwas anderes sichtbar:

Software entsteht nicht aus Code. Sie entsteht aus einem klaren Verständnis dessen, was gebaut werden soll – und warum.

Dieses Verständnis ist immer spezifisch, immer für reale Menschen relevant und immer an konkrete Probleme gebunden. Wenn es explizit formuliert ist, funktioniert Vibe-Coding erstaunlich gut. Wenn nicht, passiert genau das, was man aus jedem Projekt kennt: Das System arbeitet – aber nicht auf das eigentliche Ziel hin. Der eigentliche Fortschritt liegt deshalb nicht nur in der Technologie. Er liegt darin, dass wir gezwungen sind, klarer zu formulieren, was wir bauen, warum wir es bauen und für wen.

Und genau das ist eine Übung, die nicht nur der KI hilft – sondern uns selbst.

---

Definition

Vibe-Coding bezeichnet einen Ansatz der Softwareentwicklung, bei dem Entwickler ihre Absicht in natürlicher Sprache beschreiben und ein KI-gestütztes Werkzeug (typischerweise ein Large Language Model) den Code generiert. Der Fokus verschiebt sich dabei von der manuellen Implementierung hin zur präzisen Formulierung von Zielen und Kontext. Der Begriff wurde Anfang 2025 von Andrej Karpathy geprägt. Mehr dazu: Vibe coding – Wikipedia