Forschungslandkarte für den agentischen Softwareentwicklungszyklus

Einordnung

Diese Landkarte betrachtet Agentic Engineering nicht als schnellere Quellcodeerstellung, sondern als mögliche Veränderung eines sozio-technischen Wertstroms: von der Wahrnehmung eines Problems oder einer Chance über Produktentscheidungen, Entwicklung und Freigabe bis zu Betrieb, Wirkungsmessung und Lernen.

Die ausgewertete Literatur ist heterogen. Sie umfasst Praxisberichte, Beratungsmodelle, wissenschaftliche Reviews und empirische Studien. Praxisberichte zeigen Möglichkeiten, belegen aber nicht deren allgemeine Übertragbarkeit. Die folgenden Felder sind deshalb ein Untersuchungsprogramm und noch keine Aussage darüber, wie weit sich der Lebenszyklus tatsächlich automatisieren lässt.

Forschungsfelder

1. Probleme und Chancen erkennen

Agenten könnten Kundenfeedback, Supportfälle, Nutzungsdaten, Marktinformationen und Betriebsereignisse kontinuierlich bündeln, Widersprüche markieren und neue Hypothesen vorschlagen. Zu untersuchen ist, ob sie dabei echte Bedürfnisse und Chancen besser sichtbar machen oder nur häufige, leicht messbare Signale verstärken. Produktverantwortung, Empathie und die Bewertung strategischer Relevanz bleiben zunächst offene Grenzen.

2. Produktstrategie und Discovery

Zwischen einem beobachteten Signal und einer Investitionsentscheidung liegen Problemverständnis, strategische Auswahl, Lösungsoptionen und Experimente. Nick Tunes Unterscheidung von Problem-, Strategie-, Discovery- und Implementierungsraum hilft zu verhindern, dass eine beschleunigte Implementierung mit besserer Produktgestaltung verwechselt wird. Uwe Friedrichsen warnt entsprechend davor, mit Agenten lediglich mehr wertarme Features zu erzeugen. Siehe Nick Tune über Produktentwicklungsräume und Uwe Friedrichsens Gegenposition.

3. Requirements Engineering und Spezifikation

Mögliche Aufgaben sind Elicitation, Konsistenz- und Ambiguitätsprüfung, Traceability, Ableitung von Akzeptanzkriterien und die Verbindung von Anforderungen mit Tests und Betriebsbeobachtungen. Ein systematischer Review findet viele kontrollierte Versuche, aber bislang wenig industrielle Integration in komplexe Workflows. Siehe Review zu LLMs im Requirements Engineering.

4. Architektur, Kontext und Harnessability

Harness Engineering externalisiert Regeln, Wissen und Feedback, die Menschen bisher implizit in die Entwicklung eingebracht haben. Birgitta Böckeler unterscheidet Guides und Sensors sowie deterministische und inferentielle Kontrollen. Maintainability und Architektur lassen sich häufiger mechanisch prüfen als fachlich korrektes Verhalten. Der OpenAI-Fall zeigt, wie Repository-Wissen, Observability, strukturelle Tests und wiederkehrende Aufräumarbeit Agenten länger autonom arbeiten lassen können. Empirische Ergebnisse zu AGENTS.md challengen zugleich die Annahme, mehr Kontext sei automatisch besser: knappe, kuratierte Regeln können hilfreicher sein als umfassende, automatisch erzeugte Übersichten. Siehe Böckelers Modell, den OpenAI-Praxisbericht und die Evaluation von Repository-Kontextdateien.

5. Implementierung und Orchestrierung

Arbeit verschiebt sich von direkter Ausführung zu Zielklärung, Zerlegung, Delegation und Auswertung. Mehrere Agenten können Implementierung, Review, Dokumentation oder Analyse parallel bearbeiten. Nick Tune argumentiert, mechanische Orchestrierung als testbaren Code auszudrücken und LLMs nur für inferentielle Schritte einzusetzen. Ein detaillierter Projektbericht zeigt als Gegenprobe, dass breite Delegation ohne erhaltenes mentales Modell trotz vieler Tests in eine vollständige Neuentwicklung münden kann. Siehe Dev Workflows as Code und den Syntaqlite-Praxisbericht.

6. Verifikation, Freigabe, Deployment und Betrieb

Der Lebenszyklus kann Rückkopplungen aus Tests, Security-Scans, Telemetrie, Nutzerverhalten und Incidents direkt für Korrekturen nutzen. Offen bleiben belastbare Behaviour Harnesses, unabhängige Orakel für fachliche Richtigkeit, Freigaberechte, Rollback-Fähigkeit und Verantwortung im Störungsfall. Kief Morris beschreibt die Verschiebung vom Menschen in der Ausführungsschleife zum Menschen auf der Schleife. Siehe Humans and Agents in Software Engineering Loops.

7. Teams und Produktorganisation

Zu untersuchen sind Rollen, Entscheidungsrechte, Teamzuschnitt und Zusammenarbeit zwischen Product, Design, Engineering, Security, Operations und Fachdomäne. Ein Thoughtworks-Modell erwartet hybride Teams, agentische Self-Service-Schnittstellen und stärkere Plattformfähigkeiten, weist aber selbst auf Risiken wie kulturelle Fragmentierung und überlastete menschliche Entscheider hin. Die These der verschobenen Komplexität ergänzt Ambiguitätstoleranz, Verhandlung, Stakeholderkommunikation und bewusst gestaltete Lernpfade als mögliche Engpassfähigkeiten. Siehe Thoughtworks zum agentischen SDLC und INNOQ zur verschobenen Komplexität.

8. Engstellen, Flow und Ökonomie

Lokale Beschleunigung erhöht nicht automatisch den Durchsatz des Gesamtsystems. Engpässe können sich von Implementierung zu Problemklärung, Review, QA, Produktentscheidungen, Deployment, Marketing oder Support verschieben. Development Value Stream Mapping bietet dafür Messgrößen wie Lead Time, Process Time und Percent Complete and Accurate. Das AI-SDLC-Modell von Ona formuliert die Engpassverschiebung explizit, ist aber ein Beratungsmodell und keine unabhängige Wirksamkeitsstudie. Siehe Development Value Stream Mapping, Ona zum AI-SDLC und INNOQ zur neuen Ökonomie.

9. Governance, Sicherheit und Verantwortlichkeit

Mehr Autonomie benötigt mehr Zugriff und vergrößert den möglichen Schadensradius. Relevante Felder sind Identitäten für Agenten, Least Privilege, isolierte Ausführungsumgebungen, Netzwerkgrenzen, Secret Handling, Audit Trails, Prompt Injection, Lieferkettensicherheit und nachvollziehbare Freigaben. Anthropic argumentiert, dass häufige Einzelgenehmigungen zu Approval Fatigue führen und harte Begrenzungen der Umgebung wichtiger werden. Siehe Anthropic zur Begrenzung agentischer Systeme.

10. Wirkung, Evidenz und Lernen

Gemessen werden sollten nicht Codezeilen oder erzeugte Pull Requests, sondern Produktwirkung, Durchlaufzeit, Stabilität, Qualität, Risiko, Kosten und Lernfähigkeit. DORA beschreibt AI als Verstärker vorhandener organisationaler Stärken und Schwächen. METR zeigt zugleich, wie schnell Produktivitätsbefunde durch neue Werkzeuge, Aufgabenauswahl und parallele Agentennutzung methodisch veralten können. Eine ACM-Synthese unterstreicht, dass Code einen kleinen Anteil der Gesamtarbeit ausmacht und Wirkung stark von Aufgabe, Erfahrung und Organisationssystem abhängt. Siehe DORA 2025, das METR-Methodenupdate und Eight Myths on Software Engineering and GenAI.

Vorläufige Verbindung der Felder

Eine erste, noch zu prüfende Arbeitshypothese lautet: Agentic Engineering verändert den SDLC am stärksten, wenn Produktentwicklung als System geschlossener Feedbackschleifen gestaltet wird. Dafür müssen Ziele, Wissen, Zustände und Qualitätsmaßstäbe für Agenten lesbar sowie Grenzen technisch durchsetzbar sein. Je schneller ausführende Arbeit wird, desto wahrscheinlicher werden menschliche Aufmerksamkeit, Urteilskraft, organisationsübergreifende Entscheidungen und die Qualität der Feedbacksignale zu Engpässen.

Diese Arbeitshypothese wird in der Forschungsagenda bewusst in offene Fragen zerlegt. Der wissenschaftliche Research Roadmap zu Agentic Software Engineering liefert dafür ergänzende Begriffe für Agentenarbeitsplätze, Übergaben und menschliche Rückfragen.