Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Lesedauer 4 Min.

Agent Experience: Warum gute APIs jetzt über Vertrauen in KI entscheiden

KI-Agenten stellen neue Ansprüche an Software. Dr. Franziska Horn erklärt im DWX-Interview, warum sauberes API-Design plötzlich über Vertrauen in KI entscheidet – und wo probabilistische Systeme ganz anders versagen als klassischer Code.

"Chatfunktionen sind im Grunde nur eine andere Form von User Interface", meint Dr. Franziska Horn wie beiläufig – und trifft damit den Kern ihres DWX-Talks "AI, Rewrite the Rules of UX". Denn wenn Menschen mit KI-Agenten in natürlicher Sprache interagieren, ändert sich zwar die Oberfläche. Was dahinter passieren muss, damit das funktioniert, ist aber vertraut: gute Schnittstellen, sinnvolle Fehlermeldungen, saubere Dokumentation. API-First-Design eben. Nur dass es jetzt nicht mehr nice-to-have ist, sondern die Voraussetzung dafür, dass ein KI-Agent mit bestehender Software überhaupt etwas anfangen kann.

Horn bringt dafür einen Begriff mit, der zunehmend neben User Experience steht: Agent Experience. Im Idealfall merkt der Mensch am Ende gar nicht mehr viel davon, dass im Hintergrund ein Agent arbeitet. Statt sich durch ein komplexes Tool wie Photoshop zu kämpfen und jede Funktion einzeln zu lernen, beschreibt man einfach, was man möchte – der Agent übernimmt den Rest. Klingt komfortabel. Ist es auch. Bringt aber ein Problem mit, das in der klassischen Softwareentwicklung längst gelöst schien: Vertrauen.

Vertrauen ist gut, Kontrolle ist besser

Bei Code ist das einfach, sagt Horn. Die Versionskontrolle zeigt mit Hilfe von Diff-Tools genau, welche Zeilen sich geändert haben, was hinzukam, was gelöscht wurde. Man sieht auf einen Blick, ob der Agent Unsinn gebaut hat. Bei anderen Anwendungen fehlt dieser Mechanismus komplett. Wie soll man bei einem Foto in Photoshop nachvollziehen, was ein Agent verändert hat – und wie sagt man ihm, dass er nur den Pickel im Gesicht wegretuschieren, den Rest des Bilds aber unangetastet lassen soll? Solche Review- und Rückgängig-Funktionen existieren größtenteils noch nicht. Sie müssen erst gebaut werden, damit Menschen den Ergebnissen von KI-Agenten überhaupt vertrauen können.

Gleichzeitig eröffnet KI auch Möglichkeiten, die vorher schlicht nicht umsetzbar waren. Automatische Objekterkennung in Bildern, Hintergründe freistellen, probabilistische Komponenten, die Aufgaben lösen, an denen klassische Programmierung bislang scheiterte – das sind laut Horn die eigentlich spannenden neuen Features, nicht nur die Chat-Oberfläche obendrauf.

Mit diesen probabilistischen Komponenten kommt allerdings eine andere Fehlerkultur ins Spiel. Klassische Software ist deterministisch: Sie funktioniert oder funktioniert nicht, Fehler sind sichtbar. Ein Sprachmodell dagegen liefert immer eine Antwort – die Frage ist nur, ob sie brauchbar ist. Wer solche Systeme entwickelt, braucht deshalb von Anfang an durchdachte Testfälle. Manchmal lässt sich eine Antwort klar als richtig oder falsch einordnen. Häufiger braucht es aber einen sogenannten LLM-as-Judge-Ansatz: Ein zweites Sprachmodell bewertet die Antworten des ersten und gleicht sie mit der gewünschten Qualität ab.

Der laufende Betrieb ist entscheidend

Testfälle sind aber nur die halbe Miete. Entscheidend wird es laut Horn erst im laufenden Betrieb – weil Nutzer sich selten an die Annahmen halten, mit denen ein Feature entwickelt wurde. Diese Erfahrung machte sie selbst vor rund zehn Jahren, bei einem Startup, das Chatbots entwickelte – lange bevor ChatGPT den Begriff bekannt machte, noch zu Zeiten, als Facebook diese Funktion gerade einführte. Wochenlang überlegte das Team, was Nutzer wohl schreiben würden und wie man darauf antworten sollte. Der Blick in die echten Logs war dann ernüchternd: 95 Prozent der Nachrichten waren schlicht Spam. Bevor an die eigentliche Funktion zu denken war, musste erst ein Spamfilter her.

Wer selbst in den Bereich einsteigen will, sollte laut Horn zunächst klären, in welche Richtung es gehen soll. Wer bereits bestehende Sprachmodelle nutzen will, braucht andere Grundlagen als jemand, der sich mit der Mathematik dahinter beschäftigen möchte. Und nicht jeder Anwendungsfall braucht überhaupt ein großes Sprachmodell: Bei tabellarischen Daten oder Sensordaten reicht oft ein deutlich einfacheres, ressourcenschonenderes Modell, das auch auf der CPU läuft und trotzdem gute Ergebnisse liefert. Wer etwa in der Industrie Predictive Maintenance umsetzen will, landet ohnehin bei ganz anderen Modellen als bei den klassischen LLMs, mit denen aktuell alle Welt arbeitet.

 

Dr. Franziska Horn ist selbständige KI-Architektin und Beraterin. Sie promovierte in Machine Learning an der TU Berlin und verbindet fundierte akademische Expertise mit über zwölf Jahren praktischer Erfahrung als Data Scientist und Tech Lead in Startups und Großunternehmen. Ihr Fokus liegt auf KI, die echten geschäftlichen Mehrwert schafft – statt Marketing-Schall und -Rauch. Sie geht ML-Projekte von Anfang an mit Blick auf den Produktionseinsatz an und entwickelt Lösungen, die über reine Prototypen hinausgehen und nachhaltige Wirkung erzielen.

 


Produktion: Event Wave, Patrizio De Mitri

Neueste Beiträge

Health Checks für Ressourcen - Health Checks in ASP.NET richtig nutzen, Teil 3
Wenn externe APIs stocken, Speicher knapp wird oder Ressourcen an Grenzen laufen, reicht ein grüner Gesamtstatus nicht mehr aus. Wie Health Checks näher an die tatsächlichen Betriebsrisiken heranrücken, ohne den Diagnose-Endpunkt unnötig aufzublähen.
4 Minuten
.NET-Color-Picker für WPF- und Avalonia-Applikationen - Best of NuGet, Teil 7
Mit PixiEditor.ColorPicker steht eine Bibliothek in den Startlöchern, die Entwicklern von Desktop-zentrierten Applikationen verschiedene hochwertige Farbauswahldialoge zur Verfügung stellt.
6 Minuten
20. Jul 2026
Vom Figma-Entwurf zur Projektstruktur - UX goes Dev, Teil 4
Der erste Schritt zur Anwendung: Mit der KI-Funktion Figma Make lässt sich aus einer einfachen App-Idee in wenigen Minuten ein klickbarer Prototyp entwickeln – hier gezeigt am Praxisbeispiel eines digitalen Fotobuches.
6 Minuten
16. Jul 2026

Das könnte Dich auch interessieren

C#-.NET-Apps mit WinUI 3 - Komponentenbasierte Apps mit Fluent/FAST, Teil 3
Microsoft macht mit WinUI 3 ein natives User-Experience-Framework für Windows verfügbar, dessen Komponenten auf dem Microsoft-eigenen Design-System Fluent 2 basieren.
23 Minuten
13. Mai 2024
GitHub Copilot mit Markdown-Dateien steuern
GitHub Copilot liest Markdown-Dateien, die an bestimmten Orten im System oder im Projekt liegen. Wer diese Dateien gezielt einsetzt, gibt Copilot dauerhaften Kontext – ohne ihn bei je-dem Chat-Start neu erklären zu müssen.
5 Minuten
22. Jun 2026
Cursor als KI-Turbo für Fluent UI Blazor - Die KI-IDE Cursor in der Praxis, Teil 4
Die auf VS Code basierende KI-IDE Cursor eignet sich für die Entwicklung mit Microsoft Fluent UI Blazor. Für eine effizientere Arbeit mit dem KI-Agenten existiert inzwischen ein MCP-Server aus dem Fluent-UI-Blazor-Umfeld.
7 Minuten
24. Jun 2026
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige