Agent Experience ist die neue DX

Developer Experience (DX) fragt, wie gut Menschen Ihre Tools nutzen können. Agent Experience stellt dieselbe Frage für Maschinen.

Diese Seite konzentriert sich auf KI-Coding-Agenten: Tools wie Claude Code, Cursor und individuelle agentische Workflows, die Code schreiben, ausführen und iterieren – mit unterschiedlichem Grad an menschlicher Aufsicht. Dieselben Prinzipien gelten überall dort, wo ein Modell stellvertretend für jemanden mit Software oder Infrastruktur interagiert.

Agent Experience ist eine Designdisziplin, keine Produktkategorie. Sie zeigt sich in APIs, Kommandozeilen-Tools, Dokumentation, Berechtigungen, Umgebungen, Fehlermeldungen, Logs und Feedback-Systemen. Die meisten dieser Oberflächen wurden ursprünglich für Menschen entworfen.

Gute Developer Experience (DX) verkürzt den Weg zwischen Absicht und nützlichem Ergebnis. Menschen profitieren von visueller Hierarchie, schrittweiser Offenlegung von Informationen, verständlichen Erklärungen und Oberflächen, die zum Erkunden einladen.

Agenten interagieren anders mit denselben Systemen. Ein Dashboard, das für visuelles Scannen konzipiert ist, liefert einer Maschine möglicherweise kaum nutzbare Informationen. Eine ausführliche Fehlermeldung kann einem Menschen helfen, den Kontext zu verstehen, zwingt einen Agenten aber dazu, Token darauf zu verwenden, Signal von Rauschen zu trennen. Eine interaktive Eingabeaufforderung kann eine CLI für einen Menschen einfacher machen, während sie einen automatisierten Workflow vollständig zum Stillstand bringt.

Design für beide Zielgruppen

Agent Experience ersetzt Developer Experience nicht. Softwaresysteme bedienen zunehmend beide.

Ein Entwickler kann einen Pull Request in einer visuellen Oberfläche prüfen, während ein Agent dieselbe Änderung über eine API abruft. Ein Entwickler kann ein vollständiges Build-Log einsehen, während ein Agent nur den fehlgeschlagenen Schritt und den relevanten Fehler anfordert. Eine Person bevorzugt vielleicht einen geführten Einrichtungsprozess, während ein Agent einen nicht interaktiven Befehl mit vorhersagbarer Ausgabe benötigt.

Gutes Tooling stellt dieselben zugrunde liegenden Funktionen in einer für jede Zielgruppe passenden Form bereit.

Entwicklertools sind seit Jahrzehnten davon ausgegangen, dass ein Mensch an der Tastatur sitzt: jemand, der ein Dashboard überblicken, etwas Unerwartetes bemerken, nach weiteren Informationen suchen und Mehrdeutigkeiten mit eigenem Urteilsvermögen auflösen kann.

Agenten verändern diese Annahme. Versionsverwaltungssysteme, Build-Infrastruktur, Paket-Registries, Cloud-Plattformen, interne APIs und Entwicklertools erhalten zunehmend Anfragen von Software, die stellvertretend für jemanden handelt.

Agenten werden zu Software-Nutzern

Agenten interagieren zunehmend direkt mit Systemen, die Entwickler früher manuell bedient haben.

Sie lesen Dokumentation, rufen APIs auf, führen Befehle aus, verändern Repositories, prüfen Logs, fragen Infrastruktur ab und lösen Workflows aus. Jede Schnittstelle auf diesem Weg beeinflusst, ob der Agent die Aufgabe zuverlässig abschließt.

Schlechte AX wird zu menschlicher Arbeit

Ein Agent, dem eine Wand aus unstrukturierter Ausgabe vorgesetzt wird, muss Zeit und Token darauf verwenden, herauszufinden, was wichtig ist. Eine mehrdeutige API-Antwort kann zu einem unnötigen erneuten Versuch oder zur falschen nächsten Aktion führen. Eine interaktive Eingabeaufforderung kann eine automatisierte Aufgabe stoppen und an einen Menschen zurückgeben.

Probleme summieren sich über einen Workflow hinweg. Schon ein kleines Maß an Mehrdeutigkeit bei jedem Schritt kann aus einer autonomen Aufgabe wiederholte Rückfragen, Überprüfungen und Aufräumarbeiten machen.

Bessere Modelle machen Interface-Design nicht überflüssig

Die Fähigkeiten von Modellen werden sich weiter verbessern. Teams haben deutlich direktere Kontrolle über die Systeme, mit denen Modelle interagieren: API-Schemas, Dokumentation, CLI-Verhalten, Logs, Berechtigungen, Umgebungen und Feedback.

Bessere Modelle können mit schlechten Schnittstellen effektiver umgehen, aber stärkere Schnittstellen verringern von vornherein, wie viel Schlussfolgern überhaupt nötig ist.

Plattform-Teams leisten bereits ähnliche Arbeit für Entwickler, indem sie über gemeinsame Infrastruktur klare Standardwege (Paved Paths) schaffen. Agentische Entwicklung bringt einen weiteren Nutzer mit, für den es zu gestalten gilt.

Agent Experience ist eine Eigenschaft jeder Oberfläche, die ein Agent zur Erledigung einer Aufgabe nutzt.

Bei einem Coding-Agenten kann eine einzige Änderung das Lesen von Dokumentation, das Abfragen eines Repositorys, das Ausführen von Befehlen, das Ändern von Dateien, das Aufrufen externer Tools, das Interpretieren von Testausgaben, das Prüfen des CI-Status und das Aktualisieren eines Pull Requests erfordern.

Den richtigen Kontext bereitstellen

Agenten brauchen Zugriff auf Informationen in einer Form, die sie zuverlässig abrufen und interpretieren können.

APIs profitieren von stabilen Schemas und strukturierten Antworten. Dokumentation profitiert von präzisen Beispielen, klarer Versionierung und kanonischen Anweisungen. CLI-Tools profitieren von maschinenlesbaren Ausgabemodi. Tool-Beschreibungen profitieren von präzisen Namen, Eingaben, Ausgaben und Grenzen.

Protokolle wie MCP machen Interface-Design besonders sichtbar. Eine Tool-Beschreibung beeinflusst, wann ein Agent ein Tool auswählt und wie er die Anfrage aufbaut.

Mehr verfügbarer Kontext führt nicht automatisch zu besserer AX. Relevanter Kontext schon.

Sicher handeln

Agenten brauchen vorhersehbare Wege, um ein System zu verändern.

Kommandozeilen-Tools sollten nicht-interaktive Ausführung, aussagekräftige Exit-Codes und Operationen mit klar definierten Ergebnissen unterstützen. Wo immer praktikabel, sollten wiederholte Befehle sicher sein oder doppelte Aktionen deutlich erkennbar machen.

Berechtigungen bestimmen, wie viel Autonomie ein Agent erhalten kann, ohne dass die Kosten eines Fehlers steigen. Eng gefasste Berechtigungsbereiche, Freigabegrenzen, isolierte Umgebungen und Richtliniendurchsetzung ermöglichen es Agenten, nützliche Arbeit zu leisten und gleichzeitig unbeabsichtigte Auswirkungen zu begrenzen.

Verstehen, was passiert ist

Ein Agent muss wissen, ob eine Aktion erfolgreich war, fehlgeschlagen ist oder einen unerwarteten Zustand erzeugt hat.

Maschinenlesbarer Status, konkrete Fehler, strukturierte Logs und expliziter Status erleichtern es, den nächsten Schritt zu bestimmen. Eine nützliche Fehlermeldung teilt dem Agenten mit, was fehlgeschlagen ist, wo der Fehler aufgetreten ist und was das System erwartet hat.

Vollständige Details sollten bei Bedarf weiterhin verfügbar sein. Sie müssen nicht die Standardantwort sein.

Status und Verlauf finden

Agenten benötigen oft Informationen, die ein Entwickler normalerweise durch das Öffnen einer anderen Oberfläche abrufen würde.

Welches Deployment läuft gerade? Welche Pipeline ist fehlgeschlagen? Was hat sich seit dem letzten Versuch geändert? Wurde der API-Aufruf abgeschlossen? Ist bereits ein Pull Request offen?

Wenn der Betriebsstatus programmatisch zugänglich gemacht wird, kann ein Agent diese Fragen beantworten, ohne auf einen Menschen angewiesen zu sein, der Informationen aus einem Dashboard übersetzt.

Eine bessere Agent Experience erfordert selten den kompletten Umbau einer Plattform rund um KI. Viele der wirkungsvollsten Änderungen machen bestehende Schnittstellen lediglich expliziter, strukturierter und vorhersehbarer.

1. Strukturierte Informationen zurückgeben

Bieten Sie maschinenlesbare Ausgaben für Workflows an, die ein Agent wiederholt nutzt.

Bei einer CLI kann das eine JSON-Ausgabe nach einem dokumentierten Schema bedeuten. Bei einer API bedeutet es stabile Antworttypen und explizite Fehlerzustände. Bei Dokumentation bedeutet es Beispiele, die ein Agent ausführen kann, ohne fehlende Annahmen selbst rekonstruieren zu müssen.

Menschenlesbare Ausgaben können weiterhin für Personen verfügbar bleiben. Agents profitieren zusätzlich von einem maschinenorientierten Zugang zu denselben Informationen.

2. Kontext direkt an der Quelle kuratieren

Geben Sie die für die aktuelle Entscheidung nötigen Informationen zurück statt jeder verfügbaren Information.

Wenn drei Tests fehlschlagen, benennen Sie die drei Fehler und liefern Sie die relevanten Details, statt Tausende Zeilen unzusammenhängender Ausgabe zurückzugeben. Wenn ein Vorgang an einem ungültigen Parameter scheitert, benennen Sie den Parameter und den erwarteten Wert direkt.

Filterung an der Quelle reduziert den Tokenverbrauch und verringert die Zahl der plausiblen Interpretationen, die ein Agent in Betracht ziehen muss.

3. Aktionen vorhersehbar und wiederholbar gestalten

Agentische Workflows wiederholen Vorgänge häufig, verzweigen sich in alternative Ansätze und kehren zu vorherigen Schritten zurück.

Idempotente Operationen machen Wiederholungen sicher. Klare Zustandsübergänge helfen einem Agent zu verstehen, ob etwas bereits geschehen ist. Ehrliche Exit-Codes und ein expliziter Status verhindern, dass der Agent Erfolg aus Fließtext ableiten muss.

Schutzmechanismen sollten möglichst im System selbst verankert sein. Berechtigungsgrenzen und Richtlinienprüfungen sind zuverlässiger, als darauf zu vertrauen, dass jeder Agent eine schriftliche Konvention entdeckt und befolgt.

4. Latenz als Teil der Schnittstelle behandeln

Feedback ist am nützlichsten, solange der Agent noch an der Aufgabe arbeitet, die es hervorgebracht hat.

Die akzeptable Latenz hängt vom Workflow ab. Eine lokale Syntaxprüfung muss möglicherweise nahezu sofort zurückkommen. Ein vollständiger Integrationstest kann länger dauern. Ein Deployment kann von Natur aus mehrere Minuten benötigen.

Entscheidend ist, ob das Timing zu der Entscheidung passt, die der Agent als Nächstes treffen muss.

5. Agent-Ergebnisse messen

Traditionelle UX-Kennzahlen beschreiben nicht vollständig, wie gut ein Agent mit einem System interagiert. Definieren Sie eine kleine Menge repräsentativer Aufgaben und führen Sie diese wiederholt aus, während sich Ihr Produkt weiterentwickelt.

Nützliche AX-Signale können sein:

• Wie oft der erste Versuch erfolgreich abgeschlossen wird
• Wie viele Wiederholungen oder Tool-Aufrufe eine Aufgabe erfordert
• Wie viel Zeit oder Inferenzbudget bis zur Lösung nötig ist
• Wie häufig ein Mensch eingreifen muss
• Welche Tools oder Schnittstellen fehlgeschlagenen Versuchen am häufigsten vorausgehen

Wenn ein wiederkehrender Fehler ein Schnittstellenproblem offenlegt, beheben Sie ihn und bewahren Sie den Fall als Regressions-Eval auf. Führen Sie diese Evals in der CI aus, zusammen mit Tests für agentenseitige Verträge wie API-Schemas, Tool-Definitionen, strukturierte Ausgaben, Exit-Codes und Berechtigungsgrenzen.

Eine Baseline ermöglicht es, eine echte AX-Verbesserung von einer Änderung zu unterscheiden, die einem menschlichen Prüfer lediglich sauberer erscheint.

Bei wiederkehrenden Fehlern ansetzen

Wählen Sie eine Aufgabe, die Ihre Agents häufig ausführen, und untersuchen Sie erfolglose Versuche von Anfang bis Ende.

Suchen Sie nach dem ersten Punkt, an dem dem Agent Kontext fehlte, er den Zustand missverstand, das falsche Tool wählte, mehrdeutiges Feedback erhielt oder menschliches Eingreifen nötig wurde.

Die nützlichsten AX-Verbesserungen setzen oft an einer vertrauten Softwareschnittstelle an statt im Modell selbst. Sobald Sie einen wiederkehrenden Fehler beheben, fügen Sie ihn Ihrem Eval-Set hinzu, damit Sie die Regression später erkennen können.

KI-Agenten sind nicht deterministisch. Zwei Versuche derselben Aufgabe können zu unterschiedlichen Denkpfaden, Tool-Sequenzen und Lösungen führen.

Das Interface-Design kann das Ausmaß der Variation, die diese Unterschiede erzeugen, entweder vergrößern oder verringern.

Ein Agent, der ein komplettes Job-Log erhält, hat viele mögliche Signale, denen er folgen kann. Ein Agent, der den relevanten Fehler, die betroffene Datei, das erwartete Verhalten und unterstützenden Kontext erhält, startet mit einer deutlich engeren Problemdefinition.

Die zweite Schnittstelle macht das Modell nicht deterministisch. Sie reduziert lediglich unnötige Mehrdeutigkeit.

Präzise Tool-Beschreibungen grenzen die Toolauswahl ein. Stabile Schemas verringern den Interpretationsspielraum. Expliziter Zustand reduziert das Rätselraten. Klar definierte Berechtigungsgrenzen begrenzen die verfügbaren Aktionen.

Gute AX gestaltet das umgebende System so, dass Modellvariabilität weniger Raum hat, sich in fehlerhaftes oder teures Verhalten zu verwandeln.

Die oben genannten Prinzipien gelten für den gesamten Software-Stack. CircleCI konzentriert sich auf einen bestimmten Teil der Agent Experience: wie Agents während der Softwareentwicklung nützliches Validierungsfeedback erhalten und wie Teams von Agents generierte Änderungen unabhängig validieren, bevor diese Änderungen ausgeliefert werden.

Codegenerierung wird schneller und günstiger. Jede zusätzliche Änderung braucht trotzdem einen Nachweis, dass sie die Anforderungen für Merge und Deployment erfüllt.

Der Ansatz von CircleCI verbindet schnelles Feedback innerhalb der Arbeitsschleife des Agents mit unabhängiger Validierung in der CI.

Ein Coding-Agent kann schnell eine plausible Änderung erzeugen. Die Bewertung dieser Änderung kann deutlich mehr Aufwand erfordern.

Ein bestandener Test liefert einen nützlichen Beleg, sagt aber nur aus, dass die durchgeführten Prüfungen bestanden wurden. Eine Änderung kann einen Test bestehen und trotzdem an anderer Stelle eine Regression verursachen, das falsche Problem lösen oder eine andere Anforderung verfehlen, die die aktuelle Testsuite nicht abdeckt.

Agentische Entwicklung erhöht die Bedeutung von sowohl schnellem Feedback als auch unabhängiger Validierung. Agents brauchen genug Signal, um während der Arbeit effizient zu iterieren, und Teams brauchen eine umfassendere Validierungsebene, bevor Code geteilt wird oder deploybar ist.

Wir verwenden Merge-Qualität, um zu beschreiben, ob eine Änderung ausreichend belegt ist, um die Anforderungen des Teams für einen Merge zu erfüllen, statt ein einzelnes bestandenes Signal als Beweis für Korrektheit zu behandeln.

Die CI bietet einen unabhängigen Ort, um diese Belege zu sammeln und durchzusetzen.

Agentische Softwareentwicklung läuft über zwei Feedback-Kreisläufe.

Der innere Kreislauf

Der innere Kreislauf ist das, was passiert, während ein Agent aktiv an einer Änderung arbeitet:

schreiben → ausführen → prüfen → beheben → wiederholen

Der Agent hat das Problem, die Implementierung und die letzte Tool-Ausgabe noch im aktiven Kontext. Schnelle Validierung hilft hier, Probleme vor einem Push oder Pull Request zu erkennen.

Der äußere Kreislauf

Der äußere Kreislauf beginnt, sobald die Änderung die gemeinsame Delivery-Infrastruktur erreicht.

Dazu können die CI/CD-Pipeline, Integrations- und Systemtests, Sicherheitsprüfungen, Reviews, Deployment und die Verifizierung nach dem Deployment gehören.

Der äußere Kreislauf erfüllt einen anderen Zweck. Seine Ergebnisse werden von Entwicklern, Agenten, Reviewern und nachgelagerten Systemen gemeinsam genutzt. Er liefert unabhängige Nachweise zu einer Änderung – unabhängig von der Umgebung, in der sie entstanden ist.

Die Kreisläufe verbinden

Eine starke Agent Experience sorgt dafür, dass nützliches Feedback zwischen beiden Kreisläufen fließt.

Ein Fehler, der im inneren Kreislauf erkannt wird, lässt sich oft sofort beheben, solange der Agent noch den vollständigen Arbeitskontext hat. Ein von der CI gefundener Fehler sollte mit genügend strukturierten Informationen an den Agenten zurückgehen, damit dieser die Aufgabe fortsetzen kann, ohne das gesamte Problem neu erschließen zu müssen.

Das Ziel ist nicht, jede Prüfung aus dem äußeren Kreislauf in den inneren zu verschieben. Es geht darum, jeden Kreislauf in seiner eigenen Aufgabe gut zu machen und die Übergabe zwischen ihnen effizient zu gestalten.

CircleCI entwickelt agentenorientierte Schnittstellen für beide Kreisläufe, damit Agenten Code früher validieren, aussagekräftigeres Feedback von der CI erhalten und auf Fehler reagieren können, ohne dass ein Entwickler die Ergebnisse erst übersetzen muss.

1. CI-taugliche Validierung im inneren Kreislauf

Chunk-Sidecars führen gezielte Validierung für betroffenen Code in einer isolierten Umgebung durch, noch vor dem Push.

Der Agent kann Änderungen im Arbeitsverzeichnis validieren, während er die Implementierung noch im Kontext hat, ohne auf die vollständige CI-Pipeline zu warten. Sidecars sind darauf ausgelegt, CI-taugliches Feedback in unter einer Minute zu liefern – für Prüfungen, die in den inneren Kreislauf gehören.

Schnelle Validierung im inneren Kreislauf erkennt einfache Probleme näher an ihrem Ursprung und hält den äußeren Kreislauf frei für tiefere, gemeinsame Prüfungen.

2. Aussagekräftigere Validierung im äußeren Kreislauf

Smarter Testing nutzt Test-Impact-Analyse, um die von einer Änderung betroffenen Tests auszuführen, verteilt die Testausführung intelligent auf verfügbare Rechenkapazität und kann Fehlschläge erneut ausführen, um Flaky Tests zu identifizieren.

Agentische Entwicklung kann die Anzahl der Änderungen und Validierungszyklen erhöhen, die durch die CI laufen. Die schnelle Ausführung der relevantesten Tests hält das Feedback auch bei wachsendem Volumen nützlich.

Weniger Flaky Tests und unnötige Testausführungen geben Agenten und Entwicklern zudem ein klareres Signal, ob eine Änderung Aufmerksamkeit erfordert.

3. Fehler aus dem äußeren Kreislauf zurück in den Kontext bringen

Ein CI-Fehler nützt einem Agenten am meisten, wenn die relevanten Informationen direkt in seine Arbeitsumgebung zurückfließen können.

Die CircleCI-CLI unterstützt ein --failure-report-Flag, das einen fehlgeschlagenen Job auf die Informationen reduziert, die ein Agent zur Diagnose benötigt, ohne zuerst das komplette Log auswerten zu müssen.

CircleCI unterstützt außerdem Fix with Claude Code, das eine strukturierte Fehlerzusammenfassung aus einem fehlgeschlagenen CircleCI-Lauf zurück an Claude Code im Terminal sendet.

Der äußere Kreislauf erkennt das Problem. Der Agent erhält den relevanten Kontext, schlägt eine Lösung vor, und die CI validiert die nächste Änderung unabhängig.

4. Agenten direkten Zugriff auf CircleCI geben

Die CircleCI-CLI bietet eine maschinenorientierte Schnittstelle zu CircleCI mit strukturierter JSON-Ausgabe, Fehlerberichten, Pipeline-Operationen und Deployment-Tools.

Der CircleCI-MCP-Server stellt CircleCI-Tools direkt für MCP-kompatible Agenten bereit. Agenten können Pipeline-Status abrufen, Fehler und Testergebnisse untersuchen, Workflows erneut ausführen, Pipelines auslösen und weitere unterstützte Operationen durchführen, ohne dass ein Entwickler Informationen manuell zwischen Systemen verschieben muss.

Für neue Projekte kann circleci onboard ein Repository analysieren, eine Start-Konfiguration für CircleCI generieren und das Projekt mit CircleCI verbinden.

Zusammen ermöglichen diese Schnittstellen es Agenten, direkt am Delivery-Workflow teilzunehmen, während CircleCI eine unabhängige Validierungsebene rund um den von ihnen erzeugten Code bleibt.

Gute Agent Experience beginnt damit, Agenten als Nutzer deines Produkts zu behandeln. Gib ihnen relevanten Kontext, vorhersehbare Handlungsmöglichkeiten, einen expliziten Systemzustand und Feedback, das die nächste Entscheidung klar macht.

Beginne mit einem häufig genutzten Workflow und mache ihn End-to-End für einen Agenten nutzbar. Teste repräsentative Aufgaben wiederholt und mache aus wiederkehrenden Fehlern konkrete Verbesserungen an der Schnittstelle. Agent-Evals und Contract-Tests können Teil deines CI-Feedback-Loops werden und dir helfen, AX-Regressionen zu erkennen, während sich dein Produkt weiterentwickelt.

Mit CircleCI kann sich AX bis in den Delivery-Workflow selbst erstrecken. Coding-Agenten können auf strukturierte CLI-Ausgaben und MCP-Tools zugreifen, Änderungen im inneren Kreislauf validieren und aussagekräftigeres Feedback von der CI im äußeren Kreislauf erhalten, sodass sie weiterarbeiten können, ohne dass ein Entwickler die Ergebnisse übersetzen muss.

Baue AX in dein Produkt ein und mache es zu etwas, das du kontinuierlich testest und verbesserst.