Bevor von einem Agenten geschriebener Code ausgeliefert wird, müssen folgende Bedingungen ausnahmslos erfüllt sein: Die Testsuite läuft erfolgreich durch, Linting- und Typprüfungen bestehen, das Diff entspricht in Umfang und Reichweite exakt den Vorgaben des Plans, das Projekt lässt sich fehlerfrei bauen, ein Security-Scan meldet keine neuen Schwachstellen und ein menschlicher Entwickler hat das Diff geprüft und freigegeben. Jede dieser Hürden ist ein Verifikations-Gate: ein Kontrollpunkt, der zwingend bestanden werden muss, bevor die Arbeit in die nächste Phase übergeht. Ein weiteres, entscheidendes Gate greift sogar, bevor auch nur eine einzige Zeile Code existiert: die Freigabe des Plans durch einen Menschen. Dieses Gate spart das meiste Geld, denn ein abgelehnter Plan verursacht null Ausführungskosten. Dieser Artikel definiert Gates, stellt die wichtigsten Prüfungen für Agenten-Code vor und beschreibt, wie Ivy Tendril sie durchsetzt.

Was ein Gate ist

Ein Gate ist eine feste Bedingung, die an den Übergang zwischen zwei Arbeitsphasen gekoppelt ist. Eine Aufgabe in Phase N kann nicht in Phase N+1 übergehen, solange diese Bedingung nicht erfüllt ist. Die Bedingung muss jedes Mal auf exakt dieselbe Weise evaluiert werden, und das Ergebnis muss nachvollziehbar protokolliert werden, damit es später überprüft werden kann.

Drei Kernmerkmale unterscheiden ein Gate von einer unverbindlichen Empfehlung:

Es blockiert. Schlägt ein Gate fehl, stoppt der Phasenübergang sofort. Eine Prüfung, deren Scheitern nur Hinweisfunktion hat, ist ein Bericht, kein Gate.
Es ist automatisiert oder explizit. Entweder prüft ein Programm das Kriterium objektiv (Tests, Linting, Build) oder eine namentlich benannte Person trifft eine dokumentierte Entscheidung (Review). „Jemand hat vermutlich drübergeschaut“ erfüllt keines dieser Kriterien.
Es hat einen definierten Pfad bei Fehlern. Scheitert ein Gate, wird die Arbeit an einen klar festgelegten Punkt zurückgeroutet: zurück an den Agenten, zurück zum Plan oder an einen menschlichen Entwickler. Wenn fehlerhafte Arbeit nach einem Scheitern im Niemandsland versandet, ist das die häufigste Ursache dafür, dass Agenten-Ergebnisse unbemerkt verloren gehen.

Auch von Menschen geschriebener Code durchläuft Gates: Continuous Integration und Pull-Request-Reviews. Der Unterschied bei Agenten liegt im Volumen. Wenn ein einzelner Entwickler zwanzig Pull Requests am Tag eröffnen kann, wird die menschliche Prüfung zum Nadelöhr. Die Gates vor dem Review müssen daher so viel Ballast wie möglich aussortieren, bevor ein Mensch das Diff überhaupt zu Gesicht bekommt. Muster für die Agenten-Orchestrierung erläutert, wie sich Verifikation in Warteschlangen, Isolation und Kostenkontrolle einfügt.

Die entscheidenden Gates für Agenten-Code

Gate	Was geprüft wird	Was ein Scheitern meist bedeutet
Plan-Freigabe	Ein Mensch hat den Plan gelesen und stimmt Ansatz und Umfang zu	Die Aufgabe war unzureichend spezifiziert oder der Ansatz ist falsch
Tests	Bestehende Tests laufen durch; neues Verhalten ist durch Tests abgedeckt	Der Agent hat bestehende Funktionalität beschädigt oder die Änderung nicht getestet
Lint & Typprüfung	Code entspricht den Projektrichtlinien und kompiliert fehlerfrei	Regelverstöße, ungenutzter Code, Typfehler, die beim Fixen der Tests entstanden sind
Diff-Größe und -Scope	Geänderte Dateien entsprechen dem Plan; das Diff bleibt reviewbar	Der Agent hat Dateien außerhalb des Plans geändert oder unbeteiligten Code refaktoriert
Build	Das gesamte Projekt lässt sich aus dem Branch erfolgreich kompilieren	Etwas funktioniert isoliert, aber nicht im Gesamtkontext des Projekts
Security-Scan	Keine neuen Secrets, keine anfälligen Abhängigkeiten oder bedenklichen Muster	Der Agent hat Zugangsdaten, eine Bibliothek oder unsichere Funktionsaufrufe eingefügt
Diff-Freigabe	Ein Mensch hat das Diff gelesen und fachlich freigegeben	Alles, was automatisierte Gates nicht beurteilen können: Absicht, Benennung, Produktpassung

Die ersten sechs Gates greifen, bevor ein Mensch eingreifen muss: Das Plan-Gate läuft vor der Ausführung, die übrigen fünf laufen nach der Ausführung isoliert im Worktree des Agenten. Zwei davon verdienen besondere Beachtung.

Die spezifischen Risiken modellgenerierten Codes – unsichere Ausgabebehandlung, unerwünschte Drittanbieter-Bibliotheken, geleakte Zugangsdaten – sind in den OWASP Top 10 for LLM Applications zusammengefasst. Diese Übersicht dient als ideale Checkliste dafür, wonach das Security-Gate suchen muss.

Diff-Größe und -Scope ist das Gate, das Teams am häufigsten vernachlässigen – dabei ist es für Agenten weitaus wichtiger als für Menschen. Bittet man einen Agenten darum, einen Null-Check einzufügen, formatiert er gelegentlich die halbe Datei neu, benennt Variablen um und modifiziert drei Aufrufstellen. Zusammen verwandelt das eine 10-Zeilen-Prüfung in ein unübersichtliches 300-Zeilen-Diff. Ein Scope-Gate gleicht die tatsächlich angefassten Dateien und Module mit dem genehmigten Plan ab und meldet Abweichungen sofort.

Der Security-Scan fängt Secrets, Schwachstellen in Dependencies und unsichere Codemuster ab. Agenten reproduzieren vorhandene Muster aus dem umgebenden Code: Enthält ein Repository bereits ein unsicheres Muster, neigt der Agent dazu, es an weiteren Stellen zu vervielfältigen.

Warum der Plan-Checkpoint Ausführungsverschwendung verhindert

Alle Gates nach der Ausführung haben eine fatale Eigenschaft gemein: Wenn sie scheitern, wurden die Tokens bereits verbraucht. Tests, Linting, Build und Scan sagen Ihnen lediglich, dass die Ausführung schiefgelaufen ist. Nur das Plan-Gate bewahrt Sie vor dem Fehlschlag, bevor Kosten entstehen.

Betrachten Sie, was die späteren Gates zutage fördern: Ein Test schlägt fehl, weil der Agent die Anforderung missverstanden hat – das ist ein Problem des Plans. Das Scope-Gate schlägt an, weil der Agent Module anfasst, die im Ticket gar nicht erwähnt wurden – das ist ein Problem des Plans. Der Build bricht ab, weil der Plan eine Änderung in einem Paket vorsah, ohne abhängige Module zu berücksichtigen – das ist ein Problem des Plans. In jedem dieser Fälle hätte ein Reviewer, der den schriftlichen Plan zwei Minuten lang aufmerksam liest, den Fehler aufgedeckt – bei null Ausführungskosten.

Aus genau diesem Grund besitzt der Software-Factory-Workflow – Ivys Begriff für eine wiederholbare Sequenz aus Planen, Ausführen, Verifizieren und Reviewen – exakt zwei menschliche Checkpoints und positioniert einen davon, bevor eine einzige Zeile Code entsteht. Am Plan-Checkpoint werden Reichweite, Herangehensweise und Reihenfolge festgelegt. Am Diff-Checkpoint wird die fachliche Korrektheit bestätigt. Alles dazwischen läuft vollautomatisch ab.

Wie Ivy Tendril Verifikations-Gates durchsetzt

Ivy Tendril ist eine Local-First-Desktop-Anwendung (macOS, Windows, Linux), die eine Aufgabe vom Entwurf bis zum geprüften Pull Request führt. Die beiden menschlichen Checkpoints und die dazwischen geschalteten automatischen Gates sind fest im Lebenszyklus verankert. Die Benutzeroberfläche wird in der Review-App-Dokumentation beschrieben.

Plan-Gate. Ein Plan beginnt als Entwurf (Draft). Ein Entwickler prüft ihn und kann ihn erweitern (Expand), aufteilen (Split) oder aktualisieren (Update), oder Anmerkungen direkt im Entwurf hinterlassen, woraufhin der Plan neu generiert wird. Die Code-Ausführung beginnt erst, wenn der Plan explizit genehmigt ist.
Isolierte Ausführung. Jeder Plan läuft in einem eigenen Git-Worktree auf einem eigenen Branch. Die Verifikation prüft somit exakt die Änderungen dieses Plans und nichts sonst. Git-Worktrees für parallele KI-Agenten erklärt, warum diese Isolation die Voraussetzung für verlässliche Gates ist.
Verifikations-Tabs. Nach der Ausführung zeigt die Review-App Tests, Linting und Diff in getrennten Reitern an. Der Reviewer hat alle drei Dimensionen vor Augen, bevor er eine Entscheidung trifft.
CI-Import im Pro-Tarif. Teams, deren Gates in CI laufen – GitHub Actions oder beliebige andere CI-Systeme –, können diese Ergebnisse im Pro-Tarif direkt in die Review-App importieren, sodass niemand mehr ein separates Tool öffnen muss.
Fehlerpfad. Scheitert eine Verifikation, geht die Aufgabe zusammen mit dem Fehlerprotokoll direkt an den Agenten zurück. Der Agent erhält die echten Test- oder Lint-Ausgaben (keine vage Zusammenfassung) und unternimmt im selben Worktree einen neuen Versuch. Die Jobs-Ansicht streamt währenddessen die Ausgaben und Tool-Aufrufe des Agenten.
Diff-Gate. Erst wenn die Verifikation erfolgreich durchgelaufen ist und ein Mensch das Diff freigegeben hat, öffnet Tendril den Pull Request auf GitHub. Nichts wird ohne beide Freigaben ausgeliefert.

Die Kosten werden pro Plan und pro Job erfasst: Ein Plan, der drei Anläufe benötigte, zeigt exakt auf, was die Wiederholungsversuche gekostet haben. Dies liefert die Entscheidungsgrundlage dafür, ob das Plan-Gate künftig strenger gehandhabt werden muss.

Erste Schritte

Dokumentieren Sie Ihre aktuellen Gates: Die meisten Teams stellen fest, dass sie über Tests und Reviews verfügen, dass Linting zwar irgendwo läuft, aber niemand weiß, ob es Builds blockiert.
Tendril installieren: curl -sSf https://cdn.ivy.app/install-tendril.sh | sh (macOS, Linux) oder irm https://cdn.ivy.app/install-tendril.ps1 | iex (Windows). Siehe Installation.
Lassen Sie einen Plan durch den Lebenszyklus laufen und lesen Sie die Tabs für Tests und Linting, bevor Sie das Diff öffnen. Achten Sie darauf, was Sie übersehen hätten, wenn Sie nur das Diff betrachtet hätten.
Ergänzen Sie Ihre Plan-Prüfung um einen Scope-Check: Stimmt die Liste der Dateien, die der Agent anfassen darf, exakt mit dem Plan überein?

Tendril ist kostenlos und unter der Functional Source License quelloffen verfügbar. CI-Verifikationsimporte, Teamfunktionen, On-Premises-Hosting und SSO sind Bestandteil der Pro- und Enterprise-Tarife.

Häufig gestellte Fragen

Sollten Verifikations-Gates automatisch blockieren oder den Reviewer nur informieren?

Tests, Linting, Typprüfungen und Builds müssen zwingend hart blockieren; ein Reviewer sollte keine Zeit mit einem Diff verschwenden, das nicht einmal kompiliert. Scope- und Sicherheitsprüfungen sollten dem Reviewer mit der Option zum manuellen Überschreiben angezeigt werden, da hier situative Ausnahmen legitim sein können.

Wie viele Wiederholungsversuche (Retries) sollte ein Agent bei Verifikationsfehlern erhalten?

Setzen Sie ein klares Limit und protokollieren Sie es. Wiederholtes Scheitern an Verifikations-Gates ist fast immer ein Problem des Plans, nicht der Ausführung. Senden Sie die Aufgabe lieber zurück an die Planungsphase, anstatt für einen fünften vergeblichen Ausführungsversuch Tokens zu verbrennen. Die Kostenerfassung pro Job macht die Retry-Kosten transparent.

Bleibt ein menschliches Diff-Review nötig, wenn alle automatischen Gates bestanden wurden?

Ja, ausnahmslos. Automatische Gates prüfen nur das, was vorab formal spezifiziert werden kann. Sie können nicht beurteilen, ob die Änderung dem eigentlichen Sinn des Tickets entspricht, ob der Ansatz zukunftssicher und wartbar ist oder ob bereits der Plan konzeptionell fehlerhaft war. Genau deshalb ist der Diff-Checkpoint eines der beiden unverzichtbaren menschlichen Kontroll-Gates.

Erste Schritte mit Ivy Tendril

Sind Sie bereit für parallele Agenten-Orchestrierung auf Entwickler-Niveau?

Code erkunden: Untersuchen Sie Ivy Tendril auf GitHub (Open Source).
Dokumentation lesen: Finden Sie Integrationsanleitungen unter tendril.ivy.app.
Architektur-Sitzung vereinbaren: Kontaktieren Sie renco@ivy.app für eine 30-minütige technische Beratung.

Verifikations-Gates: Was zwingend erfüllt sein muss, bevor Agenten-Code in Produktion geht