Oct 06 2026

Wann sich agentische Softwareentwicklung lohnt

Philipp Deutscher

Laptop und Teamgespräch in einem dunklen Büro als Motiv für die Einführung agentischer Entwicklungsabläufe.

Müssen wir Softwareentwicklung heute von Anfang an als agentischen Prozess aufsetzen? Die Frage ist verständlich. Wer mit wenigen Anweisungen eine Anwendung bauen kann, fragt sich irgendwann, weshalb Planung, Implementierung und Prüfung nicht ebenfalls weitgehend automatisiert ablaufen sollten.

In Gesprächen mit Kunden begegnen mir dazu unterschiedliche Ausgangslagen. Manche prüfen gerade einen Builder wie Lovable. Andere haben ein Entwicklungsteam und einen gewachsenen Codebestand. Für beide ist die Versuchung groß, direkt über das zukünftige Gesamtmodell zu sprechen. Dabei ist oft noch nicht geklärt, welcher Teil der heutigen Arbeit tatsächlich zum Engpass wird.

Ich würde mit einer überprüfbaren Entscheidung beginnen: Welche konkrete Aufgabe soll ein Agent übernehmen, woran erkennen wir ein akzeptables Ergebnis und wer entscheidet über dessen Verwendung? Daraus kann ein zunehmend agentischer Entwicklungsprozess entstehen. Ein vollständiges System zur Koordination mehrerer Agenten muss dafür nicht am ersten Tag stehen.

Agentischer SDLC braucht einen klaren Umfang

Der Software Development Life Cycle umfasst den Weg von der Anforderung über Entwicklung und Prüfung bis zu Veröffentlichung und Betrieb. „Agentisch“ beschreibt zunächst, dass Agenten innerhalb dieses Ablaufs Aufgaben ausführen. Der Begriff sagt wenig darüber, wie viel Autonomie sie haben und wo menschliche Entscheidungen liegen.

Ein Agent kann einen Fehler analysieren und einen Änderungsvorschlag liefern. Er kann eine begrenzte Implementierung einschließlich Tests übernehmen. Oder ein koordinierter Ablauf zerlegt ein größeres Vorhaben und führt Ergebnisse mehrerer Agenten zusammen. Das sind unterschiedliche Entscheidungen über Verantwortung und Kontrolle.

Bevor ein Unternehmen einen agentischen SDLC einführt, sollte es deshalb festlegen, welche Arbeit tatsächlich gemeint ist. Sonst diskutiert ein Teil des Teams über schnellere Implementierung, während ein anderer bereits automatische Produktentscheidungen und Veröffentlichungen erwartet.

Der Engpass bestimmt den nächsten Schritt

Wenn ein Team viel Zeit mit wiederkehrenden, gut verstandenen Änderungen verbringt, ist delegierte Ausführung ein plausibler Ansatz. Wenn Änderungen dagegen tagelang auf fachliche Entscheidungen warten, wird zusätzliche Implementierungskapazität wenig helfen. Sie kann sogar die Warteschlange vor der Abnahme vergrößern.

Dasselbe gilt für schlecht reproduzierbare Entwicklungsumgebungen. Solange ein Agent nicht zuverlässig bauen und testen kann, verbringt das Team seine Zeit mit Einrichtung und Fehlersuche. In dieser Situation kann eine standardisierte Umgebung mehr bewirken als die Einführung weiterer Agentenrollen.

Für die erste Entscheidung reichen wenige Beobachtungen: Wo wartet Arbeit? Welche Schritte wiederholen sich? Bei welchen Entscheidungen muss regelmäßig jemand eingreifen? Wie viel Zeit entfällt nach dem ersten Ergebnis auf Korrekturen? Daraus ergibt sich ein besserer Auftrag als „Wir wollen mehr Autonomie“.

Ein einzelner Agent ist ein sinnvoller Ausgangspunkt

Für einen abgegrenzten Fehler oder ein kleines Feature würde ich zunächst einen vorhandenen Coding-Agenten im normalen Entwicklungsprozess einsetzen. Der Auftrag enthält das gewünschte Verhalten, relevante Einschränkungen und die erwarteten Nachweise. Die Änderung geht durch das übliche Review.

Claude Code, Codex, Cursor und GitHub Copilot dokumentieren verschiedene agentische Arbeitsabläufe. Welche Oberfläche und Ausführungsumgebung passt, muss am eigenen Repository geprüft werden. Aus dem Funktionsumfang allein lässt sich kein allgemeiner Gewinner ableiten. [1–4]

Der Versuch beantwortet zunächst eine begrenzte Frage: Kann dieses Team diese Aufgabenklasse mit dem Werkzeug verlässlich besser bearbeiten? Erst wenn das wiederholt gelingt, lohnt sich die Überlegung, welche Betreuung automatisiert werden kann.

Das gilt auch für ein Produkt, das in einem Builder begonnen wurde. Der Wechsel der Arbeitsoberfläche und die Einführung eines agentischen Gesamtprozesses müssen nicht gleichzeitig stattfinden. Eine einzelne extern umgesetzte Änderung kann der richtige nächste Schritt sein.

Wann koordinierte Agentenarbeit interessant wird

Zusätzliche Koordination lohnt sich besonders dann, wenn ein Vorhaben in unabhängige oder klar geordnete Teilaufgaben zerlegt werden kann. Die Ergebnisse müssen zusammengeführt werden können, ohne dass das Team anschließend jede Entscheidung neu rekonstruieren muss.

Ein Beispiel ist eine wiederkehrende technische Anpassung in mehreren getrennten Services. Ein gemeinsames Ziel, bekannte Schnittstellen und ausführbare Prüfungen schaffen günstige Bedingungen. Verändern dagegen mehrere Aufgaben gleichzeitig dasselbe Datenmodell, muss zuerst die gemeinsame Entscheidung fallen. Parallele Implementierung löst diesen Konflikt nicht.

Factory beschreibt für Missions die Planung, parallele Bearbeitung und Koordination größerer Vorhaben. Devin gehört ebenfalls zu den Angeboten für delegierte Entwicklungsarbeit. Ob solche Werkzeuge den Aufwand im eigenen Team senken, muss ein Versuch einschließlich menschlicher Betreuung zeigen. [5, 6]

Dabei würde ich vorhandene Funktionen zuerst prüfen. Ein eigener Orchestrator sollte eine benannte Lücke schließen. Allein der Wunsch nach einer zusätzlichen Planer-, Entwickler- und Reviewer-Rolle rechtfertigt noch keine neue Infrastruktur.

Was ein eigener Orchestrator zusätzlich verlangt

Wer einen eigenen Ablauf baut, muss dessen Zustand zuverlässig verwalten. Welche Aufgabe läuft noch? Welche ist gescheitert? Darf ein Schritt wiederholt werden? Wurde ein Ergebnis inzwischen durch eine andere Änderung ungültig? Diese Fragen werden relevant, sobald Arbeit länger läuft oder externe Systeme verändert.

Dazu kommen Berechtigungen und Kosten. Ein Analyseauftrag benötigt andere Zugriffe als eine Veröffentlichung. Wiederholte Versuche dürfen nicht unbegrenzt laufen. Ein Abbruch muss erkennbar sein und einen nachvollziehbaren Zustand hinterlassen.

Eigene Orchestrierung kann sinnvoll sein, wenn besondere Freigaben, interne Systeme oder Anforderungen an die Ausführung anders nicht ausreichend abgedeckt werden. Sie braucht dann einen zuständigen Betreiber und ein Budget für ihre Pflege. Das Unternehmen entwickelt damit zusätzlich zu seinen Produkten einen eigenen Teil der Entwicklungsplattform.

Coder zeigt zugleich, dass Infrastruktur und Agentensteuerung zunehmend gemeinsam angeboten werden: Die Dokumentation umfasst kontrollierte Umgebungen sowie Agentenfunktionen und eine API. Solche Überschneidungen gehören in die Entscheidung zwischen Kaufen, Konfigurieren und Eigenbau. [7]

Mehr Prüfung erfordert mehr als einen zweiten Agenten

Ein zweiter Agent kann eine Änderung aus einer anderen Perspektive prüfen. Er kann aber dieselbe falsche Annahme übernehmen wie der erste. Zwei zustimmende Ausgaben sind deshalb noch kein ausreichender Nachweis.

Aussagekräftiger sind Prüfungen, die an unabhängig festgelegtem Verhalten ansetzen. Ein fachlicher Referenzfall, ein gezielter Berechtigungstest oder eine nachvollziehbare Integrationsprüfung kann eine gemeinsame Fehlannahme sichtbar machen. Die Prüfkriterien sollten feststehen, bevor die Implementierung sie beeinflusst.

Welche menschliche Abnahme erforderlich bleibt, hängt von den Folgen eines Fehlers ab. Eine kleine Änderung an einer internen Darstellung und eine Anpassung an Zahlungslogik verlangen unterschiedliche Tiefe. Diese Entscheidung gehört zum Auftrag des verantwortlichen Teams und lässt sich nicht aus dem Namen des eingesetzten Werkzeugs ableiten.

Einen Pilot so gestalten dass er eine Entscheidung ermöglicht

Ich würde eine Aufgabenklasse auswählen, für die im Team bereits Erfahrung besteht. Ein einzelner spektakulärer Sonderfall ist dafür weniger hilfreich als Arbeit, die regelmäßig vorkommt. Vor dem Start werden Anforderungen, Abnahme und ein begrenztes Zeit- und Kostenbudget festgelegt.

Dann werden mehrere vergleichbare Aufgaben durchgeführt. Gemessen wird vom bereitgestellten Auftrag bis zur akzeptierten Änderung, einschließlich Einrichtung, Rückfragen und Nacharbeit. Die aktive menschliche Zeit wird getrennt von der gesamten Durchlaufzeit erfasst. Auch fehlgeschlagene Läufe bleiben in der Auswertung.

Für zusätzliche Orchestrierung ist die entscheidende Vergleichsgröße ein bereits funktionierender einfacher Ablauf. Spart die Koordination tatsächlich Betreuung? Entstehen weniger Unterbrechungen? Oder wandert Arbeit nur von der Implementierung in die Pflege des Agentensystems?

Vorab festgelegte Abbruchkriterien helfen: Wenn die fachliche Prüfbarkeit fehlt, muss zunächst daran gearbeitet werden. Wenn ein größerer Aufgabenrahmen regelmäßig unverständliche Ergebnisse produziert, wird er verkleinert. Wenn Parallelität vor allem Konflikte erzeugt, wird die Aufteilung geändert. Ein Pilot darf auch zu dem Ergebnis führen, vorerst beim einfacheren Ablauf zu bleiben.

Die nächste Delegation braucht eine Begründung

Für CTOs ist ein agentischer Entwicklungsprozess vor allem eine Folge konkreter Entscheidungen. Welche Arbeit lässt sich zuverlässig delegieren? Welche Voraussetzungen fehlen noch? Wo bringt zusätzliche Koordination einen messbaren Vorteil?

Ein Team kann mit einem Builder sinnvoll arbeiten und einzelne Agenten ergänzen. Ein anderes kann Aufgaben im vorhandenen Repository delegieren. Eine Organisation mit vielen wiederkehrenden Änderungen kann von einer umfassenderen Koordination profitieren. Keine dieser Ausgangslagen verlangt automatisch denselben Weg.

Meine Empfehlung ist, den Umfang der Autonomie schrittweise an nachgewiesene Fähigkeiten zu binden. So wird aus einem guten Versuch ein verlässlicher Ablauf, ohne dass das Team den Aufwand für dessen Betrieb aus dem Blick verliert.

Für die Einordnung der Werkzeugfamilien ergänzt der Landscape-Artikel diesen Beitrag. Für die Arbeit am eigenen Ablauf findest du weitere Informationen zur Agentic Engineering Transformation.

Quellen und Rechercheumfang

Herstellerdokumentation und offizielle Produktinformationen, geprüft am 1. Oktober 2026. Die Empfehlungen zum Vorgehen sind fachliche Einordnung, kein eigener Produktbenchmark. Verfügbarkeit und Tarifbedingungen im konkreten Zugang prüfen.