KI-Agents in der Softwareentwicklung: worauf es bei Grenzen und Aufträgen ankommt
KI-Agents können heute große Teile einer Entwicklungsaufgabe selbstständig erledigen. Sie lesen Code, ändern Dateien, führen Befehle aus und prüfen ihre eigenen Ergebnisse. Wie verlässlich das ist, hängt nicht nur vom Modell ab. Es hängt auch davon ab, wie der Agent aufgestellt ist: was er darf, wie sein Auftrag lautet und was als Ergebnis zählt.
Eine Regel im Prompt ist keine Grenze
„Ändere keine Dateien außerhalb dieses Ordners.“ „Greif nicht auf die Produktivdatenbank zu.“ „Lösche nichts.“ Solche Sätze stehen in vielen Anweisungen an Agents. Meistens hält sich das Modell daran. Aber eben nur meistens.
Eine Anweisung ist eine Bitte an ein Modell, das Wahrscheinlichkeiten folgt. Sie kann in einem langen Kontext untergehen, mit einer anderen Anweisung kollidieren oder von Text überlagert werden, der in einer gelesenen Datei steht und selbst wie eine Anweisung klingt.
Was auf keinen Fall passieren darf, kann im Prompt stehen. Es muss aber zusätzlich in der Umgebung durchgesetzt werden. Ein Agent, der nur analysieren soll, bekommt nur Lesezugriff. Lässt seine Umgebung keinen schreibenden Zugriff auf das Produktivsystem zu, kann er es nicht verändern, egal was in seinem Kontext steht. Freigegebene Werkzeuge, eine abgeschottete Umgebung und Prüfungen, die bestimmte Befehle vor der Ausführung blockieren, sind harte Grenzen. Der Prompt beschreibt, wie der Agent arbeiten soll. Was er nicht tun kann, regeln Rechte und Werkzeuge.
Ein Auftrag erzeugt Ergebnisse
Wer einem Agent sagt, er soll Probleme im Code finden, bekommt Probleme. Das ist gut, solange es welche gibt.
Ist der Code in Ordnung, findet der Agent unter Umständen trotzdem welche. Aus einer Stilfrage wird ein Risiko, aus einer Vermutung ein Befund. Manchmal wird ein Problem beschrieben, das so gar nicht existiert. Der Auftrag lautete ja: Finde Probleme.
Dagegen helfen ausdrücklich erlaubte Ausgänge. Ein Agent für Code-Reviews darf mit „keine Befunde“ zurückkommen. Einer für die Fehlersuche darf „kein Defekt“ oder „nicht eindeutig klärbar“ melden, und er ändert keinen Code, nur weil ein Fehler gemeldet wurde. Dazu kommt eine Belegpflicht: Was als Problem gemeldet wird, muss konkret belegt sein, mit der Stelle im Code und einer nachvollziehbaren Begründung. Was unsicher ist, wird als unsicher gekennzeichnet.
Ohne solche Ausgänge drängt schon der Auftrag dazu, irgendetwas zu liefern.
Eine Rolle pro Agent
Ein Agent, der alles darf, ist schwer zu kontrollieren. Klarer wird es mit getrennten Rollen: einer analysiert, einer plant, einer setzt um, einer prüft. Jede Rolle bekommt nur die Rechte, die sie braucht.
Besonders wichtig ist das beim Prüfen. Ein Agent, der Tests schreibt und anschließend bewertet, ob die Tests gut sind, prüft sich selbst. Das ist in der Softwareentwicklung mit Menschen nicht anders: Ein Review ist mehr wert, wenn es nicht vom Autor stammt.
Übergaben sind die Bruchstellen
Mit Agents wird es leicht, ganze Arbeitsabläufe zu verketten. Ein Agent findet eine Auffälligkeit, der nächste behebt sie, ein dritter prüft den Fix. Jeder Schritt ist sauber erledigt. Nur hat niemand gefragt, ob die Stelle überhaupt behoben werden sollte. Vielleicht ist sie bewusst so gebaut. Vielleicht spielt sie keine Rolle. Vielleicht kostet der Fix mehr als das Problem.
In einem Projekt entscheidet das normalerweise jemand, der den Kontext kennt, oft in wenigen Sekunden. In einer automatischen Kette kann dieser Moment wegfallen. Aus dem Befund wird direkt eine Aufgabe.
Dabei geht an einer Übergabe nicht unbedingt Information verloren. Aber ihre Gewichtung kann sich verschieben. Was ein Hinweis war, wird beim nächsten Agent zur Vorgabe. Was als Möglichkeit gemeint war, wird behandelt wie ein Beschluss.
Das gilt auch für Texte, die ein Agent liest. Ein Bericht, eine README oder ein früheres Ergebnis ist Kontext, kein Auftrag. Steht darin eine Empfehlung, ist sie noch keine Entscheidung.
Für klar abgegrenzte, wiederholbare Abläufe kann eine Kette sinnvoll sein. Bei Entwicklungsarbeit, die viel Kontext braucht, ist es verlässlicher, wenn ein Mensch an den Übergaben entscheidet, ob und wie es weitergeht.
Was ein Agent nicht sehen kann
Ein Agent sieht den Code und das, was in seinem Kontext steht. Er sieht nicht, warum eine Stelle vor Jahren so gebaut wurde, welcher Kunde auf einen Sonderfall angewiesen ist oder welche Absprache zwischen zwei Abteilungen nirgends dokumentiert ist.
Von außen sieht manches deshalb falsch aus, was einen guten Grund hat. Die Befunde eines Agents sind darum ein Ausgangspunkt. Bewerten muss sie jemand, der den Zusammenhang kennt, und die Verantwortung für das Ergebnis bleibt bei ihm.
Wie ich Rollen und Übergaben konkret strukturiere, zeigt mein öffentliches Toolkit für Claude Code.