Zum Hauptinhalt springen

Hype und Erwartung

Neue Technologien erzeugen fast immer starke Erwartungen. Das gilt auch für LLMs und agentische Systeme.
Diese Seite beschreibt typische Fehleinschätzungen, Erwartungskurven und Einführungsphasen. Ziel ist es, realistische Erwartungen für Teams, Führung und Governance zu schaffen.

Viele Diskussionen über KI bewegen sich derzeit zwischen zwei Extremen: überhöhten Produktivitätsversprechen auf der einen Seite und pauschaler Skepsis auf der anderen. Für Organisationen ist beides wenig hilfreich. Entscheidend ist eine nüchterne Einschätzung dessen, was diese Systeme tatsächlich leisten – und wie sich ihre Wirkung im organisationalen Alltag entwickelt.

Überversprechen in frühen Einführungsphasen​

In frühen Phasen der Einführung dominieren häufig sehr hohe Erwartungen.
Typische Aussagen sind etwa:

  • „Wir werden zehnmal produktiver.“
  • „Große Teile der Entwicklungsarbeit werden automatisiert.“
  • „Viele Rollen werden überflüssig.“

Solche Erwartungen entstehen oft aus eindrucksvollen Demonstrationen.
Ein Modell generiert in wenigen Sekunden funktionierenden Code, erstellt eine Pipeline oder erklärt eine komplexe Bibliothek. Diese Erlebnisse sind real – aber sie spiegeln nicht automatisch die Realität langfristiger Softwareentwicklung wider.

Der Grund liegt darin, dass Demonstrationen meist isolierte Probleme zeigen.
Sie abstrahieren von vielen Faktoren, die in realen Systemen eine Rolle spielen:

  • bestehende Architektur
  • technische Schulden
  • Systemgrenzen
  • Integrationen
  • organisatorische Abläufe
  • langfristige Wartbarkeit

Ein überzeugender Demo-Moment ist deshalb kein verlässlicher Indikator für nachhaltige Produktivität.

Warum Demo-Erfolge kein Reifeindikator sind​

LLMs sind besonders stark bei klar umrissenen Aufgaben:

  • kleine Funktionen generieren
  • Dokumentation erstellen
  • Konfigurationen erklären
  • Beispiele erzeugen

Diese Fähigkeiten lassen sich sehr gut demonstrieren.
In realen Systemen treten jedoch zusätzliche Anforderungen auf:

  • Konsistenz über viele Module hinweg
  • Architekturentscheidungen
  • Integration in bestehende Systeme
  • langfristige Wartung

Ein Prototyp kann in wenigen Stunden entstehen, während ein stabiles System oft über Jahre evolviert. Deshalb gilt:

Geschwindigkeit beim Prototyping ist kein Maßstab für die Stabilität eines Systems.

Typische Einführungsphasen​

Viele Organisationen durchlaufen bei der Einführung neuer Technologien ähnliche Phasen. Auch bei KI-Systemen lässt sich häufig ein wiederkehrendes Muster beobachten.

Hype​

In der ersten Phase stehen Begeisterung und hohe Erwartungen im Vordergrund.

  • viele Experimente entstehen
  • neue Tools werden eingeführt
  • interne Erfolgsgeschichten verbreiten sich schnell

Diese Phase ist wichtig, weil sie Aufmerksamkeit erzeugt und Innovation ermöglicht. Gleichzeitig sind Erwartungen oft noch nicht durch praktische Erfahrung kalibriert.

Einsatz​

In der zweiten Phase beginnen Teams, die Technologie im Alltag zu nutzen.

  • Entwickler integrieren KI in ihre Arbeitsprozesse
  • erste Automatisierungen entstehen
  • reale Erfahrungen werden gesammelt

Hier zeigt sich meist, dass manche Aufgaben deutlich schneller werden, während andere unverändert bleiben oder neue Aufwände entstehen.

Ernüchterung​

Mit zunehmender Nutzung werden auch Grenzen sichtbar.

Typische Beobachtungen sind:

  • generierter Code muss sorgfältig überprüft werden
  • Architekturprobleme verschwinden nicht
  • zusätzliche Review- und Verifikationsaufwände entstehen

Diese Phase kann sich wie ein Rückschritt anfühlen, ist aber häufig der Punkt, an dem Organisationen beginnen, wirklich zu lernen.

Integration​

In der letzten Phase stabilisieren sich Nutzungsmuster.

  • Teams entwickeln Best Practices
  • sinnvolle Einsatzbereiche werden klarer
  • unrealistische Erwartungen verschwinden

KI wird dann nicht mehr als revolutionäre Lösung betrachtet, sondern als Werkzeug innerhalb etablierter Engineering-Praktiken.

KPI-Illusionen​

Ein häufiges Problem in frühen Einführungsphasen ist die Verwendung ungeeigneter Kennzahlen.

Viele Organisationen messen zunächst leicht sichtbare Größen:

  • Anzahl generierter Codezeilen
  • Geschwindigkeit von Prototypen
  • subjektive Zufriedenheit der Entwickler
  • wahrgenommene Geschwindigkeit

Diese Kennzahlen können jedoch ein verzerrtes Bild erzeugen.

Ein höherer Output bedeutet nicht automatisch:

  • bessere Architektur
  • weniger Komplexität
  • stabilere Systeme
  • schnellere Produktentwicklung

Hier ist die Unterscheidung zwischen Output und Outcome entscheidend.

  • Output beschreibt die Menge produzierter Artefakte.
  • Outcome beschreibt den tatsächlichen Wert für Produkt, Nutzer und Organisation.

LLM-Unterstützung kann Output deutlich erhöhen.
Ob daraus auch ein besseres System entsteht, hängt von vielen weiteren Faktoren ab.

Leitlinien für realistische Erwartungssteuerung​

Organisationen profitieren davon, wenn sie die Einführung von KI bewusst gestalten.

Einige hilfreiche Leitlinien sind:

Erwartungen klar kommunizieren

KI ist ein leistungsfähiges Werkzeug, aber kein Ersatz für Engineering-Prinzipien.

Prototypen und Produktion unterscheiden

Erfolge im Experimentiermodus sollten nicht automatisch auf produktive Systeme übertragen werden.

Qualität weiterhin priorisieren

Architektur, Tests, Review und Systemverständnis bleiben zentrale Bestandteile professioneller Softwareentwicklung.

Lernen ermöglichen

Einführungsphasen sollten als Lernprozesse verstanden werden, nicht als einmalige Transformation.

Eine realistische Erwartungshaltung schafft die Grundlage dafür, die tatsächlichen Stärken von LLMs zu nutzen – ohne ihre Grenzen zu ignorieren. Die folgenden Abschnitte betrachten daher genauer, welche empirischen Erkenntnisse Studien liefern und wo diese Systeme in der Praxis tatsächlich einen Unterschied machen.