Entwicklung & Code
KI-Agenten, Teil 3: Adaptive Designs optimieren Entwicklung und Nutzererlebnis
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.
Entwicklung & Code
programmier.bar: Hackathons – von der Idee zum Prototyp
Die Begriffe Coding Jam, Game Jam und Hackathon sind unterschiedliche Namen für ein Format – aber alle mit einem Ziel: Mit maximalem Fokus in kürzester Zeit kreative Ideen konzipieren, entwickeln und testen.
In dieser Folge sprechen Dennis Becker, Dave Koschitzki und Jan Gregor Emge-Triebel über ihre Erfahrungen mit solchen Events. Sie verraten, welche ihrer Projekte den Sprung in die Öffentlichkeit geschafft haben und welche besser in der Schublade geblieben sind.
Sie diskutieren, warum regelmäßige Game Jams und Hackathons nicht nur für Spaß sorgen, sondern echte Innovation in ein Team und eine Firma bringen. Außerdem gibt es in dieser Folge Insights aus der Praxis, wie Lotum, das Unternehmen hinter dem programmier.bar-Podcast, teamübergreifende Coding-Events organisiert – und was andere Unternehmen davon mitnehmen können.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmung wird hier ein externer Inhalt geladen.
Die aktuelle Ausgabe des Podcasts steht auch im Blog der programmier.bar bereit: „Hackathons & Game Jams„. Fragen und Anregungen gerne per Mail oder via Mastodon, Bluesky, LinkedIn oder Instagram.
(mai)
Entwicklung & Code
Preisanstieg bei KI-Coding-Tools: The Free Lunch Is Over
Dienste wie Cursor, GitHub Copilot, Anthropic Claude Code oder Googles Gemini CLI helfen Entwicklerinnen und Entwicklern dabei, Code schneller zu schreiben, zu debuggen und Aufgaben zu automatisieren. Doch in den letzten Monaten hat sich ein klarer Trend abgezeichnet: Die Anbieter drehen an der Preisschraube. Großzügige Flatrates weichen zunehmend nutzungsbasierten Modellen und strengeren Limits. Für Poweruser entstehen teils erhebliche Mehrkosten.
Rainer Stropek ist IT-Unternehmer, Softwareentwickler, Trainer, Autor und Vortragender im Microsoft-Umfeld. Er ist seit 2010 MVP für Microsoft Azure und entwickelt mit seinem Team die Software Time Cockpit.
Dieser Artikel beleuchtet die aktuellen Entwicklungen bei den Preismodellen der genannten Tools, die Reaktionen der Community und die Frage, was das für Developer und Unternehmen bedeutet.
Cursor: Von der Flatrate zum Kredit-System
Der Editor Cursor vom gleichnamigen Start-up galt lange als einer der besten KI-Assistenzeditoren mit einem fairen, planbaren Preismodell. Bis vor Kurzem war im Pro-Abonnement für 20 US-Dollar im Monat ein Kontingent von 500 KI-Anfragen enthalten, weitere Requests waren gegen Aufpreis erhältlich. Dieses einfache Modell hat Cursor jedoch vor einigen Monaten ziemlich abrupt umgestellt und damit viele vor den Kopf gestoßen.
Ohne große Vorankündigung schaffte Cursor die feste Request-Grenze ab und versprach stattdessen „unbegrenzte Nutzung“ mit dynamischen Rate Limits. Was nach einer guten Nachricht klang, entpuppte sich schnell als Verschleierung einer massiven Kürzung. Aus den ehemals 500 enthaltenen Anfragen wurden plötzlich nur noch etwa 225 zum selben Preis.
Die unbegrenzte Nutzung galt zudem nur, wenn man dem System die automatische Modellwahl überließ. Wer gezielt ein bestimmtes Modell wie Claude Sonnet 4 auswählte, musste jeden Aufruf aus einem begrenzten Guthaben bezahlen. Die Community empfand dieses Vorgehen als Vertrauensbruch und sprach offen von Irreführung. In Reddit-Diskussionen fand sich der Vorwurf, Cursor habe „unlimited“ versprochen, aber stillschweigend stark limitiert.
Viele bemängelten außerdem, dass Cursor unter den neuen Rate Limits deutlich schlechtere Ergebnisse lieferte. Unter anderem hieß es in einem Beitrag, dass der KI-Assistent im begrenzten Modus oft mitten in der Aufgabe stoppte oder nur noch Teilaufgaben erledigte und dadurch mehrere Nachfragen erforderte. Benutzer haben den Verdacht geäußert, dass Cursor absichtlich die Ausgabe rationiert, damit man das inbegriffene Guthaben nicht zu schnell verbraucht. Wechselt man hingegen in die echte nutzungsbasierte Abrechnung, arbeitet das Modell plötzlich wieder wie gewohnt, allerdings zu entsprechend höheren Kosten. Das hat bei zahlenden Kundinnen und Kunden für viel Unmut gesorgt.
Besonders Poweruser von Cursor waren frustriert. Wer das Tool intensiv einsetzte, stieß deutlich früher an die Grenzen. Neben den Nutzungsgrenzen war auch die Agentenfunktion ein Grund dafür. Dieser Modus zerlegt komplexe Aufgaben in Teilschritte, führt aber auch dazu, dass ein einzelner Befehl Dutzende von API Requests im Hintergrund auslöst und massenhaft Token verbraucht. „Cursor hat mit seinem Agent die Formel geändert, sodass riesige Mengen Credits verbraucht werden“ berichtet ein Anwender auf Reddit. Diese Änderung führte dazu, dass manche Nutzer ihr Monatskontingent in wenigen Tagen verbrauchten.
Als Reaktion auf die Engpässe bot Cursor zwar neue, teurere Abo-Stufen für Vielnutzer an, kommunizierte dies aber kaum transparent. Plötzlich tauchte ein Pro+-Plan für 60 US-Dollar (dreifaches Limit) und ein Ultra-Plan für 200 US-Dollar (zwanzigfache Limits) auf. Dass Bestandskunden mehr zahlen sollten, um wieder auf das ursprünglich Gebotene zu kommen, stieß verständlicherweise vielen sauer auf. Der Begriff Enshittification für Plattformen, die im Laufe der Zeit ihre Leistungen verschlechtern, um Profit zu steigern, liegt nahe.
Cursor hat inzwischen eingeräumt, dass die Preisumstellung nicht gut gelaufen ist. Auf X erklärten die Gründer, man habe das Feedback gehört und das Ziel verfehlt. Fakt ist, dass das Vertrauen vieler früherer Fans erschüttert wurde. Zahlreiche Nutzerinnen und Nutzer sind zu Alternativen abgewandert oder ziehen dies in Betracht.
GitHub Copilot: Premium-Limits und Bezahlen nach Verbrauch
GitHub Copilot galt lange Zeit als „All you can eat“-Service für zehn US-Dollar im Monat. Im Abo waren unbegrenzt Codevervollständigungen und Chatantworten inklusive. Viele wunderten sich anfangs, wie Microsoft das Angebot wirtschaftlich gestalten will. Und tatsächlich kam im Juni 2025 die Wende: GitHub führte ein Limit für Premium Requests ein, das preislich in etwa dem entspricht, was vorher als unbegrenzt galt. Seit dem 18. Juni 2025 hat jeder zahlende Copilot-Kunde pro Monat ein Kontingent von Premiumanfragen, dessen Umfang vom konkreten Preisplan abhängt. Alles darüber hinaus kostet extra.
Unter Premium Requests versteht GitHub alle Anfragen an fortgeschrittene Modelle und Features außerhalb der GPT-Modellreihe von OpenAI. Dazu gehört insbesondere die Nutzung des für Coding besonders beliebten Modells Claude Sonnet innerhalb von Copilot. „Wollen Sie Claude oder Agent nutzen? Zählt als Premium“, fasste ein Nutzer das Vorgehen sarkastisch zusammen.
Das normale Coden mit den Basismodellen (GPT-4.1 und GPT-4o) bleibt zwar weiterhin unbegrenzt, doch alle anspruchsvolleren KI-Funktionen zählen zum Limit des jeweiligen Preisplans. Beim Überschreiten der Grenze fallen für jede weitere Anfrage 0,04 US-Dollar an, oder Copilot stellt die teuren Dienste ein, wenn man kein zusätzliches Budget freigibt. Microsoft hat dafür eigens ein Budgetmanagement in GitHub integriert: Team-Admins können ein monatliches Kostenlimit setzen und optional festlegen, dass Copilot nach Erreichen des Budgets automatisch stoppt. Standardmäßig ist das Zusatzbudget auf 0 US-Dollar eingestellt, sodass man ohne aktives Opt-in nicht mehr ausgeben kann als den Preis für das Basis-Abo.
Für Poweruser gibt es zudem einen neuen Copilot-Pro+-Plan für 39 US-Dollar im Monat, der 300 statt 1.500 Premium Requests enthält. Auch Business- und Enterprise-Kunden haben höhere Kontingente entsprechend ihrer Lizenz, müssen aber ebenfalls für Mehrverbrauch zahlen.
Viele Bestandskunden fühlen sich vor den Kopf gestoßen. Insbesondere die Kommunikation von Microsoft steht in der Kritik. Lange Zeit wurde Copilot Pro als „unbegrenzt“ beworben. Die plötzliche Einführung einer 300er-Grenze empfinden etliche zahlende Nutzerinnen und Nutzer daher als Lockangebot mit anschließendem Wechsel der Bedingungen. Der oben zitierte sarkastische Reddit-Beitrag zum Premium-Modell erhielt viel Zuspruch. Dabei bemängeln User auch, dass GitHub zum Rollout der Limits kaum Transparenz bot. So gab es anfangs keine verlässliche Möglichkeit, den eigenen Verbrauch einzusehen. Dass viele lediglich die Meldung „No usage found“ erhielten, wenn sie ihre Statistiken abrufen wollten, hat das Misstrauen verstärkt. In den offiziellen GitHub-Foren häuften sich Kommentare wie „Es fühlt sich an, als hätte man Pro nur beschnitten, um Pro+ attraktiver zu machen“.
Für Profi-Anwenderinnen und Anwender bedeutet die Änderung vor allem mehr Planungsaufwand und gegebenenfalls höhere Kosten. GitHub wirbt zwar damit, dass alle bezahlten Pläne weiterhin unbegrenzte Vervollständigungen und Chat enthalten, aber wer das volle Potenzial von Copilot ausschöpfen will, beispielsweise mit den Claude-Modellen im Agent Mode, kommt mit 300 Anfragen pro Monat, also knapp 15 Anfragen pro Arbeitstag, nicht weit. viele Entwickler stoßen nun regelmäßig an dieses Limit.
Microsoft ermöglicht mit dem Budgetfeature zumindest, Kosten bewusst zu kontrollieren. Unternehmen können die Copilot-Nutzung so überwachen. Doch letztlich führt kein Weg daran vorbei, für intensivere Nutzung tiefer in die Tasche zu greifen, entweder durch den Wechsel auf teurere Pläne oder durch das Pay-as-you-go-Modell.
Die Stimmung in der Copilot-Entwicklergemeinschaft ist geteilt. Manchen ist klar, dass die KI-Flatrate wirtschaftlich nicht haltbar war. Andere hingegen sind frustriert über die Verschlechterung des Angebots. Auffällig ist, dass Microsoft die Einführung der Limits aktiver kommuniziert hat als Cursor oder Anthropic. Es gab Blogbeiträge, Seiten in der Dokumentation und Hinweise in den FAQs. Dennoch blieb für viele unklar, was genau als Premium zählt. Aus der Dokumentation geht beispielsweise nicht klar hervor, dass der Agent Mode von Copilot intern oft viele einzelne Requests, sogenannte Tool Calls ausführt, und wie sich diese Aufrufe auf das Kontingent von Premium Requests auswirken. Für die Poweruser markieren die Änderungen am Preisplan von GitHub Copilot das Ende der sorglosen Copilot-Nutzung.
Entwicklung & Code
Docker: Sicherheitsalptraum MCP – sechs Lücken identifiziert
Die Containerplattform Docker warnt vor Sicherheitsrisiken, die sich durch die Nutzung von MCP-Quellen ergeben und Angreifern leichten Zugriff auf Dateien, Datenbanken, Netzwerk und Secrets eröffnen. Außerdem können die Täter weitreichend Befehle absetzen und schädlichen Code einschleusen.
Der Blogbeitrag kritisiert das von Anthropic letztes Jahr eingeführte und inzwischen weitverbreitete Model Context Protokol (MCP) als auf Komfort und nicht auf Sicherheit angelegt. „Es ist zu einem Sicherheitsalptraum geworden, der Unternehmen dem Risiko von Datenverlust, Kompromittierung der Systeme und Angriffen auf die Lieferkette aussetzt.“ Dabei betont der Text, dass diese Annahmen nicht auf Spekulation beruhen, sondern auf der „Analyse tausender MCP-Server, die systematische Schwachstellen in sechs kritischen Angriffsvektoren aufgedeckt hat“. Als Schutz empfiehlt Docker unter anderem den hauseigenen Katalog gehärteter MCP-Images.
Schadcode über OAuth
Tatsächlich untermauert der Blogeintrag seine Annahmen mit vielen Hinweisen auf Studien von Sicherheitsfirmen, die MCP untersucht haben. Als erstes Problem nennt Docker schadhafte OAuth-Prozesse, die bösartigen Code in Clients einschleusen können. Laut der zitierten Studie sind 43 Prozent der analysierten Server davon betroffen. Ein Beispiel war ein inzwischen behobenes Problem im viel genutzten Paket mcp-remote, mit dem sich Clients bei entfernten MCP-Servern anmelden können.
Als weitere Probleme nennt Docker das Einschleusen und Ausführen von Befehlen, uneingeschränkter Netzzugriff, Zugriff auf das Dateisystem, den Missbrauch von Tools sowie das Aufdecken von Secrets. Diese finden sich unter Umständen in unsauber implementierten Umgebungsvariablen, Logfiles oder Prozesslisten.
Anwenderinnen und Anwender sollten MCP-Quellen immer genau prüfen und auch im Betrieb überwachen, welche Rechte sie einfordern und auf welche Ressourcen sie zugreifen. Bei offenen Quellen lässt sich beispielsweise nach Stichwörtern wie eval()
oder exec()
suchen. Die Server sollten ferner keine Credentials als Umgebungsvariablen benötigen.
(Bild: Titima Ongkantong/Shutterstock)
Am 30. September und 1. Oktober findet die heise devSec 2025 in Regensburg statt. Auf der von iX, heise Security und dpunkt.verlag ausgerichteten Konferenz stehen in Themen wie Threat Modeling, Software Supply Chain, OAuth, ASPM, Kubernetes und der Einfluss von GenAI auf Security im Programm.
Der Autor des Blogbeitrags hat angekündigt, weitere Artikel zum Thema zu veröffentlichen.
(who)
-
Datenschutz & Sicherheitvor 2 Monaten
Geschichten aus dem DSC-Beirat: Einreisebeschränkungen und Zugriffsschranken
-
Online Marketing & SEOvor 2 Monaten
TikTok trackt CO₂ von Ads – und Mitarbeitende intern mit Ratings
-
Apps & Mobile Entwicklungvor 2 Monaten
Metal Gear Solid Δ: Snake Eater: Ein Multiplayer-Modus für Fans von Versteckenspielen
-
Digital Business & Startupsvor 1 Monat
10.000 Euro Tickets? Kann man machen – aber nur mit diesem Trick
-
UX/UI & Webdesignvor 2 Monaten
Philip Bürli › PAGE online
-
Digital Business & Startupsvor 1 Monat
80 % günstiger dank KI – Startup vereinfacht Klinikstudien: Pitchdeck hier
-
Apps & Mobile Entwicklungvor 1 Monat
Patentstreit: Western Digital muss 1 US-Dollar Schadenersatz zahlen
-
Social Mediavor 2 Monaten
LinkedIn Feature-Update 2025: Aktuelle Neuigkeiten