Agentische Arbeit, ein Jahr später

Es gab eine Zeit, in der ein KI-Vorschlag maximal ein paar Zeilen Code war. Heute schreibt der Agent ein Skript, führt es aus, sieht den Trace, korrigiert und fragt nach, und das nicht in einer Spielwiese, sondern in der gleichen Shell, in der auch du arbeitest. Zwölf Monate nach dem ersten produktiven Einsatz ist es an der Zeit, ehrlich Bilanz zu ziehen.

Auf den Punkt

Wer die Lesezeit für die nächsten zehn Minuten nicht hat, hier die Verdichtung in einem Absatz: Iteration ist billig geworden, Kontext ist die neue Test-Suite, Vertrauen wächst durch Korrekturen, nicht durch Akzeptanz. Wer einen Agenten produktiv einsetzen will, gibt ihm eine eingegrenzte Werkzeugkiste, explizite Akzeptanzkriterien und ein hartes Stoppsignal. Wer die Domäne nicht versteht, bekommt am Ende schneller Unsinn. Wer das alles befolgt, gewinnt Stunden zwischen Architekturentscheidung und erstem lauffähigen Verschnitt. Wer es ignoriert, gewinnt ein System, das unter Last bricht.

Glossar

Begriff

Agent

Bedeutung

Ein KI-System, das nicht nur Text erzeugt, sondern autonom Werkzeuge aufruft, deren Ergebnisse beobachtet und auf dieser Basis weitere Schritte plant. Im Unterschied zu einem reinen Chat-Modell hat ein Agent typischerweise Zugriff auf eine Shell, ein Dateisystem oder externe APIs.

Begriff

Session

Bedeutung

Ein zusammenhängender Arbeitsablauf mit dem Agenten, von der ersten Aufgabe bis zum expliziten Abschluss. Sessions können je nach Tool zwischen einer und mehreren Stunden dauern; Kontext und Tool-History bleiben innerhalb der Session erhalten.

Begriff

Tool-Call

Bedeutung

Der Aufruf eines definierten Werkzeugs durch den Agenten, typischerweise mit benannten Argumenten und einem definierten Rückgabewert. Ein Tool-Call ist die kleinste beobachtbare Aktion eines Agenten, und die wichtigste Stelle, an der Protokolle (siehe Der Prompt-Beitrag) definiert werden müssen.

Begriff

Distribution Shift

Bedeutung

Die schleichende Verschiebung zwischen der Datenverteilung, mit der ein Modell trainiert wurde, und der Verteilung, in der es heute eingesetzt wird. Wer einen Agenten über Monate betreibt, erlebt diesen Drift regelmäßig, oft unbemerkt, bis ein Output auffällt.

Was sich wirklich verändert hat

Drei Beobachtungen aus der Praxis, die ich in Was still bleibt bereits angedeutet habe und die sich seither verfestigt haben.

Iteration ist billig geworden. Früher kostete ein "probieren wir es kurz anders" einen Checkout, einen Commit, ein Review. Heute ist es ein Tastendruck und eine Beobachtung. Die Zahl der Iterationen pro Session hat sich verdoppelt, die durchschnittliche Sitzungsdauer ist gleich geblieben. Das ist kein Effizienzgewinn, das ist eine Änderung des Tempos, in dem Entscheidungen sichtbar werden.

Kontext ist die neue Test-Suite. Wer mit einem Agenten arbeitet, lernt schnell, dass das Modell nicht deshalb versagt, weil die Frage zu schwer ist, sondern weil der Kontext zu eng war. Eine Architekturentscheidung, die im Kopf klar ist, muss explizit gemacht werden, sonst halluziniert der Agent eine plausible Variante, die nicht deine ist.

Vertrauen kommt aus Korrekturen, nicht aus Akzeptanz. Die spannendste Beobachtung: ein Workflow, in dem der Agent zehn Mal hintereinander einen falschen Vorschlag macht und ich zehn Mal korrigiere, ist vertrauensbildender als einer, in dem er einmal richtig liegt. Der Grund liegt auf der Hand, ich sehe seine Fehlermuster und lerne, wo er zuverlässig ist.

Die drei Agent-Formen, die ich unterscheide

Im Alltag haben sich drei Formen heraus kristallisiert, die ich konsistent verwende. Sie unterscheiden sich nicht in der zugrunde liegenden Technologie, sondern in der Rolle, die der Agent einnimmt.

Der Recherche-Agent

Wirft eine breite Frage in den Kontext und bekommt strukturierte Antworten mit Verweisen auf konkrete Stellen. Ich nutze ihn für "wie funktioniert X in Bibliothek Y" und "gibt es einen Standard für Z". Sein Output ist fast nie 1:1 übernommen, sondern liefert die Landkarte, auf der ich mich bewege.

Der Implementierungs-Agent

Hat Zugriff auf die Shell und das Dateisystem, schreibt Patches, führt Tests aus und meldet zurück. Das ist das Profil, mit dem die meisten Schlagzeilen assoziiert sind. In der Praxis braucht es Disziplin: kurze Aufträge, klar definierte Akzeptanzkriterien, ein Abbruchkriterium, wenn die Iteration dreht.

Der Reflexions-Agent

Bekommt einen fertigen Diff und die Aufgabe, ihn zu kritisieren. Klingt nach Spielerei, hat sich aber als einer der wirksamsten Anwendungsfälle herausgestellt. Wer seinen eigenen Code dreißig Minuten lang angestarrt hat, sieht die blinden Flecken nicht mehr. Ein zweiter Blick von außen, und sei es von einem Modell, findet sie fast immer.

Wann das Modell scheitert

Nach einem Jahr fällt die Fehlerquote nicht auf Null. Sie konvergiert auf ein Niveau, das ich inzwischen gut einschätzen kann. Drei Muster, die immer wiederkehren:

• Kontextdrift über lange Sessions: ab etwa der fünfzigsten Tool-Aktion beginnt das Modell, Annahmen aus früheren Iterationen mitzuschleifen, die nicht mehr stimmen. Lösung: Session neu starten, alten Kontext als Notiz reingeben, weiter.
• Halluzinierte API-Signaturen: besonders bei kleineren Bibliotheken erfindet das Modell Funktionsparameter, die es nicht gibt. Lösung: das Modell anweisen, bei Unsicherheit die Quelle zu zitieren, und die Annahme verifizieren.
• "Sicherheits-Halluzinationen": das Modell weigert sich, harmlose Shell-Befehle auszuführen, weil es ein Risiko-Muster zu erkennen glaubt. Lösung: dem Agenten klare Policies mitgeben, statt ihn raten zu lassen.

Eine Konfiguration, die funktioniert

Was ich nicht mehr mache: dem Agenten ein leeres Terminal und einen vagen Auftrag geben. Was ich mache: ihm eine Aufgabe geben, die so formuliert ist, dass ein erfahrener Mensch sie in einer Sitzung lösen könnte. Drei Bausteine haben sich bewährt.

Eingrenzung des Werkzeugkastens. Der Agent bekommt nur die Tools, die er braucht. Wer "alle Dateien lesen, alle Tests laufen lassen, beliebige Skripte ausführen" erlaubt, bekommt eine kreative Kraft, die manchmal grandios und manchmal katastrophal ist. Eine eingegrenzte Toolbox ist langweiliger, aber vorhersagbarer.

Explizite Akzeptanzkriterien. "Mach das Modul lauffähig" ist zu vage. "Mach das Modul lauffähig, alle bestehenden Tests grün, neue Tests für die zwei Edge-Cases" ist konkret. Der Agent kann sich selbst überprüfen, und du kannst das Ergebnis überprüfen.

Ein Stoppsignal. Ein Wort oder ein Marker, bei dem der Agent abbricht und Rückfrage stellt, statt weiter zu iterieren. Das ist das einzige, was hilft, wenn der Agent in einer Schleife gefangen ist. Eine Sandbox kann das nicht leisten, weil der Agent innerhalb seiner Sandbox korrekt arbeitet, er kommt nur nicht zum Ziel.

Die Werkzeugkiste, die ich einem Agenten gebe

Eine Frage, die ich am Anfang jedes Projekts beantworte: was darf der Agent nicht? Das klingt defensiv, ist aber die produktivste Frage überhaupt. Eine Werkzeugkiste wird durch das definiert, was sie ausschließt.

In einem Web-Projekt gebe ich dem Agenten typischerweise Lesezugriff auf das Repo, einen eingeschränkten Schreibzugriff auf einen Branch, die Ausführung der Projekt-Test-Suite und einen Search-Tool für die Dokumentation. Was er nicht bekommt: Netzwerkzugriff, Schreibzugriff auf die Datenbank, Produktions-Credentials, destruktive Git-Befehle (force-push, Branch-Löschung, History-Rewrite). Diese vier Verbote haben in zwölf Monaten keinen nennenswerten Produktivitätsverlust verursacht, und sie haben drei Vorfälle verhindert, die sonst in echten Schäden geendet hätten.

Die Form, in der diese Verbote formuliert werden, ist wichtig. "Sei vorsichtig mit Datenbanken" ist zu vage. "Schreibzugriff auf die Produktion ist nicht erlaubt; jeder Versuch wird mit permission_denied quittiert" ist präzise. Die Regel ist: der Agent muss die Grenze technisch wahrnehmen, nicht ethisch verstehen. Ethische Regeln werden ignoriert, technische Grenzen halten.

Das gilt auch für die Output-Seite. Der Agent sollte nie direkt in einen Produktionskanal schreiben dürfen, weder einen Mail-Versand triggern, noch eine Datei ins Deployment-Verzeichnis legen, noch eine HTTP-Antwort an einen externen Service schicken. Sein Output landet immer zuerst in einem Review-Schritt, der von einem Menschen oder von einem deterministischen Validator ausgeführt wird. Das ist der Punkt, an dem der Agent aufhört, ein Werkzeug zu sein, und anfängt, ein Produktionssystem zu sein, und dieser Übergang verdient eine andere Architektur.

Eine letzte Beobachtung zur Toolchain, die sich aus den zwölf Monaten herausgeschält hat: die Liste der Werkzeuge, die ein Agent bekommt, korreliert invers mit der Qualität seiner Outputs. Je weniger Werkzeuge, desto besser die Ergebnisse. Das klingt kontraintuitiv, ist aber konsistent beobachtbar. Ein Agent mit drei präzisen Werkzeugen arbeitet besser als einer mit dreißig generischen, nicht weil er weniger kann, sondern weil er weniger entscheiden muss, welches Werkzeug das richtige ist. Die Auswahl selbst ist eine kognitive Last, die das Modell in jedem Schritt mitträgt. Wer sie ihm abnimmt, gibt ihm Kapazität für das eigentliche Problem zurück.

Drei Kennzahlen, die ich tracke

Wer einen Agenten über Monate betreibt, kommt ohne Metriken nicht weiter. Die Beobachtung "es fühlt sich schneller an" ist nicht verifizierbar und nicht entscheidungsrelevant. Drei Kennzahlen haben sich in meiner Praxis als minimal ausreichend herausgestellt, um den Zustand eines Workflows zu beurteilen.

Iterationen pro Session. Die Zahl der Tool-Calls, bis die Aufgabe gelöst oder abgebrochen ist. Sie schwankt zwischen 4 und 60; ein Anstieg über mehrere Sessions deutet entweder auf wachsende Aufgabenkomplexität oder auf nachlassende Modellqualität hin. Ich tracke den Median pro Projekt, nicht den Mittelwert, weil Ausreißer den Mittelwert schnell unbrauchbar machen.

Acceptance-Rate. Der Anteil der vom Agenten vorgeschlagenen Patches, der ohne Änderung übernommen wird. Eine gesunde Rate liegt zwischen 50 und 80 Prozent, darüber wird verdächtig (der Agent macht nur, was ich sowieso sagen würde), darunter wird teuer (ich werde zum Editor). Wer die Rate regelmäßig misst, sieht früh, wenn das Modell sich verändert oder der Kontext driftet.

Drift-Alerts. Die Anzahl der Sessions, in denen der Agent etwas Halluziniertes produziert hat, das im Review aufgefallen ist. Das ist die teuerste Metrik, weil sie manuell erfasst wird, aber sie ist die einzige, die eine Aussage über Qualität macht und nicht nur über Volumen.

Wer keine dieser drei Zahlen trackt, hat eine Meinung. Wer sie trackt, hat eine Grundlage für die nächste Architekturentscheidung.

Eine kleine Anekdote aus dem ersten Monat

Damit das nicht alles Theorie bleibt: ein konkretes Beispiel aus dem ersten Monat der produktiven Nutzung, das drei der oben genannten Punkte gleichzeitig demonstriert.

Ich hatte einem Agenten die Aufgabe gegeben, ein Auth-Modul zu refaktorisieren. Konkrete Vorgabe: "Zerlege die Datei auth.js in drei Module, Token-Generierung, Middleware, Session-Storage, und führe alle bestehenden Tests grün." Klar formuliert, klare Akzeptanzkriterien, klingt unproblematisch.

Der Agent hat das in elf Tool-Calls erledigt. Die ersten acht waren überzeugend, Module sauber getrennt, Tests grün, sauberer Diff. Beim neunten Call wollte er "noch eine kleine Verbesserung" machen: er hat die Token-Generierung durch eine externe Bibliothek ersetzt, die er aus einem früheren Recherche-Call im Kontext hatte. Das war nicht Teil des Auftrags, war aber plausibel. Ich habe es durchgewunken.

Beim zehnten Call hat er bemerkt, dass die neue Bibliothek eine andere Default-Salt-Länge hat als unsere. Er hat das korrigiert. Beim elften Call hat er noch eine kleine Refactoring-Idee gehabt, die er gleich umgesetzt hat. Ich habe wieder durchgewunken.

Das Ergebnis: drei Commits, einer zu viel, einer mit subtil falscher Salt-Länge (die der Default der neuen Bibliothek war und die wir in unseren Compliance-Vorgaben explizit ausgeschlossen hatten), und ein ungetesteter Refactor. Zeitaufwand für die Nachbereitung: 90 Minuten. Zeitaufwand, wenn ich die Salz-Länge-Konfiguration im Auftrag explizit als Akzeptanzkriterium festgehalten hätte: null.

Diese Anekdote ist nicht spektakulär. Sie zeigt aber drei Dinge: Akzeptanzkriterien müssen erschöpfend sein, nicht nur ausreichend. Der Agent wird Initiativen ergreifen, die du nicht angefordert hast, und sie werden meistens harmlos, manchmal aber nicht sein. Und das Review jedes einzelnen Patches ist billiger als die Korrektur eines schlecht gemergten.

Was sich nicht verändert hat

Wer einen Agenten produktiv einsetzt, muss die Domäne selbst beherrschen. Das ist keine Übertreibung. Ein Agent kann nur innerhalb des Rahmens sinnvoll arbeiten, den sein Auftraggeber setzt. Wer die Architektur nicht versteht, bekommt einen Agenten, der die Architektur erfindet, und zwar eine, die auf den ersten Blick funktioniert und bei der ersten Lastspitze bricht.

Das ist auch der Grund, warum die Behauptung "Agenten ersetzen Entwickler" so oft daneben liegt. Sie ersetzen nicht das Urteil, sie ersetzen den Weg zum Urteil. Wer keins hat, bekommt am Ende schneller Unsinn.

Empfehlung für den Einstieg

Wer anfängt, mit einem Agenten zu arbeiten, sollte nicht mit dem schwierigsten Problem beginnen. Eine gute erste Aufgabe ist eine, die du selbst in zwanzig Minuten lösen würdest und an der du das Verhalten des Agenten beobachten kannst, ohne unter Druck zu stehen. Migrationen kleinerer Module, das Hinzufügen von Tests zu bestehendem Code, das Aufschreiben einer Architekturentscheidung in einem Dokument.

Sobald das Modellverhalten verlässlich ist, kann die Komplexität steigen. Davor nicht. Die Zahl der Stunden, die in einem zu ambitionierten ersten Projekt versenkt werden, ist konstant hoch, egal, wie gut das Modell ist.

Ein Wort zum Schluss

Ein Agent ist kein Teammitglied. Er ist auch kein Werkzeug im klassischen Sinn. Er ist etwas Drittes: ein Spiegel deiner eigenen Klarheit. Was du nicht weißt, zeigt er dir, indem er es falsch macht. Was du weißt, zeigt er dir, indem er es richtig macht und du verstehst, warum. Beides ist nützlich, solange du weißt, in welche Kategorie der aktuelle Output fällt. Wer diese Disziplin ernst nimmt, landet fast zwangsläufig bei der Frage, die in Prompt als Protokoll vertieft wird: was genau ist die Vereinbarung zwischen dir und dem Modell?

Weiterführend

Wer sich tiefer einlesen will, ohne bei null anzufangen, drei Anlaufstellen, die in den letzten Monaten tatsächlich geholfen haben:

• Anthropic, Building Effective Agents (Dezember 2024), eine der wenigen Schriften, die ehrlich zwischen Workflows und Agents unterscheidet und nicht beides in einen Topf wirft. Die Aufteilung in "Workflows sind deterministisch, Agents sind nicht" ist die nützlichste einzelne Erkenntnis daraus.
• Simon Willison, Agentic Coding Definitions, eine Begriffsklärung, die in der Community zirkuliert und mehr Klarheit schafft als die Marketing-Broschüren der Anbieter. Hilfreich vor allem, wenn man mit Nicht-Technikern über das Thema spricht.
• AWS, Bedrock AgentCore Documentation, die Dokumentation der eigenen Architektur, die ich als Referenz nutze, wenn ich überlege, welche Werkzeuge in welcher Reihenfolge exponiert werden sollten. Wenig Theorie, viel Konfiguration.

Wer mit einem konkreten Projekt anfängt, dem empfehle ich, diese drei Quellen in der genannten Reihenfolge zu lesen, und sich beim Lesen Notizen zu machen, welche Definition jeweils zur eigenen Situation passt. Das ist die produktivste Stunde Recherche, die ich in diesem Feld investiert habe.