Ein Dashboard skizzieren, Funktionen nachschieben, das Ergebnis per Link an die Kollegen weitergeben – und das ohne eine Zeile Code selbst zu schreiben: Genau dieser Ablauf wird derzeit unter dem Schlagwort Vibe Coding beschrieben. Gemeint ist Entwicklung, bei der nicht mehr Syntax getippt, sondern in natürlicher Sprache beschrieben wird, was ein Werkzeug tun soll. Ein Assistent wie Claude Code erzeugt daraus den lauffähigen Stand, den man anschließend im Dialog weiter verfeinert.

Für Fachabteilungen ist das ein Bruch mit einer gewohnten Reihenfolge. Bisher war der Weg zu einem kleinen internen Tool: Bedarf formulieren, Anforderung dokumentieren, Priorisierung abwarten, Umsetzung beauftragen. Jetzt entstehen erste Versionen dort, wo der Bedarf sitzt – im Controlling, im Vertrieb, im Marketing.

Wo der Effizienzgewinn tatsächlich entsteht

Der Nutzen ist am größten bei Werkzeugen, die heute niemand baut, weil sie sich betriebswirtschaftlich nie gerechnet haben. Die Liste solcher Lücken ist in fast jedem Mittelstandsbetrieb lang:

  • Übersichten, die Zahlen aus mehreren Exporten zusammenführen, damit nicht jede Woche dieselbe Tabelle händisch entsteht.
  • Kleine Eingabemasken für wiederkehrende Meldungen, die bisher per E-Mail oder Zuruf laufen.
  • Checklisten und Rechner, die eine Fachlogik abbilden, welche sonst nur in den Köpfen einzelner Personen existiert.
  • Prototypen, mit denen sich eine Idee schnell zeigen lässt, bevor über ein richtiges Projekt entschieden wird.

Der zweite, weniger offensichtliche Gewinn liegt in der Kommunikation. Wer selbst ein funktionierendes Miniatur-Tool gebaut hat, formuliert Anforderungen anschließend präziser. Statt eines Wunschzettels liegt ein anfassbarer Stand auf dem Tisch, an dem sich diskutieren lässt, was fehlt und was überflüssig ist. Für Projektverantwortliche ist das oft wertvoller als das Tool selbst.

Der Unterschied zwischen läuft und trägt

Genau hier beginnt allerdings die Zone, in der Selbstbau ohne Begleitung teuer wird. Ein Prompt-generiertes Werkzeug ist zunächst nur eines: lauffähig. Ob es tragfähig ist, entscheiden Eigenschaften, die man beim Ausprobieren nicht sieht.

Wartbarkeit. Code, den niemand im Haus gelesen hat, ist im Zweifel auch niemandes Verantwortung. Solange das erzeugende Werkzeug jede Änderung übernimmt, funktioniert das. Sobald sich eine Schnittstelle ändert, eine Abhängigkeit ein Sicherheitsupdate braucht oder die Person das Unternehmen verlässt, die das Tool angelegt hat, fehlt die Person, die den Stand einordnen kann. Aus einem Nachmittagsprojekt wird dann ein Altsystem, von dem eine Abteilung abhängt.

Datenschutz und Datenhaltung. Der kritische Moment ist selten das Erzeugen des Codes, sondern der erste echte Datensatz. Sobald Kundendaten, Personalinformationen oder Kalkulationen in ein selbstgebautes Werkzeug wandern, gelten dieselben Anforderungen wie für jedes andere System: Wo liegen die Daten, wer greift darauf zu, wie lange bleiben sie liegen, wie kommt man sie wieder los. Ein per Link geteiltes Dashboard ist bequem – und die Frage, wer diesen Link weitergeben kann, gehört vor die erste Nutzung geklärt, nicht danach.

Integration. Isolierte Tools erzeugen Doppelarbeit. Wenn Stammdaten im ERP stehen, Inhalte im TYPO3-Backend gepflegt werden und ein neues Dashboard seine Zahlen aus einem manuellen Export zieht, dann ist die Übersicht ab dem Moment veraltet, in dem sie erstellt wurde. Der Wert eines internen Werkzeugs steigt sprunghaft, sobald es an die bestehenden Systeme angebunden ist – und genau das ist der Teil, der Architekturwissen verlangt: Rechte, Schnittstellen, Fehlerfälle, Betrieb.

Ein pragmatischer Rahmen für Unternehmen

Die Antwort auf diese Risiken ist kein Verbot. Verbote verlagern solche Werkzeuge nur in private Accounts, wo niemand mehr Einblick hat. Sinnvoller ist ein klarer Rahmen, in dem Selbstbau ausdrücklich erlaubt ist – mit einer Grenze, ab der ein Projekt in die professionelle Umsetzung wechselt.

  1. Freigegebene Spielwiese. Legen Sie fest, mit welchen Werkzeugen, in welcher Umgebung und mit welchen Daten experimentiert werden darf. Testdaten statt Echtdaten ist die einfachste und wirksamste Regel.
  2. Kriterien für den Übergang. Definieren Sie, wann ein Prototyp kein Prototyp mehr ist: sobald personenbezogene Daten verarbeitet werden, sobald mehrere Abteilungen darauf angewiesen sind, sobald Externe Zugriff haben oder sobald ein Ausfall Arbeitsprozesse blockiert.
  3. Inventar. Halten Sie fest, welche Tools existieren, wer sie gebaut hat und wozu. Diese Liste ist der einzige Schutz davor, dass Schatten-IT unbemerkt wächst.
  4. Überführung statt Neubau. Ein guter Prototyp ist eine Spezifikation. Er zeigt Datenmodell, Bedienlogik und Sonderfälle – und verkürzt die anschließende saubere Umsetzung deutlich.

Was das für die Rollen im Projekt bedeutet

Prompt-getriebene Entwicklung senkt die Einstiegshürde zum ersten funktionierenden Stand, nicht den Aufwand für Betrieb, Sicherheit und Integration. Die Arbeit verschiebt sich: weg vom Schreiben einfacher Oberflächen, hin zu Fragen der Architektur, der Datenqualität und der Frage, welche Werkzeuge ein Unternehmen dauerhaft betreiben will. Für Entwicklerinnen und Entwickler heißt das weniger Routine und mehr Beratung. Für Fachabteilungen heißt es mehr Gestaltungsspielraum – und mehr Mitverantwortung dafür, wo die eigene Kompetenz endet.

Für Web- und Softwareprojekte lohnt es sich, diese Entwicklung aktiv einzuplanen statt sie zu ignorieren: Selbstgebaute Prototypen aus den Fachabteilungen sind eine ausgezeichnete Grundlage für Anforderungsgespräche, weil sie zeigen, was wirklich gebraucht wird. Entscheidend ist ein definierter Übergabepunkt, an dem ein Prototyp in eine wartbare, datenschutzkonform betriebene und in TYPO3 oder die bestehende Systemlandschaft integrierte Lösung überführt wird. Wer diesen Punkt klar benennt, gewinnt Geschwindigkeit ohne die stille Ansammlung von Systemen, für die sich später niemand verantwortlich fühlt.

Quellen