KI in Softwareentwicklung und IT: Assistenten, Agenten und klare Leitplanken

Die Werkzeuge haben sich schnell entwickelt, die Grundformen sind aber stabil. Code-Vervollständigung schlägt im Editor die nächsten Zeilen vor; die Entwicklerin übernimmt oder verwirft sie. Chat-Assistenten beantworten Fragen zum Code, erklären Fehlermeldungen und erzeugen Funktionen oder Tests auf Anfrage. Coding-Agenten erhalten eine Aufgabe und arbeiten sie in mehreren Schritten ab: Sie lesen das Repository, ändern Dateien, führen Befehle und Tests aus und legen einen Änderungsvorschlag an.

Welche Produkte für ein Team passen, ändert sich laufend und sollte anhand aktueller Herstellerdokumentation, Datenschutzbedingungen und eigener Tests entschieden werden. Wichtiger als die Marke sind drei Fragen: Wo werden Eingaben und Code verarbeitet, werden sie für Training genutzt, und welche Rechte hat das Werkzeug in der Arbeitsumgebung? Die Datenschutzkonferenz nennt die Fehlersuche in Code ohne Personenbezug ausdrücklich als Beispiel, weist aber darauf hin, dass Personenbezug auch über das Modell oder Testdaten entstehen kann.

Beim Code-Review kann KI eine erste Durchsicht übernehmen: mögliche Fehler, fehlende Fehlerbehandlung, inkonsistente Benennung, nicht getestete Pfade. Das ersetzt nicht das Review durch einen Menschen, der Fachlogik und Architektur kennt, entlastet es aber von Routinehinweisen. Besonders nützlich ist eine KI-Zusammenfassung großer Änderungen, die Reviewenden zeigt, wo sie genau hinsehen sollten.

Tests und Dokumentation gehören zu den Aufgaben, die in vielen Teams liegen bleiben. KI erzeugt Unit-Tests für bestehende Funktionen, schlägt Randfälle vor und schreibt Docstrings, README-Abschnitte oder Schnittstellenbeschreibungen. Erzeugte Tests müssen allerdings geprüft werden: Ein Test, der nur das aktuelle Verhalten festschreibt, schützt auch Fehler. Die Frage lautet immer, ob der Test die fachliche Anforderung prüft.

Viele Mittelständler betreiben Eigenentwicklungen, deren ursprüngliche Autoren nicht mehr im Haus sind – in älteren Sprachen, mit wenig Dokumentation und vielen impliziten Geschäftsregeln. Hier liegt ein unterschätzter Nutzen von KI: Sie erklärt unbekannten Code, rekonstruiert Abläufe, erstellt Übersichten über Abhängigkeiten und formuliert gefundene Geschäftsregeln so, dass Fachbereiche sie bestätigen können.

Für die eigentliche Migration empfiehlt sich ein kontrolliertes Vorgehen: zuerst Charakterisierungstests, die das heutige Verhalten festhalten, dann Übersetzung oder Neuentwicklung in kleinen Schritten, jeweils mit Vergleich gegen die Tests. Ein Agent kann einzelne Module übertragen, aber die Entscheidung, welche Regel fachlich noch gilt, liegt beim Fachbereich. Große automatische Umschreibungen ohne Testabdeckung verschieben Risiko nur in die Zukunft.

In der internen IT bearbeitet KI wiederkehrende Tickets: Sie kategorisiert Meldungen, schlägt Lösungen aus der Wissensdatenbank vor, fasst lange Verläufe zusammen und formuliert Antworten an Anwender. Bei Störungen hilft sie, Logauszüge zu lesen, ähnliche frühere Vorfälle zu finden und Runbooks Schritt für Schritt abzuarbeiten. Daraus entsteht häufig auch bessere Dokumentation, weil Lösungen in einer gemeinsamen Form festgehalten werden.

Vorsicht gilt bei schreibenden Eingriffen. Benutzerkonten anlegen, Rechte vergeben, Server neu starten oder Konfigurationen ändern sollte ein KI-System nur über vordefinierte, protokollierte Aktionen mit Freigabe dürfen. Die OWASP-Liste der Risiken für LLM-Anwendungen beschreibt dieses Problem als übermäßige Handlungsbefugnis (Excessive Agency): Je mehr Rechte ein System hat, desto größer ist der Schaden bei Fehlern oder manipulierten Eingaben.

Drei Sicherheitsthemen stehen im Vordergrund. Erstens Secrets: Zugangsdaten, Schlüssel und Kundendaten dürfen nicht in Eingaben, Kontextdateien oder generierten Code gelangen; Secret-Scanning in Repository und Pipeline fängt Fehler ab. Zweitens die Lieferkette: KI schlägt Bibliotheken vor, die veraltet, unsicher oder gar nicht existent sein können. Abhängigkeiten brauchen deshalb eine Prüfung, und Frameworks wie SLSA beschreiben, wie sich die Integrität von Build und Herkunft schrittweise absichern lässt. Drittens Lizenzen: Erzeugter Code kann fremdem Code ähneln; Lizenzscans und klare Regeln zu Open-Source-Lizenzen gehören in den Prozess.

Governance heißt im Mittelstand vor allem: eine kurze, verbindliche Richtlinie. Sie legt fest, welche Werkzeuge mit welchen Konten erlaubt sind, welche Repositories und Daten tabu sind, dass jeder Merge ein menschliches Review braucht und wer Agenten mit welchen Rechten betreiben darf. Agenten laufen in isolierten Umgebungen ohne Produktionszugang und ohne dauerhafte Zugangsdaten. Das deutsch-französische Papier von BSI und ANSSI zu KI-Programmierassistenten richtet seine Empfehlungen ausdrücklich auch an das Management.

Ob KI ein Team tatsächlich schneller und besser macht, lässt sich nicht an erzeugten Zeilen oder angenommenen Vorschlägen ablesen. DORA beschreibt fünf Kennzahlen für die Softwarelieferung: Durchlaufzeit von Änderungen, Deployment-Häufigkeit und Wiederherstellungszeit nach fehlgeschlagenen Deployments für den Durchsatz sowie Änderungsfehlerrate und Nacharbeitsrate bei Deployments für die Stabilität. DORA betont, dass die Kennzahlen je Anwendung oder Service betrachtet werden sollten.

Sinnvoll ist ein Vorher-nachher-Vergleich für ein oder zwei Anwendungen über mehrere Monate, ergänzt um Beobachtungen aus dem Team: Wo hilft das Werkzeug, wo kostet es Zeit, etwa durch aufwendige Reviews? Steigt der Durchsatz, während die Stabilität sinkt, ist das ein Signal, Review und Tests zu stärken, nicht die Nutzung auszuweiten.