KI-gestützt programmieren: schneller, aber nicht ohne Fachwissen und Qualitätssicherung

KI und Machine Learning

Der KI-Assistent schreibt in Sekunden das Gerüst für ein AutoCAD-Add-in. Es sieht überzeugend aus – und ruft eine Methode auf, die es in der API nicht gibt. Oder es lässt sich fehlerfrei übersetzen und benutzt eine Klasse, die unter .NET 10 zur Laufzeit eine Ausnahme wirft. KI beschleunigt das Programmieren spürbar. Ob das Ergebnis taugt, entscheidet aber weiterhin jemand, der das Fach versteht.

Was sich verschiebt

Ebi F. Eilber, Geschäftsführer von Cadida und seit über 25 Jahren in der CAD-Entwicklung, bringt es auf den Punkt: Das Programmieren übernimmt zunehmend die KI. Umso wichtiger werden Kreativität, Fachwissen, Produktverständnis, Innovation und Qualitätssicherung.

• Kreativität: Welche Lösung ist die richtige? Die KI beantwortet die Frage, die man ihr stellt – nicht die, die man hätte stellen sollen.
• Fachwissen: Wie verhält sich eine Blockreferenz, was verlangt eine Norm, wie rauscht ein Sensor? Ohne dieses Wissen fällt ein plausibler Fehler nicht auf.
• Produktverständnis: Was braucht der Anwender wirklich, und was darf auf keinen Fall passieren?
• Innovation: Neues entsteht aus Erfahrung und Ideen, nicht aus dem Durchschnitt bekannter Beispiele.
• Qualitätssicherung: Wenn Code schneller entsteht, muss er auch schneller und gründlicher geprüft werden.

Wo KI heute hilft

Gut geeignet ist KI für Gerüste und wiederkehrenden Code, für das Umformen bestehender Programme, etwa bei einer Portierung, für Testfälle, die man sonst aus Zeitmangel weglässt, und zum Erklären fremden Codes. Je verbreiteter eine Technik ist, desto besser kennt die KI sie. Bei Spezial-APIs wie AutoCAD, Revit oder FeatureCAM, bei Gerätetreibern und bei Versionswechseln wird sie unsicherer – und klingt trotzdem genauso überzeugt.

Wo sie danebenliegt

Ein gut untersuchtes Beispiel sind erfundene Pakete. Für eine auf der USENIX Security 2025 vorgestellte Studie erzeugten 16 Sprachmodelle 576.000 Codebeispiele. Im Schnitt waren mindestens 5,2 % der empfohlenen Pakete bei kommerziellen Modellen und 21,7 % bei frei verfügbaren Modellen erfunden. Das ist mehr als ein Ärgernis: Angreifer können solche Namen registrieren und Schadcode darunter veröffentlichen.

Ein zweites Beispiel ist das eigene Gefühl. In einer randomisierten Studie von METR aus dem Jahr 2025 brauchten 16 erfahrene Open-Source-Entwickler mit KI-Werkzeugen im Schnitt 19 % länger für ihre Aufgaben – und schätzten hinterher, sie seien 20 % schneller gewesen. METR weist selbst darauf hin, dass sich die Werkzeuge seitdem weiterentwickelt haben und das Ergebnis nicht verallgemeinert werden darf. Die Lehre bleibt: messen statt schätzen.

Qualitätssicherung für KI-Code

• Review wie bei einem neuen Kollegen: Jede Änderung liest jemand, der den Code verantwortet.
• Tests zuerst: Abnahmekriterien und Testfälle legen fest, was richtig ist – nicht der Assistent.
• Automatisch prüfen: Unit- und Oberflächentests, statische Analyse und Sicherheitsprüfungen laufen bei jedem Build.
• Vertraulichkeit: Kundencode und Geschäftsgeheimnisse gehören nur in KI-Dienste, deren Vertrag und Datenverarbeitung geklärt sind.
• Abhängigkeiten freigeben: Neue Pakete kommen nur nach Prüfung ins Projekt. Ein kleines Skript im Build hält alles auf, was nicht freigegeben ist:

import re
import sys


def paketnamen(pfad):
    """Liest die Paketnamen einer requirements-Datei, normiert nach PEP 503."""
    namen = set()
    with open(pfad, encoding="utf-8") as datei:
        for zeile in datei:
            zeile = zeile.split("#")[0].strip()
            if zeile and not zeile.startswith("-"):
                name = re.split(r"[\s\[<>=!~;@]", zeile, maxsplit=1)[0]
                namen.add(re.sub(r"[-_.]+", "-", name).lower())
    return namen


neu = paketnamen("requirements.txt") - paketnamen("freigegeben.txt")
for name in sorted(neu):
    print("Nicht freigegeben:", name)
sys.exit(1 if neu else 0)

Entscheidend ist die Freigabe, nicht die bloße Existenz eines Pakets. Ein erfundener Name kann längst von einem Angreifer registriert sein. Und die Verantwortung bleibt, wo sie war: Der Cyber Resilience Act fragt nicht, ob ein Mensch oder eine KI den Code geschrieben hat. Für die Sicherheit des Produkts steht der Hersteller ein.

Typische Fehler

• KI-Code übernehmen, weil er sich übersetzen lässt.
• Vorschläge für Spezial-APIs nicht gegen die Dokumentation der eingesetzten Version prüfen.
• Pakete installieren, die der Assistent vorschlägt, ohne sie zu prüfen.
• Die Tests ebenfalls von der KI schreiben lassen und nur darauf achten, dass sie grün sind.
• Den Zeitgewinn schätzen statt messen.
• Berufseinsteiger nur noch Eingaben formulieren lassen. Ohne Fachwissen erkennen sie die Fehler nicht.

Quellen: J. Spracklen u. a., „We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs“, USENIX Security 2025; METR, „Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity“, Juli 2025; Einschätzung: Ebi F. Eilber, Geschäftsführer der Cadida Software GmbH.