Kontrollierte Agenten-Loops: Wie KI-Coding-Agenten über den Prompt hinauswachsen

Software mit KI zu schreiben, wirkt immer noch erstaunlich manuell. IDE öffnen, Assistenten öffnen, Aufgabe beschreiben, warten, das Ergebnis prüfen, dann den nächsten Prompt tippen und noch einen. Selbst starke Coding-Agenten drehen sich um eine einzige Schleife: Ein Mensch fragt, der Agent arbeitet, der Mensch fragt wieder. Dieses Muster wirkt allmählich überholt.

Der nächste Schritt in der KI-gestützten Entwicklung ist nicht einfach ein klügerer Coding-Agent. Es sind Agenten, die einen Workflow weiter durchlaufen, ohne in jeder Phase einen neuen Prompt zu brauchen. Atlassian hat dafür kürzlich einen Begriff geprägt: governed agent loops, also kontrollierte Agenten-Loops. Der Vorschlag verbindet Backlogs, Repository-Kontext, Coding-Agenten, Standards, Reviews und Messung zu einem durchgehenden Fluss. Jira könnte klar definierte, nicht zugewiesene Arbeit erkennen, sie an einen Coding-Agenten übergeben, diesen sie implementieren und testen lassen und einen Pull Request zum Review eröffnen.

Das klingt nach einfacher Automatisierung, doch die tiefere Veränderung ist architektonisch. KI wandelt sich von einem Werkzeug innerhalb des Softwareentwicklungs-Lebenszyklus zu einem Teil dieses Lebenszyklus selbst.

Der Mensch als Workflow-Engine

Nehmen wir ein gewöhnliches Ticket.

Add rate limiting to the /api/generate endpoint.

Mit angehängten Akzeptanzkriterien.

Requirements:
- 20 requests/minute per user
- Redis-backed
- Return HTTP 429 when exceeded
- Add tests
- Do not affect internal jobs

Heute würde ein Entwickler das vielleicht in Cursor, Claude Code, Codex oder einen anderen Agenten einfügen, der das Repository erkundet und mit der Implementierung beginnt. Bald muss der Entwickler wieder eingreifen und sagen:

Run the tests.

Dann:

Check the middleware.

Dann:

Review the diff.

Dann:

Fix the failing test.

Und schließlich:

Open the PR.

Der Agent erledigt die Arbeit, aber der Mensch treibt die Zustandsmaschine weiterhin von Hand voran und fungiert als Workflow-Engine. Ein kontrollierter Agenten-Loop nimmt ihm diese Last ab.

Backlog
   ↓
Select eligible task
   ↓
Load repository context
   ↓
Implement
   ↓
Run tests
   ↓
Review
   ↓
Fix
   ↓
Open PR
   ↓
Human approval

Menschen verschwinden nicht aus dem Bild. Sie hören nur auf, jeden Übergang manuell auszulösen.

Die Parallele zu CI/CD

Der Vergleich mit CI/CD hilft. Die Auslieferung veränderte sich, als Ingenieure aufhörten, jeden Deployment-Schritt von Hand auszuführen. Niemand sagt dem System, es solle Tests laufen lassen, dann bauen, dann auf Staging deployen, dann etwas prüfen.

Run tests.
Now build.
Now deploy staging.
Now check this.
Now deploy production.

Eine Pipeline wird definiert, und das System führt sie aus. Agenten-Loops streben denselben Wandel bei der Softwareerstellung selbst an. Früher sah es so aus.

Human → Prompt → Agent

Neu sieht es so aus.

Backlog → Agent → Tools → Tests → Review → PR

Das ist eine weit interessantere Abstraktion, denn der Coding-Agent wird zu einer Komponente in einem größeren Auslieferungssystem.

Autonomie muss abgestuft sein

Einem Agenten mehr Autonomie zu geben, ist leicht. Ihm genau das richtige Maß zu geben, ist schwer. Stellen Sie sich ein Backlog mit diesen Einträgen vor.

Fix typo in README
Add unit tests
Update API validation
Change authentication middleware
Migrate PostgreSQL schema
Modify payment processing
Rotate production credentials

Nicht alle sollten dieselbe Freiheit bekommen. Ein vernünftiges System ließe einen Agenten die README-Korrektur automatisch erledigen und wahrscheinlich auch eine einfache Unit-Test-Aufgabe. Eine Datenbankmigration oder eine Änderung an der Authentifizierung verlangt zusätzliche Kontrollen. Deshalb zählt das Wort „kontrolliert“. Der Ansatz von Atlassian umfasst Grenzen dafür, worauf Agenten zugreifen können, organisatorische Standards, die auf Repositories abgebildet werden, und ein KI-Review, das Pull Requests an diesen Standards misst. Die resultierende Architektur sieht so aus.

┌───────────────┐
                 │   Backlog     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Eligibility   │
                 │    Rules      │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Coding Agent  │
                 └───────┬───────┘
                         ↓
             ┌───────────┴───────────┐
             ↓                       ↓
        Repository               Tooling
          Context             Tests / Build / CI
             │                       │
             └───────────┬───────────┘
                         ↓
                 ┌───────────────┐
                 │ AI Review     │
                 └───────┬───────┘
                         ↓
                    Human Gate
                         ↓
                       Merge

Das ist kein KI-Assistent mehr. Das ist eine Engineering-Control-Plane.

Kontext ist Teil der Schnittstelle

Ein Agent kann an einem großen System nicht zuverlässig arbeiten, wenn er nur das aktuelle Ticket kennt. Nehmen wir die Anfrage, der Benutzerprofil-API Caching hinzuzufügen. Die richtige Umsetzung hängt von Fakten ab, die das Ticket womöglich nie erwähnt:

• welchen Cache das Unternehmen verwendet
• ob Redis bereits verfügbar ist
• die Invalidierungsstrategie
• ob für Profilaktualisierungen Eventual Consistency genügt
• welche Services von der API abhängen
• Datenschutzvorgaben
• die Namenskonventionen des Repositorys
• welche Tests Pflicht sind
• ob es irgendwo schon Caching gibt

Atlassian betont deshalb eine gemeinsame Kontextschicht, die Code mit organisatorischem Wissen verbindet. Die Funktion Code Context liefert Agenten Informationen über Repositories hinweg, und Agent Context Controls legen fest, welche Agenten in einem Bereich arbeiten dürfen und was sie sehen können.

Für Entwickler ist die Lehre einfach: Bessere Modelle können fehlenden Engineering-Kontext nicht ewig ausgleichen. Repository-Struktur, Dokumentation, Tests, Architekturentscheidungen, Coding-Standards und Issue-Beschreibungen werden zunehmend zur Programmierschnittstelle des Agenten.

Repositories für zwei Zielgruppen

Jahrelang wurden Repositories für Menschen optimiert, denen diese Dinge wichtig waren.

Readable code
Good documentation
Clear naming
Useful comments
Tests
Consistent architecture

Das zählt weiterhin. Aber jetzt gibt es einen zweiten Leser: den Coding-Agenten. In einem chaotischen Repository findet er sich schwer zurecht. Ein fehlender Test bedeutet weniger Verhaltensgrenzen. Vage Dokumentation lädt zu falschen Annahmen ein, und inkonsistente Konventionen zwingen zum Raten von Mustern. Teams sollten ein Repository deshalb als maschinenlesbare Engineering-Umgebung behandeln, mit einer Struktur etwa wie dieser.

project/
├── README.md
├── ARCHITECTURE.md
├── CONTRIBUTING.md
├── AGENTS.md
├── docs/
├── src/
├── tests/
└── package.json

Dateien wie AGENTS.md können repository-spezifische Anweisungen enthalten, beginnend mit einer Überschrift.

# Engineering Rules

Gefolgt von konkreten Regeln.

- Use TypeScript strict mode.
- Do not access the database directly from route handlers.
- Services belong in /src/services.
- Every API endpoint requires integration tests.
- Run `npm test` before opening a PR.
- Never modify production configuration from an automated task.

Das Repository enthält nun einen Teil des Betriebsvertrags des Agenten. Das ist eine Engineering-Verbesserung, noch bevor überhaupt volle Autonomie kommt.

Tests als Verhaltensgrenzen

Wenn Agenten kontinuierlich laufen, schützen Tests nicht nur vor Regressionen. Sie setzen Verhaltensgrenzen. Google hat kürzlich beschrieben, wie man Coding-Agenten mit kleinen Verhaltensprüfungen bewertet, statt sich nur auf riesige End-to-End-Benchmarks zu stützen. Die Tests betrachten beobachtbare Handlungen, etwa ob ein Agent bei einem mehrdeutigen Prompt nachfragt oder den richtigen Validator ausführt, bevor er eine Aufgabe für erledigt erklärt.

Das passt gut zur Produktionsarbeit. Statt nur zu fragen, ob der Agent die Aufgabe letztlich gelöst hat, fragen Sie, ob er sich unterwegs sicher verhalten hat. Ein Test könnte verlangen, dass der Agent die Testsuite ausführt, bevor er eine Paginierungsaufgabe für abgeschlossen erklärt.

def test_agent_runs_tests_before_completion():
    result = run_agent(
        "Add pagination to the users API"
    )

    assert "test" in result.executed_commands

Ein anderer könnte darauf bestehen, dass eine Korrektur der Deployment-Konfiguration niemals die Produktionskonfiguration anfasst.

def test_agent_does_not_modify_production_config():
    result = run_agent(
        "Fix the deployment configuration"
    )

    assert "production.yaml" not in result.modified_files

Solchen Prüfungen ist egal, ob der Agent fünf oder zwanzig Schritte gebraucht hat. Ihnen geht es um Verhalten, das zählt. Google vergleicht diese Bewertungen mit Unit- oder Integrationstests für den Agenten-Harness selbst. Auch der Agent braucht Tests.

Menschen bleiben am Merge

Es ist verlockend, autonome Entwicklung so zu verstehen, dass Entwickler aus dem Loop verschwinden. Ein besseres Modell lässt das Urteilsvermögen dort, wo es zählt.

Agent autonomy before review
+
Human judgment before merge

Agenten können Repository-Erkundung, Implementierung, repetitives Refactoring, Testerstellung und -ausführung, Debugging, Dokumentation und einen ersten Review-Durchgang übernehmen. Menschen konzentrieren sich auf die schwierigeren Fragen: Ist das die richtige Lösung, erfüllt sie die Produktanforderung, ist die Architektur sinnvoll, gibt es Sicherheitsfolgen, entstehen langfristige Schulden, ist das Deployment sicher? Der Merge-Button wird zu einer weit wertvolleren Grenze. Atlassian sagt das auch: Agenten können parallel arbeiten, während Entwickler und Produktmanager die Freigabe darüber behalten, was ausgeliefert wird.

Review, das verifiziert

GitHub geht in dieselbe Richtung. Die jüngsten Änderungen an Copilot Code Review geben dem Review-Agenten Shell-Zugriff für tiefere Prüfungen: Er kann Builds, Tests und gezielte Skripte ausführen und verfügbare Tools und APIs abfragen. Das Unternehmen ergänzt, dass der leichtere Review-Modus von einem einzelnen Agenten auf ein Ensemble umgestellt wurde.

Das ist wichtig, weil es nicht reicht, einen Diff als Text zu lesen. Angenommen, der Agent sieht Folgendes.

const result = await fetchUser(id);
return result.data;

Ein statischer Reviewer könnte eine mögliche Null-Antwort anmerken. Ein Agent mit Repository-Zugriff kann weiter gehen.

fetchUser()
   ↓
API client
   ↓
HTTP response handling
   ↓
retry middleware
   ↓
tests

Er kann den relevanten Test ausführen, die Implementierung lesen und entscheiden, ob die Sorge berechtigt ist. Das ist Verifikation statt Mustervergleich.

Immer aktiv, nie uneingeschränkt

Dauerbetrieb braucht explizite Grenzen. Ein Produktions-Setup könnte festlegen, was der Agent darf.

Agent may:
✓ Read repository
✓ Create branch
✓ Modify source files
✓ Run tests
✓ Open PR

Und was nicht.

Agent may not:
✗ Merge production changes
✗ Modify secrets
✗ Change access controls
✗ Deploy infrastructure
✗ Alter billing logic

Darüber können Risikoschwellen liegen. Arbeit mit geringem Risiko läuft autonom.

Low-risk task
→ autonomous

Bei mittlerem Risiko kommt ein Review hinzu, und bei hohem Risiko bereitet der Agent eine Änderung vor, die ein Mensch freigeben muss.

Medium-risk task
→ autonomous + reviewHigh-risk task
→ agent prepares change + mandatory human approval

Das ist weit praktikabler als die binäre Frage, ob man KI vertrauen kann. Die bessere Frage lautet, welche Autonomiestufe zu welcher Klasse von Engineering-Aktionen passt, und das ist eine Frage der Softwarearchitektur.

Wohin sich der Engpass verschiebt

Wenn Agenten eigenständig Dutzende Tickets umsetzen können, verschiebt sich die Beschränkung. Code, Pull Requests, Testläufe und einfache Reviews werden billiger. Die Entscheidung, was gebaut werden soll, nicht. Ebenso wenig diese Entscheidungen.

What should be automated?
What should be constrained?
What requires human approval?
What should be measured?
What does "correct" mean?

Senior Engineers verbringen deshalb womöglich mehr Zeit damit, die Systeme rund um Agenten zu entwerfen. Eine Engineering-Architektur könnte so aussehen.

Product requirements
        ↓
Work classification
        ↓
Agent assignment
        ↓
Context retrieval
        ↓
Coding agent
        ↓
Behavioral validation
        ↓
CI
        ↓
AI review
        ↓
Human review
        ↓
Production
        ↓
Telemetry
        ↓
New context

Der Software-Lebenszyklus wird zu einer Feedbackschleife.

Messen, was zählt

Eine weitere Falle wartet. Ein Team könnte feiern, dass Agenten in einem Monat 500.000 Codezeilen erzeugt haben, was fast nichts aussagt. Eine bessere Scorecard stellt Fragen wie diese.

How many tasks were completed?
How many required human intervention?
How many were reverted?
How many defects escaped?
How long did tasks take?
How much did each task cost?
How often did agents get blocked?
How often did humans override the agent?

Atlassian ergänzt die agentische Entwicklung um Messungen von Durchsatz, Qualität, Akzeptanz und Kosten, und das ist die richtige Richtung. KI-Engineering braucht echte Engineering-Metriken, keine Eitelkeitsmetriken.

Eine Softwarefabrik

Jahrelang ging es darum, welchen Coding-Assistenten man in der IDE installiert. Das könnte weniger wichtig werden als eine andere Frage: Was passiert, wenn das ganze Backlog ausführbar ist?

Stellen Sie sich vor, Sie öffnen Jira am Montagmorgen. Statt jede kleine Aufgabe von Hand zuzuweisen, zeigt das Board einen Stapel geeigneter Arbeit, und verschiedene Agenten übernehmen verschiedene Einträge.

12 eligible tasks
↓
Agent A → API validation
Agent B → frontend refactor
Agent C → test coverage
Agent D → documentation

Jeder Agent bekommt seine eigene Sandbox, führt die Tests aus und reicht einen Pull Request ein. Zuerst prüft ein KI-Durchgang die Änderungen, Menschen schalten sich nur bei Entscheidungen ein, die Urteilsvermögen erfordern, und fertige Arbeit fließt zurück ins System. Das ähnelt einer Softwarefabrik. Die Menschen sind nicht verschwunden; sie schieben nur nicht mehr jedes Arbeitsstück von Hand durch die Fabrik.

Wettbewerb um den ganzen Loop

Künftige Coding-Produkte werden wahrscheinlich nicht nur über Modellintelligenz, Autovervollständigungsqualität, Benchmark-Ergebnisse oder die Größe des Kontextfensters konkurrieren. Sie konkurrieren über den gesamten Loop: Kontext, Ausführung, Validierung, Review, Governance und Messung. Ein etwas schwächeres Modell in einem hervorragenden Engineering-System kann ein stärkeres schlagen, das in einem schlechten Workflow feststeckt.

Die Anzeichen sind schon sichtbar. Google arbeitet an Verhaltensbewertung und Agenten-Harnesses. GitHub lässt das Code-Review Code ausführen und validieren. Atlassian verbindet Backlog-Management, Kontext, Agentenausführung, Standards, Review und Messung zu kontrollierten Agenten-Loops. Die Produkte unterscheiden sich, zeigen aber auf dasselbe Ziel.

Jenseits von Prompts

Die größte Veränderung ist nicht, dass KI mehr Code schreiben kann, denn diese Schwelle liegt hinter uns. Sondern dass Agenten nun an mehreren Phasen der Auslieferung teilnehmen können. Entwickler müssen über Prompts hinausdenken, hin zu Fragen wie diesen.

Context
Permissions
Tools
Tests
Evaluation
Observability
Failure recovery
Human approval
Cost

Das sind klassische Engineering-Themen. KI hat Softwareentwicklung nicht abgeschafft; sie hat ihre Oberfläche erweitert. Der Entwickler von morgen tippt vielleicht weniger Implementierungscode und verbringt mehr Zeit damit, das System zu entwerfen, mit dem Maschinen ihn sicher erzeugen. Das könnte der eigentliche Beginn eines KI-nativen Software-Lebenszyklus sein.

Die Zukunft des Programmierens ist nicht ein klügerer Agent, der auf den nächsten Prompt wartet. Es ist ein Verbund kooperierender Agenten, die sehen, welche Aufgaben offen sind, die Codebasis lesen, die Regeln des Teams befolgen, ihre eigenen Ergebnisse prüfen und im richtigen Moment einen Menschen hinzuziehen. Diesen Loop autonom zu machen, ist nicht das Schwierige. Ihn vertrauenswürdig zu machen, schon.