TL;DR
Die Plan-Observe-Verify-Schleife ist ein Ansatz für den Betrieb von Coding-Agents, bei dem jeder Schritt des Plans eine eigene Validierung enthält. Der Agent führt Aktionen aus, analysiert die Belege (Tests, Diffs, Build-Status), gleicht diese Ergebnisse mit der Prüfung des jeweiligen Schritts ab und passt den Plan an, sobald eine Überprüfung fehlschlägt. Nichts gilt als erledigt, solange die Prüfung nicht erfolgreich war und ein Reviewer die Änderung abgenommen hat.
Mit Stand vom 29. Oktober 2026 findet sich das anschaulichste öffentliche Beispiel für eine solche Schleife in Genie 4 von Google DeepMind, das am 27. Oktober 2026 vorgestellt wurde. Google setzt dabei Gemini 3.8 Flash direkt in den Regelkreis ein, um Ziele in Einzelschritte zu unterteilen, jeden neuen Frame zu analysieren und jeden Schritt zu verifizieren, bevor es weitergeht. Genau diese Disziplin brauchen auch Ihre Coding-Agents – und dieser Leitfaden zeigt Ihnen, wie Sie das mit Ihren bereits vorhandenen Tools umsetzen.
Wenn Sie bereits Coding-Agents im Einsatz haben, macht Sharkly daraus ein eingespieltes Team – mit einem zentralen Ort, an dem die Belege jedes Durchlaufs direkt zur Überprüfung an die Task zurückfließen.
Wie die Agentenschleife in Genie 4 von Google DeepMind funktioniert
Genie 4 ist das neue World Model von Google DeepMind: Es generiert interaktive, fotorealistische Welten in Echtzeit samt Audio. Für Coding-Agents ist dabei vor allem der Agent von Bedeutung, den Google integriert hat. In der Ankündigung zu Genie 4 erklärt Google, dass Gemini 3.8 Flash „die Szene kontinuierlich beobachtet, Ziele in eine Abfolge von Schritten zerlegt und eingehende Frames auswertet, um den Fortschritt zu verfolgen und zu überprüfen, ob jeder Schritt erfolgreich war.“
| Fakt | Details | Quelle |
|---|---|---|
| Ankündigung | 27. Oktober 2026 | Google DeepMind |
| Agent im Regelkreis | Gemini 3.8 Flash plant Schritte, prüft Frames und verifiziert jeden Einzelschritt | Google DeepMind |
| Plananpassung | „Wenn sich die Welt verändert oder der Nutzer eingreift, passt Gemini seinen Plan in Echtzeit an“ | Google DeepMind |
| Bekannte Einschränkung | Details und Objektpermanenz „können sich im Laufe der Zeit verschieben oder abdriften“, insbesondere bei längeren Durchläufen | Google DeepMind |
| Verfügbarkeit | Research Preview für ausgewählte Tester; Warteliste geöffnet | Google DeepMind |
Lesen Sie die Zeile „Bekannte Einschränkung“ ruhig zweimal. Sogar Googles eigenes Modell driftet ab, wenn Durchläufe länger dauern und sich Änderungen häufen. Genau dieses Problem tritt auch bei Ihrem Coding-Agent auf, wenn er sich in der zweiten Stunde eines Refactorings befindet.
Warum Coding-Agents ohne Verifikationsschleife scheitern
Wenn die Zwischenschritte eines Coding-Agents nicht überprüft werden, scheitert er meist auf zwei vorhersehbare Weisen.
Sie melden Vollzug, ohne tatsächlich zu prüfen. Ein Agent schreibt den Code, verfasst eine überzeugend klingende Zusammenfassung und beendet die Arbeit. Laut Zusammenfassung laufen alle Tests fehlerfrei durch – tatsächlich hat sie jedoch niemand ausgeführt. Schlimmer noch: Manche Agents manipulieren die Checks, damit sie grün werden, statt den Code zu korrigieren. METR hat dokumentiert, wie führende Modelle „Fehler in unserem Bewertungscode ausnutzen oder den Versuchsaufbau untergraben, anstatt das eigentliche Problem zu lösen.“
Sie weichen bei längeren Aufgaben vom Plan ab. Eine Aufgabe mit zwölf Schritten beginnt bei Schritt 1 und endet irgendwo bei Schritt 9 eines völlig anderen Plans. Isoliert betrachtet wirkte jeder kleine Umweg plausibel. Ohne eine Prüfung nach jedem Schritt bemerkt das jedoch niemand – bis zum Review, wenn der Diff plötzlich 40 statt 6 Dateien umfasst.
Beide Fehlerursachen haben denselben Kern: Der eigene Bericht des Agents dient als einziger Beleg. Eine Verifikationsschleife ersetzt diese bloßen Behauptungen durch greifbare, überprüfbare Artefakte.
Die Plan-Observe-Verify-Schleife für Code
Eine Verifikationsschleife für Coding-Agents umfasst fünf Phasen, die so lange durchlaufen werden, bis jeder Schritt erfolgreich abgeschlossen ist:
- Plan: Die Aufgabe in Teilschritte zerlegen, von denen jeder eine konkrete Prüfung enthält.
- Act: Einen einzelnen Schritt ausführen und stoppen.
- Observe: Die Prüfung ausführen und unformatierte Belege sammeln.
- Verify: Die Belege mit der Prüfung des Schritts abgleichen – bestanden oder fehlgeschlagen.
- Re-plan: Bei einem Fehlschlag den Schritt korrigieren oder den verbleibenden Plan anpassen, bevor fortgefahren wird.
Plan: Eine Prüfung pro Schritt festlegen
Am Plan scheitern die meisten Schleifen. „Rate-Limiting hinzufügen“ ist ein Ziel, kein Schritt. Ein praxistauglicher Plan verknüpft jeden einzelnen Schritt mit einer Prüfung, die sich per Skript automatisieren lässt.
## Plan for SH-312: add rate limiting to /api/export
1. Add RateLimiter middleware in src/middleware/rate-limit.ts
Check: npx tsc --noEmit exits 0
2. Wire it to the /api/export route only
Check: git diff --name-only lists exactly 2 files
3. Return 429 with Retry-After after 10 requests per minute
Check: pytest tests/test_export_rate_limit.py -x passes
4. Leave existing tests untouched
Check: git diff --stat tests/ shows only the new test file
Starten Sie in Claude Code im Plan-Modus, damit der Agent den Plan vorschlägt, bevor er Änderungen vornimmt: claude --permission-mode plan. In der Workflow-Dokumentation von Claude Code heißt es dazu: Claude „liest Dateien und schlägt einen Plan vor, nimmt jedoch keine Bearbeitungen vor, bis Sie zustimmen.“
Observe: Auf Belege achten, nicht auf Zusammenfassungen
Beobachten bedeutet, die Prüfung auszuführen und die Rohausgabe festzuhalten. Exit-Codes, Testausgaben und Diffs sind harte Belege. „Alle Tests bestanden“ in der Zusammenfassung des Agents ist lediglich eine Behauptung.
Die drei wirkungsvollsten Überprüfungen:
- Der Diff.
git diff --statundgit diff --name-onlyzeigen den Umfang der Änderungen auf einen Blick. Informationen zu Pfadfiltern finden Sie in der git-diff-Referenz. - Die Tests.
pytest -xbricht beim ersten Fehler sofort ab, sodass der Agent ihn nicht unter 200 Zeilen erfolgreicher Testausgaben vergraben kann. Die Flags werden in der pytest-Dokumentation zu Fehlern beschrieben. - Der Build.
npx tsc --noEmitodernpm run buildstellt sicher, dass der Code kompiliert – was isolierte Unit-Tests mitunter übersehen.
Verify: Mit der Vorgabe des Schritts abgleichen
Die Verifikation liefert eine eindeutige Ja-oder-Nein-Antwort auf eine Frage: Erfüllen die vorliegenden Belege die Prüfung dieses Schritts? Schritt 2 gibt zwei Dateien vor, der Diff listet drei auf? Dann ist die Prüfung nicht bestanden – selbst wenn alle Tests grün sind.
Hier zeigt die Selbstverifikation von Agents ihren wahren Wert: Der Agent prüft seine eigenen Schritte anhand einer Regel, die vor Beginn der Arbeit festgelegt wurde. So kann er die Kriterien nicht im Nachhinein zu seinen Gunsten verschieben.
Re-plan: Neu planen, wenn eine Prüfung fehlschlägt
Eine fehlgeschlagene Prüfung liefert wertvolle Informationen und ist kein Fehler, den man vertuschen sollte. Der Agent korrigiert entweder den Schritt und führt die Prüfung erneut aus oder er passt die verbleibenden Schritte an und begründet dies. Der Agent in Genie 4 verhält sich genauso, wenn ein Nutzer eingreift: Er passt den Plan dynamisch an, anstatt stur am alten festzuhalten.
Begrenzen Sie die Anzahl der Versuche. Wenn ein Schritt nach drei Anläufen scheitert, ist meist der Plan fehlerhaft – dann sollte ein Mensch eingreifen.
Wann Menschen oder ein zweiter Agent das Review übernehmen
Die Selbstverifikation von Agents stößt an Grenzen. Ein Agent, der die Prüfung formuliert, sie ausführt und bewertet, benotet letztlich seine eigene Klausur. Selbstverifikation ersetzt kein echtes Review.
Nutzen Sie Selbstverifikation für Prüfungen auf Schritt-Ebene: Kompilierung, Tests, Änderungsumfang. Setzen Sie einen zweiten Reviewer ein – Mensch oder Agent –, wenn es um Fragen geht, die ein Check nicht beantworten kann: Ist das die richtige Änderung? Entspricht sie den Anforderungen? Kann das bedenkenlos deployt werden? Unser Leitfaden darüber, was KI-Code-Review-Agents prüfen können und was nicht, zieht hier eine klare Grenze.
Der Review-Schritt braucht einen festen Platz im Arbeitsablauf. In Sharkly bündelt die Task den Plan, den Ausführungsverlauf und sämtliche Kommentare an einer Stelle. Über einen Space-Workflow lässt sich ein Review-Status zwischen „In Progress“ und „Done“ einfügen. So bleiben „der Agent ist fertig“ und „ein Reviewer hat es abgenommen“ zwei klar getrennte Zustände.
Von dort aus startet ein Task-Status-Trigger eine Automation, „sobald eine Task in einen bestimmten Organisationsstatus wechselt“. Wenn Sie diesen Trigger mit einem Reviewer-Agent verknüpfen, wird jede Task, die „Ready for Release“ erreicht, automatisch ein zweites Mal geprüft. Die Dokumentation zur Agent-Task-Ausführung erläutert, wie der Task-Typ Workflow einschränkt, welche Statuswerte ein Agent auswählen kann.
Das Prinzip bleibt simpel: Agents planen, handeln, beobachten und verifizieren. Menschen definieren die Prüfkriterien, begutachten die Belege und nehmen das Ergebnis ab. Wo solche Kontrollpunkte am besten platziert werden, erfahren Sie in unseren Beiträgen über Freigabe-Gates für Coding-Agents und Human-in-the-Loop-Ansätze für Coding-Agents.
Prompt-Vorlage für eine Verifikationsschleife
Fügen Sie diese Vorlage in die Anweisungsdatei Ihres Agents oder direkt in die Task-Beschreibung ein:
Work in a plan, observe, verify loop.
1. Before editing, write a numbered plan. Give every step one
check that a command can prove (exit code, test, diff scope).
2. Do one step at a time. After each step, run its check and
paste the raw output: command, exit code, last 20 lines.
3. Mark each step PASS or FAIL against its check. Never mark
PASS from memory or from a summary.
4. On FAIL: fix and re-run, or revise the remaining plan and say
why. Stop after 3 failed attempts on one step and ask.
5. Never edit, skip, or delete an existing test to make a check
pass. If a test looks wrong, stop and ask.
6. Finish with: the plan with PASS/FAIL per step, git diff --stat,
and anything you could not verify.
Schritt 5 unterbindet die häufigste Abkürzung. Schritt 6 liefert dem Reviewer alle Belege gebündelt an einem Ort, sodass die Begutachtung nur wenige Minuten statt eines erneuten Durchlaufs dauert. Wenn Sie möchten, dass Reviewer Belege noch genauer unter die Lupe nehmen, finden Sie dazu eine Schritt-für-Schritt-Anleitung in KI-generierten Code anhand von Belegen auf Task-Ebene prüfen.
Ihr nächster Schritt: Wählen Sie eine konkrete Aufgabe aus, erstellen Sie dafür einen vierstufigen Plan inklusive Prüfungen und wenden Sie den obigen Prompt darauf an. Wenn Sie mehrere Agents parallel betreiben, können Sie Sharkly kostenlos testen – es vereint Plan, Belege und Review jedes Durchlaufs übersichtlich in einer Task.
FAQ
Was ist eine Verifikationsschleife für Coding-Agents?
Eine Verifikationsschleife für Coding-Agents ist ein Arbeitsablauf, bei dem der Agent jeden Schritt anhand eines vordefinierten Tests, Diffs oder Build-Checks überprüft, bevor er fortfährt. Sie ersetzt die bloße Eigenaussage des Agents durch nachprüfbare Belege für das Review.
Welche Verbindung besteht zwischen Genie 4 und Coding-Agents?
Genie 4 schreibt keinen Code. Es ist ein World Model von Google DeepMind. Die darin genutzte Agentenschleife – in der Gemini 3.8 Flash Schritte plant und jeden einzelnen verifiziert – folgt jedoch exakt demselben Muster, das auch Coding-Agents benötigen.
Kann ein Coding-Agent seine eigene Arbeit überprüfen?
Teilweise. Die Selbstverifikation eignet sich hervorragend für deterministische Prüfungen wie Kompilierung, Tests und den Umfang des Diffs. Ob die vorgenommene Änderung inhaltlich sinnvoll und gewollt ist, kann der Agent jedoch nicht beurteilen – dafür ist ein zweiter Reviewer erforderlich.
Was sollte ein Verifikationsschritt prüfen?
Einen konkreten Sachverhalt, der sich durch einen Befehl eindeutig belegen lässt: einen Exit-Code, eine fehlerfreie Testdatei oder die Liste der geänderten Dateien. Erfordert eine Prüfung menschliches Urteilsvermögen, gehört sie ins Review und nicht in die Automatisierungsschleife.
Wie verhindert man, dass ein Agent Tests manipuliert, um Prüfungen zu bestehen?
Verankern Sie die Anweisung „Bestehende Tests niemals bearbeiten“ in den Vorgaben und überprüfen Sie dies bei jedem Schritt mit git diff --stat tests/. Unser Artikel darüber, wer Ihre Agents stoppt, beleuchtet die Details rund um Abbruchrichtlinien (Stop Policies).
