Stand: 22. September 2026
Agentic AI kann in der Softwareentwicklung Aufgaben nicht nur vorschlagen, sondern in mehreren Schritten planen und mit Werkzeugen ausführen: Code lesen, Dateien ändern, Tests anstoßen oder Pull Requests vorbereiten. Das kann Entwicklungsarbeit beschleunigen. Es verlagert Verantwortung jedoch nicht an die KI. Architektur, Sicherheit, Wartbarkeit und die Freigabe produktiver Änderungen bleiben eine Engineering-Aufgabe.
Mehr als Code-Vervollständigung
Ein Coding-Agent unterscheidet sich von einer reinen Autovervollständigung durch seinen Handlungsspielraum. Er kann eine Aufgabe in Teilaufgaben zerlegen, sich durch ein Repository bewegen, Dateien verändern und Ergebnisse aus Werkzeugen verwerten. Genau darin liegt der Nutzen: Wiederkehrende Arbeiten wie Tests, Dokumentation, kleine Umstellungen oder die Vorbereitung eines Features lassen sich schneller anstoßen.
Der größere Handlungsspielraum erhöht aber auch die Wirkung eines falschen Auftrags. Ein unklarer Agent kann eine vorhandene Architektur ignorieren, Abhängigkeiten austauschen oder eine fachlich plausible, aber unpassende Lösung in viele Dateien tragen. OWASP ordnet agentische Systeme deshalb als Systeme mit erweiterten Fähigkeiten und zugleich erweiterten Risiken ein. Sicherheitsmaßnahmen müssen den Zugriff auf Werkzeuge, Daten und Aktionen mitdenken. [1]
Wo der Nutzen tatsächlich entstehen kann
Agentic AI eignet sich besonders für klar abgegrenzte und überprüfbare Arbeitspakete. Dazu gehören etwa das Erstellen von Testfällen, die Suche nach einer konsistenten Umstellung, ein Entwurf für eine Schnittstelle oder die Aufbereitung technischer Dokumentation. Der Mensch definiert Ziel, Grenzen und Akzeptanzkriterien. Der Agent übernimmt die Ausarbeitung innerhalb dieses Rahmens.
Das kann Kosten senken, wenn Entwicklungszeit für wiederkehrende Arbeit eingespart wird und die Ergebnisse ohne große Nacharbeit in das Projekt passen. Eine kontrollierte Studie zu GitHub Copilot beobachtete bei einer eng abgegrenzten JavaScript-Aufgabe eine schnellere Fertigstellung. Daraus folgt jedoch keine allgemeine Zusage für komplexe Produkte. In Bestandssoftware, bei unklaren Anforderungen oder hohen Sicherheitsanforderungen können Prüfung, Integration und Korrekturen den anfänglichen Zeitgewinn wieder aufzehren. [2]
Der wirtschaftliche Vorteil entsteht nicht durch möglichst viel generierten Code, sondern durch weniger wiederkehrende Arbeit bei gleicher oder besserer Prüfbarkeit.
Wartbarkeit ist kein Nebenprodukt
Code ist erst dann günstig, wenn er auch später verstanden, verändert und zuverlässig betrieben werden kann. Agenten können rasch viel Quelltext erzeugen. Ohne Vorgaben kann dabei jedoch eine neue Variante neben einer bestehenden Lösung entstehen: andere Fehlerbehandlung, neue Hilfsfunktionen, abweichende Namensgebung oder zusätzliche Bibliotheken. Das erhöht die kognitive Last im Team und kann kleine Änderungen später unnötig teuer machen.
Eine gute Aufgabenbeschreibung benennt deshalb den Kontext. Dazu gehören die betroffene Domäne, bestehende Schnittstellen, Architekturentscheidungen, Code-Stil, erlaubte Abhängigkeiten und konkrete Tests. Ebenso wichtig ist ein Review der Änderungen als Gesamtpaket: Nicht nur die geänderte Funktion muss stimmen, sondern auch Zusammenspiel, Fehlermeldungen, Logging und Rückbau. Der Agent kann bei der Analyse helfen; er ersetzt aber nicht das Verständnis dafür, warum eine Lösung in dieses Projekt passt.
Security muss im Auftrag stehen
Ein Agent kennt die Schutzbedürftigkeit eines Projekts nicht automatisch. Ohne klare Grenzen kann er Geheimnisse aus Konfigurationsdateien in Ausgaben übernehmen, unpassende Bibliotheken vorschlagen oder Eingaben nur unzureichend prüfen. Bei einem Agenten mit Werkzeugzugriff kommt hinzu, dass Berechtigungen, Dateizugriffe, Datenbankzugriffe und Deployment-Schritte selbst Teil des Bedrohungsmodells werden. Prompt Injection, übermäßige Berechtigungen und unkontrollierte Tool-Aufrufe sind daher keine theoretischen Nebenthemen. [1]
Vor der Arbeit sollte daher feststehen, welche Daten der Agent sehen darf und welche nicht. Zugangsdaten, private Schlüssel und personenbezogene Daten gehören nicht in Prompts oder Testausgaben. Für verschlüsselte Übertragung und Speicherung reicht die Anweisung „bitte verschlüsseln“ nicht aus. Entscheidend sind Datenklassifikation, geeignetes Schlüsselmanagement, ein klarer Einsatzbereich und die Prüfung, ob die Umsetzung tatsächlich die gewünschte Schutzwirkung hat. Das NIST Secure Software Development Framework empfiehlt, Sicherheitspraktiken durchgängig in den Entwicklungslebenszyklus einzubetten, um Schwachstellen zu reduzieren und ihre Auswirkungen zu begrenzen. [3]
Der Prompt ist eine technische Spezifikation
Je selbstständiger ein Agent arbeitet, desto genauer muss sein Auftrag sein. „Baue eine Login-Seite“ ist keine ausreichend belastbare Anforderung. Eine brauchbare Spezifikation beschreibt zum Beispiel Technologie und vorhandene Struktur, Zielgruppe und fachlichen Ablauf, Datenfelder, Berechtigungen, Fehlerfälle, Qualitätskriterien und die erwarteten Tests. Sie benennt auch, was der Agent ausdrücklich nicht tun darf: keine neuen Abhängigkeiten, keine Schemaänderungen ohne Freigabe, keine produktiven Deployments und keine Ausgabe von Secrets.
Auch nichtfunktionale Anforderungen müssen sichtbar werden. Dazu zählen Authentifizierung und Autorisierung, Eingabevalidierung, Protokollierung, Datenschutz, Verschlüsselung, Barrierefreiheit sowie Suchmaschinenoptimierung. Wer eine öffentliche Seite erzeugen lässt, muss etwa wissen, dass Seitentitel, Meta-Beschreibung, kanonische URL, strukturierte Inhalte, Ladezeit und zugängliches Markup eigene Anforderungen sind. Ein Agent kann diese Punkte umsetzen oder prüfen. Er kann sie nicht verlässlich erraten.
- Kontext geben: Architektur, Technologie, vorhandene Konventionen und betroffene Dateien benennen.
- Grenzen setzen: Berechtigungen klein halten, Secrets ausschließen und keine unkontrollierten Werkzeugaktionen erlauben.
- Akzeptanz festlegen: Funktion, Tests, Fehlerfälle, Sicherheitsanforderungen und Qualitätskriterien vorab definieren.
- Ergebnis prüfen: Diffs lesen, Tests unabhängig ausführen, Abhängigkeiten bewerten und kritische Änderungen fachlich freigeben.
Ein belastbarer Arbeitsablauf
In der Praxis funktioniert ein schrittweiser Ablauf besser als ein großer Auftrag. Zuerst wird die Aufgabe eingegrenzt und der relevante Projektkontext bereitgestellt. Dann erstellt der Agent einen Plan oder einen kleinen Änderungsvorschlag. Anschließend folgen automatisierte Tests, Sicherheitsprüfungen und ein menschliches Review. Erst nach dieser Prüfung wird die Änderung zusammengeführt oder veröffentlicht. So bleibt nachvollziehbar, welche Entscheidung der Mensch getroffen hat und welche Ausarbeitung das Werkzeug geliefert hat.
Das passt auch zum NIST AI Risk Management Framework. Es versteht Risikomanagement nicht als einmaligen Freigabepunkt, sondern als Einbettung von Vertrauenswürdigkeitsaspekten in Entwicklung, Nutzung und Bewertung von KI-Systemen. Für Agentic AI bedeutet das: Fähigkeiten, Zugriff und Auswirkungen müssen zusammen betrachtet werden. [4]
Fazit: Beschleunigung mit Fachverantwortung
Agentic AI kann Softwareentwicklung wirtschaftlicher machen, wenn sie repetitive und klar prüfbare Arbeit reduziert. Sie kann Entwürfe, Tests, Dokumentation und Umstellungen beschleunigen. Ihr Mehrwert sinkt jedoch, wenn Anforderungen unscharf bleiben oder Ergebnisse ungeprüft übernommen werden. Besonders bei Security, Verschlüsselung, Datenschutz und SEO braucht es ausreichend Fachwissen, um die richtigen Anforderungen zu formulieren und die Umsetzung beurteilen zu können.
Der sinnvolle Maßstab ist daher nicht „Kann der Agent das erzeugen?“, sondern „Ist die Änderung fachlich passend, sicher, wartbar und nachvollziehbar?“. Wer diese Fragen beantwortet und einen kontrollierten Arbeitsablauf etabliert, kann den Geschwindigkeitsvorteil nutzen, ohne Qualität und Verantwortung aus der Hand zu geben.
Quellen und weiterführende Informationen
[1] OWASP GenAI Security Project: Agentic AI – Threats and Mitigations
[2] Peng et al. (2023): The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
[3] NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1
[4] NIST: AI Risk Management Framework
Dieser Beitrag dient der allgemeinen Information und ersetzt keine individuelle technische, Sicherheits- oder Rechtsberatung.