Der Wandel im Quality Engineering: Qualitätssicherung im Agent Loop

Shift in: Einbindung der Qualitätstechnik in die Agentenschleife

Das Tempo der Veränderungen in der Softwarebranche beschleunigt sich in einer Weise, die das letzte Jahrzehnt als langsam erscheinen lässt.

"In den nächsten fünf Jahren wird es größere Veränderungen geben als in den letzten 40 Jahren." - Martin Woodward, VP Developer Relations, GitHub (2024)

Wenn ihr in den Jahren 2025 und 2026 etwas Zeit mit Coding Agents verbracht habt, wirkt dieses Zitat nicht mehr wie ein Hype, sondern wie eine Beschreibung. Agenten lesen jetzt Code, führen Tests durch, bearbeiten Dateien, versenden Pull-Requests und denken über Fehler nach. Sie sind keine Autovervollständiger mehr – sie sind autonome Akteure, die eine Umgebung wahrnehmen, Entscheidungen treffen und ihren Zustand verändern.

Für diejenigen unter uns, denen die Qualität am Herzen liegt, stellt dies ein Problem dar. Die gewohnten Vorgehensweisen – nach links verschieben, um Fehler frühzeitig zu erkennen, nach rechts verschieben, um aus der Produktion zu lernen – wurden für eine Welt entwickelt, in der Menschen den Output der Pipeline lesen und danach handeln. Agenten lesen keine Menschen. Sie lesen Tools. Wenn wir also wollen, dass das Qualitäts-Engineering Einfluss darauf hat, was ein Agent als Nächstes tut, müssen wir eine neue Richtung einschlagen. Ich nenne das " Shift in".

In diesem Beitrag wird erläutert, woher diese Idee stammt, warum sie wichtig ist und wie sie in der Praxis aussieht. Nebenbei definieren wir die Bausteine moderner KI-Agenten - Kontext, Werkzeuge, Fähigkeiten, Aufhänger, die ReAct-Schleife - damit wir eine gemeinsame Sprache finden, bevor wir zur Pointe kommen.

Zwei alte Testprobleme, angewandt auf Agenten

Wenn ich mir ein beliebiges KI-System ansehe – Assistent, Agent, Schwarm – finde ich es nützlich, es auf zwei Probleme zu (über-)vereinfachen, die jeder mit einem Testhintergrund bereits kennt:

• Das Kommunikationsproblem: Wie sagen wir dem System, was wir wollen? In der Testsprache ist dies die Lücke zwischen Absicht und Spezifikation. Bei agentenbasierten Systemen ist es die Lücke zwischen dem Ziel des Benutzers und der Aufforderung, dem Kontext und den Anweisungen, die das Modell tatsächlich erhält.
• Das Orakelproblem: Woher wissen wir, dass die Ausgabe korrekt ist? In der Testsprache ist dies das Testorakel – die Quelle der Wahrheit, die über Bestehen oder Nichtbestehen entscheidet. In agentenbasierten Systemen ist es die Auswertung, der Mensch in der Schleife, der LLM als Richter, die Pipelineprüfung und schließlich der zufriedene Kunde.

Jede Designentscheidung in der agentenbasierten Entwicklung ist letztendlich ein Versuch, eines dieser beiden Probleme zu verringern. Bessere Prompts, reichhaltigerer Kontext, abrufunterstützte Generierung - alles Kommunikation. Evals, Leitplanken, Regressionstests, Richter – alles Orakel. Sobald ihr die beiden Säulen seht, fügen sich die Bausteine ineinander.

Die Bausteine eines KI-Agenten

Bevor wir darüber sprechen können, wo Qualität hingehört, brauchen wir ein gemeinsames Vokabular. KI-Werkzeuge entwickeln sich schnell, und ein und dasselbe Wort bedeutet in verschiedenen Gesprächen oft etwas anderes. In diesem Beitrag verwende ich die Begriffe folgendermaßen.

Large Language Model (LLM): Der Reasoning-Kern des Agents. Gegeben einen Kontext sagt es die nächsten Tokens voraus. Modelle wie Claude, GPT, Gemini und Llama sind LLMs. Das Modell ist nicht der Agent; es ist das Gehirn darin.

Kontext: Alles, was das LLM in einem bestimmten Schritt „sehen“ kann: der System-Prompt, der Gesprächsverlauf, die Tool-Definitionen, abgerufene Dokumente und das neueste Tool-Ergebnis. Kontextfenster sind endlich, weshalb ihr Management eine eigene Disziplin ist – siehe Context Engineering.

System-Prompt: Die Anweisungen am Anfang des Kontexts, die Rolle, Verhalten und Einschränkungen des Agents definieren. Man kann ihn als Stellenbeschreibung plus Verhaltensregeln verstehen.

Memory (Gedächtnis): Ein Mechanismus zum Speichern und Abrufen von Informationen über mehrere Schritte oder Sessions hinweg. Kurzzeitgedächtnis liegt im Kontextfenster, Langzeitgedächtnis in einer Vektordatenbank, einer Datei oder beidem.

Retrieval-Augmented Generation (RAG): Vor einer Antwort durchsucht der Agent eine Wissensquelle nach relevanten Textausschnitten und fügt sie in den Kontext ein. RAG sorgt dafür, dass der Agent in deiner Fachsprache, Codebasis, Dokumentation und deinen Tickets verankert bleibt, statt zu halluzinieren.

Vektordatenbank: Eine Datenbank, die Text als numerische Embeddings speichert, sodass er nach Bedeutung statt nach Stichworten durchsucht werden kann. Die technische Grundlage der meisten RAG-Systeme.

Tool: Eine aufrufbare Funktion, mit der der Agent in der Welt handelt: Dateien lesen, Befehle ausführen, APIs abfragen, Code ausführen. Jedes Tool hat einen Namen, eine Beschreibung und ein Input-Schema. Das LLM entscheidet, wann welches Tool genutzt wird; der Orchestrator führt es aus.

Tool Use: Der Vorgang, bei dem ein LLM eine strukturierte Anfrage zum Aufruf eines Tools erzeugt, der Orchestrator diese ausführt und das Ergebnis zurück in den Kontext gespeist wird. Tool Use macht aus einem Chatbot einen Agenten.

MCP: Model Context Protocol. Ein offener Standard zur Verbindung von Agents mit Tools und Datenquellen, ohne jedes Mal individuelle Integrationen zu bauen. Vergleichbar mit USB-C für KI-Tooling. Eingeführt von Anthropic Ende 2024 – siehe MCP-Spezifikation.

Skill: Eine gebündelte Fähigkeit – meist ein Ordner mit Beschreibung, Anweisungen und ggf. Skripten oder Referenzen, die der Agent benötigt, um eine bestimmte Aufgabe gut auszuführen. Skills kodieren „wie wir X hier machen“ als etwas, das der Agent bei Bedarf laden kann. Unterschied zu Tools: Ein Tool macht eine einzelne Aktion; ein Skill bündelt Wissen und Vorgehensweise für eine ganze Aufgabe.

Hook: Ein deterministischer Kontrollpunkt, der automatisch rund um Tool-Aufrufe ausgelöst wird. PreToolUse läuft vor dem Tool-Aufruf (blockieren, ändern oder erlauben). PostToolUse läuft danach (validieren, loggen, transformieren). Stop läuft, wenn der Agent glaubt, fertig zu sein (zwingt eine weitere Prüfung). Hooks sind der Weg, nicht verhandelbare Regeln in den Loop einzubauen, ohne dem Modell zu vertrauen.

Guardrail: Eine Sicherheitsschicht, die steuert, was in das LLM hinein- und hinausgeht – etwa zur Abwehr von Prompt-Injection, PII-Schutz oder das Blockieren gefährlicher Aktionen. Guardrails sitzen an der Grenze; Hooks innerhalb des Loops.

Eval: Ein Test für einen Agenten. Ähnlich einem Unit-Test, aber Input (Ziel) und Output (Ergebnis/Trajektorie) sind unscharf, daher auch die Bewertung oft unscharf – z. B. durch Rubrics, die von einem Judge-Modell oder Menschen bewertet werden.

Orchestrierung: Die Kontrolllogik, die den Loop ausführt: Nachricht holen, LLM aufrufen, Tool-Calls ausführen, entscheiden, wann gestoppt wird. Der Orchestrator ist normaler Code; das LLM ist der Reasoner. Diese beiden zu vermischen ist ein häufiger Designfehler.

ReAct: Reason → Act → Observe. Die heute dominierende Agenten-Architektur. Jeder Zyklus: Das LLM denkt über das Ziel nach, wählt eine Aktion, der Orchestrator führt sie aus, und das Ergebnis fließt als Beobachtung in den nächsten Zyklus ein. Ursprüngliches Paper: Yao et al., 2022.

:Yao et al., 2022.

Vom Chat zum Agenten: die ReAct-Schleife

Ein einfacher Chat-Assistent ist ein einmaliger Vorgang. Sie senden eine Aufforderung, er sendet eine Antwort, und Sie tun etwas damit. Das Modell schlägt vor, der Mensch führt aus. Keine Feedback-Schleife, keine Werkzeuge, kein Dateizugriff.

Ein Kodieragent ist anders. Ihm wird ein Ziel und ein Werkzeugkasten vorgegeben, dann läuft er in einer Schleife. Er liest Dateien, schreibt Code, führt Tests durch, stellt Fehler fest und versucht es erneut. Komplexe Aufgaben benötigen in der Regel 20 bis 80 Iterationen.

Eine Iteration des ReAct-Loops:

1. Receive: Der Orchestrator fügt die neueste Nachricht – Nutzereingabe oder Tool-Ergebnis – dem Gesprächsverlauf hinzu.
2. Think: Das LLM liest den gesamten Kontext, schließt und entscheidet: Text ausgeben, ein Tool aufrufen oder den Durchlauf beenden.
3. Act: Der Orchestrator prüft den Stop-Grund. Bei Tool-Nutzung wird das Tool ausgeführt. Bei „Turn beenden“ ist die Aufgabe abgeschlossen.
4. Observe: Die Tool-Ausgabe wird als Tool-Nachricht an den Kontext angehängt. Der Loop startet erneut mit erweitertem Kontext.

Zwei Dinge umgeben diesen Loop und sind für unsere Geschichte wichtig. Erstens: Guardrails für maximale Durchläufe, maximale Tokens und maximale Kosten – ohne sie würde der Orchestrator endlos in einer Schleife laufen. Zweitens: Unterbrechungspunkte für Human-in-the-Loop-Pausen bei risikoreichen Aktionen wie Löschen, Deployment oder externen API-Aufrufen.

Das ist der Loop, über den Quality Engineers nachdenken müssen. Nicht der DevOps-Loop im Architekturdiagramm – das ist der äußere Loop. Der ReAct-Loop ist der innere Loop, der pro Aufgabe hunderte Male läuft, der Loop, in dem der Agent seine eigentlichen Entscheidungen trifft.

Wo spezialisierte Agenten in den SDLC passen

Zoomen wir heraus: weg vom Coding-Agenten hin zu einem Blick darauf, wie spezialisierte Agenten in den bekannten DevOps-Zyklus passen – Planen, Design, Codieren, Build, Test, Release, Deploy, Operate, Monitor. Wir können Agent-Teams bereits entlang dieses Zyklus einordnen:

• Spezifikations-Agenten auf der linken Seite: Sie erstellen UX-Briefs, User Personas, Journey Maps, BDD/ATDD-Spezifikationen und keywordgetriebene Test-Scaffolds. Testing wandert dadurch früher in den Prozess – klassisches „Shift Left“.
• CD-Pipeline-Agenten auf der rechten Seite: Sie führen Akzeptanz- und Performance-Tests in Staging-Umgebungen aus, spielen Canary-Releases aus, beobachten das System und initiieren Rollbacks oder Roll-forwards. Feedback kommt aus der Produktion – klassisches „Shift Right“.

Vertrautes Terrain. Seit Jahren sprechen wir über Shift Left und Shift Right, und diese Prinzipien gelten weiterhin, auch wenn der Akteur im Loop ein Agent ist. Aber es gibt eine dritte Dimension der Qualität, die jetzt existieren muss – und sie liegt nicht außerhalb des SDLC.

Drei Richtungen für das Quality Engineering in der agentenbasierten Entwicklung

Gleiche Quality-Engineering-Praktiken. Unterschiedliche Konsumenten des Feedbacks.

← Verschiebung nach links – Spezifikations-Agenten: Menschen und Agenten lesen Specs. Quality Engineering formt die Absicht, bevor der Code existiert: UX-Design-Briefe, User Persona/Journey/Story, BDD/ATDD-Spezifikationen, schlüsselwortgesteuerte Abnahmetestgenerationen. Alle kommunizieren die Absicht. Einsatz dedizierter Agenten, um die Designpraktiken unumgänglich zu machen

↓ Verschiebung nach innen – innerhalb der ReAct-Schleife: Der Coding-Agent handelt auf der Grundlage seiner Anweisungen und nutzt seine Fähigkeiten, um Probleme zu lösen, und liest dann die Ausgabe des Tools. Quality-Engineering-Praktiken steuern die richtigen Verhaltensweisen und werden zu Werkzeugen, die der Agent bei jeder Iteration aufruft. Eine gut definierte Testdesign-Fähigkeit hilft dem Agenten, wertvolle Testfälle zu definieren. Unit-Tests, API-Tests, lokale Integrationstests und kontinuierliche Testzyklen dienen als schnelles Feedback innerhalb der inneren Schleife.

→ Verschiebung nach rechts – CD-Pipeline-Agenten: Die Produktion dient als Orakel, um die Schleife zu schließen: Akzeptanztests im Staging, Performance-Benchmarking in der Produktion, Canary-Release/Dark-Launch zur Kontrolle des Auswirkungsradius, Rollback/Roll-Forward zur schnellen Reaktion, Beobachtung, wie reale Benutzer das System kennenlernen. Alle Praktiken der Qualitätstechnik zur Validierung der Korrektheit und schließlich zur Rückmeldung.

Verlagerung nach innen: Qualitätstechnik innerhalb der Schleife des Agenten

Die Kernidee ist folgende: Coding-Agenten nehmen die Welt ausschließlich über Tool-Ausgaben wahr. Das ist ihre gesamte sensorische Ebene. Alles Feedback, auf das sie reagieren sollen, muss ihnen daher als strukturierte Tool-Ergebnisse innerhalb des ReAct-Loops zugeführt werden.

Das bedeutet, dass Quality Engineering einen neuen „Konsumenten“ bekommt.

Die „Shift-in“-These lautet: Wenn Qualität das Verhalten des Agents im nächsten Schritt beeinflussen soll, muss sie innerhalb des Loops existieren – als ein Tool, das der Agent aufrufen kann, ein Hook, der automatisch ausgelöst wird, ein Skill, den der Agent laden kann, oder eine Eval, die die gesamte Ausführung bewertet. Die CI/CD-Pipeline wird damit zu maschinenlesbarem sensorischem Feedback für den Agenten. Aber welche weiteren Feedback-Signale können wir ihm noch geben?

Ganz konkret bedeutet „Shift-in“, dass vier Ebenen der QE-Praxis neu aufgebaut werden müssen – mit dem Agenten als Leser.

1. Quality Engineering Praktiken diktieren das Verhalten

Eine klar definierte Anweisungsdatei, die sich auf Qualitätsaspekte konzentriert, eine gründlich überprüfte, spezifische Fähigkeit, die dem Agenten sagt, WIE er bestimmte Probleme zu lösen hat, oder sogar ein spezialisierter Unteragent, der eine Expertenmeinung abgibt oder an delegierten Aufgaben arbeitet – all das ist erforderlich, um unsere Quality-Engineering-Praktiken in die Welt der Agenten zu bringen und unserer Stimme Gehör zu verschaffen.

2. Tests als Werkzeuge, die der Agent bei jeder Iteration aufruft

Eine Unit-Test-Suite, die in wenigen Sekunden abläuft und einen strukturierten Pass/Fail-Bericht liefert, ist die perfekte ReAct-Beobachtung. Der Agent schreibt eine Funktion, ruft das Testwerkzeug auf, liest die Fehlschläge, korrigiert den Code und ruft es erneut auf. Das ist die Schleife, die funktioniert. Stellt euch nun dasselbe mit API-Vertragstests, schnellen Integrationstests und Mutationstests auf den geänderten Zeilen vor. Jedes schnelle, deterministische, strukturierte Signal, das ihr in die Schleife einfügen könnt, bewahrt den Agenten davor, umherzuwandern – und erspart euch die spätere Beseitigung seiner Irrwege.

3. Hooks als deterministische Leitplanken und Compliance Enforcer

Ein PreToolUse-Hook kann einen destruktiven Befehl blockieren, bevor er ausgeführt wird. Ein PostToolUse-Hook kann verlangen, dass nach jeder Dateibearbeitung ein Linting-Durchlauf erfolgt, oder er kann das Schreiben eines Audit-Logs erzwingen. Ein Stop-Hook kann sich weigern, eine Aufgabe als abgeschlossen zu markieren, solange die Tests nicht bestanden sind und die Code-Coverage unter dem definierten Schwellenwert liegt.
Hooks sind der Mechanismus, mit dem man aufhört zu hoffen, dass der Agent sich an Standards erinnert, und stattdessen beginnt, sie durchzusetzen. Sie sind der Ort, an dem DoR-/DoD-Prüfungen, schnelle SAST-Scans, Dependency-Vulnerability-Checks, Style-Regeln – die gesamte nicht verhandelbare Sicherheitsschicht – tatsächlich unverhandelbar werden.

4. Pull-Request-Gates als Brücke zwischen der inneren und der äußeren Schleife

In der lokalen Schleife des Agenten werden Unit-, API- und Integrationstests schnell ausgeführt. Das Pull-Request-Gate fügt die langsameren, teuren Tests hinzu: vollständige SAST, vollständige Regression, Komplexitätsanalyse, Abdeckungsgates. Hier trifft die innere ReAct-Schleife auf die äußere DevOps-Schleife. Der Agent betrachtet das Ergebnis der PR-Prüfung als eine weitere Beobachtung des Tools und reagiert darauf – er behebt, was nicht funktioniert hat, rechtfertigt, was ein falsches Positiv war, und bittet um eine menschliche Überprüfung, wenn er nicht weiterkommt.

Beachtet, was sich nicht geändert hat. Wir führen immer noch statische Analysen durch. Wir führen immer noch Unit-Tests durch. Wir achten immer noch auf die Abdeckung. Die QE-Praktiken sind dieselben. Was sich geändert hat, ist, wer oder was den Befehl ausführt, das Ergebnis liest und entscheidet, was als nächstes zu tun ist. Das ist das ganze Spiel.

Was das bedeutet, wenn ihr im Bereich Quality arbeitet

Drei Implikationen stechen für QE-Praktiker hervor.

Eure Tests haben ein neues Publikum: Wenn der Konsument von Testausgaben ein Agent ist, ist das Ausgabeformat genauso wichtig wie die Testlogik selbst. Kryptische Stacktraces, die ein erfahrener Mensch noch entschlüsseln kann, sind für einen Agenten keine guten Signale. Strukturierte, benannte und deterministische Ausgaben – JSON-Reports, maschinenlesbare Diffs und klare Assertions – geben dem Agenten etwas, womit er weiterarbeiten kann.

Euer CI wird zu einer API: Pipelines wurden bisher von Menschen über Dashboards und PR-Checks gelesen. Jetzt werden sie auch von Agenten über Tool-Calls konsumiert. Dieselbe Pipeline dient beiden Zielgruppen, aber die API-Oberfläche – also der Teil, den der Agent aufruft und interpretiert – muss bewusst gestaltet werden. Continuous Delivery für ML hat diesen Gedanken bereits aufgegriffen; die agentenbasierte Entwicklung treibt ihn weiter voran.

Eure Rolle wandert nach upstream des Agents: Gute Evals zu bauen, Tool-Verträge zu designen, Skills und Instruktionsdateien zu schreiben, die Testwissen kodieren, sowie die Ownership der Hook-Schicht – das ist QE-Arbeit in einem agentischen Stack. Die Arbeit verschwindet nicht. Sie verlagert sich in den inneren Loop.

Schließen der Schleife

Shift Left war die richtige Antwort, als der Entwicklungsprozess noch überwiegend von Menschen gesteuert wurde und Nacharbeit nach dem Release der größte Kosten- und Zeitfaktor war. Shift Right war die richtige Antwort, als die Produktion selbst zur wichtigsten Wahrheitsquelle wurde und wir lernen mussten, aus ihr Erkenntnisse zu gewinnen. Beide Ansätze sind nach wie vor richtig.

Shift In ist die Antwort auf den Teil des Prozesses, der heute von Agenten gesteuert wird. Die Wahrnehmung eines Agenten ist auf das begrenzt, was er als Tool-Ergebnis lesen kann. Deshalb muss auch Qualitätsfeedback dort verfügbar sein. Die grundlegenden Fähigkeiten ändern sich nicht – Testmethodik, das Oracle-Problem, die Herausforderung klarer Kommunikation und die Disziplin, Systeme für Fehlerfälle zu entwerfen. Was sich ändert, ist der Empfänger dieses Feedbacks. Und das verändert grundlegend, wie wir es aufbereiten müssen.

Die nächsten fünf Jahre werden tatsächlich mehr Veränderungen bringen als die vergangenen vierzig. Quality Engineering hat die Chance, buchstäblich Teil des Loops zu werden – wenn wir uns bewusst dafür entscheiden.