Thomas Immich ist Unternehmer, Trainer und Berater und unterstützt Unternehmen bei der menschzentrierten Automatisierung ihrer Prozesse mittels KI-Agenten.
KI-Agenten übernehmen zunehmend Aufgaben entlang der gesamten digitalen Produktionsstraße – von der Codegenerierung über die Prozessautomatisierung bis hin zur kontinuierlichen Verbesserung. Während Teil 1 dieser Artikelserie die grundlegende Verschiebung durch agentische Rollen skizzierte und Teil 2 den Wandel vom Produkt zur Produktion nachzeichnete, geht in diesem letzten Teil nun um die Frage, wie sich Effizienz, Individualisierung und Qualität in Einklang bringen lassen. Adaptive Interfaces, simulationsgestützte Variantenbildung und automatisiertes Testing treffen auf menschliche Rahmengebung – und eröffnen neue Spielräume für eine wirklich menschzentrierte Produktentwicklung.
Individuelle Anpassung
Wer an individuelle Anpassungen denkt, hat nicht zwangsläufig das Stichwort Minimalismus im Sinn. Doch aus menschzentrierter Sicht ist jedes Produkt-Feature, für das kein Nutzungsbedürfnis besteht, eine kognitive Last und digitale Schwelle. Das Anpassen einer Software an die Nutzenden hat daher viel mit "Weglassen" zu tun. Die Reduktion von Features wird zum eigentlichen Ziel.
Die moderne Softwareentwicklung hatte vor der KI-Ära bereits einige Strategien, um ein digitales Produkt für bestimmte Zielgruppen mit mehr oder weniger Features auszustatten.
Doch es gibt bei der Anwendung dieser Strategien langfristig ungelöste und daher klassische Probleme: Geschieht die Reduktion von Features während der Programmlaufzeit über sogenannte Feature Flags, muss der Quellcode viele konditionelle Programmteile enthalten, die es zu überblicken gilt. Das wirkt sich negativ auf den Speicherbedarf und die Performance des Programms aus.
Der Einsatz von Feature Flags widerspricht im Kern dem Pull-Prinzip des Lean Manufacturing. Dieses Prinzip fordert eine bedarfsorientierte, ressourceneffiziente Produktion entlang konkreter Nachfrage. Überträgt man den Feature-Flag-Ansatz auf die industrielle Fertigung, entspräche das etwa dem Bau eines Fahrzeugs mit einem 360-PS-Motor, obwohl lediglich ein kleiner Teil der Kundschaft diese Leistung benötigt. Für die Mehrheit müsste die Leistung anschließend künstlich gedrosselt werden – ein Vorgehen, das sowohl Material als auch Energie verschwendet und den Prinzipien schlanker Produktion zuwiderläuft.
So absurd das Beispiel klingt, wird dieser Ansatz in manchen Teilen der industriellen Produktion sogar tatsächlich gewählt, weil die Mehrkosten, einer flexibleren Produktionsstraße die Mehrkosten für kastriert eingebaute Komponenten übersteigen würden. Ich persönlich halte den Ansatz aus Nachhaltigkeitsgesichtspunkten für äußerst fragwürdig, denn es müssen dennoch die entsprechen Rohstoffe aufgebraucht und nach dem "End of Life" des Produktes entsorgt werden. Und auch aus menschzentrierter Sicht bin ich kritisch, denn Nutzende könnten zurecht das Gefühl bekommen, für etwas zu zahlen, das sie bereits besitzen, was in der Folge äußerst negativ auf die User Experience des Produktes einzahlen dürfte.
Reduktion durch Bauvarianten
Eine alternative Strategie sieht vor, nicht benötigte Funktionen erst gar nicht in das finale Produkt aufzunehmen, sondern sie bereits während der Bauzeit wegzulassen. Diesen Bau-Varianten-Ansatz bildet die Softwareentwicklung bereits heute über komplexe Delivery-Pipelines ab. Dass der Begriff "Pipeline" aus der industriellen Produktion stammt, ist hierbei natürlich kein Zufall.
Der Aufbau und die Verwaltung effektiver und gleichzeitig flexibler Delivery-Pipelines ist komplex und wird mit der Anzahl der Produktvarianten zunehmend anspruchsvoller. Geht man vom UX-Idealfall aus, also einer 1:1-Personalisierung der Software für jeden einzelnen Nutzenden, müsste für jeden dieser Nutzenden eine eigene Produktvariante erstellt werden, die nur diejenigen Features enthält, die individuell relevant sind – ein Set an Funktionen, das sich im Laufe der Nutzung leider sogar verändern wird, denn mit zunehmender Erfahrung im Umgang mit dem Produkt entwickeln sich neue Bedürfnisse. Power-User stellen daher ganz andere Anforderungen als Newbies.
(Bild: ipopba/stock.adobe.com)
Der Product Owner AI Day von iX und dpunkt.verlag zeigt dir am 6. November 2025, wie du als Product Owner, Product Managerin oder mit deinem Team KI konkret in deine Arbeit integrieren kannst – von der Discovery bis zum Rollout. Tickets sind zum Frühbucherpreis erhältlich.
Im Extremfall hat also jeder einzelne Nutzende sein über die Zeit angepasstes individuelles Set von Bedürfnissen und benötigt daher auch sein entsprechendes Set an Features.
In fernerer Zukunft wird sich sicherlich zeigen, wie KI-Agenten hyper-individualisierte Produkte für einzelne Nutzende autark maßschneidern oder User Interfaces sogar während der Bedienung adaptiv "fortschreiben". Doch welche Möglichkeiten ergeben sich, wenn eine solche Hyper-Individualisierung aktuell noch keine Option ist?
Zielgruppen-Simulation als agentische Schlüsselkompetenz
Ein Product Owner muss entscheiden, wo die Bedürfnisse verschiedener Nutzender so deckungsgleich sind, dass man sie in einer Produktvariante zusammenfassen kann und wo sie sich so stark unterscheiden, dass man besser unterschiedliche Varianten ansetzt. Diese Analyse ist sehr zeitaufwendig, weil die Beteiligten immer wieder verschiedenste Kombinationen durchspielen müssen.
Betrachtet man den Softwareentwicklungsprozess als Produktionsstraße, so lohnt es sich also in der KI-augmentierten Zukunft, eine Station vorzusehen, an der KI-Agenten herausfinden, welche Produktvarianten es minimal geben muss, um die maximale Zahl Nutzender glücklich zu machen.
Hier kommen KI-Agenten in Form von Personas, also virtuellen Nutzenden, zu Hilfe. Wie am Beispiel des Podcasts UX Therapy AI im ersten Teil der Artikelserie gezeigt, können KI-Persona-Agenten direkt miteinander sprechen, um herauszufinden, wo gemeinsame und wo sich widersprechende Bedürfnisse liegen.
Diese Art von Simulation plausibler Gesprächsausgänge ist ein komplexer Prozess, der emergente Ergebnisse liefert und sich daher nur schwerlich von einem Menschen durchspielen lässt. Per statischer Formel berechnen kann man die möglichen Gesprächsausgänge nicht, da sie eine Folge komplexer LLM-Operationen sind.
TinyTroupe simuliert die Interaktionen zwischen verschiedenen Rollen als autonome KI-Agenten (Abb. 1)
(Bild: Microsoft)
KI-Agenten als Akteure innerhalb einer LLM-Simulation zu verwenden (sogenannte Sims), ist inzwischen ein so vielversprechender Ansatz, dass Microsoft daraus ein eigenes Open-Source-Projekt mit dem Namen TinyTroupe aus der Taufe gehoben hat.
In einem weiteren Schritt könnten KI-Agenten die verschiedenen Bauvarianten nicht nur vorschlagen, sondern auf Basis einer Referenzvariante direkt implementieren. Als flexible Code-Generatoren sind sie somit Teil der automatisierten Software-Produktionsstraße, ähnlich wie humanoide Roboter voraussichtlich bald in der Güterproduktion. Es lohnt sich demnach doppelt, die Optimierung von Produktvarianten in Zeiten von KI-Agenten neu zu denken.
English (US) ·