Ein Coding-Copilot schlägt vor. Ein Coding-Agent handelt. In diesem einen Wort steckt das gesamte Steuerungsproblem.
Bis 2025 haben die meisten Entwicklungsteams KI behandelt, als wäre sie eine klügere Autovervollständigung: Ein Vorschlag erscheint, eine Entwicklerin nimmt ihn an oder verwirft ihn, und zwischen Modell und Repository liegt ein menschlicher Tastendruck. 2026 trägt diese Annahme nicht mehr. Hintergrund-Agenten legen Branches an, lassen Testsuiten laufen, refaktorieren über Dateien hinweg, erstellen Pull Requests und mergen sie in manchen Setups sogar selbst. Der Mensch ist nicht mehr standardmäßig in der Schleife. Er steht daneben und überwacht, oder er ist gar nicht mehr dabei.
Wenn wir einem Team in Hamburg oder im DACH-Raum helfen sollen, genau das in den Griff zu bekommen, schauen wir als Erstes, ob überhaupt jemand festgelegt hat, was ein Agent ohne anwesenden Menschen tun darf. Meistens hat das niemand. Die Richtlinie geht noch immer von einem Menschen an der Tastatur aus.
Kernaussagen
- Ein Copilot schlägt vor, ein Agent handelt. Regeln, die für Vorschläge gedacht waren, decken autonome Aktionen nicht ab.
- Definieren Sie den Geltungsbereich eines Agenten als ausdrückliche Positivliste mit minimalen Rechten, nie als Negativliste.
- Setzen Sie menschliche Freigaben dort, wo sich das Risiko bündelt, und halten Sie bei jedem Merge in die Produktion einen Menschen dazwischen.
- Ein Agent trägt nie die Verantwortung. Weisen Sie jedem Agenten (und allem, was er ausliefert) ein benanntes, verantwortliches Team zu.
Was einen Agenten von einem Copilot unterscheidet
Der Unterschied liegt nicht in der Modellqualität. Er liegt in der Autonomie und in der Reichweite des Schadens. Ein Copilot schlägt eine Änderung in einem Editor vor, den die Entwicklerin ohnehin im Blick hat. Ein Agent nimmt ein Ziel entgegen und führt eine ganze Kette von Aktionen aus, um es zu erreichen, oft an Systemen, die kein einzelner Reviewer in Echtzeit beobachtet.
| Eigenschaft | Copilot (assistierend) | Agent (autonom) |
|---|---|---|
| Auslöser | Menschlicher Tastendruck | Ziel, Zeitplan oder Webhook |
| Position des Menschen | In der Schleife, bei jedem Vorschlag | Daneben oder gar nicht dabei |
| Aktionsumfang | Eine Datei, ein Cursor | Viele Dateien, Befehle, externe Aufrufe |
| Sichtbarkeit von Fehlern | Sofort, im Editor | Verzögert, in der CI oder in der Produktion |
| Wer die Ausgabe verantwortet | Die annehmende Entwicklerin | Oft ungeklärt |
Aus dieser letzten Zeile entstehen die Störfälle. Wird ein Vorschlag ausgeliefert, gehört er der Person, die ihn angenommen hat. Liefert ein Agent etwas aus, muss die Verantwortung bewusst zugewiesen werden. Denn es gab keinen einzelnen Moment menschlicher Zustimmung, an dem man sie festmachen könnte.
Die drei Fragen vor dem unbeaufsichtigten Lauf
Bevor ein Agent läuft, ohne dass jemand jeden Schritt beobachtet, braucht eine Entwicklungsorganisation klare Antworten auf drei Fragen. Können Sie sie nicht beantworten, steuern Sie keine Agenten, Sie hoffen nur.
- Worauf darf der Agent zugreifen? Welche Repositories, Branches, Umgebungen, Zugangsdaten und externen Dienste liegen im Geltungsbereich, und welche ausdrücklich nicht.
- Wo muss ein Mensch freigeben? Welche Aktionen ein Agent frei ausführen darf, welche vor ihrer Wirksamkeit ein Review brauchen und welche er niemals ausführen darf.
- Wer verantwortet das Ergebnis? Die namentlich benannte Person oder das Team, das für das geradesteht, was der Agent ausliefert, ganz gleich, wie autonom es entstanden ist.
Daraus ergibt sich eine einfache Steuerungsfläche: Geltungsbereich, Freigabe, Verantwortlicher. Der Rest dieses Artikels zeigt, wie Sie jeden dieser Punkte konkret machen.
Geltungsbereich: die Reichweite des Schadens vor dem ersten Lauf festlegen
Die Reichweite eines Agenten ist alles, was er ändern oder erreichen kann. Die meisten Standard-Setups haben eine weit größere Reichweite als jemals beabsichtigt, weil der Agent schlicht die Rechte erbt, die seine Zugangsdaten mitbringen.
Wir empfehlen, den Geltungsbereich als ausdrückliche Positivliste zu definieren, nicht als Negativliste. Eine Negativliste setzt voraus, dass Sie jede gefährliche Aktion im Voraus aufzählen können. Das können Sie nicht. Eine Positivliste setzt das Gegenteil voraus: Der Agent darf nur innerhalb einer festgelegten Grenze handeln, und alles darüber hinaus erfordert einen Menschen.
| Dimension | Enge Voreinstellung | Warum |
|---|---|---|
| Repositories | Nur benannte Repos | Verhindert projektübergreifende Überraschungen |
| Branches | Feature-Branches, nie main | Hält den menschlichen Merge als Schranke offen |
| Umgebungen | Standardmäßig nicht produktiv | Produktionszugriff ist eine eigene, auditierte Entscheidung |
| Zugangsdaten | Eingegrenzte, kurzlebige Tokens | Begrenzt den Schaden, wenn der Agent entgleist |
| Externe Aufrufe | Endpunkte auf Positivliste | Verhindert, dass Daten an ungeprüfte Dienste abfließen |
Das Prinzip ist dasselbe, das Sicherheitsteams seit Jahren auf Dienstkonten anwenden: minimale Rechte. Ein Agent ist ein nicht-menschlicher Akteur mit Zugangsdaten. Behandeln Sie ihn auch so.
Leitplanken: festlegen, wo ein Mensch stehen muss
Eine Freigabe ist die Stelle, an der die Aktion eines Agenten anhält, bis ein Mensch sie bestätigt. Die Kunst besteht darin, diese Schranken dort zu setzen, wo sich das Risiko bündelt, und nicht überall. Denn eine Freigabe an jeder einzelnen Aktion macht aus dem Agenten wieder einen langsamen Copilot, und das Team wird Wege finden, sie zu umgehen.
Wir sortieren Agenten-Aktionen in drei Stufen:
- Frei: Aktionen, die der Agent selbst ausführen und abschließen darf. Code lesen, Tests laufen lassen, Änderungen auf einem Feature-Branch entwerfen, einen Pull Request als Entwurf öffnen.
- Freigabepflichtig: Aktionen, die vor ihrer Wirksamkeit eine menschliche Freigabe brauchen. Merge in einen geschützten Branch, Abhängigkeiten ändern, Infrastruktur oder Migrationen anfassen, alles, was die Produktion erreicht.
- Verboten: Aktionen, die der Agent niemals ausführen darf. Secrets im Klartext verarbeiten, unbeaufsichtigt in die Produktion deployen, Zugriffsrechte ändern, außerhalb seiner Repositories handeln.
Die wichtigste Schranke ist die vor dem Merge. Solange ein Mensch prüft und merged, gilt weiterhin die bestehende Code-Review-Disziplin, und der Agent bleibt ein sehr schneller Mitarbeiter statt eines unbeaufsichtigten Committers. Die meisten Teams sollten diese Schranke noch lange geschlossen halten.
Verantwortung: Ein Agent ist kein Verantwortlicher
Die schädlichste Vorstellung, die uns begegnet, ist die, der Agent sei für seine Ausgabe verantwortlich. Ist er nicht. Ein Agent kann keine Rufbereitschaft übernehmen, lässt sich in einer Nachbesprechung nicht zur Rede stellen und kann gegenüber einer Kundin nicht geradestehen. Die Verantwortung muss bei einer Person oder einem Team liegen.
Das ist nicht nur betrieblich vernünftig. Nach dem EU AI Act ist die menschliche Aufsicht über KI-Systeme eine Anforderung an die Governance, keine Kür. Und Aufsicht ist sinnlos, wenn niemand tatsächlich für das einsteht, was das System getan hat. „Der Agent hat es geschrieben“ ist keine Verteidigung. Es ist das Eingeständnis, dass es keine gibt.
In der Praxis weisen wir Verantwortung genauso zu, wie Teams Code-Zuständigkeiten verteilen: Jeder Agent hat ein benanntes verantwortliches Team, jede Änderung, die ein Agent ausliefert, erbt dessen Zuständigkeit, bis ein Reviewer sie übernimmt, und das verantwortliche Team steht dauerhaft für Geltungsbereich, Freigaben und Verhalten des Agenten ein.
Ein Betriebsmodell für den Einstieg
Würden wir 2026 für eine Entwicklungsorganisation eine Agenten-Steuerung aufsetzen, wäre das das Minimum, das wir vor dem ersten unbeaufsichtigten Lauf einrichten würden.
| Kontrolle | Konkrete Form |
|---|---|
| Agentenverzeichnis | Eine Liste jedes Agenten mit Zweck, Geltungsbereich und verantwortlichem Team |
| Eingegrenzte Zugangsdaten | Kurzlebige Tokens mit minimalen Rechten je Agent |
| Branch-Schutz | Agenten pushen auf Feature-Branches, Menschen mergen |
| Aktionsstufen | Frei / freigabepflichtig / verboten, schriftlich festgehalten und durchgesetzt |
| Audit-Trail | Jede Agenten-Aktion protokolliert: was, wann, auf wessen Anweisung |
| Not-Aus | Ein dokumentierter, getesteter Weg, einen Agenten sofort zu stoppen |
Nichts davon ist exotisch. Es ist die Betriebsdisziplin, die Teams ohnehin auf Deployments und Dienstkonten anwenden, nur erweitert auf einen neuen Typ von Akteur.
Was das nicht ist
Das ist kein Argument gegen Agenten. Innerhalb einer klaren Grenze eingesetzt, sind Agenten der bedeutendste Produktivitätssprung in der Entwicklung seit CI. Gewinnen werden weder die Teams, die sie verbieten, noch die, die sie ohne Geltungsbereich laufen lassen. Gewinnen werden die, die in einem Satz sagen können, was jeder Agent darf und wer für ihn geradesteht.
Es ist auch kein Aufruf zu einer großen neuen Bürokratie. Die Kontrollen oben passen auf eine Seite. Die Arbeit liegt nicht in der Menge, sondern in der Klarheit: die Grenze bewusst zu ziehen, statt sie erst während eines Störfalls zu entdecken.
Unsere Sicht
Der Wechsel vom Copilot zum Agenten ist ein Wechsel darin, wer Ihre Codebasis bedient. Regeln, die für Vorschläge geschrieben wurden, decken Aktionen nicht ab. Organisationen, die einen Agenten als berechtigten, eingegrenzten, verantworteten Akteur behandeln, mit einem Menschen an den Schranken, die zählen, werden Agenten sicher skalieren. Wer einen Agenten als schnellere Autovervollständigung behandelt, lernt den Unterschied auf die harte Tour kennen: in der Produktion.
Legen Sie die Reichweite des Schadens fest, setzen Sie die Schranken dorthin, wo das Risiko sitzt, und schreiben Sie einen Namen auf das Ergebnis. Mehr ist es nicht.
Quellen
- EUR-Lex, Verordnung (EU) 2024/1689 (EU AI Act), Artikel 14 zur menschlichen Aufsicht, abgerufen am 2026-06-10
- NIST,
AI Risk Management Framework (AI RMF 1.0), abgerufen am 2026-06-10 - OWASP,
OWASP Top 10 for Large Language Model Applications, abgerufen am 2026-06-10
Häufige Fragen
- Was ist der Unterschied zwischen einem KI-Coding-Copilot und einem KI-Coding-Agenten?
- Ein Copilot schlägt Änderungen in einem Editor vor, den eine Entwicklerin beobachtet, mit einem menschlichen Tastendruck zwischen Modell und Repository. Ein Agent nimmt ein Ziel entgegen und führt eine Reihe von Aktionen aus, um es zu erreichen – Branches öffnen, Befehle ausführen, Pull Requests erstellen oder mergen –, oft ohne eingebundenen Menschen. Der Unterschied liegt in Autonomie und Wirkungsradius, nicht in der Modellqualität.
- Was darf ein KI-Coding-Agent ohne menschliche Freigabe tun?
- Definieren Sie den Geltungsbereich als ausdrückliche Positivliste mit minimalen Rechten. Agenten sollten frei Code lesen, Tests laufen lassen und Änderungen auf Feature-Branches entwerfen. Merge in geschützte Branches, Änderungen an Abhängigkeiten, Infrastruktur oder Migrationen und alles, was die Produktion erreicht, sollten eine menschliche Freigabe erfordern. Secrets verarbeiten, unbeaufsichtigt ausliefern und außerhalb der Repositories handeln sollten verboten sein.
- Wer ist verantwortlich, wenn ein KI-Agent fehlerhaften Code ausliefert?
- Eine benannte Person oder ein Team – nie der Agent. Ein Agent kann keine Rufbereitschaft übernehmen, lässt sich in einer Nachbesprechung nicht befragen und kann gegenüber einer Kundin nicht geradestehen. Weisen Sie jedem Agenten ein verantwortliches Team zu, und lassen Sie jede ausgelieferte Änderung diese Zuständigkeit erben, bis eine prüfende Person sie übernimmt. Nach dem EU AI Act erfordert menschliche Aufsicht einen Menschen, der wirklich für das einsteht, was das System getan hat.
- Welche Steuerung ist mindestens nötig, bevor Coding-Agenten unbeaufsichtigt laufen?
- Ein Agentenverzeichnis, eingeschränkte kurzlebige Zugangsdaten, Branch-Schutz, sodass Menschen mergen, schriftliche Aktionsstufen frei/freigabepflichtig/verboten, ein Prüfprotokoll jeder Agenten-Aktion und ein getesteter Not-Aus. Diese Kontrollen passen auf eine Seite; die Arbeit ist Klarheit, nicht Bürokratie.
