Shift in: Quality Engineering in den Agenten-Loop integrieren

Shift in: Quality Engineering in den Agenten-Loop bringen

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

Wenn ihr 2025 und 2026 etwas Zeit mit Coding-Agenten verbracht habt, wirkt dieses Zitat nicht mehr wie Hype, sondern wie eine Beschreibung der Realität. Agenten lesen heute Code, führen Tests aus, bearbeiten Dateien, erstellen Pull Requests und analysieren Fehler. Sie sind nicht länger Autocomplete — sie sind autonome Akteure, die ihre Umgebung wahrnehmen, Entscheidungen treffen und Zustände verändern.

Das schafft ein Problem für alle, denen Qualität wichtig ist. Die bekannten Ansätze — Shift Left, um Fehler früh zu erkennen, und Shift Right, um aus der Produktion zu lernen — wurden für eine Welt entwickelt, in der Menschen Pipeline-Ausgaben lesen und darauf reagieren. Agenten lesen keine Menschen. Sie lesen Tools. Wenn Quality Engineering also beeinflussen soll, was ein Agent als Nächstes tut, brauchen wir eine neue Richtung. Ich nenne sie Shift in.

Dieser Beitrag erklärt, woher die Idee kommt, warum sie wichtig ist und wie sie in der Praxis aussieht. Dabei definieren wir die Bausteine moderner AI-Agenten — Kontext, Tools, Skills, Hooks und den ReAct-Loop — damit wir dieselbe Sprache sprechen, bevor wir zur Kernaussage kommen.

Zwei bekannte Testprobleme, auf Agenten angewendet

Wenn ich ein AI-System betrachte — Assistent, Agent oder Schwarm — hilft es mir, es auf zwei Probleme zu (über-)vereinfachen, die jeder mit Testerfahrung bereits kennt:

• Das Kommunikationsproblem: Wie teilen wir dem System mit, was wir wollen? In der Sprache des Testens ist das die Lücke zwischen Intention und Spezifikation. In agentischen Systemen ist es die Lücke zwischen dem Ziel eines Nutzers und dem Prompt, Kontext und den Anweisungen, die das Modell tatsächlich erhält.

• Das Oracle-Problem: Woher wissen wir, ob die Ausgabe korrekt ist? In der Sprache des Testens ist das das Test-Oracle — die Quelle der Wahrheit, die über bestanden oder nicht bestanden entscheidet. In agentischen Systemen sind es die Evaluierung, der Human-in-the-Loop, das LLM-as-Judge, der Pipeline-Check und letztlich der zufriedene Kunde.

Jede Designentscheidung in der agentischen Entwicklung ist letztlich ein Versuch, eines dieser beiden Probleme zu verringern. Bessere Prompts, umfangreicherer Kontext, Retrieval-Augmented Generation — all das dient der Kommunikation. Evals, Guardrails, Regressionstests, Judges — all das dient dem Oracle. Sobald ihr diese beiden Spalten erkennt, fügen sich die Bausteine an der richtigen Stelle ein.

Die Bausteine eines AI-Agenten

Bevor wir darüber sprechen können, wo Qualität hineinpasst, brauchen wir ein gemeinsames Vokabular. AI-Tools entwickeln sich schnell, und dasselbe Wort bedeutet in verschiedenen Vorträgen oft etwas anderes. So verwende ich die Begriffe in diesem Beitrag.

Large Language Model (LLM): Der Kern des Agenten, der Schlussfolgerungen zieht. Auf Basis eines Kontexts 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 in ihm.

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

System Prompt: Die Anweisungen am Anfang des Kontexts, die Rolle, Verhalten und Einschränkungen des Agenten definieren. Stellt ihn euch als Stellenbeschreibung des Agenten inklusive seiner Spielregeln vor.

Memory: Ein Mechanismus zum Speichern und Abrufen von Informationen über mehrere Durchläufe oder Sessions hinweg. Kurzzeit-Memory befindet sich im Kontextfenster, Langzeit-Memory in einer Vektordatenbank, einer Datei oder beidem.

Retrieval-Augmented Generation (RAG): Bevor der Agent antwortet, durchsucht er eine Wissensquelle nach relevanten Abschnitten und fügt sie in den Kontext ein. Mit RAG bleibt ein Agent in eurer Fachterminologie, eurem Codebestand, eurer Dokumentation und euren Tickets verankert, statt zu halluzinieren.

Vektordatenbank: Eine Datenbank, die Text als numerische Embeddings speichert, damit er nach Bedeutung statt nach Schlüsselwörtern durchsucht werden kann. Das Fundament der meisten RAG-Systeme.

Tool: Eine aufrufbare Funktion, mit der der Agent in der Welt handelt: eine Datei lesen, einen Befehl ausführen, eine API abfragen oder Code ausführen. Jedes Tool hat einen Namen, eine Beschreibung und ein Eingabeschema. Das LLM entscheidet, wann es welches Tool aufruft; der Orchestrator führt es tatsächlich aus.

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

MCP: Model Context Protocol. Ein offener Standard, um Agenten mit Tools und Datenquellen zu verbinden, ohne jedes Mal eigene Integrationen schreiben zu müssen. Stellt es euch als USB-C für AI-Tools vor. Anthropic hat es Ende 2024 eingeführt — siehe die.

Skill: Eine gebündelte Fähigkeit — in der Regel ein Ordner mit einer Beschreibung, Anweisungen sowie allen Skripten oder Referenzen, die der Agent benötigt, um eine bestimmte Aufgabe gut auszuführen. Mit Skills könnt ihr „so machen wir hier X“ als etwas abbilden, das der Agent bei Bedarf laden kann. Sie unterscheiden sich von Tools im Umfang: Ein Tool erledigt eine Sache, ein Skill bündelt Wissen und Vorgehensweisen für eine ganze Aufgabe.

Hook: Ein deterministischer Kontrollpunkt, der bei der Tool-Nutzung automatisch ausgelöst wird. PreToolUse läuft, bevor ein Tool aufgerufen wird (blockieren, ändern oder zulassen). PostToolUse läuft danach (validieren, protokollieren, transformieren). Stop läuft, wenn der Agent meint, fertig zu sein (eine weitere Prüfung erzwingen). Mit Hooks verankert ihr nicht verhandelbare Regeln im Loop, ohne darauf vertrauen zu müssen, dass das Modell sich daran erinnert.

Guardrail: Eine Sicherheitsschicht, die filtert, was in das LLM hinein- und herauskommt — sie blockiert Prompt Injection, bereinigt PII und verweigert gefährliche Aktionen. Guardrails befinden sich an der Grenze, Hooks innerhalb des Loops.

Eval: Ein Test für einen Agenten. Ähnlich wie ein Unit-Test, doch die Eingabe ist unscharf (ein Ziel) und die Ausgabe ebenfalls (ein Ablauf oder Artefakt), daher ist auch die Assertion unscharf — oft eine Rubrik, die von einem Judge-Modell oder einem Menschen bewertet wird.

Orchestrierung: Die Steuerlogik, die die Schleife ausführt: die neueste Nachricht abrufen, das LLM aufrufen, Tool-Aufrufe ausführen und entscheiden, wann sie beendet wird. Der Orchestrator ist einfacher Code; das LLM übernimmt das Schlussfolgern. Beides zu vermischen, ist einer der häufigsten Fehler beim Agenten-Design.

ReAct: Reason → Act → Observe. Die heute dominierende Agentenarchitektur. In jeder Iteration denkt das LLM über das Ziel nach, wählt eine Aktion aus, der Orchestrator führt sie aus, und das Ergebnis wird zu einer neuen Beobachtung, die in die nächste Iteration einfließt. Originalpublikation: Yao et al., 2022.

Vom Chat zum Agenten: die ReAct-Schleife

Ein einfacher Chat-Assistent arbeitet einmalig. Ihr sendet einen Prompt, er sendet eine Antwort, und ihr macht etwas damit. Das Modell schlägt vor, der Mensch führt aus. Keine Feedbackschleife, keine Tools, kein Dateizugriff.

Ein Coding-Agent ist anders. Er erhält ein Ziel und einen Werkzeugkasten und arbeitet dann in einer Schleife. Er liest Dateien, schreibt Code, führt Tests aus, erkennt Fehler und versucht es erneut. Komplexe Aufgaben benötigen regelmäßig 20 bis 80 Iterationen.

Eine Iteration der ReAct-Schleife:

1. Empfangen: Der Orchestrator fügt die neueste Nachricht – Nutzereingabe oder Tool-Ergebnis – zum Gesprächsverlauf hinzu.

2. Denken: Das LLM liest den gesamten Kontext, zieht Schlüsse und entscheidet: Text ausgeben, ein Tool aufrufen oder den Turn beenden.

3. Handeln: Der Orchestrator prüft den Grund für das Beenden. Tool-Nutzung → ausführen. Turn beenden → Aufgabe abgeschlossen.

4. Beobachten: Die Tool-Ausgabe wird als Tool-Nachricht angehängt. Die Schleife startet mit angereichertem Kontext neu.

Zwei Dinge umgeben diese Schleife und sind für unsere Geschichte wichtig. Erstens Schutzmechanismen für maximale Turns, Token und Kosten – ohne sie würde der Orchestrator endlos weiterlaufen. Zweitens Unterbrechungspunkte für Human-in-the-Loop-Pausen bei risikoreichen Aktionen wie Löschen, Deployments und externen API-Aufrufen.

An diese Schleife müssen Quality Engineers denken. Nicht an die DevOps-Schleife im Architekturdiagramm – das ist die äußere Schleife. Die ReAct-Schleife ist die innere Schleife: Sie läuft hunderte Male pro Aufgabe und hier trifft der Agent seine tatsächlichen Entscheidungen.

Wo spezialisierte Agenten im SDLC eingesetzt werden

Betrachtet einen Coding-Agenten im größeren Zusammenhang und schaut darauf, wie spezialisierte Agenten in die vertraute DevOps-Schleife passen – Plan, Design, Code, Build, Test, Release, Deploy, Operate, Monitor. Wir können Agenten-Teams bereits entlang dieser Schleife einordnen:

• Spezifikationsagenten links: Sie erstellen UX-Briefings, User Personas, Journey Maps, BDD/ATDD-Spezifikationen und keyword-basierte Testgerüste. Tests rücken nach vorne – klassisches Shift Left.

• CD-Pipeline-Agenten rechts: Sie führen Akzeptanz- und Performance-Tests in Staging-Umgebungen aus, deployen Canary Releases, beobachten das System und leiten Rollbacks und Roll-forwards ein. Feedback aus der Produktion – klassisches Shift Right.

Vertrautes Terrain. Wir sprechen seit Jahren über Shift Left und Shift Right, und diese Ansätze gelten auch dann, wenn der Akteur in der Schleife ein Agent ist. Doch es gibt noch einen dritten Ort für Qualität, der nun berücksichtigt werden muss – und der liegt überhaupt nicht außerhalb des SDLC.

Drei Richtungen für Quality Engineering in der agentenbasierten Entwicklung

Gleiche Quality-Engineering-Praktiken. Andere Empfänger des Feedbacks.

← Shift Left – Spezifikationsagenten: Menschen und Agenten lesen Spezifikationen. Quality Engineering gestaltet die Absicht, bevor Code entsteht: UX-Design-Briefings, User Personas/Journeys/Stories, BDD/ATDD-Spezifikationen, keyword-basierte Generierung von Akzeptanztests. Alles dient dazu, die Absicht zu vermitteln. Nutzt dedizierte Agenten, damit die Designpraktiken unvermeidbar werden.

↓ Shift In – Innerhalb der ReAct-Schleife: Der Coding-Agent handelt anhand seiner Anweisungen und nutzt Skills, um Probleme zu lösen. Anschließend liest er die Tool-Ausgabe. Quality-Engineering-Praktiken fördern das richtige Verhalten und werden zu Tools, die der Agent in jeder Iteration aufruft. Ein klar definierter Skill für Test Design hilft dem Agenten, wertvolle Testfälle zu definieren. Unit-Tests, API-Tests, lokale Integrationstests und kontinuierliche Testzyklen liefern schnelles Feedback innerhalb der inneren Schleife.

Shift Right → – CD-Pipeline-Agenten: Die Produktion dient als Oracle, um die Schleife zu schließen: Akzeptanztests in Staging-Umgebungen, Performance-Benchmarking in der Produktion, Canary Releases/Dark Launches zur Begrenzung des Wirkungsbereichs, Rollback/Roll-forward für schnelle Reaktionen sowie die Beobachtung, wie echte Nutzer mit dem System interagieren. Alle Quality-Engineering-Praktiken validieren die Korrektheit und liefern letztlich Feedback.

Shift In: Quality Engineering innerhalb der Schleife des Agenten

Das ist die zentrale Idee. Coding-Agenten nehmen die Welt über Tool-Ausgaben wahr. Das ist ihre gesamte sensorische Ebene. Jedes Feedback, auf das sie reagieren sollen, muss als strukturiertes Tool-Ergebnis innerhalb der ReAct-Schleife eintreffen.

Das bedeutet: Quality Engineering hat einen neuen Empfänger.

Die Shift-in-These: Wenn Qualität beeinflussen soll, was der Agent als Nächstes tut, muss sie innerhalb der Schleife liegen — als Tool, das der Agent aufrufen kann, als Hook, der automatisch ausgelöst wird, als Skill, den der Agent laden kann, oder als Eval, das die Trajektorie bewertet. Die CI/CD-Pipeline wird zum maschinenlesbaren sensorischen Feedback für den Agenten. Doch welches weitere Feedback können wir ihm geben?

Konkret bedeutet Shift in, vier Ebenen der QE-Praxis mit dem Agenten als Leser neu aufzubauen.

1. Quality-Engineering-Praktiken steuern das Verhalten

Eine klar definierte Anweisungsdatei mit Fokus auf Qualitätsaspekte, ein gründlich geprüfter, spezifischer Skill, der dem Agenten erklärt, WIE er bestimmte Probleme löst, oder sogar ein spezialisierter Sub-Agent, der Experteneinschätzungen liefert oder delegierte Aufgaben übernimmt: All das brauchen wir, um unsere Quality-Engineering-Praktiken in die agentische Welt zu bringen und unserer Stimme Gehör zu verschaffen.

2. Tests als Tools, die der Agent in jeder Iteration aufruft

Eine Unit-Test-Suite, die in wenigen Sekunden läuft und einen strukturierten Pass/Fail-Bericht liefert, ist die perfekte ReAct-Beobachtung. Der Agent schreibt eine Funktion, ruft das Test-Tool auf, liest die Fehler, korrigiert den Code und ruft es erneut auf. So funktioniert die Schleife. Stellt euch nun dasselbe mit API-Vertragstests, schnellen Integrationstests und Mutationstests für die geänderten Zeilen vor. Jedes schnelle, deterministische und strukturierte Signal, das ihr in die Schleife einbringt, bewahrt den Agenten davor, sich zu verzetteln — und euch davor, später seine Umwege aufräumen zu müssen.

3. Hooks als deterministische Leitplanken und zur Durchsetzung von Compliance

Ein PreToolUse-Hook kann einen destruktiven Befehl blockieren, bevor er ausgeführt wird. Ein PostToolUse-Hook kann nach jeder Dateibearbeitung einen Lint-Durchlauf verlangen oder das Schreiben eines Audit-Logs erzwingen. Ein Stop-Hook kann sich weigern, eine Aufgabe als abgeschlossen zu markieren, bevor Tests erfolgreich sind und die Testabdeckung den Schwellenwert erreicht. Mit Hooks hört ihr auf zu hoffen, dass der Agent eure Standards befolgt, und beginnt, sie durchzusetzen. Hier werden eure DoR-/DoD-Prüfungen, schnellen SAST-Scans, Scans auf Schwachstellen in Abhängigkeiten und Stilregeln — eure gesamte nicht verhandelbare Ebene — tatsächlich nicht verhandelbar.

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

Die lokale Schleife des Agenten führt Unit-, API- und Integrationstests schnell aus. Das Pull-Request-Gate ergänzt die langsameren, aufwendigeren Prüfungen: vollständige SAST-Scans, vollständige Regressionstests, Komplexitätsanalysen und Gates für die Testabdeckung. Hier trifft die innere ReAct-Schleife auf die äußere DevOps-Schleife. Der Agent sieht das Ergebnis der PR-Prüfung als weitere Tool-Beobachtung und reagiert darauf — er behebt Fehler, begründet False Positives und bittet um menschliche Prüfung, wenn er nicht weiterkommt.

Beachtet, was sich nicht geändert hat. Wir führen weiterhin statische Analysen durch. Wir führen weiterhin Unit-Tests aus. Wir nutzen weiterhin die Testabdeckung als Gate. Die QE-Praktiken sind dieselben. Geändert hat sich, wer oder was den Befehl ausführt, das Ergebnis liest und entscheidet, was als Nächstes zu tun ist. Darum geht es.

Was das bedeutet, wenn Qualität euer Beruf ist

Für QE-Praktiker stechen drei Auswirkungen hervor.

Eure Tests haben ein neues Publikum: Wenn ein Agent die Testausgabe nutzt, ist das Ausgabeformat genauso wichtig wie die Testlogik. Kryptische Stack Traces, die ein erfahrener Mensch entschlüsseln kann, sind keine guten Signale für einen Agenten. Strukturierte, benannte, deterministische Ausgaben — JSON-Reports, maschinenlesbare Diffs, klare Assertions — geben dem Agenten etwas, worauf er reagieren kann.

Eure CI wird zu einer API: Pipelines wurden schon immer von Menschen über Dashboards und PR-Prüfungen gelesen. Jetzt werden sie von Agenten über Tool-Aufrufe gelesen. Dieselbe Pipeline bedient beide Zielgruppen, aber die API-Oberfläche — der Teil, den der Agent aufruft und parst — muss bewusst gestaltet werden.Continuous delivery for ML hat diese Idee bereits aufgegriffen; die agentische Entwicklung treibt sie weiter.

Eure Rolle liegt vor dem Agenten: Gute Evals erstellen, Tool-Verträge gestalten, Skills und Anweisungsdateien schreiben, die Test-Know-how festhalten, und die Hook-Ebene verantworten — all das ist QE-Arbeit in einem agentischen Stack. Die Arbeit verschwindet nicht. Sie verlagert sich in die innere Schleife.

Die Schleife schließen

Shift left war die richtige Antwort, als die Schleife von Menschen gesteuert wurde und Nacharbeit nach dem Release den größten Zeitaufwand verursachte. Shift right war die richtige Antwort, als die Produktion zur eigenen Quelle der Wahrheit wurde und wir aus ihr lernen mussten. Beides ist weiterhin richtig.

Shift in ist die Antwort für den Teil der Schleife, der jetzt agentengesteuert ist. Die Wahrnehmung des Agenten wird durch das begrenzt, was er als Tool-Ergebnis lesen kann. Daher muss auch das Qualitätsfeedback dort liegen. Die Skills ändern sich nicht — Testgrundlagen, das Oracle-Problem, das Kommunikationsproblem, die Disziplin, für Fehler zu entwerfen. Was sich ändert, ist der Leser des Feedbacks. Und das verändert alles daran, wie wir es aufbereiten.

In den nächsten fünf Jahren wird es tatsächlich mehr Veränderungen geben als in den vergangenen vierzig. Quality Engineering kann ganz wörtlich Teil der Schleife sein — wenn wir uns dafür entscheiden, es dort zu platzieren.