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. Ein Feldexperiment bei P&G zeigt zwar, dass GenAI die Qualität früher Produktinnovationsvorschläge und die Verbindung technischer mit kommerziellen Perspektiven verbessern kann; es untersucht aber weder autonome Agenten noch Forschung mit realen Kunden. Produktverantwortung, Empathie und die Bewertung strategischer Relevanz bleiben deshalb offene Grenzen. Siehe The Cybernetic Teammate.
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. MAUX zeigt, wie Strategy, Scope, Structure, Skeleton und Surface als koordinierter Multi-Agent-Workflow verbunden werden können. Die Evaluation belegt kohärentere UX-Artefakte, aber noch keine zutreffenden Nutzerbedürfnisse oder bessere Produkte im Feld. Siehe Nick Tune über Produktentwicklungsräume, Uwe Friedrichsens Gegenposition und MAUX für mehrstufiges UX Design.
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. Ein Google-Whitepaper ergänzt die Unterscheidung zwischen stets geladenem statischem Kontext und bei Bedarf geladenem dynamischem Kontext und behandelt deren Grenze als versionierte Architekturentscheidung. 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. Statischer und dynamischer Kontext sollten deshalb nicht nur technisch organisiert, sondern hinsichtlich Erfolgsrate, Verhalten und Kosten evaluiert werden. SlopCodeBench verschärft die Qualitätsfrage über längere Änderungsketten: bestandene Checkpoints verhinderten bei den untersuchten Agents keine zunehmende Redundanz und strukturelle Erosion. Siehe Böckelers Modell, den OpenAI-Praxisbericht, Googles Whitepaper zum neuen SDLC, die Evaluation von Repository-Kontextdateien und den Langzeit-Benchmark SlopCodeBench.
Sinkende Implementierungskosten könnten außerdem die Produktgrenze verändern. Ein Architekturmodell trennt einen geschützten Kern für Identität, Berechtigungen, fachlichen Zustand, Transaktionen und Audit von einer generierbaren Peripherie aus Reports, Oberflächen, Adaptern und Workflows. Daraus folgt noch nicht, dass Anwender solche Artefakte sicher selbst erzeugen und betreiben können. Die im Dialog entwickelte, bislang ungeprüfte These zu risikobasiertem Self-Service begrenzt die Möglichkeit deshalb nach Wirkungsradius, Reversibilität und Kritikalität. Siehe Eisele über einen kleineren Kern und eine generierbare Peripherie.
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. Das Google-Whitepaper unterscheidet dazu Conductor und Orchestrator: synchrone, feingranulare Führung eignet sich eher für unklare oder lernintensive Arbeit, asynchrone Delegation eher für klar abgegrenzte Aufgaben mit belastbaren Prüfungen. Diese Modi sind keine automatische Reifestufenfolge; die Aufgabe und ihr Risiko bestimmen die passende Steuerung. Nick Tune argumentiert ergänzend, 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. Eine große MSR-Studie zu agentischen Pull Requests verbindet Ablehnungen außerdem mit großen Änderungen, fehlgeschlagener CI, Dubletten, unerwünschten Features und unzureichender Reviewer-Interaktion. Siehe Googles Whitepaper zum neuen SDLC, Dev Workflows as Code, den Syntaqlite-Praxisbericht und die Analyse gescheiterter agentischer Pull Requests.
6. Verifikation, Freigabe, Deployment und Betrieb
Der Lebenszyklus kann Rückkopplungen aus Tests, Security-Scans, Telemetrie, Nutzerverhalten und Incidents direkt für Korrekturen nutzen. Eine 17-wöchige Produktionsstudie mit 232 Incidents zeigt ein konkretes Human-in-the-loop-Muster: Ein Agent unterstützt Triage, vergleicht tatsächliche Maßnahmen mit Runbooks und schlägt Dokumentationsänderungen vor, während Menschen entscheiden und freigeben. Das liefert erste Betriebsevidenz, aber keinen kausalen Nachweis und kein Modell für autonomen Betrieb. 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. Dirk Lässig deutet diese äußere Steuerung kybernetisch als Zusammenspiel von Attenuation, Amplification, Sensors, Guides und regelmäßigem Go See. Das liefert ein differenziertes Kontrollmodell, aber ebenfalls keinen empirischen Nachweis dafür, wann direkte menschliche Prüfung sicher reduziert werden kann. Die kritische Einordnung bewertet Kybernetik deshalb als nützliches Designvokabular, nicht als bereits erfolgten Wirksamkeitsnachweis. Siehe agentische Runbook-Verbesserung im Betrieb, Humans and Agents in Software Engineering Loops, Lässigs kybernetisches Modell und die zugehörige Referenz- und Konzeptlandkarte.
Im betrachteten Prozess bleibt menschliches Review verpflichtend, obwohl statische Analyse, mehrere Testebenen und Secret Scanning bereits vorhanden sind. Eine Suffizienzschwelle für automatische Kontrollen fehlt. Die daraus abgeleitete Forschungsfrage behandelt Ersatz deshalb nicht binär, sondern als gestaffelte, risikoabhängige Assurance aus deterministischen Kontrollen, agentischen Reviews, begrenzter Ausführung, menschlichem Urteil und Produktionsfeedback.
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. Eine qualitative Studie professioneller Entwickler beobachtet passend dazu Planung, begrenzte Parallelität, fortlaufende Kontrolle und aufgabenspezifische Delegation statt vollständiger Autonomie. Eine MSR-Studie zeigt ergänzend, dass Core und Peripheral Developers Agenten unterschiedlich einsetzen und Core Developers häufiger auf bestandener CI bestehen. Frühe Open-Source-Daten zeigen zugleich meist nur geringe Nutzungsintensität und ein dominantes Single-Reviewer-Modell. Ein Experiment mit Studierenden warnt, dass bessere kurzfristige Aufgabenerfüllung mit schwächerem Codeverständnis einhergehen kann; ob dies auf Junior Developers in Teams übertragbar ist, bleibt offen. Ein persönlicher Erfahrungsbericht von Brent Fitzgerald wirft zusätzlich die Frage auf, wann Delegation und Parallelisierung Aufmerksamkeit fragmentieren, Work in Progress erhöhen oder Lerngelegenheiten verdrängen. Siehe Thoughtworks zum agentischen SDLC, INNOQ zur verschobenen Komplexität, die Studie professioneller Agentennutzung, den Vergleich von Core und Peripheral Developers, die Studie zu Codeverständnis, die Studie früher Open-Source-Adoption und Fitzgeralds Gegenentwurf zur dauernden Agentennutzung.
Cutlers Journey to Product Teams ergänzt ein Gesprächsmodell über Teamgrenzen, interne und externe Übergaben sowie den Zusammenhang von Build, Measure und Learn. Der Nutzer verortet das betrachtete Team zwischen „Design as team member“ und „Feature Factory“, mit unterschiedlich ausgeprägten Bereichen. Daraus entstehen eine Frage nach Bereitschaft, Fähigkeiten und Mandat sowie die ungeprüfte These, dass Product-Team-Arbeit Kapazitätsverschiebung statt zusätzlicher Pflichten braucht.
Eine weitere ungeprüfte These trennt Team-Flow von Prozessframework: Eine Scrum-Organisation kann als Feature Factory arbeiten, während ein Product Team Scrum als Planungs- und Reflexionsrhythmus beibehält. Der entscheidende Unterschied ist, ob Produktwirkung als Folgeentscheidung in die Arbeit desselben Teams zurückfließ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.
Zur Engstellenperspektive gehört eine Kostenperspektive. Das Google-Whitepaper stellt niedrigen Einstiegskosten von ad-hoc Prompting mögliche Folgekosten durch unstrukturierte Wiederholung, Wartung und Security gegenüber und beschreibt Context Engineering, Tests und einen gemeinsamen Harness als Vorleistung mit wiederholtem Nutzen. Für den Garden ist dies eine prüfbare TCO-Hypothese: Nicht nur Tokenkosten, sondern auch Aufbau und Pflege des Harness, Validierungsaufwand, Fehlversuche, Wartung und Risikokosten müssen einem Nutzen gegenübergestellt werden. Das Whitepaper selbst liefert dafür keine belastbare vergleichende Kostenmessung. Siehe Googles Whitepaper zum neuen SDLC.
Eine erste, noch ungemessene Beobachtung aus der betrachteten Organisation konkretisiert dieses Problem: „Implementierung“ erscheint als Engpass, bündelt vermutlich aber Anforderungsklärung, Systemanalyse, Review, Test, Build, Rollout und die dazwischenliegenden Wartezeiten. Vor Auswahl eines Experiments müssen diese Teilflüsse getrennt betrachtet werden.
Eine weitere ungeprüfte These verbindet aufwendiges Review, Test und Deployment mit dem lokalen Anreiz, Änderungen zu bündeln. Dadurch könnte ein Gegenkopplungseffekt entstehen: Große Batches sparen wiederholte Prozesskosten, sind aber schwerer zu prüfen, auszurollen und zurückzunehmen. Agentic Engineering müsste dann nicht nur Arbeit innerhalb eines Batches beschleunigen, sondern die Kosten sicherer kleiner Änderungen senken.
Eine konkrete Beobachtung zu Feature-Testumgebungen zeigt einen möglichen Mechanismus: Instabile Bereitstellung und Testausführung verlangen menschliche Betreuung; während des Wartens wird neue Arbeit begonnen, wodurch Work in Progress und Aufmerksamkeitswechsel steigen. Ein Agent könnte Überwachung und bekannte Diagnosewege übernehmen, sollte die Instabilität aber nicht dauerhaft verdecken.
Die daraus entwickelte Frage nach einem Agentic Flywheel für Testumgebungen verbindet Betriebshilfe mit Harness-Verbesserung: Fehlerdaten sollen in erklärbare Diagnosen, Regressionstests, Umgebungsinvarianten und geprüfte Plattformkorrekturen zurückfließen. Ob dies Ursachen zuverlässig reduziert und seinen zusätzlichen Pflegeaufwand rechtfertigt, bleibt zu untersuchen.
Eine daraus abgeleitete These begrenzt das Flywheel durch explizite Evidenz- und Autoritätsgrenzen. Fehlende Telemetrie und nicht zugängliche Infrastruktur dürfen nicht durch vermeintlich sichere Agentenschlüsse kaschiert werden; zugleich ist breiter Zugriff wegen des wachsenden Schadensradius keine neutrale Lösung.
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. SecRepoBench ergänzt diese Systemperspektive um Code-Security: Repositoryweite Agenten übertrafen isolierte Modelle, hatten aber weiterhin Schwierigkeiten, funktional korrekte und zugleich sichere Ergänzungen zu erzeugen. Siehe Anthropic zur Begrenzung agentischer Systeme und SecRepoBench.
10. Wirkung, Evidenz und Lernen
Gemessen werden sollten nicht Codezeilen oder erzeugte Pull Requests, sondern Produktwirkung, Durchlaufzeit, Stabilität, Qualität, Risiko, Kosten, Lernfähigkeit und Developer Experience. 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 aktuelle Microsoft-Feldstudie schätzt zwar ungefähr 24 Prozent mehr gemergte Pull Requests bei Nutzern von CLI Coding Agents, bezeichnet Pull Requests aber selbst nur als Output-Proxy. Eine dreimonatige Fintech-Fallstudie ergänzt die menschlichen Kosten: Beschleunigte Routineaufgaben gingen mit Validierungsarbeit für Prompts, Ergebnisse und Architekturabgleich einher. 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, die Microsoft-Feldstudie, die Fintech-DevEx-Fallstudie und Eight Myths on Software Engineering and GenAI.
Die radikale Frage nach einem produktionsreifen Thin Slice in wenigen Tagen verschiebt „10x“ von Feature-Output zu Zeit bis zu belastbarem Feedback. Eine lokale Beobachtung zeigt dabei eine nicht-technische und eine technische Grenze: Aktivierung dauert meist nur ein bis zwei Tage, doch gezielte Pilotnutzer und Instrumentierung des Benutzerverhaltens fehlen häufig. Die daraus abgeleitete, ungeprüfte These zur Feedback Readiness behandelt Nutzeraufmerksamkeit und Produktmonitoring als vor der Umsetzung vorzubereitende Fähigkeiten, die Agenten unterstützen, aber nicht ersetzen können.
Eine weitere lokale Beobachtung zeigt, dass Ergebnisse nach dem Rollout informell in die Priorisierung einfließen, ohne festen Entscheidungszeitpunkt oder verlässliche Rückmeldung an das Entwicklungsteam. Daraus entsteht die ungeprüfte These, dass höherer Delivery-Durchsatz ohne geschlossenen Entscheidungsloop vor allem Feature-Akkumulation beschleunigen kann.
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.
Die vorläufige Forschungsagenda hält eine kleine, noch unpriorisierte Auswahl möglicher erster Untersuchungsschritte fest. Der wissenschaftliche Research Roadmap zu Agentic Software Engineering liefert ergänzende Begriffe für Agentenarbeitsplätze, Übergaben und menschliche Rückfragen.