Agentic Software Engineering: Wo autonome Agents sinnvoll sind – und wo nicht

„Agentisch“ ist derzeit das Etikett für alles zwischen Autovervollständigung und der Vorstellung, ein System entwickle sich selbst. Dazwischen liegt ein Feld, in dem sich real arbeiten lässt – wenn man weiß, welche Aufgaben Autonomie vertragen und wo sie zuverlässig teuer wird.

1. Was „agentisch“ heißt

Agentisch ist ein System, das eine Aufgabe in Schritte zerlegt, Werkzeuge einsetzt, Ergebnisse bewertet und daraufhin weiterarbeitet – über mehrere Runden hinweg, ohne dass jeder Schritt einzeln angestoßen wird. Der Unterschied zur reinen Codegenerierung ist nicht die Modellqualität, sondern die Rückkopplung: Der Agent sieht, was seine Aktion bewirkt hat.

Daraus folgt unmittelbar die wichtigste Bedingung: Autonomie funktioniert nur so weit, wie es eine verlässliche Rückmeldung gibt. Ohne Prüfinstanz läuft der Agent im Blindflug – nur schneller als ein Mensch.

2. Fünf Reifegrade

Die meisten Teams arbeiten produktiv auf Stufe 2 und 3. Stufe 4 lohnt sich für gut abgegrenzte Aufgabentypen. Stufe 5 ist heute vor allem dort sinnvoll, wo Ergebnisse billig zu prüfen und Fehler folgenlos sind.

3. Wann eine Aufgabe autonomiefähig ist

Vier Kriterien, die gemeinsam erfüllt sein sollten:

1. Prüfbar. Es gibt eine automatische Instanz, die Erfolg feststellt – Tests, Compiler, Schema, Contract.
2. Abgegrenzt. Der betroffene Bereich ist benennbar und begrenzt, nicht „die Anwendung“.
3. Umkehrbar. Ein falsches Ergebnis lässt sich verwerfen, ohne dass etwas kaputtgeht.
4. Beschreibbar. Das Ziel lässt sich in wenigen Sätzen so formulieren, dass zwei Menschen dasselbe verstehen.

Typische Kandidaten, die alle vier erfüllen:

• Migration entlang klarer Regeln über viele Dateien,
• Testabdeckung für vorhandene, stabile Module ergänzen,
• bekannte Fehlerklassen beheben, für die ein reproduzierbarer Testfall existiert,
• Abhängigkeitsaktualisierungen mit anschließendem Testlauf,
• Übersetzung zwischen Formaten, wenn ein Schema beide Seiten definiert.

4. Wo Autonomie scheitert

• Unklare Anforderungen. Der Agent löst dann eine plausible Nachbarversion des Problems – gründlich und über viele Dateien hinweg.
• Architekturentscheidungen. Es gibt keine automatische Instanz, die „ist das die richtige Struktur?“ beantwortet.
• Fachliche Grenzfälle. Was fachlich korrekt ist, steht nicht im Code – es steht in den Köpfen der Fachabteilung.
• Irreversibles. Migrationen produktiver Daten, Deployments, Rechteänderungen.
• Schwach getestete Altsysteme. Ohne Rückmeldung fehlt genau die Bedingung, auf der Autonomie beruht.

5. Die Schleife: Plan, Aktion, Prüfung

Ein produktiver Lauf folgt fast immer demselben Muster: planen, kleinsten sinnvollen Schritt ausführen, automatisch prüfen, Ergebnis bewerten, weitermachen oder abbrechen. Drei Details entscheiden über die Qualität:

• Der Plan ist sichtbar, bevor gehandelt wird – Missverständnisse sind dann noch billig.
• Die Prüfung ist unabhängig vom Änderungsvorschlag; ein selbstgeschriebener Test, der die eigene Implementierung bestätigt, prüft nichts.
• Zwischenstände sind sichtbar, nicht nur das Endergebnis. Sonst lässt sich nicht beurteilen, an welcher Stelle es schiefging.

6. Abbruchbedingungen

Ohne harte Grenzen läuft ein Agent, bis das Budget oder die Geduld endet. Sinnvolle Grenzen:

• Maximale Runden je Aufgabe.
• Keine Verbesserung über mehrere Runden – Abbruch statt Variantensuche.
• Änderungsumfang über einer Schwelle – dann übernimmt ein Mensch.
• Betroffene Bereiche außerhalb des freigegebenen Ausschnitts.
• Kosten- oder Zeitbudget je Lauf.

Ein abgebrochener Lauf ist kein Scheitern, sondern die günstigste Form der Fehlererkennung.

7. Die Kostenseite

Autonome Läufe verbrauchen Rechenzeit und erzeugen Ergebnisse, die geprüft werden müssen. Beides ist nicht kostenlos. Ehrlich rechnen heißt, drei Posten zu berücksichtigen: die Ausführung selbst, die Prüfzeit eines Menschen und die Wahrscheinlichkeit, dass ein Lauf verworfen wird.

Für gut geeignete Aufgaben ist die Rechnung deutlich positiv. Für schlecht geeignete ist sie schlechter als manuelle Arbeit – weil zusätzlich Prüfzeit für ein Ergebnis anfällt, das am Ende verworfen wird.

8. Was das für Teams heißt

Die Rollenverschiebung ist real, aber unspektakulärer als oft beschrieben: weniger Zeit mit Umsetzung, mehr Zeit mit Aufgabenzuschnitt, Prüfung und Architektur. Wer Aufgaben so formulieren kann, dass sie prüfbar sind, wird deutlich produktiver – das ist im Kern dieselbe Fähigkeit, die gute Anforderungsarbeit ausmacht.

Unverändert bleibt die Verantwortung: Wer einen Änderungssatz einreicht, verantwortet ihn – auch wenn ein Agent ihn erzeugt hat. Mehr dazu im Pillar KI in der Softwareentwicklung.

Checkliste: Autonomie dosieren

Fazit

Agentische Entwicklung ist weder Hype noch Selbstläufer. Sie ist ein Werkzeug mit einer klaren Einsatzbedingung: Es braucht eine Instanz, die Erfolg feststellen kann. Wo diese Bedingung erfüllt ist, sind mehrstufige Läufe erstaunlich produktiv. Wo sie fehlt, erzeugt Autonomie vor allem Prüfarbeit.

Die praktische Konsequenz ist unspektakulär: In gute Tests, klare Verträge und saubere Aufgabenzuschnitte investieren. Das erhöht den Anteil autonomiefähiger Aufgaben – und zahlt sich unabhängig davon aus, wie sich die Werkzeuge weiterentwickeln.