Du sitzt im Auto deines Vertrauens. Der Wagen ist neu, hat jede Menge Assistenzsysteme und fährt fast von allein. Würdest du deshalb aufs Anschnallen verzichten? Wohl kaum. Genau so verhält es sich mit KI-Agenten: Nur weil die Modelle intelligenter werden, heißt das nicht, dass du ihnen blind vertrauen solltest. Die Frage ist nicht, wie gut das Modell ist, sondern wie gut du die Aufgabe kontrollieren kannst.
In der Softwareentwicklung setzen immer mehr Teams auf KI-Agenten, die Code schreiben, refaktorieren oder Pull Requests mergen. Wo liegt die Grenze zwischen sinnvoller Delegation und fahrlässiger Übergabe? Die Antwort liefert ein einfaches Raster mit zwei Fragen: Ist das Ergebnis leicht zu überprüfen? Ist der Schaden im Fehlerfall leicht rückgängig zu machen?
Die zwei Achsen der Delegation
Der Schlüssel liegt nicht im Modell, sondern in der Aufgabe. Code, der gegen Unit-Tests läuft, ist leicht zu prüfen. Eine subjektive Entscheidung wie die Umbenennung einer Variable zur besseren Lesbarkeit dagegen schwer – da braucht es menschliches Urteilsvermögen. Auch die Rückgängigmachung zählt: Ein fehlerhafter Commit im Hauptzweig kann ganze Teams lahmlegen, ein verworfener Entwurf in einem Branch schadet kaum.
Diese zwei Dimensionen – Checkbarkeit und Undo-Kosten – spannen eine 2×2-Matrix auf, die vier Stufen der Autonomie für KI-Agenten definiert. Level 0 bis Level 3. Gehen wir sie durch.
Level 0: Der Agent als Assistent
Die niedrigste Stufe betrifft Aufgaben, die schwer zu prüfen und teuer rückgängig zu machen sind. Hier arbeitet der Agent im Assistentenmodus: Er macht Vorschläge, aber der Mensch entscheidet und führt aus. Genau das, was wir seit 2024 von ChatGPTs Autovervollständigung in Cursor kennen. Für sensible Codebereiche ist das richtig.
Ein Beispiel: Als ein Entwickler bei PostHog das Feature-Flag-System um generisches Property-Targeting erweiterte, musste er eine Annahme ändern, die indirekt in jedem Feature-Flag steckte. Für einen Agenten war das weder durchsuchbar noch deterministisch prüfbar. Die Änderung hatte zudem eine enorme Reichweite – sie betraf Live-Kunden-Flags, API-Response-Formate und Scoring-Funktionen. Der Entwickler zerlegte die Aufgabe in kleine Stücke. Die weniger kritischen Teile – etwa die Verteilung der neuen Logik auf verschiedene SDKs – delegierte er an Agenten, den Kern erledigte er von Hand.
Die Lehre: Zerlege komplexe Aufgaben. Kleine Einheiten machen sofort sichtbar, wo Delegation sicher ist und wo nicht.
Level 1: Human-in-the-Loop
Hier liegen Aufgaben, die schwer zu prüfen, aber billig rückgängig zu machen sind. Typischerweise geht es um subjektive Bewertungen: Code-Lesbarkeit, Kommentare, kleine Umstrukturierungen. Der Agent erstellt einen Vorschlag, der in einem Entwurf bleibt. Ein Mensch prüft ihn, gibt Feedback oder lehnt ab. Ein Undo bedeutet einfach eine weitere Iteration.
Ein gutes Beispiel ist eine Code-Readability-Refaktorisierung – wenige Zeilen, die das Verständnis verbessern, ohne die Logik zu ändern. Ein Agent kann solche Änderungen vorschlagen, aber nicht beurteilen, ob sie wirklich besser sind. Hier hilft der Einsatz eines LLM-as-judge: Man lässt ein großes Sprachmodell die Qualität bewerten. Auch das Definieren eines messbaren Ziels (etwa „Konversionsrate der Landingpage um 3 % steigern“) oder das Schreiben von Custom Skills – spezifischen Regeln für den Agenten – kann die subjektive Prüfung objektivieren.
Level 2: Agentendelegation
Die meisten Entwickleraufgaben befinden sich heute auf dieser Stufe: Der Code ist leicht zu testen (Unit-Tests, Integrationstests), aber der finale Merge ist riskant. Ein Agent schreibt den Code, aber bevor er ins Hauptsystem kommt, wird er durch mehrere Sicherheitsschleusen geschickt.
Ein beeindruckendes Beispiel ist die Neuimplementierung eines SQL-Parsers in Rust bei PostHog. Der Agent hat die Arbeit erledigt, der Entwickler hat kaum eine Zeile gelesen – denn er hatte ein maschinelles Orakel, das die Korrektheit prüfte. Trotzdem wurde der Code nicht einfach gemerged, sondern durchlief einen Schattenmodus in der Produktion und dann eine gestaffelte Umstellung. Das verhindert böse Überraschungen.
Die wichtigste Erkenntnis für Level 2: Ersetze die menschliche Genehmigung durch programmatische Guardrails. Statt jedes Mal selbst zu reviewen, baue Policies ein – Trockenläufe, eingeschränkte Credentials, Feature-Flags. Das entlastet dich und beschleunigt die Entwicklung.
Level 3: Self-Driving Mode
Die höchste Stufe der Autonomie umfasst Aufgaben, die leicht zu prüfen und billig rückgängig zu machen sind. Das sind heute noch kleine Dinge: Dependency-Updates, Lint-Fixes, Hinzufügen von Testabdeckung. Aber die Kategorie wächst rasant – vor allem mit langlebigen Agenten, zielgetriebenen Schleifen und komplexer Orchestrierung.
PostHog treibt diesen Bereich aktiv voran. Mit Scouts etwa laufen Agenten zeitgesteuert, analysieren Produktdaten und erstellen eigenständig Pull Requests. Die Herausforderung ist, dem Agenten beizubringen, wann sich eine Aktion lohnt und wie er echte Signale von Rauschen unterscheidet.
Um Level 3 für weitere Aufgaben zu erschließen, sind drei Hebel entscheidend:
- Domain-spezifische Modelle trainieren: Ein Modell, das gelernt hat, was „gut“ in einer bestimmten Domäne bedeutet, kann Prüfungen übernehmen, die heute noch menschliches Urteil erfordern.
- Experten-Wissensbanken aufbauen: Oft ist mangelnde Autonomie schlicht ein Kontextdefizit. Wer dem Agenten strukturiertes, aktuelles Wissen mitgibt, ermöglicht zuverlässigere Entscheidungen.
- Klare Signale für Scouts definieren: Der Flaschenhals langlebiger Agenten ist die Frage, ob sie überhaupt wissen, wann Arbeit nötig ist. Hier braucht es präzise Metriken und Alarme.
Was bedeutet das konkret?
Die vier Stufen sind keine feste Hierarchie, sondern ein Werkzeug, um für jede einzelne Aufgabe bewusst zu entscheiden, wie viel Autonomie sinnvoll ist. Der entscheidende Punkt: Vertraue nicht blind auf die Intelligenz des Modells – vertraue auf die Nachvollziehbarkeit und Rückholbarkeit der Aufgabe. Das ist wie der Sicherheitsgurt: Egal wie gut das Auto fährt, er rettet dich, wenn etwas schiefläuft.
Indem du Aufgaben in ihre Bestandteile zerlegst und für jedes Teil prüfst, ob du es leicht testen und leicht rückgängig machen kannst, findest du das optimale Maß an Delegation. Und du wirst feststellen: Mit den richtigen Guardrails kannst du immer mehr an Agenten abgeben – ohne die Kontrolle zu verlieren. Die Zukunft gehört nicht den Modellen, sondern dem klugen Design der Aufgaben.
Quelle: newsletter.posthog.com
