KI-Einführung braucht Change-Management

Ich halte einen Workshop über 4 Tage. Ein Team von etwa 10 technisch versierten Personen, Sys-Admins und Softwareentwicklern. Und ein Geschäftsführer, der selbst sehr nah am Entwicklungsprozess ist. Der Wunsch, sich in die Welt der KI-gestützten Softwareentwicklung zu begeben, aber auch viele Fragen. Wie sieht es mit unserem Intellectual Property und Datenschutz aus? Machen wir uns hier gerade selbst unnötig? Und wie garantieren wir, dass der Output nicht kompletter Müll ist?

Der verlockende Irrtum

In diesem Fall ging der Geschäftsführer bewusst anders vor. Ihm war klar, dass es nicht reicht, den Entwicklern eine Lizenz für Claude Code zu geben, und zu erwarten, dass sich der Rest schon von selbst erledigt. Das höre ich leider oft aus meinem beruflichen und privaten Umfeld.

Viele, vor allem große Companies, entlassen Hunderte oder Tausende Entwickler, hoffend, dass die KIs das schon ausgleichen würden (oder schieben das als Grund vor). Dann die harte Realität: Rehiring zu höheren Kosten, Bugs und Verlust von Kunden, Schädigung der Marke. Das Ziel sollte sein, durch KI die Qualität zu erhöhen, Lücken zu schließen… nicht die wichtigste Ressource, die Wissensträger, loszuwerden.

Was haben wir gemacht

Erstmal einen Tag lang alle auf einen Stand bringen. Wie funktioniert das alles überhaupt, auch hinter der UI oder dem CLI. Für manche vielleicht nur wiederholtes Wissen, aber eine gemeinsame Sprache und gefüllte Wissenslücken sind die Basis, um daraus etwas Nachhaltiges entwickeln zu können.

Am zweiten Tag wurde vielen klar, dass KI gar nicht das eigentliche Thema ist. Prozesse wurden diskutiert, Meetings hinterfragt. Und wie schreibt man gute Tickets? Wie läuft es aktuell, was ist das Ideal, das Ziel. Es geht nicht darum, Prozesse vorzuschreiben, sondern darum, Verständnis zu schaffen, warum sich Agiles Projektmanagement wie Scrum oder Kanban in der Branche etabliert hat.

Tag 3 brachte beides zusammen, mit einer in letzter Zeit immer häufiger genannten Technik, dem Spec Driven Development. Statt direkt Code zu erzeugen, wird zunächst die Spezifikation gemeinsam erarbeitet und iterativ verfeinert. Erst danach übernimmt die KI die eigentliche Implementierung. Auch der Rückblick auf die vorherigen Tage, warum wir hier den “Human in the Loop” beibehalten, sich vielleicht Aufwände verschieben, aber Softwareentwicklung mehr ist, als Code zu generieren.

Der letzte Tag dann nochmal mit einem Blick auf Trends, tokeneffiziente KI-Nutzung, offene Fragen der letzten Tage. Und, ganz wichtig, eine grobe Planung der nächsten 2 Wochen, die als Pilot-Sprint das Gelernte greifbar machen sollen.

Was haben wir gelernt

Vielleicht gab es hier und da die Erwartungshaltung, nach der Workshop-Woche direkt damit beginnen zu können, die KI zum Umsetzen der ersten Features zu nutzen.

Schon am ersten Tag wurde aber allen klar, dass hier noch so einige Hürden zu bewältigen sind. Wie stellen wir sicher, dass wir Datenschutz einhalten, Kunden- und Mitarbeiterdaten klar aus dem LLM raushalten? Genauso wichtig: Wie sieht es mit Intellectual Property aus? Wie schützt man geschäftskritische Algorithmen, und muss man das überhaupt? Ist die Codebasis frei von Credentials, und wie sieht es in der Git-History aus? Diese Diskussion sollte geführt werden, Fakten müssen gefunden und Entscheidungen getroffen werden. Ein Commitment aus dem Team ist nötig, das Verständnis der Technik und potentieller Konsequenzen vorausgesetzt.

Auch die Prozesse können nicht unverändert weiterlaufen. Ob es in Meetings neue Räume für KI-Themen geben wird oder sich die Ticketstruktur an einen kommenden Spec Driven Development Modus anpasst, das ergibt sich nicht von alleine, muss im Team entschieden und von allen mitgetragen werden.

Gerade das Spec Driven Development war gefühlt der größte Aha-Effekt, im Praxisteil wurde in mehreren Teams mit einer ähnlichen Aufgabe von allen Teilnehmern gespürt, dass hier Kontrolle entsteht, der Output vergleichbar, der Weg dahin dokumentier- und justierbar ist: Alles aber kein Vibe Coding.

Der Pilot-Sprint

Schon in den ersten Meetings wird klar, dass vieles im Workshop Gelernte von der täglichen Anwendung und Gewohnheit noch weit entfernt ist. Jedes Ticket ist anders, mal ein Feature, mal ein Bug. Fragen müssen gestellt und beantwortet werden, im Idealfall von allen, damit nicht jeder die Learnings nur für sich selbst macht.

Es geht um Change-Management, das ist Menschenarbeit, die einem keine KI abnehmen kann. Moderation ist hier nötig, und die benötigt Zeit und Gefühl für die Individuen, die am Change beteiligt sind. Es gibt Skeptiker, es gibt Early Adopter und ganz viel dazwischen, und alle müssen mitgenommen und gehört werden. Die Theorie und die technischen Möglichkeiten müssen ins Team und die Prozesse integriert werden, da gibt es auch keine allgemeingültige Vorlage, sondern nur eine exakte Anpassung und ständige Adaption des Gelernten.

Die Arbeit beginnt erst

Das Wissen ist verteilt, Sorgen wurden ernst genommen und besprochen, in vielen Bereichen wurden diese bestimmt auch neutralisiert. Durch praktische Anwendung wurde motiviert, gezeigt, dass auch Chancen entstehen, die bisher noch nicht da waren. Probleme wurden aufgedeckt, die inhaltlich gar nicht im Vordergrund standen, aber eine geplante Veränderung macht diese oft deutlicher, als direkt auf diese zu zeigen.

Der Pilot-Sprint läuft gerade noch, und dieser ist ein bewusstes erstes Experiment, bei dem man genau zuhören und zusehen muss, wo es hakt, um Lösungen zu finden. Danach wird es aber auch noch längere Zeit brauchen, bis alles zur Gewohnheit geworden ist, jeder die Sicherheit hat, die Prozesse richtig anzuwenden. Und in einer aktuellen KI-Welt, in der schon nach ein paar Wochen geglaubte Standards komplett ersetzt wurden, ist es umso wichtiger, dies auch als dauerhaften Change zu begreifen, der immer wieder auf den Alltag einwirkt und nicht ignoriert werden kann.