Ein Dashboard skizzieren, Schritt für Schritt Funktionen ergänzen und das Ergebnis per Link an das Team weitergeben: Genau dieses Vorgehen beschreibt ein aktueller Praxisbericht zu Claude Code, dem Entwicklungswerkzeug von Anthropic. Der Punkt daran ist weniger die Technik als die Zielgruppe. Wer so arbeitet, braucht keine Programmierkenntnisse mehr, sondern formuliert in normaler Sprache, was das Werkzeug tun soll.

Für diese Arbeitsweise hat sich der Begriff Vibe Coding etabliert – gemeint ist prompt-getriebene Entwicklung, bei der ein KI-Modell den Code schreibt und die Person davor vor allem beschreibt, prüft und nachjustiert. Der Quelltext entsteht weiterhin, er wird nur nicht mehr von Hand getippt.

Warum das in Fachabteilungen ankommt

In vielen mittelständischen Unternehmen gibt es einen langen Schwanz kleiner Anforderungen, die nie ein Projektbudget bekommen: eine Übersicht über offene Angebote, ein Auswertungsblatt für die Produktionsplanung, ein Formular, das drei Excel-Dateien ersetzt. Solche Wünsche landen entweder in der Warteschlange der IT oder in einer weiteren Tabellenkalkulation.

Prompt-getriebene Werkzeuge verschieben diese Grenze. Eine Marketingleiterin kann in einer Stunde eine erste Version ihres Kampagnen-Dashboards sehen, statt sie in einem Anforderungsdokument zu beschreiben. Der Wert liegt dabei weniger im fertigen Werkzeug als in der Klarheit: Ein laufender Prototyp beantwortet Fragen, die ein Konzeptpapier offenlässt.

Der Unterschied zwischen Prototyp und Produktivsystem

Genau hier beginnt aber auch das Missverständnis. Ein Werkzeug, das für drei Kolleginnen und Kollegen funktioniert, ist noch kein System, das in einer Organisation über Jahre trägt. Zwischen beidem liegen mehrere Themen, die in der schnellen Entstehung leicht untergehen.

Datenschutz und Zugriffsrechte. Sobald ein selbstgebautes Dashboard reale Kunden-, Personal- oder Umsatzdaten anzeigt, gelten dieselben Regeln wie für jede andere Anwendung. Wer sieht welche Daten? Wo liegen sie? Wird der Link, über den das Werkzeug geteilt wird, tatsächlich nur intern verwendet? Ein per Link verteiltes Werkzeug ohne Anmeldung ist für eine Demo unproblematisch, für Echtdaten in der Regel nicht.

Wartbarkeit. Code, den niemand im Haus gelesen hat, lässt sich schwer weiterentwickeln. Solange die ursprüngliche Person mit demselben KI-Werkzeug weiterarbeitet, geht das gut. Verlässt sie das Unternehmen oder ändert sich eine Schnittstelle, steht die Abteilung vor einem Werkzeug, das niemand erklären kann. Das ist kein Argument gegen Vibe Coding, aber eines für eine bewusste Entscheidung, welche Werkzeuge übergeben werden und welche bewusst Wegwerfware bleiben.

Integration. Die meisten dieser Prototypen leben zunächst isoliert. Der Nutzen entsteht aber erst, wenn sie an vorhandene Systeme andocken – an das CRM, das ERP oder an ein TYPO3-Backend, in dem Inhalte und Redaktionsprozesse ohnehin gepflegt werden. Diese Anbindung ist der Teil, der Erfahrung mit Schnittstellen, Authentifizierung und Datenmodellen verlangt.

Leitlinien für den Einsatz im Unternehmen

Ein pragmatischer Rahmen verhindert, dass aus vielen kleinen Erfolgen eine unübersichtliche Schatten-IT wird:

  • Zwei Kategorien unterscheiden: Experimente mit Testdaten dürfen frei entstehen. Alles, was Echtdaten verarbeitet oder von mehr als einer Handvoll Personen genutzt wird, durchläuft eine Prüfung.
  • Testdaten zuerst: Prototypen mit anonymisierten oder erfundenen Datensätzen bauen. Die Frage, ob das Werkzeug taugt, lässt sich damit genauso beantworten.
  • Ein Verzeichnis führen: Wer hat was gebaut, welche Datenquellen sind angebunden, wer ist Ansprechperson? Eine einfache Liste genügt.
  • Übergabepunkt definieren: Ab wann übernimmt die IT oder eine Agentur? Sinnvolle Auslöser sind Echtdaten, externe Nutzung oder Abhängigkeit eines Geschäftsprozesses vom Werkzeug.
  • Prototypen bewusst verwerfen: Der Erkenntnisgewinn bleibt auch dann, wenn der Code neu geschrieben wird. Das ist oft günstiger, als eine gewachsene Bastellösung nachträglich zu härten.

Was sich für die Zusammenarbeit ändert

Für Dienstleister verschiebt sich die Rolle. Wenn Fachabteilungen ihre Ideen selbst bis zum lauffähigen Entwurf bringen, beginnt ein Projekt nicht mehr bei null, sondern bei einer konkreten Vorlage. Anforderungsworkshops werden kürzer, weil weniger Text und mehr Bildschirm besprochen wird. Gefragt sind dafür stärker die Fähigkeiten, die ein Prototyp nicht mitliefert: Datenmodellierung, Rechte- und Rollenkonzepte, Betrieb, Barrierefreiheit und die Anbindung an bestehende Systeme.

Realistisch bleibt: Prompt-getriebene Entwicklung senkt die Einstiegshürde, nicht die Anforderungen an ein Produktivsystem. Die Arbeit verschiebt sich vom Schreiben des Codes hin zum Beurteilen, Absichern und Einbetten.

Für Web- und Softwareprojekte heißt das konkret: Es lohnt sich, Fachabteilungen das Prototyping ausdrücklich zu erlauben und gleichzeitig eine klare Linie zu ziehen, ab wann ein Werkzeug in geordnete Bahnen gehört. Wer diese Linie früh definiert, gewinnt Tempo in der Ideenphase, ohne sich in zwei Jahren mit einer Sammlung unbetreubarer Insellösungen auseinandersetzen zu müssen. Der Prototyp ist dann das, was er sein sollte – ein sehr gutes Lastenheft.

Quellen