KI schreibt Code — die Verantwortung bleibt beim Menschen

Wer nach den Risiken KI-gestützter Softwareentwicklung sucht, findet zuerst Warnungen: ein Forschungsinstitut, das vor unbesehener Übernahme warnt, Sicherheitsanalysen mit unangenehmen Zahlen, Fachanwälte, die auf ungeklärte Rechtsfragen hinweisen. Das ist keine Panikmache, sondern eine begründete Gegenposition zu einem Werkzeug, das gerade sehr schnell verbreitet wird.

Wir entwickeln KI-gestützt. Deshalb ist dieser Artikel kein neutraler Überblick, und wir schreiben das an den Anfang statt ans Ende. Was wir hier tun, ist etwas anderes: die belegten Einwände einzeln benennen, sagen, was wir dagegen tun — und an der Stelle, an der wir nichts zusagen können, das ebenfalls sagen.

Was die Kritik tatsächlich sagt

Vier Einwände tauchen in ernstzunehmenden Quellen immer wieder auf. Sie betreffen unterschiedliche Ebenen und lassen sich nicht mit derselben Maßnahme beantworten.

Einwand	Belegt durch	Was er für Ihr Projekt bedeutet
Wartbarkeit	GitClear, Auswertung von 211 Mio. Codezeilen	Der Code funktioniert heute und ist in drei Jahren schwerer zu ändern
Sicherheitslücken	Veracode, 2025 GenAI Code Security Report	Bekannte Angriffsmuster landen unbemerkt in der Anwendung
Haftung	Fachanwaltliche Einordnungen, laufende Verfahren	Die Frage, wer geradesteht, wird erst im Schadensfall gestellt
Herkunft der Bausteine	Rechtsanalysen zu Trainingsdaten und Lizenzen	Fremder, lizenzbehafteter Code kann unbemerkt in Ihr System gelangen

Der Reihe nach.

Wartbarkeit: das Problem zeigt sich später

Der bestbelegte Einwand betrifft nicht die Funktion, sondern die Struktur. Die Codeanalysefirma GitClear hat über mehrere Jahre Änderungen an Quellcode ausgewertet und zwei gegenläufige Bewegungen gefunden: Der Anteil kopierter Zeilen stieg von 8,3 Prozent im Jahr 2020 auf 12,3 Prozent im Jahr 2024, während der Anteil umstrukturierter Zeilen im selben Zeitraum von 24,1 auf 9,5 Prozent fiel (GitClear, AI Code Quality Research 2025).

Übersetzt heißt das: Es wird mehr dupliziert und weniger aufgeräumt. Für ein System, das drei Monate lebt, ist das gleichgültig. Für eines, das Ihren Betrieb fünf Jahre lang trägt, ist es der Unterschied zwischen einer Änderung an einer Stelle und derselben Änderung an sieben Stellen, von denen man sechs findet.

Das Fraunhofer IESE hat den entscheidenden Punkt nüchtern formuliert: „Die Prämisse, dass KI-Agenten eigenständig qualitativ hochwertigen Code generieren, der keinerlei Inspektion mehr benötigt, können wir zum jetzigen Zeitpunkt nicht bestätigen.” Als Grund nennt das Institut unter anderem, dass komplexe, gewachsene Codebestände und projektspezifische Rahmenbedingungen es den Modellen erschweren, den Zusammenhang richtig zu erfassen (Fraunhofer IESE).

Die Entwicklerbefragung von Stack Overflow zeigt dieselbe Erfahrung aus der Praxis: 66 Prozent der Befragten nennen als größte Schwierigkeit Ergebnisse, die „fast richtig, aber nicht ganz” sind; 46 Prozent misstrauen der Genauigkeit der Ausgaben, gegenüber 31 Prozent im Vorjahr (Stack Overflow Developer Survey 2025). Das ist die unangenehmste Fehlerart überhaupt — nicht der Absturz, sondern das plausible Ergebnis mit einem falschen Sonderfall darin.

Sicherheitslücken: die Zahlen sind eindeutig

Veracode hat für den 2025 GenAI Code Security Report Code aus über 100 Sprachmodellen gegen wiederkehrende Sicherheitsaufgaben geprüft. 45 Prozent der erzeugten Codebeispiele fielen durch die Sicherheitstests und enthielten Schwachstellen aus den bekannten OWASP-Kategorien. Bei Cross-Site-Scripting lag die Fehlerquote bei 86 Prozent, in Java bei 72 Prozent über alle Aufgaben (Veracode).

Bemerkenswert ist weniger die Höhe als der Verlauf: Die syntaktische Qualität der Ausgaben ist seit 2023 deutlich gestiegen, die Sicherheitsquote dagegen kaum. Neuere und größere Modelle schnitten nicht besser ab. Das spricht dafür, dass sich das Problem nicht von selbst mit der nächsten Modellgeneration erledigt.

Praktisch bedeutet das: Erzeugter Code ist in der Regel funktional, aber überdurchschnittlich oft in einer Weise geschrieben, die Eingaben zu gutgläubig behandelt. Genau das findet keine Abnahme durch den Fachbereich, weil die Anwendung sich vollkommen richtig verhält, solange niemand sie angreift.

Haftung: die Frage ist geklärter, als sie wirkt

Bei der Haftung entsteht der meiste Nebel — dabei ist der für Sie wichtige Teil einfach. Ihr Vertragspartner ist die Firma, die die Software liefert. Ein Werkzeug ist kein Vertragspartner und kann keine Verantwortung übernehmen. Wer den Code liefert, schuldet ein Werk ohne Mängel, unabhängig davon, womit er es erstellt hat.

Ungeklärt ist etwas anderes, nämlich das Verhältnis zwischen den Anbietern der Werkzeuge und ihren Nutzern. Das Verfahren Doe v. GitHub zu diesen Fragen ist seit 2022 anhängig, eine abschließende Klärung steht aus (Rechtliche Einordnung zu KI-generiertem Code). Freistellungserklärungen der Werkzeuganbieter enthalten zahlreiche Ausschlüsse und bieten deshalb nur begrenzte Absicherung (CMS, Legal Update).

Für Ihr Projekt folgt daraus eine sehr konkrete Prüffrage an jeden Anbieter: Steht in seinem Vertrag ein Vorbehalt, der zwischen von Hand geschriebenem und KI-gestützt entstandenem Code unterscheidet? Bei uns steht dort keiner. Wir gewährleisten für den gelieferten Code unabhängig davon, mit welchen Werkzeugen er entstanden ist — nachzulesen unter Wie wir arbeiten.

Die Herkunft der Bausteine: das Risiko, für das wir keine Zusage machen

Der vierte Einwand ist der einzige, der wirklich neu ist. Sprachmodelle sind auf großen Mengen vorhandenen Quellcodes trainiert, darunter Code unter Lizenzen mit Weitergabepflicht. Reproduziert ein Modell einen solchen Abschnitt und landet er in einer Anwendung, können die Pflichten dieser Lizenz mit hineinwandern (CMS, Legal Update). Das ist kein theoretisches Konstrukt, sondern der Grund, warum bei Unternehmenskäufen inzwischen gefragt wird, mit welchen Werkzeugen eine Software entstanden ist.

Es gibt an dieser Stelle noch eine zweite, seltener genannte Seite. Nach § 69a Abs. 3 UrhG ist rein maschinell erzeugter Code häufig nicht urheberrechtlich geschützt, weil die eigene geistige Schöpfung eines Menschen fehlt. Wer Wert darauf legt, dass an seiner Software Rechte entstehen, hat also ein Interesse daran, dass Menschen sie entwerfen, überarbeiten und prüfen — nicht nur aus Qualitätsgründen. Das ist keine Rechtsberatung; wer darauf angewiesen ist, sollte es anwaltlich klären lassen.

Und jetzt der Teil, den wir nicht versprechen. Wir sagen Ihnen nicht zu, den gelieferten Code auf Rechte Dritter oder auf Lizenzverträglichkeit zu prüfen. Eine solche Prüfung gehört bei uns nicht zum Lieferumfang, und deshalb behaupten wir sie hier nicht — auch nicht in einer weichen Formulierung. Wer sie zusagt, sagt zu, jeden fremden Codeanteil zuverlässig zu erkennen. Ein Versprechen ohne Deckung wäre an dieser Stelle schlimmer als das Risiko selbst, weil Sie sich darauf verlassen würden.

Was tatsächlich hilft, ist unspektakulär und wirkt vorbeugend:

• Verbreitete Bausteine statt beliebiger Fundstücke. Wir setzen auf bekannte, weit verbreitete Bibliotheken, deren Lizenz aus der Paketverwaltung hervorgeht, statt auf zusammengesuchte Codeschnipsel unklarer Herkunft.
• Wenige Abhängigkeiten. Jede zusätzliche fremde Komponente ist eine weitere Herkunft, die jemand kennen müsste. Die Zahl klein zu halten, ist die wirksamste Maßnahme, die keiner Prüfung bedarf.
• Nachvollziehbare Entstehung. Jede Änderung hat in der Versionsverwaltung einen Zeitpunkt, einen Autor und einen Grund. Sie können später rekonstruieren, wann ein Abschnitt entstanden ist und wer ihn übernommen hat.
• Eigenständig geschriebene Fachlogik. Der Teil, der Ihren Betrieb abbildet, ist per Definition nicht anderswo vorhanden. Das Risiko konzentriert sich auf allgemeine, austauschbare Bausteine — und genau dort helfen die ersten beiden Punkte.
• Menschliche Code-Prüfung. Ein größerer Abschnitt, der stilistisch nicht zum Rest passt, fällt beim Lesen auf. Das ist keine Lizenzprüfung, aber es ist der Grund, warum unbesehene Übernahme bei uns nicht vorkommt.

Ein Restrisiko bleibt. Es trifft jede Firma, die heute KI-gestützt entwickelt, und es ist rechtlich nicht abschließend geklärt. Wenn Ihr Einkauf eine ausdrückliche Zusicherung zu Rechten Dritter verlangt, gehört das in den Vertrag und muss verhandelt werden. Verlassen Sie sich dabei auf keinen Fall auf einen Satz auf einer Website — weder auf unserem noch auf dem eines anderen Anbieters.

Wie wir damit umgehen

Vier Schritte gehören bei uns zu jedem System. Sie stehen als Position im Angebot, damit Sie sie vergleichen können.

Schritt	Was dabei passiert	Gegen welchen Einwand er wirkt
Menschliche Code-Prüfung	Jede Änderung wird gelesen, bevor sie in den Hauptstand geht: auf Verständlichkeit, auf Randfälle, auf Übereinstimmung mit dem Konzept	Wartbarkeit, „fast richtig”
Automatisierte Tests	Die Abläufe, an denen Ihr Betrieb hängt, werden abgesichert und bei jeder Änderung erneut geprüft	Wartbarkeit, unbemerkte Folgefehler
Prüfung fremder Bausteine	Abhängigkeiten werden auf bekannte Schwachstellen geprüft, und ihre Zahl wird bewusst klein gehalten	Sicherheitslücken
Sicherheitsprüfung	Zugriffsrechte, Prüfung von Eingaben, Umgang mit Zugangsdaten, Protokollierung, Sicherungen — vor dem Start und bei jeder größeren Änderung	Sicherheitslücken

Dazu kommt, was Sie am Ende in der Hand halten: Quellcode, unbeschränktes Nutzungsrecht, Dokumentation und verbreitete Technik, mit der ein anderer Entwickler übernehmen kann. Das ist die eigentliche Absicherung gegen den Wartbarkeitseinwand — sie verlangt von Ihnen kein Vertrauen, sondern lässt sich prüfen.

Die Aufgabenteilung dabei ist unverändert: Wie Ihr Ablauf funktionieren soll, welche Regeln gelten und welche Ausnahmen zählen, entsteht im Gespräch und steht im Konzept, bevor die erste Zeile geschrieben wird. Wie dieses Konzept aufgebaut ist, steht in Lastenheft: Struktur und Vorlage.

Was wir nicht behaupten

Drei Aussagen, die in diesem Umfeld häufig fallen, werden Sie bei uns nicht finden.

Keine Multiplikatoren. Wir nennen keine Faktoren und keine Vergleichszahlen zur Entwicklungsgeschwindigkeit. Wir haben keine eigenen gemessenen Projektdaten, mit denen wir sie belegen könnten, und fremde Zahlen sagen über unsere Arbeit nichts aus.

Keine Tempoversprechen. Aus demselben Grund nennen wir keine allgemeinen Zeitangaben. Was ein bestimmtes Vorhaben braucht, steht im Angebot zu diesem Vorhaben.

Keine Lizenzprüfung. Siehe oben. Sie steht nicht im Lieferumfang, also steht sie auch nicht auf dieser Seite.

Was bleibt, ist eine Aussage über die Kosten, die belegbar ist, weil sie unsere eigene ist: Individualsoftware ist bei uns günstiger möglich, als sie es vor wenigen Jahren war. Die Preise dazu stehen offen unter Kosten, einschließlich des Stundensatzes, mit dem wir kalkulieren.

Die Fragen, die Sie jedem Anbieter stellen sollten

Diese sechs Fragen sind unabhängig von uns nützlich. Sie funktionieren bei jedem Anbieter, und die Antworten sind vergleichbar.

1. Arbeiten Sie KI-gestützt? Wenn nein — woher kommt Ihr Preis? Wenn ja — wer liest den Code, bevor er in mein System geht?
2. Steht in Ihrem Vertrag ein Gewährleistungsvorbehalt für KI-gestützt entstandenen Code?
3. Stehen Code-Prüfung, Tests und Sicherheitsprüfung als benannte Positionen im Angebot?
4. Bekomme ich Quellcode, Dokumentation und Zugänge — und ab wann?
5. Könnte ein anderer qualifizierter Entwickler das System übernehmen, ohne Sie zu fragen?
6. Welche Zusicherungen zu Rechten Dritter geben Sie, und welche ausdrücklich nicht?

Frage sechs ist die, an der sich am meisten zeigt. Ein Anbieter, der sie mit einem pauschalen Ja beantwortet, hat sie entweder nicht verstanden oder verspricht etwas, das er nicht halten kann. Weitere Prüffragen zur Anbieterauswahl stehen in Softwaredienstleister auswählen.

Warum wir das aufschreiben

Weil Sie es im Projekt ohnehin sehen würden. Und weil die eigentliche Frage hinter „arbeiten Sie mit KI” nicht das Werkzeug ist, sondern eine andere: Wer steht dafür gerade, wenn etwas nicht funktioniert, und komme ich ohne Sie weiter, wenn ich muss? Diese Antwort ändert sich durch kein Werkzeug — sie steht im Vertrag.

Wenn Sie das genauer wissen wollen, steht der vollständige Ablauf unter Wie wir arbeiten. Und wenn Sie eine konkrete Frage zu einem Vorhaben haben, beschreiben Sie sie in zwei Sätzen im Erstgespräch — auch kritische Fragen zur Arbeitsweise gehören dort hinein und nicht in den dritten Projektmonat.