Maschinelles Lernen ML, Künstliche Intelligenz KI, Rebound und Backfire

Es hat mich umgehauen: als Hochschuldozent lehre ich seit vielen Jahren psychologische Fächer wie Arbeits‑ und Organisationspsychologie, Werbepsychologie (Recruitingprobleme? In den beschriebenen Experimenten und Resultaten finden Sie Ansätze für die Lösung) oder auch an der IHK‑Akademie das Fach „Führung und Zusammenarbeit“. Dazu kommen die inferenzmathematischen Grundlagen, durch die sich alle Studierende der Psychologie durchquälen müssen. Als ich aus beruflichen Gründen begann, mich in die Themenfelder des Maschinellen Lernens ML und der Künstlichen Intelligenz KI einzufuchsen, rieb ich mir verwundert die Augen: die Grundlagen sind die selben wie in der Psychologie. Mit Clustering entschlüsselte man das Motivsystem und selbst die Idee für neuronale Netze stammt aus den 1960ern. Nur das Fach „Diskrete Mathematik“ mit der Graphentheorie, dem „Rechnen mit Resten“ und den darauf aufbauenden Kryptografiethemen hebt sich deutlich ab. Die Seminargestaltung war ein Klacks und so darf ich seither regelmäßig im VDI in Stuttgart schulen und hatte auch die Ehre, bei Mercedes in Stuttgart tätig werden zu können. Cool!

In Zusammenhang mit ML/KI und DevOps haben sich, marketingmäßig recht schlau, weitere Ops-Konstrukte wie DataOps, MLOps und AIOps entwickelt. Wie ist das Ganze einzuordnen? Der Hype um die phantastischen Berufsaussichten von „Prompt Engineers“ ist jedenfalls ziemlich klar beendet. Ein Anhängen von „Engineering“ oder „Ops“ an irgend ein Substantiv ist erst einmal Marketing und hat nicht unbedingt viel Fundamentalbedeutung. Für nachhaltig taugliche Entscheidungen im Berufs‑ und Unternehmensbereich wird man genauer hinschauen und ggf. auch aktuell recherchieren müssen.

Angesichts dessen, dass die vollständige und umfassende Aufnahme und umsetzbare Dokumentation der Anforderungen des Kunden erfahrungsgemäß eine entscheidende Schwachstelle von Projekten darstellt und Coding nur die nachgelagerte Ausführung ist: könnte es sein, dass unser Fokus auf KI‑Coding bisweilen von den auswirkungsmächtigsten Stellschrauben ablenkt? „Shit in, shit out“ gilt auch zwischen Requirements Engineering und Coding. Bauen wir zusätzlich KI ein, sollten wir sehr sorgfältig darauf achten, dass wir nicht Missverständnisse automatisiert in Code mit hoher Entropie übertragen. Grundsatz: KI erstellt Inhalte, die plausibel aussehen und damit Vertrauen erzeugen. Probleme ploppen erst später im SDLC aus den Tiefen an die Oberfläche hoch. Die damit ursprünglich früher einmal befassten Entwickler arbeiten dann schon längst in einem anderen Unternehmen, wenn sie Glück haben oder ihre Karriere schlau planen.

Im Folgenden einige ausgewählte, stichpunktartige Aspekte zum Thema.
Dass man mit den auf neuronalen Netzen und Agentensystemen basierenden großen Sprachmodellen tolle Sachen machen kann, haben die meisten inzwischen praktisch erfahren: mächtige Werkzeuge leicht gemacht, Prompting und fertig. In meinen Seminaren z.B. beim VDI „Python+KI mit Tensorflow“ oder wvib „KI‑Express“ spüre ich eine rasch wachsende und begrüßenswerte Anwendungskompetenz seitens der Industrievertreter (leider bleiben ‑innen eine seltene Ausnahme). Daher hier einmal eine andere Sicht auf die Dinge:

Nehmen wir an, in einem Unternehmen wird KI eingesetzt, um aus im Unternehmen vorhandenen digitalen Daten relevante Informationen und Dokumente zu gewinnen. KPI‑Dashboards etwa, oder Angebote an Kunden oder was‑auch‑immer. Es ist zu erwarten, dass Menschen normale Handlungsmuster ausführen: Rebound und Backfire. Wenn die KI alles aus allem herausfischen kann, gibt es beispielsweise keinen Grund mehr, Daten aus Besuchsberichten oder E‑Mails ins CRM oder ein Data Warehouse einzupflegen. Die natürliche Intelligenz erschlafft zügig, die Datenqualität folgt auf dem Fuße. Irgendwann explodieren die Probleme, das schlagartig nötige Refactoring wird anspruchsvoller als ohnehin schon. Muss nicht passieren, kann aber. Es handelt sich dabei ja auch lediglich um eines von vielen möglichen Szenarien absehbarer Technikfolgen.

Vorsicht ist bei allzu euphorisch betriebenen Hypes sowieso geboten: in der iX 6/2026 erfahren wir von folgendem Experiment: Sechzehn erfahrene Entwickler mit jeweils über 1 Mio. Zeilen Code wurden zufällig in zwei Gruppen eingeteilt. Beide bearbeiteten 246 praxisnahe Aufgaben, eine Gruppe mit und die andere ohne Coding‑KI. Ergebnis: mit KI‑Unterstützung sank die Produktivität um 19%. Die erfahrenen Entwickler glaubten jedoch, 20% schneller gewesen zu sein. Eine Wahrnehmungsverzerrung um satte 39 Prozentpunkte. Auch nach Bekanntgabe des Messergebnisses blieben sie bei ihrer (falschen) Einschätzung. Eine andere Experimentalstudie berichtet von rund 30% Verschlechterung. Forscher an der Stanford University fanden weiterhin heraus, dass Entwickler mit Zugang zu KI‑Assistenten „signifikant unsichereren Code schrieben“ und genau das Gegenteil glaubten. Auch für die Bereiche Betrieb und Wartbarkeit des V‑Modells und DevOps zeichnen sich entsprechende Ergebnisse ab.

„A Fool with a Tool is still a Fool“
zugeschrieben dem Informatiker Grady Booch

Dass Bauchgefühl und Intuition nicht allzu gut funktionieren, hätten wir schon seit Jahrzenten aus einer Zahl des Statistischen Bundesamtes lernen können: der Scheidungsrate, die in Deutschland je nach Jahr um 40% liegt 😉. Das alles ist normal - unser Gehirn funktioniert so. Glücklicherweise haben wir heute eine Fülle an datenbasierten(!) Forschungsergebnissen der Psychologie und können unsere Situation deutlich verbessern - auch und insbesondere in Bezug auf Beziehungen zwischen Menschen. Im Beruf und privat. Führungskräfte können heute für ihren Hauptjob, dem des Sozialen Architekten, darauf bauen. Wenn sie denn offen genug sind für Persönlichkeitsentwicklung.

Bei der betrieblichen Anwendung von KI bekommt diese mentale Verzerrung eine neue Dimension: hier wird die Wettbewerbsfähigkeit der Zukunft entschieden. Einige Schlagsätze:

• Ohne Zweifel ist festzustellen, dass ein durchdachter(!), kompetenter(!) Einsatz von KI im gesamten SDLC Vorteile bringt.
• Urteil OLG Hamm, 12.5.2026: Unternehmen haften für irreführende Aussagen von KI‑Chatbots (verkürzt dargestellt). Es ist zu erwarten, dass die Zahl der Judikate stark zunimmt. Am Ball bleiben vor Entscheidungen!
• In vielen Anwendungsfällen ist Maschinelles Lernen den KI‑LLMs weit überlegen. Versuchen Sie mal, ein Neuronales Netz so zu trainieren, dass es Gleichungssysteme lösen kann. Sie brauchen dazu einen regelbasierten Agenten, z.B. via MCP angebunden. Oder nehmen wir die vorausschauende Wartung (predictive Maintenance): die Regression ist ungeschlagen. Insbesondere bei Zeitreihen müssen sich NN gleichfalls meist geschlagen geben. Eines von mehreren Zauberworten heißt hier „Feature Engineering“, gerne mit einer Laplace‑Transformation 😉.
• Anbieter von LLMs schreiben Milliardenverluste. Planen wir stets einen spontanen Disconnect mit Plan B ein.
• Chatmodelle nutzen unsere Eingaben in der gratis‑Version typischerweise zum Trainieren des Modells. Inhalte können extrahiert werden (z.B. der Fall Samsung).
• KI‑Codes mögen schnell lauffähig erscheinen. Die Wahrheit zeigen erst geeignete Testmetriken. Je mehr KI, desto automatisierter, feingranularer und umfänglicher sollten unsere Testverfahren sein.
• Wie irre teuer große LLMs sind, erfahren wir bei ersten Recherchen zum Self‑Hosting. Oft tun es Small Language Models SLM
• Entwickler stehen bei einem KI‑Code erst einmal vor einem Rätsel: Fehlerbehebung? Entropieminderung? Refactoring? Tauglichkeit für den gesamten SDLC?
• Superhilfreich sind die LLMs, wenn es beispielsweise darum geht, gemeldete Sicherheitslücken zu fixen. LLMs liefern uns den Kontext der Lösung, ohne dass wir Unternehmensgeheimnisse hochladen müssen.
• AI‑Tools zum Coden ploppen vielfach auf, eine aktuelle Recherche ist erforderlich zur Auswahl.
• Python wird sich vielfach als Nützlich erweisen, alleine schon aufgrund des großen Ökosystems. Mit Tensorflow können Sie z.B. selbst auf einem Billig‑Laptop ein NN (und vieles mehr) problemlos ans Laufen bringen.
• [...]

„Ich habe mehr Angst vor natürlicher Dummheit als vor künstlicher Intelligenz“
zugeschrieben u.a. Paolo Benanti

Das Thema ML/KI kann ich hier nicht in Ansätzen erschöpfend behandeln. Die mager geschilderten Aspekte sollen lediglich deutlich machen, dass es als Software Engineers unsere Aufgabe ist, ökonomisch sinnvolle von nicht sinnvollen Anwendungen unterscheiden zu können. Genau dazu sollte der Umgang mit Metriken (Messtechniken für Software) beherrscht werden. Zugleich brauchen wir natürlich ein gutes Verständnis der zeitlich weitgehend konstanten Grundlagen: Die oben stehende Grafik beispielsweise zeigt das bereits in den 1960ern skizzierte Neuron, heute Kern der modernsten KI‑Sprachmodelle. Wer die „ewigen“ Grundlagen versteht, wird von täglich neuen Werkzeugen nicht geblendet, sondern versteht schnell, weist steile Umsetzungskurven auf und bleibt am Geschäftsziel orientiert. Dies gilt für die hinter ML und KI stehenden Technologien so, wie ich es in meinen Kursen „Python‑Softwareentwicklung für KI mit Tensorflow“ im VDI oder „KI‑Express“ im Wirtschaftsverband wvib Freiburg vermittle - allerdings auch nur ein erster Start, der die Weiterentwicklung in Eigenregie initiieren kann, denn dieses Fachgebiet ist von großem Umfang und in einigen Sektoren von schnellem Wandel betroffen: Hardware, Software, Tools und Coding‑Strategien, Cybersecurity, Recht, Safety, Security und SotiF sind volatile Aspekte.

Reden wir jetzt darüber!