Dabei ist das eigentliche Problem selten die Technologie. Auch die österreichischen Daten zeigen: Die größte Hürde beim Einsatz von GenAI in der Softwareentwicklung ist mit 52 Prozent Compliance und Sicherheit, gefolgt von fehlenden Skills im Team (31 Prozent) und veralteten Architekturen (28 Prozent). Kein Coding-Assistent, kein Prompt-Engineering-Workshop und kein weiteres Pilotprojekt beantwortet diese Frage. Was es braucht, ist ein Grundverständnis dafür, wie Mensch und Maschine im gesamten Software Development Lifecycle zusammenarbeiten – vom ersten Requirement bis zum produktiven Betrieb.
Sieben Prinzipien machen dabei den Unterschied:
1. Mensch und Agent übernehmen verschiedene Jobs
Der häufigste Fehler beim Einstieg: AI-Agenten werden behandelt wie sehr schnelle Entwickler. Das ist die falsche Analogie. Agenten sind keine Junior-Entwickler, die man einfach frei auf Aufgaben loslassen kann. Sie sind ausführende Instanzen, die präzise Leitplanken brauchen, um zu funktionieren.
Der Mensch bringt das “Warum” und “Was” ein: Architekturprinzipien, fachliche Anforderungen, Qualitätskriterien. Der Agent übernimmt die Ausführung. Dazu gehört: Code generieren, Tests ausführen, Fehler beheben, Dokumentation schreiben. Immer in kontinuierlichen Feedbackschleifen, ohne dass jeder Schritt manuell angestoßen werden muss.
2. Die Qualität des Inputs bestimmt die Qualität des Outputs
Halluzination ist kein technisches Problem, das sich mit einem besseren Modell löst. Es ist meistens ein Kontextproblem. Wer AI-Agenten mit vagen Anforderungen startet, bekommt vage Ergebnisse, egal wie leistungsfähig das Modell dahinter ist.
Strukturierte Artefakte wie klare Spezifikationen, Architekturprinzipien und Kontextdokumentationen sind deshalb keine lästige Pflicht, sondern die eigentliche Steuerungsebene. Ein gut aufgebautes Spezifikationsdokument ist im Kontext agentischer Entwicklung wertvoller als tausend Zeilen manuell geschriebener Code. Es ist der Unterschied zwischen einem Agenten, der weiß, was er tut, und einem, der rät.
3. Kurze Zyklen schlagen lange Sprints
Klassische agile Entwicklung arbeitet in Sprints von zwei bis drei Wochen. Agentische Teams schaffen Entwicklungszyklen von zwei bis vier Tagen, über den gesamten Software Development Lifecycle hinweg: von der Anforderung über Implementierung und Test bis zu Review und Betrieb. Damit geht nicht nur ein quantitativer Unterschied einher, sondern auch ein qualitativer. Kürzere Zyklen verändern, wie Entscheidungen getroffen werden, wie Fehler entdeckt werden und wie schnell ein Team auf veränderte Anforderungen reagiert.
Das treffendere Bild ist nicht länger der Sprint, sondern das Fließband. Agenten arbeiten kontinuierlich, auch nachts, auch am Wochenende. Releases werden häufiger, die Iterationen kleiner. Wer einmal in diesem Rhythmus gearbeitet hat, will nicht zurück.
4. Guided Automation ist das Gegenteil von Vollautonomie
Eines der hartnäckigsten Missverständnisse rund um agentische Entwicklung: Agenten programmieren selbstständig, der Mensch schaut zu. Der Blick in die Praxis zeigt: Das ist kein funktionierender Ansatz.
Agenten handeln nicht frei, sie handeln in Strukturen, die Menschen definieren. In der Praxis bedeutet das: Hochspezialisierte Agenten mit klar abgegrenztem Fokus und präzisem Kontext arbeiten innerhalb explizit definierter Übergabepunkte, automatisierter Qualitäts-Gates und klarer Abnahmekriterien. Der Mensch macht als Kontrollinstanz das, was tatsächlich menschliches Urteilsvermögen erfordert: Architekturentscheidungen, strategische Weichenstellungen, finale Abnahmen – nicht Zeilenkontrolle.
5. Governance ist keine Kür, sondern Pflicht
Agentische Entwicklung stellt Compliance-Verantwortliche vor neue Fragen. Welche Modelle dürfen in welchen Projekten eingesetzt werden? Wie wird sichergestellt, dass kein Code mit geschütztem IP in Trainingsdaten landet? Wer trägt die LLM-Kosten, und wie werden sie projektgenau zugeordnet?
Diese Fragen sind lösbar. Aber sie müssen vor dem ersten produktiven Einsatz beantwortet sein, nicht danach. Ein standardisierter, rechtskonformer Zugang zu Large Language Models mit transparenter Kostenstruktur und definierten Governance-Regeln ist die Grundlage, auf der sich agentische Entwicklung überhaupt skalieren lässt.
6. Legacy ist kein Hindernis, wenn der Ansatz stimmt
Die Annahme, agentische Softwareentwicklung funktioniere nur auf der grünen Wiese, ist weit verbreitet, aber falsch. In der Projektpraxis zeigt sich: Bestehende Codebasen, gewachsene Systeme und gemischte Teams lassen sich sehr wohl in agentische Prozesse integrieren. Die Voraussetzung ist eine Methodik, die dafür ausgelegt ist.
Das Schlüsselprinzip ist Parallelität. Klassische und agentische Teams arbeiten im selben System, mit klar definierten Übergabepunkten und einem Koordinationsmechanismus wie Kanban, der Konflikte zwischen den unterschiedlichen Taktfrequenzen verhindert. Ein klassisches Team arbeitet in Zweiwochensprints, ein agentisches Team im selben Projekt mit Zwei-bis-Vier-Tages-Zyklen. Das ist keine bloße Theorie, sondern bereits in Kundenprojekten erprobt.
7. Software ist nur der Anfang
Was in der Softwareentwicklung funktioniert, gilt nicht nur dort. Die Prinzipien des agentischen Arbeitens beschreiben ganz allgemein ein Grundmodell für die Zusammenarbeit von Menschen und autonomen Systemen. Dazu gehören eine klare Rollenverteilung, strukturierter Input, kurze Zyklen, Guided Automation und Governance by Design. Das können Unternehmen auf viele andere Kontexte übertragen.
Überall dort, wo Prozesse iterativ sind, dokumentierbar und in klar abgegrenzte Schritte zerlegbar, lassen sich agentische Ansätze einsetzen. In der Qualitätssicherung, in der Dokumentenverarbeitung, in der automatisierten Analyse. Und in Geschäftsprozessen, die Unternehmen heute noch vollständig manuell abbilden. Nicht weil das sinnvoll ist, sondern weil es bisher keine praktikable Alternative gab.
