KI-Coding-Tools sind in Softwareteams inzwischen weit verbreitet, doch die Belege für ihren Nutzen sind deutlich uneinheitlicher, als es die Entwicklung der Verbreitung vermuten lässt. Einige Studien zeigen Vorteile bei klar abgegrenzten Programmieraufgaben, während andere Sicherheits- und Review-Risiken feststellen, die in komplexen oder speicherunsicheren Codebasen zunehmen.
Für Unternehmensteams geht es in der Debatte weniger darum, ob Entwickler KI nutzen sollten, sondern vielmehr darum, wo die Tools eingesetzt werden. Ausgabequalität, Sicherheitsrisiko und Review-Aufwand variieren je nach Programmiersprache, Aufgabenkomplexität und dem Maß an menschlicher Beurteilung, das angewendet wird, bevor Code die Produktion erreicht.
Eine Studie zum SecurityEval-Benchmark ergab, dass vier große LLMs in mehr als 75 % der getesteten Fälle anfälligen Code erzeugten. Häufig erfüllten sie zwar die funktionalen Anforderungen, ließen aber den Sicherheitskontext außer Acht. Eine Studie zur statischen Java-Analyse fand keinen direkten Zusammenhang zwischen den Erfolgsquoten von Unit-Tests und der Qualität oder Sicherheit des generierten Codes.
Dieselbe Sorge prägt bereits die Produktstrategie: OpenAI arbeitet daran, Codex für Entwickler in Unternehmen sicherer zu machen , indem rund um Coding-Agenten weitere kontrollierte Umgebungen geschaffen werden.
Warum die Ergebnisse von KI-Coding je nach Aufgabe variieren
Einige Argumente für KI sind in engen Einsatzbereichen gut belegt. Eine Studie zur Python-Codequalität ergab, dass von LLMs generierter Code insgesamt weniger Fehler aufwies und weniger Nachbesserungsaufwand erforderte als von Menschen geschriebener Code – insbesondere bei Einsteiger- und auf Bewerbungsgespräche zugeschnittenen Aufgaben.
Das erklärt, warum Entwickler, die an klar abgegrenztem, testbarem Anwendungscode arbeiten, von tatsächlichen Vorteilen berichten können. Die Erkenntnis bedeutet weder, dass KI-generierter Code in jeder Umgebung sicherer ist, noch dass sich einfachere Benchmark-Ergebnisse ohne Weiteres auf Produktionssysteme übertragen lassen.
Auch die skeptische Sichtweise wird gestützt. Dieselbe Python-Studie stellte fest, dass KI-generierte Lösungen bei einer Komplexität auf Wettbewerbsniveau strukturelle Probleme einführten, selbst wenn die Ergebnisse bei einfacheren Aufgaben besser ausfielen.
Eine neuere Sicherheitsstudie zu C++ zeigte ein deutlich ausgeprägteres Risikomuster bei speicherunsicherem Systemcode. Die Forschenden untersuchten 8.918 C++-Programme und stellten fest, dass KI-generierter Code etwa doppelt so häufig wie von Menschen geschriebener Code eine bestätigte Laufzeitverletzung auslöste – selbst nach Kontrolle von Codeumfang und Erfolgsquote der Tests.
Der praktikable Mittelweg besteht in scannerunterstützten Reviews und menschlicher Freigabe. In der SecurityEval-Studie steigerte die scannerunterstützte Behebung mit Tools wie CodeQL und Bandit die Erfolgsquote bei der Behebung von Schwachstellen auf 65,9 % bis 85,5 %, verglichen mit 33,2 % bis 59,6 % bei einer nicht unterstützten LLM-Reparatur.
Diese Review-Ebene ist auch zentral für OpenAIs Open-Source-Sicherheitsinitiative Patch the Planet, die von der KI generierte Befunde mit einer menschlichen Validierung kombiniert, bevor Maintainer zum Handeln aufgefordert werden.
Wo Review-Kontrollen entscheidend werden
Diese Studien stützen sich stark auf Benchmark-Aufgaben und nicht auf vollständige Bereitstellungsabläufe in Unternehmen. Sie legen ein Mindestrisiko bei begrenzter Kontrolle fest, nicht ein präzises Risikoniveau für Teams, die strukturierte Reviews, Tests und Bereitstellungskontrollen einsetzen.
Die praktische Trennlinie verläuft nach dem Risiko, nicht nach dem Tool. Zu den risikoärmeren Einsatzbereichen gehören klar abgegrenzter Anwendungscode, interne Tools, Tests, Dokumentation und Prototypen mit eindeutigen Anforderungen und automatisierten Tests. Zu den risikoreicheren Einsatzbereichen gehören C- und C++-Systemcode, sicherheitsrelevante Funktionen, regulierte Produkte sowie Code, der einer Prüfung durch Kunden, Investoren oder im Rahmen einer Übernahme ausgesetzt sein wird.
Die Kontrollen sollten sich nach dem Risiko richten. Für Arbeiten mit geringem Risiko kann ein standardmäßiges Code-Review ausreichen, doch Repositories mit höherem Risiko sollten vor dem Merge eine statische Analyse, eine semantische Analyse, gegebenenfalls dynamische Tests und eine menschliche Freigabe erfordern. Das entspricht der übergreifenden Entwicklung hin zu Sicherheitskontrollen für KI-Agenten, bei der Überwachung, Zugriffsbeschränkungen und Blockierungsmechanismen Teil des Bereitstellungsplans werden.
Teams sollten dokumentieren, wo KI-Tools eingesetzt werden, für Repositories mit höherem Risiko Sicherheits- und Lizenzprüfungen vorschreiben und Belege für die menschliche Prüfung aufbewahren. Eine bestandene Testsuite ist keine Freigabe für den Produktionseinsatz; Code-Review, statische Analyse und Sicherheitstests müssen die Lücke weiterhin schließen.
Mehr dazu: Während KI immer tiefer in Abläufe der Anwendungssicherheit vordringt, nutzt IBM ebenfalls OpenAI-Modelle, um Unternehmen dabei zu helfen, ausnutzbare Softwarefehler zu finden , bevor Angreifer dies tun.