KI-Programmierung: Wie viel Arbeit an Agenten abgeben?

Für Entwicklungsverantwortliche empfiehlt sich als Ausgangspunkt eine klar begrenzte Aufgabe auf einem separaten Branch, mit eindeutigen Abnahmekriterien, automatisierten Prüfungen und einer benannten Person für das Review. Mehr Eigenständigkeit ist dann sinnvoll, wenn dieses Verfahren Änderungen hervorbringt, die sich mit gutem Gewissen abnehmen lassen.

Die folgenden Angaben zum Verhalten der Tools wurden am 24. Oktober 2026 anhand der aktuellen Herstellerdokumentation geprüft. Die Regeln zur Delegation und das Beispiel eines Rechnungsexports sind redaktionelle Einordnungen, keine Ergebnisse eines Produkttests.

Was bedeutet KI-Programmierung mit Agenten?

Beim Agentic Coding übernimmt ein KI-System eine Abfolge von Entwicklungsaufgaben und berücksichtigt nach jedem Schritt dessen Ergebnis. Es untersucht die Codebasis, plant eine Änderung, bearbeitet Dateien, führt Befehle und Tests aus, wertet die Ergebnisse aus und passt den nächsten Schritt an. Ein Durchlauf kann enden, weil die Aufgabe erledigt ist, eine Berechtigungsgrenze erreicht wurde oder eine Entscheidung fehlt.

Anthropic beschreibt diesen Kreislauf als Kontext sammeln, handeln und überprüfen. Entscheidend ist, dass das Ergebnis eines Tool-Aufrufs in die nächste Entscheidung einfließt: Ein fehlgeschlagener Test liefert Hinweise für die nächste Codeänderung. Ein vorgeschlagener Codeblock allein bietet diese Rückkopplung noch nicht. Die Agentenschleife von Claude Code.

Das lässt sich mit einem Handwerksbetrieb vergleichen, der einen Raum renoviert. Der Auftrag beschreibt das Ergebnis, die ausgehändigten Schlüssel bestimmen den Zugang und die Abnahme entscheidet, ob die Arbeit akzeptiert wird. Mehr Schlüssel machen die Renovierung nicht automatisch fachgerecht. Coding-Agenten brauchen dieselbe Trennung zwischen Auftrag, Zugriff und Prüfung.

Ein Agent braucht außerdem einen Harness: die Software um das Modell herum, die Werkzeuge bereitstellt und den Arbeitskontext verwaltet. Das Modell schlägt Aktionen vor; der Harness führt erlaubte Tool-Aufrufe aus und gibt deren Ergebnisse zurück. Ein anderes Modell bedeutet deshalb nicht automatisch andere Zugriffsregeln für die Umgebung.

Was unterscheidet einen Coding-Agenten von Autovervollständigung und Chat?

Der Unterschied liegt darin, wer die Arbeit von einem Schritt zum nächsten weiterführt. Die Autovervollständigung schlägt beim Bearbeiten Text vor. Ein gewöhnlicher Chat kann Code erklären oder einen Patch vorschlagen; Kopieren, Ausführen und Prüfen bleiben beim Menschen. Ein Agent mit Zugriff auf Repository und Befehlsausführung kann diese Schritte selbst übernehmen und ihre Ergebnisse untersuchen.

Die Oberfläche ist dabei nicht entscheidend. Ein Agent kann in einem Chatfenster ebenso arbeiten wie im Terminal. Maßgeblich sind die verfügbaren Werkzeuge, die Rückkopplung der Ergebnisse und die Befugnisse der jeweiligen Sitzung.

Agentic Coding und Vibe Coding: Was ist der Unterschied?

Agentic Coding beschreibt, wie ein Tool arbeitet. Vibe Coding bezeichnet meist eine Arbeitsweise, bei der jemand erzeugte Software vor allem über Prompts und das beobachtete Verhalten steuert, teils mit wenig Einblick in die Implementierung. In der Praxis überschneiden sich die Begriffe, sie beschreiben aber unterschiedliche Aspekte.

Auch mit einem Agenten lassen sich sämtliche Änderungen prüfen und strenge Tests beibehalten. Ebenso ist es möglich, generierten Code nahezu ungeprüft zu übernehmen. Bei einem kurzlebigen Prototyp kann das eine bewusste Abwägung sein. Sobald Kundendaten oder Zahlungen betroffen sind, gehört das Verständnis der Implementierung zur Verantwortung für die Software. Der Leitfaden zu Vibe-Coding-Tools gibt einen breiteren Überblick über App-Builder und Programmierwerkzeuge.

Was Coding-Agenten leisten können

Die wichtigsten Tools bieten eine ähnliche Handlungsschleife in unterschiedlichen Arbeitsumgebungen. Ihre dokumentierten Funktionen zeigen, welche Aufgaben sich delegieren lassen. Wie viel unbeaufsichtigte Arbeit ein bestimmtes Repository verträgt, lässt sich daraus nicht ableiten.

Claude Code

Claude Code, der Coding-Agent von Anthropic, kann Projekte durchsuchen, Dateien lesen und bearbeiten sowie Befehle und Tests ausführen. Laut Dokumentation passt er sein Vorgehen anhand dessen an, was er aus den einzelnen Tool-Ergebnissen lernt. Ein klar eingegrenzter Bugfix passt zu diesem Ablauf: den Fehler untersuchen, den betroffenen Code ändern und das Verhalten prüfen. Dokumentation zu Claude Code.

In der Praxis setzt fehlender oder vergessener Kontext eine Grenze. Anthropic beschreibt ein begrenztes Kontextfenster und die Verdichtung des Kontexts in langen Sitzungen. Dauerhafte Vorgaben gehören deshalb in die Projektanweisungen, und jede Änderung sollte überschaubar bleiben. Ein langes Gespräch ersetzt kein Abnahmekriterium. Unser Leitfaden zu Claude Code Best Practices führt diesen Arbeitsablauf weiter aus.

OpenAI Codex

OpenAI Codex, der Coding-Agent von OpenAI, bietet eine Kommandozeilenschnittstelle (CLI), die ein Repository untersuchen, Änderungen planen, Dateien bearbeiten und lokale Entwicklungsbefehle ausführen kann. Hinzu kommt ein eigener Review-Ablauf für noch nicht committete Änderungen, einen Commit oder den Vergleich mit einem Basis-Branch. Dokumentation zur Codex CLI.

Hier setzt die Ausführungsumgebung die praktische Grenze. Benötigt eine Prüfung einen nicht verfügbaren Dienst oder einen gesperrten Netzwerkzugriff, kann sie den vorgesehenen Nachweis nicht liefern. Sie muss als ungeprüft festgehalten und anschließend in einer geeigneten Umgebung nachgeholt werden. Der Vergleich von Codex und Claude Code hilft bei der Produktwahl; die Berechtigungseinstellungen erfordern eine eigene Entscheidung.

Cursor Agent

Cursor Agent, der Coding-Agent im Editor von Cursor, kann eine Codebasis durchsuchen, Dateien bearbeiten und Terminalbefehle ausführen. Das passt zu einem interaktiven Ablauf, bei dem die Änderung während der laufenden Arbeit gesteuert und geprüft wird. Diese Aktionen sind dokumentiert; daraus folgt keine Garantie für ein korrekt umgesetztes Feature. Überblick zu Cursor Agent.

Wichtig ist, wo die Freigabegrenze unmittelbar verläuft: Gewöhnliche Änderungen im Arbeitsverzeichnis werden ohne Genehmigung auf der Festplatte gespeichert; für Konfigurationsdateien gelten zusätzliche Schutzmaßnahmen. Cursor weist darauf hin, dass eine Anwendung mit automatischem Neuladen geänderten Code schon vor dem Review ausführen kann. Zugangsdaten und Daten der Entwicklungsumgebung müssen zu diesem Verhalten passen. Sicherheit von Cursor Agent.

Der Coding-Agent von GitHub Copilot

Der Coding-Agent von GitHub Copilot, in der aktuellen Dokumentation als Copilot cloud agent bezeichnet, kann ein Repository untersuchen, Änderungen planen, Dateien bearbeiten sowie Tests und Linter in einer temporären Cloud-Umgebung ausführen. Er kann Branches, Commits und Pull Requests vorbereiten. Das unterscheidet sich von Codevorschlägen in einer IDE oder einem Copilot-Review für einen bestehenden Pull Request. Copilot auf GitHub.com.

Die praktische Grenze liegt in der Übergabe. GitHub warnt, dass generierte Änderungen fehlerhaft oder unsicher sein können und geprüft sowie getestet werden müssen. Eine abgeschlossene Sitzung liefert Arbeit zur Begutachtung; sie bestätigt noch nicht, dass die Abnahmekriterien erfüllt sind. GitHubs Hinweise zur verantwortungsvollen Nutzung.

Details zu den Tarifen stehen auf unseren Seiten zu den Preisen von Claude Code, Codex, Cursor und GitHub Copilot.

Programmieren mit KI beginnt mit einer prüfbaren Spezifikation

Eine brauchbare Spezifikation sagt dem Agenten sowohl, was sich ändern soll, als auch, was weiterhin gelten muss. „CSV-Export hinzufügen“ lässt wesentliche Entscheidungen offen. Ein Agent kann einen funktionierenden Download bauen und dabei die falschen Zugriffsregeln umsetzen.

Als hypothetisches Beispiel dient eine Rechnungsanwendung, die mehrere voneinander getrennte Kundenorganisationen nutzen. Ein Kontoadministrator soll Rechnungen exportieren können. Ein brauchbarer Arbeitsauftrag legt Folgendes fest:

• Ergebnis: Ein berechtigter Administrator kann die Rechnungen herunterladen, die unter den aktuell gesetzten Filtern sichtbar sind.
• Zugriffsregel: Eine Organisation darf niemals Rechnungen einer anderen Organisation erhalten, auch nicht über eine manipulierte Anfrage.
• Unverändertes Verhalten: Die bestehenden Rechnungsberechtigungen und Filterregeln bleiben maßgeblich.
• Umfang: Vorhandene Konventionen für Berechtigungsprüfungen und Exporte wiederverwenden; sachfremde Refaktorierungen und Abhängigkeiten vermeiden.
• Nachweise: Erlaubte und abgewiesene Zugriffe, einen organisationsübergreifenden Zugriffsversuch, ein leeres Ergebnis und die einschlägigen bestehenden Prüfungen zeigen.
• Stoppbedingung: Eine Entscheidung einholen, wenn die Zugriffsregeln unklar sind oder die Lösung Änderungen an gemeinsam genutzter Berechtigungslogik erfordert.

Dieser Auftrag lässt die konkrete Umsetzung offen und legt zugleich das zugesicherte Produktverhalten fest. Zeigt sich bei der Arbeit eine fehlende Regel, muss sie geklärt und die Spezifikation ergänzt werden. Eine zufällige Implementierungsentscheidung darf nicht stillschweigend zur verbindlichen Regel werden. Unser Leitfaden zu spezifikationsgetriebener Entwicklung erklärt, wie sich dieser Zusammenhang pflegen lässt.

Anthropics Best-Practices-Dokumentation empfiehlt, dem Agenten eine Möglichkeit zur Überprüfung seiner Arbeit zu geben. Armin Ronacher betont in seinen Empfehlungen aus der Praxis schnelle, verständliche Werkzeuge und aussagekräftige Logs. Für den Betrieb folgt daraus: Fehler müssen erkennbar sein. Eine verständliche Meldung über einen abgewiesenen Zugriff hilft dem Agenten bei der Korrektur; ein hängender Befehl liefert kaum Orientierung.

Berechtigungen und Sandboxing setzen unterschiedliche Grenzen

Berechtigungen regeln zulässige Aktionen, Sandboxing begrenzt deren Reichweite, und Branch- sowie Review-Regeln bestimmen die Abnahme. Alle diese Ebenen müssen konfiguriert werden. Ein Prompt mit der Anweisung „Produktivsysteme nicht anfassen“ ersetzt nicht den Entzug des Zugriffs auf diese Systeme.

Eine Freigaberichtlinie legt fest, welche Aktionen eine Genehmigung brauchen. Eine Sandbox erzwingt Grenzen für die Ausführung, etwa bei beschreibbaren Dateien und ausgehenden Netzwerkverbindungen. Keine dieser Maßnahmen beurteilt, ob der Rechnungsexport die fachlichen Regeln einhält.

Welche Einstellungen gelten tatsächlich im jeweiligen Tool?

Für Claude Code dokumentiert Anthropic die Isolation von Dateisystem und Netzwerk bei Befehlen in der Sandbox, einschließlich ihrer Unterprozesse. Dokumentiert ist auch ein Mechanismus, der einen erneuten Versuch außerhalb der Sandbox erlaubt. Bevor die Grenze als verbindlich gilt, müssen dieser Ausweg, Ausnahmen für einzelne Befehle und das Verhalten bei einem fehlgeschlagenen Sandbox-Start geprüft werden. Eingeschränkte Schreibrechte bedeuten nicht automatisch, dass sensible Dateien nicht gelesen werden können. Sandboxing in Claude Code.

Bei der Codex CLI erlaubt workspace-write mit der Freigabeeinstellung on-request die Arbeit innerhalb des Arbeitsverzeichnisses. Der Netzwerkzugriff aus Befehlen ist standardmäßig deaktiviert, sofern er nicht ausdrücklich eingeschaltet wird. Freigaberichtlinie und Sandbox-Modus sind getrennte Einstellungen: Das Abschalten von Freigabeabfragen hebt die Sandbox nicht automatisch auf. Die Netzwerkrichtlinie für Befehle regelt für sich genommen auch nicht die gehostete Websuche, Apps oder MCP-Verbindungen, über die der Agent externe Werkzeuge und Dienste erreicht. Diese Zugriffswege müssen separat geprüft werden. Freigaben und Sicherheit bei Codex.

Bei Cursor Agent benötigen Terminalbefehle standardmäßig eine Genehmigung. Die konfigurierbaren Run Modes werden dagegen als Schutzvorkehrungen nach dem Best-Effort-Prinzip beschrieben, nicht als harte Sicherheitsgrenze. Dieser Unterschied ist entscheidend, wenn Befehle unbeaufsichtigt laufen sollen. Neben der Ausführung im Terminal muss auch das zuvor beschriebene automatische Neuladen berücksichtigt werden. Sicherheit von Cursor Agent.

Für GitHub Copilot cloud agent dokumentiert GitHub eingeschränkte Branch-Berechtigungen, die direkte Pushes auf den Standard-Branch verhindern. Hinzu kommen eine standardmäßig aktive Firewall und die erforderliche Freigabe durch eine Person mit Schreibzugriff, bevor Actions-Workflows aus Pull Requests des Agenten ausgeführt werden. Allgemeine Actions-Secrets des Repositorys und der Organisation werden nicht an den Agenten weitergegeben; Secrets, die ausdrücklich der Umgebung copilot hinzugefügt wurden, dagegen schon. Deshalb muss geprüft werden, welche Geheimnisse dort hinterlegt sind. Die von GitHub dokumentierten Schutzmaßnahmen.

Die Zugriffsgrenzen an der Aufgabe ausrichten

Für den Rechnungsexport braucht der Agent Quellcode, Entwicklungsabhängigkeiten und synthetische Rechnungsdaten. Echte Kundenrechnungen, Zugangsdaten zur Produktivdatenbank oder Deployment-Rechte sollten dafür nicht nötig sein. Erhalten sollte er nur den Ressourcenzugriff, den er benötigt, um das Verhalten zu reproduzieren und zu prüfen.

Texte im Repository, abgerufene Webseiten und Inhalte von Issues sind als potenziell nicht vertrauenswürdige Eingaben zu behandeln. Bei einer Prompt Injection versuchen bösartige Inhalte, die Aktionen des Agenten umzulenken. Eine versteckte Anweisung in einem Dokument darf nicht dieselbe Verbindlichkeit erhalten wie der Arbeitsauftrag. Die Sicherheitshinweise der Hersteller benennen dieses Risiko; ein begrenzter Ressourcenzugriff verringert die möglichen Folgen. Das Sicherheitsmodell von Cursor.

Code-Review in der Praxis: Diff und Nachweise prüfen

Zu prüfen sind das geänderte Verhalten und die Tests, die seine Korrektheit belegen sollen. Die Zusammenfassung des Agenten hilft bei der Orientierung. Abgenommen wird jedoch die tatsächliche Änderung.

Den Anfang machen die Abnahmekriterien. Beim Rechnungsexport ist nachzuvollziehen, wie die Organisation der Anfrage bestimmt wird, wie die Berechtigungen geprüft werden und wie die Exportabfrage dieselbe Grenze durchsetzt. Danach folgen die Tests. Ein Test, der nur Datensätze einer einzigen Organisation verwendet, kann die Trennung zwischen Organisationen nicht nachweisen.

Anschließend ist zu prüfen, ob der Patch die Aussagekraft der Prüfungen geschwächt hat: durch gelöschte Assertions, neuerdings übersprungene Tests, weiter gefasste Mocks, geänderte Snapshots oder eine angepasste CI-Konfiguration. Eine Testsuite kann grün werden, weil die Implementierung besser wurde oder weil die Prüfung weniger verlangt. Der Diff zeigt, welcher Fall vorliegt.

In einem Repository-Checkout mit noch nicht committeten Änderungen liefern diese Git-Befehle eine grundlegende Übersicht:

git status --short
git diff --stat
git diff --check
git diff
git diff --cached

git status zeigt auch noch nicht versionierte Dateien, deren Inhalt separat geprüft werden muss. Diese Befehle führen keine Anwendungstests aus. Hat der Agent seine Arbeit bereits committet, muss der vollständige Diff des Pull Requests zwischen Basis- und Head-Stand geprüft werden. Die dokumentierten Prüfungen des Repositorys sind in einer sauberen Umgebung auszuführen.

Eine brauchbare Übergabe enthält die exakt ausgeführten Befehle, ihre Ergebnisse, die relevanten Ausgaben bei Erfolg oder Fehlern und jede Prüfung, die nicht ausgeführt werden konnte. „Tests erfolgreich“ lässt ohne Benennung der Tests offen, was überhaupt abgedeckt wurde. Eine gescheiterte Einrichtung der Umgebung verhindert den Nachweis; sie belegt nicht, dass der Code funktioniert.

Drew Breunig plädiert in 10 Lektionen für Agentic Coding für Tests des Produktverhaltens, dokumentierte Absichten und Spezifikationen, die sich mit der Implementierung weiterentwickeln. Im vorliegenden Beispiel lautet die dauerhaft relevante Prüfung: Ein Kunde kann keine Rechnungen eines anderen Kunden exportieren. Welche Hilfsfunktion diese Regel durchsetzt, darf sich ändern.

Ein automatisiertes Review kann weitere Befunde liefern. Die Person, die eine Änderung abnimmt, sollte deren entscheidenden Ablauf trotzdem verstehen. GitHub weist ausdrücklich darauf hin, dass KI-Reviews Probleme übersehen und Fehlalarme erzeugen können. Für sicherheitsrelevantes Verhalten und Wartbarkeit muss weiterhin ein menschlicher Reviewer verantwortlich bleiben. Grenzen von Reviews laut GitHub.

Wer kann mehr delegieren, und wer sollte noch warten?

Mehr Delegation ist sinnvoll, wenn das Erfolgskriterium klar ist, Fehler begrenzt bleiben und das Review überschaubar bleibt. Die folgende Tabelle schlägt eine Regelung für Entwicklungsteams vor. Sie ist keine Leistungszusage eines Anbieters.

Entwicklungsverantwortliche mit verlässlicher CI können jetzt anfangen. Geeignet sind zunächst Änderungen, die bestehenden Mustern folgen. Für jeden vom Agenten erzeugten Pull Request muss eine verantwortliche Person benannt sein. Wird das Review schwer nachvollziehbar, sollte die Aufgabe kleiner werden. Erfolgreiche Prüfungen helfen nur, wenn sie das entscheidende Verhalten abdecken.

Gründerinnen und Gründer können die Umsetzung eines Prototyps in einer entbehrlichen Umgebung weitgehend delegieren. Dafür eignen sich synthetische Daten; explorativer Code muss gegebenenfalls später ersetzt werden. Bevor Kundenkonten oder Geldtransfers hinzukommen, braucht es jemanden, der Zugriffsregeln, Fehlerbehandlung und betriebliche Folgen beurteilen kann.

Wer ein schlecht verstandenes Altsystem betreut, sollte zuerst die Prüfgrundlage verbessern. Ein Agent kann Verhalten untersuchen und Tests vorschlagen. Unbeaufsichtigtes Refactoring ist jedoch ein schwacher Einstieg, wenn niemand beabsichtigtes Verhalten von Zufällen unterscheiden kann. Vor mehr Autonomie muss der Ausgangszustand geklärt sein.

Wer mit Autovervollständigung gut zurechtkommt, muss nicht jede Aufgabe umstellen. Eine kleine, offensichtliche Änderung lässt sich mitunter schneller direkt erledigen. Der Aufwand für Delegation lohnt sich, wenn eine sinnvolle Abfolge aus Untersuchung, Änderung und Überprüfung übergeben werden kann.

Wo Agentic Coding scheitert und Erwartungen zu hoch sind

Die Agentenschleife scheitert, wenn ihre Rückmeldungen eine korrekte Lösung nicht von einer lediglich plausiblen unterscheiden können. Eine grüne Prüfung kann die Formatierung bestätigen und zugleich nichts über Mandantentrennung aussagen, also die Trennung der Daten verschiedener Kunden. Ein erfolgreicher Test mit Mocks kann an der Integration vorbeigehen, die Kunden tatsächlich nutzen. Eine überzeugende Zusammenfassung kann einen fehlgeschlagenen Befehl verschweigen.

Eine weitere Grenze ist der Kontext. Der Agent sieht womöglich die relevante Funktion, kennt aber nicht den Grund für eine ungewöhnliche Vorgabe. Folgenschwere Entscheidungen sollten nahe am betroffenen Code dokumentiert sein. Die maßgebliche Spezifikation muss benannt werden, und der Agent sollte Unsicherheiten offenlegen. Anthropic beschreibt, wie lange Sitzungen mit begrenztem Kontext umgehen. Es ist deshalb nicht davon auszugehen, dass eine frühe Gesprächsanweisung während einer umfangreichen Änderung durchgehend gleich präsent bleibt. So arbeitet Claude Code.

Mehr Agenten bedeuten auch mehr Abstimmungsaufwand. Bearbeiten getrennte Sitzungen dieselben Dateien, dieselbe Schnittstelle oder denselben Datenbankzustand, kann selbst ein lokal erfolgreiches Ergebnis mit einer anderen Änderung kollidieren. Dafür braucht es separate Checkouts und eine klar benannte Verantwortung für die Integration. Zunächst sollten unabhängige Untersuchungen parallel laufen, bevor eng miteinander verzahnte Implementierungen parallelisiert werden.

Grundsätzlicher wird das Problem, wenn Komplexität übernommen wird, die niemand warten wollte. Eine neue Abstraktion, Abhängigkeit oder Hintergrundaufgabe geht in die eigene betriebliche Verantwortung über, auch wenn sie leicht zu generieren war. Zu prüfen ist deshalb, ob der Umfang der neuen technischen Konstruktion zur Aufgabe passt.

Was Benchmarks für Agentic Coding nicht belegen

Ein Programmierbenchmark belegt für sich genommen keine Verbesserung der Lieferfähigkeit des eigenen Teams. Um ein veröffentlichtes Ergebnis zu übertragen, müssten Aufgaben, Repository-Kontext, Werkzeuge, Regeln für erneute Versuche und Erfolgsdefinition bekannt sein. Eine Produktivitätssteigerung in Prozent aus einer Herstellerangabe ist keine Prognose für die eigene Codebasis.

Ein eigener Pilotversuch sollte die Zeit bis zur abgenommenen Änderung, den Review-Aufwand, Nacharbeiten, nach dem Merge entdeckte Fehler und blockierte Durchläufe erfassen. Verglichen werden sollten ähnliche Aufgabentypen; auch gescheiterte Versuche müssen in der Auswertung bleiben. Das ist ein vorgeschlagener Messplan. Eine prozentuale Verbesserung wird hier nicht behauptet.

Delegation lässt sich ausweiten, wenn abgenommene Änderungen leichter fertigzustellen sind, ohne dass Review-Aufwand oder Fehler auf ein unvertretbares Maß steigen. Werden Patches schneller erzeugt, aber schwerer verständlich, sollte der Umfang sinken und die Prüfgrundlage besser werden.

Häufige Fragen

Der nächste konkrete Schritt

Als Einstieg eignet sich ein kleines Backlog-Issue mit reproduzierbarem Verhalten. Die Person für das Review sollte feststehen, bevor der Agent startet. Abnahmekriterien formulieren, eine isolierte Arbeitsumgebung bereitstellen und keine Zugangsdaten für Produktivsysteme herausgeben. Der Auftrag lautet: einen Patch liefern, einschließlich der Nachweise, die zu seiner Beurteilung nötig sind.

Nach dem Review festhalten, was der Agent übernommen hat, wo ein Mensch eingreifen musste und welche Prüfungen fehlten. Daraus ergibt sich der sinnvolle Umfang der nächsten Aufgabe. Mehr Autonomie ist angebracht, wenn das Prüfverfahren sie rechtfertigt.

Praktische Einblicke in die Entwicklung mit KI gibt es im Newsletter.