# Warum AI-Einführungen scheitern ## Der falsche Startpunkt Viele Organisationen wissen, dass sie mit AI etwas tun müssen. Was fehlt, ist ein belastbarer Einstieg. Nicht aus Skepsis, sondern aus Verantwortung. Statt etwas zu bauen, wird erklärt. Statt Verantwortung zu verankern, wird vorbereitet. "AI-Einführungen" starten dort, wo sie nicht wirken können: auf Papier. ## Warum „Einführung“ in die Irre führt Der Begriff "Einführung" suggeriert, dass etwas vorbereitet, erklärt und anschliessend ausgerollt werden kann – wie ein neues Tool oder eine Methode. AI-native Software Engineering funktioniert so nicht. AI wirkt nicht in Konzepten, sondern dort, wo Software tatsächlich entsteht. Solange nichts gebaut wird, bleibt Verantwortung abstrakt, Entscheidungen lassen sich aufschieben, und Annahmen bleiben ungeprüft. ## Ohne reale Arbeit bleibt alles abstrakt Strategien, Programme und Guidelines folgen einer vertrauten Logik: erst Klarheit schaffen, dann handeln. Diese Logik verschiebt die reale Auseinandersetzung mit diesem hochkomplexen, fundamentalen Thema immer weiter nach hinten. Verantwortung lässt sich nicht an Konzepte delegieren. Sie wird erst real, wenn Software existiert und laufen muss. ## Weil Strukturen und Regeln nicht mehr passen Sobald reale Systeme entstehen, prallen zwei Welten aufeinander: Organisationen, die auf saubere Übergaben, klare Linien, Planbarkeit und exakte Zuständigkeiten getrimmt sind – und kreative Arbeit, die gleichzeitig kontinuierliche Führung, Co-Creation und Innovation verlangt. Was aktuell in segmentierten Prozessen funktioniert (Stage-Gates, Abstimmungen, Handover), wird durch den neuen Setup auf einige wenige Engineers konzentriert. **Prozesse müssen neu gedacht, radikal vereinfacht und automatisiert werden.** Was bisher in getrennten Rollen funktionierte – Business-Analyse, Architektur, Testing, Betrieb – konzentriert sich beim Engineer. Nicht als Methode, sondern als Konsequenz: AI beschleunigt Code-Produktion, nicht Prozesse oder Team-Dynamik. Verantwortung verdichtet sich dort, wo Software gebaut wird. Strukturen und Prozesse müssen sich der Arbeit anpassen – nicht umgekehrt. ## Warum „alle mitnehmen“ nicht funktioniert Viele Organisationen versuchen die neue Realität mit Change Management abzufedern: alle mitnehmen, niemand überfordern, zuerst erklären. Das glättet aber nur die Oberfläche und geht nicht tief genug. Die wirkliche, tiefgreifende Veränderung im Software Engineering wird erst sichtbar, sobald reale Systeme laufen: - *Manche können nicht.* Die neue Rolle verlangt eine Breite, die nicht alle mitbringen: fachliche Anforderungen, Architektur, UX, Tests und Betrieb gleichzeitig im Blick halten. Jahrelange Spezialisierung wird zur Einschränkung. - *Manche wollen nicht.* 20 Jahre Erfahrung in einer Rolle – und jetzt soll das plötzlich weniger zählen? Sätze wie "Ausserdem schreibe ich sowieso viel besseren Code als eine Maschine!" werden laut. Diese Abwehr ist nachvollziehbar. Sie ändert aber nichts an der neuen Realität. - *Manche lassen sich nicht ein.* Technisch offen, aber nicht bereit, grundlegend anders zu arbeiten. AI schreibt den Code, fordert kontinuierliche Führung, lückenlose Aufmerksamkeit und Kontrolle; nicht punktuelle Anweisung. Lesen Sie mehr zur Veränderung im Software Engineering in unserem Beitrag AI vereinfacht Coding – Software Engineering wird anspruchsvoller ## Fazit Simple AI-Einführungen scheitern nicht an der neuen Technologie, sondern an einem falschen Anspruch: alle mitnehmen, nichts riskieren, erst erklären, dann handeln. Dieser Weg führt nirgendwo hin. Was stattdessen gebraucht wird, ist ein anderer Einstieg. Einer, der Verantwortung nicht theoretisch hält, sondern real werden lässt. Einer, der mit denen startet, die wollen, können und bereit sind. Wie dieser Einstieg aussieht, zeigt der nächste Beitrag Der richtige Einstieg in AI-native Software Engineering.