Agentische KI im Software‑Entwicklungslebenszyklus

Ein Sprachmodell, das eine Codezeile vorschlägt, ist ein Werkzeug.
Ein System, das ein GitHub‑Issue liest, das Repository klont, Dateien bearbeitet, Tests ausführt und einen Pull Request öffnet, ist ein Agent.
Der Unterschied besteht nicht allein in der bloßen Fähigkeit, sondern im Ausmaß der Autonomie, mit der das System einen gesamten Workflow steuert, den Menschen bislang von Anfang bis Ende manuell erledigten. Diese Autonomie lässt die Geschwindigkeit menschlicher Arbeit übertreffen, birgt aber gleichzeitig das Risiko, Entscheidungen ohne unmittelbare Kontrolle zu treffen.

Im Jahr 2026 werden Multi‑Agenten‑Systeme in jeder Phase des Software‑Entwicklungslebenszyklus (SDLC) eingesetzt: Planung, Implementierung, Testing, Review und Deployment. Die zentrale Frage verschiebt sich von der reinen Machbarkeit hin zu der Frage, in welchen Abschnitten menschliche Kontrolle unabdingbar bleibt und welche Methoden garantieren, dass das Resultat eines Agenten wirklich korrekt ist.

Was sich in jeder Phase ändert

Planung und Anforderungen

Agenten analysieren Issue-Trackers, fassen verwandte Tickets zusammen, identifizieren mehrdeutige Anforderungen und schlagen Akzeptanzkriterien vor. Das Risiko besteht darin, dass ein plausibel klingender Plan erst bei der Implementierung als falsch entpuppt wird, weil er verborgene Abhängigkeiten wie Altlasten-Integrationen oder Performance-Grenzwerte übersieht, die erst beim Codieren sichtbar werden.
Es deckt bereits bei einem kurzen Review des Entwurfs fehlende Randbedingungen auf, bevor teure Änderungen vorgenommen werden.

Implementierung

Systeme wie OpenHands und Aider können eine Aufgabenbeschreibung empfangen, das Repository inspizieren, Änderungen über mehrere Dateien hinweg vorschlagen und die Testsuite ausführen.
SWE‑bench, ein Benchmark mit echten GitHub‑Issues, zeigt, dass die besten Agentensysteme Anfang 2025 etwa 50 % der Issues korrekt lösen, ein bedeutender Fortschritt, aber nicht zuverlässig genug, um ohne Review zu mergen; die übrigen 50 % scheitern häufig an Randfällen oder domänenspezifischer Logik, die in den Testfällen nicht abgebildet ist.

Agent erhält: GitHub Issue #412 - "JWT‑Ablaufprüfung verwendet falschen Feldnamen"
Agent‑Aktionen:
  1. Repository klonen, fehlgeschlagenen Test lesen
  2. Codebase nach JWT‑Verifikationslogik durchsuchen
  3. Identifiziert: token.exp statt token.expires_at verwendet
  4. src/auth/verify.ts bearbeiten
  5. Ausführen: npm test -- --testPathPattern=auth
  6. Alle Tests bestehen → Draft‑PR mit Diff und Testausgabe öffnen
Menschliche Aktion: Diff prüfen, Randfälle kontrollieren, genehmigen oder Änderungen anfordern

Der Agent übernimmt die mechanische Suche‑und‑Fix‑Aufgabe.

Testing

Agenten können Unit‑Tests aus Funktionssignaturen generieren, eigenschaftsbasierte Testfälle erstellen und nicht getestete Zweige identifizieren.
Der entscheidende Vorbehalt lautet: Ein Test, der dieselben Annahmen wie die implementierte Logik zugrunde legt, deckt die zugrunde liegenden Fehler nicht auf. Deshalb muss man prüfen, welche Eigenschaften der Test tatsächlich überprüft, anstatt nur zu schauen, ob er grün wird.

Code‑Review

KI-geführtes Code-Review markiert gängige Muster: fehlende Null-Prüfungen, unsichere Abhängigkeiten, inkonsistente Fehlerbehandlung und Stilabweichungen.
Tools wie CodeRabbit und GitHub Copilot integrieren sich in Pull-Request-Workflows.
Sie sind nützlich für mechanische Probleme, können aber keinen Reviewer ersetzen, der die Invarianten des Systems, den Geschäftskontext oder das Sicherheitsmodell versteht. Erfahrene Reviewer analysieren Datenflüsse und decken Risiken auf, die statische Analysen übersehen.

Deployment und Betrieb

Agenten können CI‑Pipelines überwachen, Fehler zusammenfassen, Rollback‑Entscheidungen vorschlagen und Incident‑Berichte entwerfen.
Vollständig autonome Produktionsänderungen sind hochriskant: Ein falsch diagnostizierter Fehler kann dazu führen, dass ein Agent ein korrektes Deployment zurückrollt oder einen Patch einspielt, der einen neuen Fehler einführt. Da Produktionssysteme reale Nutzer betreffen, kann ein solcher Fehltritt sofortige Serviceunterbrechungen oder Datenverlust nach sich ziehen.

Wo menschliche Aufsicht endet: und wo sie es nicht kann

Die ehrliche Antwort ist, dass menschliche Aufsicht in keiner Phase enden kann, in der die Fehlerkosten hoch sind und die Fehlerrate des Agenten nicht trivial ist. Das betrifft den größten Teil des SDLC im Jahr 2026.

Ein nützlicher Ansatz ist der Reversibilitätstest:

• Reversibel und geringer Wirkungsradius: Entwurf generieren, Tests lokal ausführen, Draft‑PR öffnen. Da ein falscher Schritt jederzeit durch einen einzelnen Commit rückgängig gemacht werden kann, bleibt das Risiko begrenzt, und Agenten können hier autonom handeln.
• Reversibel, aber hoher Wirkungsradius: Merge in main, Deployment in Staging. Hier prüfen Menschen, ob die Änderungen in das Gesamtsystem passen und keine unvorhergesehenen Seiteneffekte erzeugen.
• Irreversibel oder extern sichtbar: Deployment in Produktion, Benachrichtigungen senden, Kundendaten ändern. Einmal ausgeliefert, lässt sich ein Fehlverhalten nicht mehr einfach zurücknehmen, weshalb ein lückenloses Protokoll (Audit‑Trail) unumgänglich ist und menschliche Genehmigung zwingend erforderlich bleibt.

Aufgaben‑ vs. Zeilenebene‑Korrektheit

Dies ist das schwierigste Verifikationsproblem bei agentischer SDLC‑Arbeit. Ein Agent kann Code produzieren, der

• alle vorhandenen Tests besteht (Zeilenebene korrekt), aber
• das falsche Problem löst (Aufgabenebene inkorrekt).

Eine Testsuite, die das beabsichtigte Verhalten nicht abdeckt, kann das nicht erkennen. Der Agent liefert ein grünes Ergebnis, doch der zugrunde liegende Bug bleibt im Produkt.

Die Konsequenz: Aufgabenebene‑Verifikation erfordert menschenlesbare Akzeptanzkriterien, die vor dem Agentenlauf definiert werden, nicht danach. Wenn das Issue beispielsweise fordert, die JWT‑Ablaufprüfung zu korrigieren, muss der Reviewer bereits vorab wissen, welches Feld die gültige Ablaufzeit definiert, wie Toleranzen bei Uhrabweichungen gehandhabt werden und welches Antwortverhalten für bereits abgelaufene Tokens erwartet wird.

Multi‑Agenten‑Pipelines

Komplexe SDLC‑Workflows verwenden oft einen Orchestrator, der an Spezialagenten delegiert:

Orchestrator
  ├── Planer‑Agent     - zerlegt Issue in Teilaufgaben
  ├── Coder‑Agent      - implementiert jede Teilaufgabe
  ├── Test‑Agent       - generiert und führt Tests aus
  ├── Review‑Agent     - prüft Sicherheit, Stil, Abdeckung
  └── PR‑Agent         - stellt Diff zusammen, schreibt Beschreibung, öffnet PR

Jede Grenze fügt Latenz, einen potenziellen Fehlermodus und einen Ort hinzu, an dem Kontext verloren gehen kann. Ein Missverständnis zwischen Planer‑ und Coder‑Agent kann dazu führen, dass ein korrekt implementiertes, aber falsches Feature entsteht. End‑to‑End‑Evaluation, löst der finale PR das ursprüngliche Issue?, ist wichtiger als Metriken pro Agent.

Praktisches Adoptionsmuster

Teams, die agentische SDLC‑Tools erfolgreich einsetzen, folgen einem konsistenten Muster:

1. Mit risikoarmen, hochvolumigen Aufgaben beginnen: Abhängigkeitsupdates, Testgenerierung, Dokumentationsentwürfe. Diese Tätigkeiten bringen sofortige Produktivitätsgewinne, während ein möglicher Schaden begrenzt bleibt.
2. Fehlerraten bei diesen Aufgaben messen, bevor der Umfang erweitert wird: Erst wenn die gemessene Fehlerrate akzeptabel ist, skalieren wir auf komplexere Issues.
3. Genehmigungsstufen vor jeder Aktion hinzufügen, die gemeinsame Infrastruktur berührt.
4. Agentenausgabe als ersten Entwurf behandeln, nicht als fertiges Produkt.
5. In Akzeptanzkriterien und Testabdeckung investieren, bevor Agenten eingesetzt werden, da sie die bereits vorhandene Review‑Disziplin stärken. Ein robustes Pflichtenheft wird zum Sicherheitsnetz, das agentische Fehler sofort sichtbar macht.

Was zu beachten

Weitere Bewertungsbenchmarks entstehen neben SWE‑bench, etwa SWE‑bench Verified (eine von Menschen validierte Teilmenge), Multi‑File‑Reasoning‑Benchmarks und sicherheitsorientierte Benchmarks, die prüfen, ob Agenten Schwachstellen einführen.

Standardisierte Audit‑Trail‑Formate und Schnittstellen‑Protokolle für Werkzeuge (unter anderem MCP, das regelt, wie Agenten Werkzeuge entdecken und ansteuern) werden aktiv weiterentwickelt.

Haftungsrahmen für von Agenten erzeugten Code sind in den meisten Rechtsordnungen noch nicht geklärt; Teams sollten daher rechtliche Leitlinien aufmerksam verfolgen.

Warum die 50‑%‑SWE‑bench‑Zahl sowohl beeindruckend als auch unzureichend ist

Die etwa 50 % Lösungsrate auf SWE‑bench verdient Kontext. SWE‑bench‑Issues sind echte GitHub‑Issues aus Open‑Source‑Repositories, wurden aber so ausgewählt, dass sie lösbar sind, sie haben klare Reproduktionsschritte, vorhandene Tests und begrenzten Umfang.

Reale Issues sind oft weniger gut spezifiziert, umfassen mehr Dateien und erfordern das Verständnis undokumentierten Systemverhaltens.

Noch wichtiger: „Löst das Issue“ auf SWE‑bench bedeutet, dass der Patch des Agenten die mit diesem Issue verbundene Testsuite besteht. Das bedeutet nicht, dass der Patch in allen Randfällen korrekt ist, keine Regressionen in nicht getesteten Pfaden einführt oder der Absicht des Maintainers entspricht.

Der Benchmark misst einen Proxy für Korrektheit, nicht Korrektheit selbst. Das ist keine Kritik am Benchmark, er ist ein nützlicher und strenger Proxy. Es ist eine Erinnerung daran, dass Benchmark‑Performance und Produktionszuverlässigkeit verschiedene Dinge sind, und dass die Lücke zwischen ihnen genau dort ist, wo menschliches Review Wert schöpft.