Warum dieselbe Aufgabe nicht dieselbe Lösung ergibt

Frag einen Coding Agent fünfmal dasselbe und du kannst mehrere unterschiedliche, jeweils plausible Lösungen bekommen.

Das bedeutet nicht, dass bei fünf Versuchen zwangsläufig fünf völlig verschiedene Implementierungen entstehen. Häufig werden sich große Teile ähneln, insbesondere wenn die Aufgabe eng beschrieben ist und der vorhandene Code bereits starke Konventionen vorgibt. Es bedeutet auch nicht, dass Large Language Models reine Zufallsmaschinen wären, die bei jedem Durchlauf beliebig irgendwo abbiegen.

Die technisch wichtigere Aussage ist eine andere:

Es gibt keinen technischen Anspruch darauf, dass aus demselben Auftrag immer derselbe Lösungsweg und dieselbe Implementierung entstehen.

Für einfache Textgenerierung ist diese Eigenschaft schon lange bekannt. Bei Coding Agents bekommt sie jedoch eine zusätzliche Dimension. Ein Agent generiert nicht nur Text oder Code. Er durchsucht ein Repository, liest Dateien, entscheidet sich für Werkzeuge, führt Tests aus, interpretiert deren Ergebnisse und passt sein weiteres Vorgehen daran an.

Ein Agent produziert deshalb nicht nur eine Antwort. Er konstruiert einen Lösungsweg.

Genau hier wird die Vorstellung problematisch, agentische Softwareentwicklung funktioniere wie ein neues, besonders schnelles Fließband.

Der Mythos der Fließbandarbeit

Ein erheblicher Teil der Diskussion über AI-Produktivität lässt sich gedanklich auf ein sehr einfaches Modell reduzieren:

Ticket
  ↓
Agent
  ↓
vorhersagbare Bearbeitung
  ↓
Patch

Wenn dieses Bild stimmen würde, wäre ein Coding Agent vor allem eine neue Form der Automatisierung. Man könnte ihm immer mehr Tickets zuführen und müsste im Wesentlichen nur noch messen, wie schnell und kostengünstig er daraus Code produziert.

Für manche Aufgaben kommt die Realität diesem Modell durchaus nahe. Je enger die Aufgabe definiert ist, je stärker der Lösungsraum durch bestehende Strukturen eingeschränkt wird und je weniger Entscheidungen der Agent selbst treffen muss, desto ähnlicher können verschiedene Durchläufe werden.

Agentische Arbeit beginnt jedoch gerade dort interessant zu werden, wo der Weg zur Lösung nicht vollständig vorgegeben ist.

Anthropic unterscheidet deshalb zwischen Workflows, bei denen Modelle und Tools entlang vorab definierter Codepfade orchestriert werden, und Agents, bei denen das Modell selbst bestimmt, wie es eine Aufgabe bearbeitet und welche Tools es dafür verwendet. OpenAI beschreibt Agents ähnlich als Systeme, in denen ein Modell den Workflow steuert, Entscheidungen trifft und abhängig vom aktuellen Zustand dynamisch Werkzeuge auswählt.

Das ist mehr als eine begriffliche Feinheit.

Ein fest verdrahteter Workflow entscheidet nicht während seiner Ausführung neu, welcher Weg vermutlich sinnvoll ist. Ein Agent tut genau das.

Ein Agent ist keine Ticket-zu-Patch-Maschine mit garantiert identischem Produktionsmuster.

Agentic Work ist daher weniger mit einem Fließband als mit einer Folge von Entscheidungen unter sich veränderndem Context vergleichbar.

Was Determinismus in klassischer Software bedeutet

In der Softwareentwicklung sind wir an Systeme gewöhnt, bei denen der Weg zwischen Eingabe und Ausgabe vollständig durch Code festgelegt ist.

Vereinfacht betrachtet:

Input
  ↓
Schritt A
  ↓
Schritt B
  ↓
Schritt C
  ↓
Output

Wenn dieselben Eingaben vorliegen und sich der relevante Zustand nicht verändert hat, erwarten wir denselben Ablauf und dasselbe Ergebnis.

Natürlich gibt es auch in klassischer Software zahlreiche Quellen für Unterschiede: Zeit, Parallelität, externe Services, Netzwerkzustände, zufällige Werte oder veränderte Datenbanken. Der entscheidende Punkt ist jedoch, dass wir diese Variabilität normalerweise als Teil des expliziten Systemzustands modellieren können. Der Algorithmus selbst entscheidet nicht spontan, heute lieber Schritt B2 statt Schritt B1 auszuprobieren, weil dieser Weg im aktuellen Moment plausibler erscheint.

Viele Automatisierungen leben genau von dieser Eigenschaft.

Ein Formatter soll bei derselben Datei dieselbe Formatierung erzeugen. Ein Compiler soll aus demselben Quelltext unter denselben Bedingungen dasselbe Programm erzeugen. Eine CI-Pipeline soll nicht bei jedem Lauf neu überlegen, welche Qualitätssicherung sie diesmal für sinnvoll hält.

Für solche Probleme ist Determinismus ausgesprochen wertvoll.

Das erklärt zugleich, warum das mentale Modell eines Fließbands bei Agents so attraktiv ist. Softwareentwicklung hat über Jahrzehnte immer mehr wiederkehrende Arbeit in deterministische Prozesse verwandelt.

Ein Coding Agent ist jedoch kein weiterer fest codierter Schritt in dieser Entwicklung. Er bringt ein Modell in den Kontrollfluss, das innerhalb bestimmter Grenzen selbst auswählt, was als Nächstes sinnvoll erscheint.

Warum LLMs nicht wie eine klassische Funktion arbeiten

Ein Large Language Model kann man aus Anwendungssicht durchaus wie eine Funktion aufrufen:

const result = model(input);

Diese Schreibweise sollte jedoch nicht zu der Annahme führen, dass das System konzeptionell einer klassischen Funktion entspricht, die für denselben Input zwingend immer exakt denselben Output produziert.

Ein Sprachmodell berechnet für die mögliche Fortsetzung eines vorhandenen Contexts Wahrscheinlichkeiten. Vereinfacht gesagt existiert nicht nur das eine nächste Token, sondern eine Verteilung möglicher Fortsetzungen. Einige davon sind sehr wahrscheinlich, andere weniger wahrscheinlich, viele praktisch irrelevant.

Das Modell arbeitet deshalb nicht beliebig. Wenn wir nach einer TypeScript-Funktion fragen, wird es nicht mit gleicher Wahrscheinlichkeit ein Kochrezept oder einen mittelalterlichen Text erzeugen. Der vorhandene Context schränkt den Raum sinnvoller Fortsetzungen massiv ein.

Innerhalb dieses Raums können jedoch mehrere Fortsetzungen plausibel sein.

Sampling-Parameter wie temperature oder top_p beeinflussen, wie aus solchen Wahrscheinlichkeitsverteilungen ausgewählt wird. Sie können Varianz reduzieren oder erhöhen, sind aber nicht der eigentliche Gegenstand dieses Artikels. Auch Einstellungen, die Wiederholbarkeit verbessern, sollte man nicht mit einer allgemeinen Garantie identischer Ausgaben verwechseln. Für agentische Arbeit ist ohnehin entscheidender, was aus kleinen Unterschieden wird, sobald das Modell nicht nur formuliert, sondern den nächsten Arbeitsschritt auswählt.

Für unser mentales Modell reicht deshalb zunächst diese Aussage:

Nichtdeterminismus bedeutet nicht, dass ein Modell beliebig arbeitet. Es bedeutet, dass innerhalb eines Lösungsraums mehrere plausible nächste Schritte existieren können.

Bei einer einzelnen Antwort kann daraus unterschiedliche Wortwahl entstehen. Bei Code können zwei Implementierungen dieselbe Anforderung unterschiedlich strukturieren.

Bei einem Agenten passiert allerdings noch etwas wesentlich Interessanteres.

Von Token-Varianz zu Entscheidungs-Varianz

Ein Coding Agent erzeugt normalerweise nicht in einem einzigen Schritt den finalen Patch.

Er könnte zunächst die Verzeichnisstruktur betrachten. Danach sucht er nach einem existierenden ähnlichen Feature. Anschließend öffnet er vielleicht eine Facade, einen Store und einen Test. Oder er beginnt beim API-Contract. Vielleicht führt er zuerst einen bestehenden Test aus. Vielleicht sucht er nach einem Symbol. Vielleicht betrachtet er zunächst die Git-Historie.

All diese Aktionen können sinnvoll sein.

Ein typischer Agent-Loop lässt sich stark vereinfacht so darstellen:

Task
  ↓
Entscheidung
  ↓
Aktion / Tool
  ↓
Beobachtung
  ↓
neuer Context
  ↓
nächste Entscheidung

Genau solche Schleifen gehören zu den zentralen Architekturmustern heutiger Agents. Das Modell entscheidet anhand des aktuellen Zustands, welche Aktion folgen soll, beobachtet deren Ergebnis und setzt die Bearbeitung mit dem dadurch erweiterten Wissen fort.

Damit wird aus der Varianz eines Sprachmodells eine neue Form von Varianz.

Der Unterschied besteht nicht mehr nur darin, ob eine Zeile Code auf zwei verschiedene Arten formuliert wird. Unterschiedlich kann bereits sein,

• welche Datei zuerst untersucht wird,
• welche Suche gestartet wird,
• welcher Test zuerst ausgeführt wird,
• welche Hypothese über die bestehende Architektur entsteht,
• welcher Fehler als relevant eingestuft wird,
• welches Tool als Nächstes benutzt wird.

Eine dieser Entscheidungen kann dazu führen, dass Informationen entdeckt werden, die in einem anderen Run zunächst gar nicht auftauchen.

Bei einem Agenten ist Varianz nicht nur Output-Varianz. Sie kann zur Prozessvarianz werden.

Das ist für das Verständnis agentischer Systeme erheblich wichtiger als die bloße Feststellung, dass Sprachmodelle probabilistisch generieren.

Context ist kein statischer Eingabeblock

Im vorherigen Artikel dieser Serie ging es darum, dass Context nicht einfach alles Wissen ist, das ein Modell theoretisch besitzen könnte. Entscheidend ist, welche Informationen im jeweiligen Arbeitsschritt tatsächlich verfügbar sind.

Bei einem Agenten ist dieser Context außerdem nicht statisch.

Nach einer Aktion kann beispielsweise ein Suchergebnis hinzukommen:

Search Result

Nach der nächsten ein Stück Quelltext:

geladene Datei

Danach vielleicht:

Compiler Error

oder:

Test Output

oder:

Git Diff

Jede dieser Beobachtungen kann die Einschätzung verändern, welche Aktion als Nächstes sinnvoll ist.

Anthropic beschreibt Context Engineering für Agents deshalb nicht lediglich als Gestaltung eines guten initialen Prompts, sondern als fortlaufende Frage, welche Informationen während eines mehrstufigen Prozesses im Context vorhanden sein sollten. Agentische Systeme können Informationen zudem gezielt „just in time“ laden, anstatt alles Wissen bereits am Anfang bereitzustellen.

Das führt zu einer wichtigen Konsequenz.

Nehmen wir zwei Agent-Runs mit demselben Auftrag. Beide starten mit nahezu identischen Bedingungen. Im ersten Run entscheidet sich der Agent dafür, nach einer bestehenden Implementierung desselben Patterns zu suchen. Im zweiten öffnet er direkt die Dateien des neuen Features.

Nach dieser ersten Entscheidung sind die beiden Situationen bereits nicht mehr identisch.

Run A besitzt nun möglicherweise ein existierendes Architekturbeispiel im Context. Run B besitzt stattdessen Details über die lokale Implementierung.

Die nächste Entscheidung wird jeweils auf Grundlage dieses unterschiedlichen Contexts getroffen.

Frühe Unterschiede im Lösungsweg verändern den späteren Context.

Und der veränderte Context beeinflusst wiederum die nächsten Entscheidungen.

Damit entsteht Pfadabhängigkeit.

Pfadabhängigkeit: Kleine Abzweigung, anderer weiterer Verlauf

Der Begriff Pfadabhängigkeit klingt theoretischer, als er in diesem Zusammenhang ist.

Gemeint ist lediglich, dass der weitere Verlauf eines Prozesses davon abhängt, welche vorherigen Schritte bereits stattgefunden haben.

Stellen wir uns ein Repository mit zwei ähnlichen Features vor. Das ältere Feature verwendet eine inzwischen überholte Struktur, das neuere entspricht der aktuellen Architektur.

Ein Agent findet zuerst das neue Feature und übernimmt dessen Pattern.

Ein zweiter Agent findet bei seiner Suche zunächst das ältere Feature und interpretiert dieses als lokale Konvention.

Beide Entscheidungen können im jeweiligen Moment nachvollziehbar sein. Der Agent weiß schließlich nicht automatisch, welche historische Entwicklung hinter beiden Implementierungen steckt.

Ab diesem Zeitpunkt unterscheiden sich die verfügbaren Hinweise. Weitere Suchen werden möglicherweise mit anderen Begriffen durchgeführt. Andere Dateien erscheinen relevant. Andere Abhängigkeiten werden untersucht. Der entstehende Patch strukturiert sich anders.

Ein kleiner Unterschied zu Beginn kann sich über mehrere Schritte verstärken.

Das bedeutet nicht, dass zwei Agenten zwangsläufig immer weiter auseinanderlaufen. Ein Test, ein Compilerfehler oder eine explizite Architekturregel kann beide Pfade später wieder zusammenführen.

Aber es gibt keine Garantie dafür.

Genau deshalb ist es irreführend, ausschließlich auf den finalen Output zu schauen und sich zu fragen, warum „dieselbe Eingabe“ plötzlich zu zwei unterschiedlichen Lösungen geführt hat. Bei einem Agenten besteht der Prozess aus einer ganzen Sequenz von Entscheidungen und Beobachtungen.

Derselbe Auftrag ist nicht automatisch derselbe Zustand

Hinzu kommt ein zweiter Punkt, der bei Vergleichen schnell übersehen wird.

Zwei wortgleiche Prompts bedeuten nicht zwangsläufig, dass zwei Agent-Runs tatsächlich unter mathematisch identischen Bedingungen starten oder verlaufen.

Unterschiedlich sein können beispielsweise:

• bereits geladene Dateien,
• Suchergebnisse,
• Ergebnisse externer Tools,
• der Zustand des Repositorys,
• vorhandene Session-Historie,
• verfügbare Memories,
• aktivierte Skills,
• zwischengespeicherte Informationen,
• Test- oder Compiler-Ausgaben.

Bei webbasierten Tools kann sich sogar die Außenwelt zwischen zwei Runs verändert haben.

Man sollte dieses Argument allerdings nicht überdehnen. Es wäre ebenso falsch, daraus zu schließen, dass Agent-Runs grundsätzlich unvergleichbar seien. Gute Evaluation versucht gerade, den Ausgangszustand möglichst sauber zu kontrollieren. Anthropic empfiehlt beispielsweise für Agent-Evals isolierte, saubere Umgebungen pro Trial, damit übrig gebliebene Dateien, Caches oder gemeinsam genutzter Zustand nicht zusätzliche Varianz erzeugen.

Auch wenn wir solche äußeren Einflüsse weitgehend kontrollieren, bleibt jedoch der Kern bestehen:

Selbst unter sehr ähnlichen Ausgangsbedingungen bleibt der Lösungsweg nicht zwangsläufig identisch.

Denn ein Agent besitzt weiterhin Entscheidungsspielraum innerhalb des erlaubten Lösungsraums.

Eine Beobachtung aus meinem Architekturlabor

Ich beschäftige mich mit diesem Verhalten nicht nur theoretisch. In meinem Architekturlabor lasse ich bewusst viele kleine Anwendungen und wiederkehrende Features entstehen. Ein Teil davon dient natürlich dazu, Technologien und Architekturansätze auszuprobieren. Gleichzeitig nutze ich diese Projekte aber auch, um herauszufinden, wie präzise die Leitplanken für Coding Agents tatsächlich sein müssen.

Dabei interessieren mich besonders Agent Files und Skills.

Agent Files beschreiben beispielsweise Architekturregeln: Welche Layer existieren? Wo gehört State hin? Welche Abhängigkeiten sind erlaubt? Welche Patterns sollen verwendet oder ausdrücklich vermieden werden?

Skills beschreiben dagegen wiederkehrende Vorgehensweisen. Wie wird ein bestimmter Slice aufgebaut? Welche Schritte gehören zu einem CRUD-Feature? Welche Prüfungen sollen nach einer Änderung durchgeführt werden?

In einer Demo-App für ein Schulungsseminar hatte ich einen Stand erreicht, mit dem ich architektonisch ausgesprochen zufrieden war. Die Strukturen waren klar, mehrere Features folgten denselben Prinzipien, und die entsprechenden Agent Files und Skills existierten bereits.

Dann ließ ich ein weiteres Feature bauen. Fachlich war daran nichts besonders exotisch, strukturell war es sogar wieder ein CRUD-Fall – also genau eine Art von Aufgabe, für die im Projekt bereits Beispiele und Arbeitsanweisungen existierten.

Trotzdem entstand plötzlich eine Architektur, die ich selbst in dieser Form niemals gebaut hätte. Interessant war daran nicht, dass der Agent offensichtliches Chaos produziert hätte. Im Gegenteil: Die Lösung war in sich durchaus plausibel, und einzelne Entscheidungen ließen sich nachvollziehen. Es war kein zufälliger Haufen Code, sondern ein konsistenter Lösungsweg, der nur nicht zu der Architektur führte, die ich erwartet hatte.

Irgendwo früh im Prozess war der Agent anders abgebogen. Vielleicht hatte er eine andere bestehende Struktur zuerst als Referenz verwendet oder eine frühe Interpretation ließ anschließend andere Dateien relevant erscheinen. Welche einzelne Abzweigung es konkret war, ist für die Beobachtung weniger wichtig als ihre Folge: Durch die Entscheidung entstand ein anderer Context, und auf Grundlage dieses Contexts wurden die nächsten Entscheidungen getroffen.

Diese Beobachtung ist kein wissenschaftlicher Beweis für ein allgemeines Verhalten. Sie ist ein einzelnes praktisches Beispiel. Für mich war sie trotzdem lehrreich, weil die naheliegende Erklärung gerade nicht lautete, dass dem Agenten die Leitplanken gefehlt hätten.

Die Agent Files, die Skills und die bestehenden Architekturbeispiele waren vorhanden. Trotzdem blieb innerhalb dieser Grenzen Entscheidungsspielraum.

Leitplanken können den Lösungsraum einschränken, aber sie machen den Entscheidungsweg nicht automatisch deterministisch.

Genau diese Unterscheidung halte ich in der praktischen Arbeit mit Coding Agents für wichtig.

Nichtdeterministisch heißt nicht unkontrollierbar

An diesem Punkt kann leicht ein falscher Eindruck entstehen.

Wenn der Weg eines Agenten nicht exakt vorhersehbar ist, könnte man daraus schließen, dass agentische Systeme grundsätzlich unkontrollierbar seien.

Das folgt daraus nicht.

Nichtdeterminismus und Beliebigkeit sind zwei verschiedene Dinge.

In der Softwarearchitektur kennen wir dieses Prinzip sogar sehr gut. Ein Team bekommt normalerweise nicht vorgeschrieben, in welcher Reihenfolge jeder einzelne Entwickler Dateien öffnen muss. Trotzdem können wir sehr präzise Regeln dafür formulieren, wie eine akzeptable Lösung aussehen soll.

Ähnlich funktioniert die Kontrolle eines Agents.

Wir können seinen Lösungsraum beispielsweise durch klare Requirements einschränken. Architekturregeln können unerwünschte Abhängigkeiten verbieten. Agent Files können projektspezifische Konventionen verfügbar machen. Skills können bewährte Arbeitsabläufe beschreiben.

Danach kommen die wesentlich härteren Grenzen klassischer Softwaretechnik.

Ein Type-System akzeptiert bestimmte Zustände schlicht nicht. Ein Compiler kann ungültigen Code zurückweisen. Ein Linter kann Architektur- oder Qualitätsregeln überprüfen. Tests können fachliches Verhalten verifizieren. Architekturtests können unerlaubte Abhängigkeiten erkennen. Evals können wiederkehrende Verhaltensanforderungen prüfen. Reviews können schließlich Aspekte bewerten, die sich nicht sinnvoll vollständig automatisieren lassen.

Das ist ein fundamentaler Unterschied zwischen der Kontrolle eines Lösungswegs und der Kontrolle eines Lösungsraums.

Wir können nicht garantieren, welchen Weg ein Agent nimmt. Wir können aber sehr genau definieren, welche Wege akzeptabel sind.

Für mich ist das die sinnvollere Engineering-Perspektive. Das Ziel muss nicht darin bestehen, aus einem Agenten mit immer ausführlicheren Prompts einen schlecht nachgebauten deterministischen Workflow zu machen, der jeden Lösungsweg identisch werden lässt. Das Ziel ist, den Raum akzeptabler Lösungen zu definieren.

Je besser dieser Raum beschrieben und technisch abgesichert ist, desto weniger problematisch wird es, dass unterschiedliche Runs innerhalb dieses Raums verschiedene Wege wählen.

Mehrere Lösungen sind nicht automatisch ein Fehler

Varianz wird häufig erst dann diskutiert, wenn zwei Ergebnisse voneinander abweichen. Dadurch bekommt sie schnell einen negativen Beigeschmack.

Dabei ist unterschiedliche Lösungsgestaltung in Softwareentwicklung zunächst nichts Ungewöhnliches.

Gib fünf erfahrenen Entwicklern dasselbe Ticket und du wirst ebenfalls nicht zwangsläufig fünf identische Pull Requests erhalten. Einer erweitert eine bestehende Abstraktion, ein anderer hält eine lokale Implementierung für einfacher. Einer beginnt beim Datenmodell, ein anderer beim Use Case. Manche Unterschiede wären Gegenstand eines Reviews. Andere wären schlicht verschiedene legitime Trade-offs.

Der Vergleich mit Menschen sollte nicht dazu dienen, Modellverhalten zu vermenschlichen. Er macht lediglich sichtbar, dass in einem Problem mit mehreren zulässigen Lösungen Varianz nicht automatisch mit schlechter Qualität gleichgesetzt werden kann.

Zwei Agent-Runs können unterschiedliche Implementierungen produzieren, die beide korrekt sind. Sie können verschiedene Trade-offs sichtbar machen, unterschiedliche Hypothesen über einen Fehler verfolgen und trotzdem beide zur Ursache gelangen oder alternative Architekturvarianten liefern, die eine Diskussion überhaupt erst ermöglichen.

In solchen Fällen ist Varianz keine Störung, sondern Teil eines offenen Lösungsraums.

Problematisch wird sie dort, wo die Unterschiede Grenzen überschreiten, die für das System relevant sind: wenn fachliche Anforderungen nur manchmal erfüllt werden, wenn Architekturregeln nicht stabil eingehalten werden, wenn sicherheitsrelevante Vorgaben von Run zu Run variieren oder wenn ein Prozess eine Reproduzierbarkeit benötigt, die das agentische System nicht zuverlässig liefert.

Die relevante Frage lautet deshalb nicht:

„Warum hat der Agent diesmal etwas anderes gemacht?“

Sondern:

„Ist das, was er anders gemacht hat, innerhalb unserer akzeptablen Grenzen?“

Das ist eine wesentlich produktivere Qualitätsfrage.

Was das für Evaluation bedeutet

Aus dieser Sicht wird auch verständlicher, warum ein einzelner beeindruckender Agent-Run nur begrenzte Aussagekraft besitzt.

Wenn ein System probabilistisch arbeitet, mehrere Entscheidungen trifft und seinen späteren Context durch vorherige Aktionen mitgestaltet, dann zeigt ein erfolgreicher Lauf zunächst einmal, dass dieser Lauf erfolgreich war.

Er beweist nicht automatisch, dass vergleichbare Aufgaben zuverlässig genauso gut gelöst werden.

Anthropic beschreibt in seiner aktuellen Anleitung für Agent-Evals deshalb ausdrücklich jeden einzelnen Versuch einer Aufgabe als Trial. Da Modelloutputs zwischen Runs variieren können, werden mehrere Trials verwendet, um das Verhalten robuster einzuschätzen. Besonders interessant ist dabei die Unterscheidung zwischen der Wahrscheinlichkeit, wenigstens einmal erfolgreich zu sein, und der wesentlich strengeren Frage, wie konsistent ein Agent mehrere Versuche erfolgreich bewältigt.

Für die normale Softwareentwicklung bedeutet das nicht, dass jetzt jedes kleine Ticket fünfzigmal von einem Agenten implementiert werden müsste.

Es geht um den Denkrahmen.

Wenn ich wissen möchte, ob ein neues Agent File eine Architekturregel zuverlässig vermittelt, ist ein einzelner erfolgreicher Versuch nur ein schwaches Signal.

Wenn ich einen Skill für wiederkehrende CRUD-Arbeit entwickle, sollte ich ihn nicht ausschließlich mit der Aufgabe testen, an der ich ihn gerade geschrieben habe.

Wenn ich ein Agent-Modell oder einen neuen Harness für mein Repository bewerte, brauche ich repräsentative Aufgaben und mehr als einen glücklichen Durchlauf.

Dabei sollte Evaluation nicht unnötig den exakten Lösungsweg festschreiben. Auch hier ist die Unterscheidung zwischen Pfad und Ergebnis wichtig. Anthropic weist bei Agent-Evals darauf hin, dass eine starre Überprüfung einer bestimmten Reihenfolge von Tool Calls legitime Lösungswege bestrafen kann. Wo es möglich ist, sollte deshalb geprüft werden, ob das gewünschte Ergebnis und die relevanten Constraints erfüllt wurden, statt jeden Zwischenschritt vorzuschreiben.

Das passt sehr gut zur praktischen Softwareentwicklung.

Für einen Coding Agent können solche Kriterien beispielsweise lauten:

• Verhalten durch Tests abgesichert,
• öffentliche API unverändert,
• keine unerlaubten Layer-Abhängigkeiten,
• Type Check erfolgreich,
• Linter erfolgreich,
• Security-Regeln eingehalten,
• fachlicher Use Case vollständig umgesetzt.

Wie der Agent zu diesem Zustand gelangt ist, kann zweitrangig sein, solange der Weg selbst keine relevanten Risiken erzeugt.

Wenn ein System probabilistisch und pfadabhängig arbeitet, reicht ein einzelner erfolgreicher Durchlauf als Qualitätsaussage nur selten aus.

Das ist keine Forderung nach grenzenloser Evaluation. Es ist lediglich die Konsequenz daraus, Agent-Qualität nicht mit einer guten Demo zu verwechseln.

Wann ein Workflow die bessere Lösung ist

Damit landen wir bei einer Frage, die in der Begeisterung für Agents erstaunlich leicht vergessen wird:

Muss diese Aufgabe überhaupt agentisch gelöst werden?

Anthropic empfiehlt für LLM-basierte Systeme ausdrücklich, zunächst die einfachste geeignete Lösung zu wählen. Für klar definierte Aufgaben können Workflows mehr Vorhersagbarkeit und Konsistenz bieten; Agents werden interessant, wenn Flexibilität und modellgesteuerte Entscheidungen tatsächlich benötigt werden.

Das ist keine Einschränkung von Agents, sondern normale Architekturarbeit.

Wenn ich exakt weiß, dass nach einem Commit immer

Format
→ Lint
→ Test
→ Build
→ Deploy

ausgeführt werden soll, brauche ich keinen Agenten, der jedes Mal neu entscheidet, welcher Schritt sinnvoll sein könnte.

Wenn eine Datei nach klaren Regeln transformiert werden kann, ist ein Skript vermutlich besser.

Wenn ein Generator aus einem bekannten Schema reproduzierbaren Boilerplate-Code erzeugen soll, ist ein Generator genau das richtige Werkzeug.

Ein Agent spielt seine Stärke dort aus, wo Entscheidungen notwendig sind.

Welche Teile des Systems sind für diesen Fehler relevant?

Welche vorhandene Implementierung ist die beste Referenz?

Welcher Test hilft, eine Hypothese zu überprüfen?

Ist ein lokaler Fix ausreichend oder deutet der Fehler auf ein strukturelles Problem hin?

Welche von mehreren möglichen Lösungen passt am besten zu den vorhandenen Constraints?

Für solche Fragen wäre ein vollständig deterministischer Ablauf nur möglich, wenn wir die Antwort bereits vorher in Software gegossen hätten.

Und genau daraus ergibt sich eine einfache Engineering-Regel:

Je genauer der richtige Lösungsweg bereits bekannt ist, desto weniger Grund gibt es, ihn einem Agenten zur Entscheidung zu überlassen.

Automatisierung und agentische Arbeit sind deshalb keine konkurrierenden Konzepte.

Ein gutes System kombiniert beides.

Deterministische Mechanismen sichern das ab, was bekannt und überprüfbar ist. Der Agent bekommt Entscheidungsspielraum dort, wo dieser tatsächlich einen Wert besitzt.

Agentic Work ist keine Fließbandarbeit

Die Vorstellung vom Fließband verspricht eine angenehme Welt: Oben kommt ein Ticket hinein, der Agent bearbeitet es, unten fällt ein Patch heraus. Wenn das einmal funktioniert, müssten wir nur noch mehr Tickets und mehr Agents hinzufügen.

Dieses Bild unterschätzt jedoch genau die Eigenschaft, die einen Agenten interessant macht. Er interpretiert seinen aktuellen Context, entscheidet über den nächsten Schritt, handelt, beobachtet das Ergebnis und entscheidet erneut. Frühe Abzweigungen können andere Informationen verfügbar machen; der dadurch veränderte Context kann wiederum andere Entscheidungen nahelegen. So entsteht Pfadabhängigkeit.

Das erklärt, warum derselbe Auftrag nicht zwangsläufig dieselbe Implementierung produziert, ohne dass diese Varianz automatisch negativ sein muss. Mehrere Pfade können zu korrekten Ergebnissen führen. Architekturregeln, Agent Files, Skills, Tests, Compiler, Type-Systeme und Evals können den Lösungsraum so stark einschränken, dass unterschiedliche Wege trotzdem innerhalb derselben Qualitätsgrenzen enden.

Agentische Softwareentwicklung verlangt deshalb einen anderen Kontrollbegriff: Nicht jeder Schritt muss vorab feststehen. Entscheidend ist, welche Ergebnisse wir akzeptieren und welche Grenzen auf dem Weg dorthin nicht überschritten werden dürfen.

Agentic Work ist keine Fließbandarbeit.

Und Nichtdeterminismus erklärt zunächst nur, warum zwei plausible Läufe unterschiedliche Wege einschlagen können.

Er erklärt noch nicht, warum ein Agent auf einem dieser Wege ausgesprochen überzeugend falsch liegen kann. Er erklärt auch nicht, warum sich bestimmte Annahmen oder Architekturentscheidungen über mehrere Änderungen hinweg verfestigen können, obwohl sie ursprünglich gar nicht beabsichtigt waren.

Unterschiedliche Lösungen wären schließlich relativ harmlos, wenn alle davon richtig wären.

Warum Agents halluzinieren können und warum aus einzelnen Abweichungen langfristiger Drift entstehen kann, ist deshalb die nächste Frage dieser Serie.

Quellen und weiterführende Literatur

• Anthropic: Building effective agents — Abgrenzung von vordefinierten Workflows und modellgesteuerten Agents sowie Hinweise zur Wahl zwischen beiden Ansätzen. Building effective agents
• Anthropic: Effective context engineering for AI agents — Context als dynamischer Zustand bei mehrstufigen Agent-Loops und „just in time“ geladene Informationen. Effective context engineering for AI agents
• Anthropic: Demystifying evals for AI agents — Trials, Varianz zwischen Runs, isolierte Eval-Umgebungen sowie Evaluation von Outcomes statt unnötig starrer Trajectories. Demystifying evals for AI agents
• OpenAI: A practical guide to building AI agents — Agents als Systeme, in denen ein LLM Workflow-Ausführung und dynamische Tool-Auswahl steuert. A practical guide to building AI agents