Tests zu schreiben gehört zu den Aufgaben, die in vielen Teams am häufigsten aufgeschoben werden. Sie kosten Zeit, bringen kurzfristig keine sichtbare Funktion, und ihr Nutzen zeigt sich erst Monate später, wenn eine Änderung einen Fehler an unerwarteter Stelle verursacht und ein Test ihn rechtzeitig meldet. Genau deshalb wirken KI-Assistenten auf diesem Feld so verlockend: Ein Klick, und zu einer Klasse liegen zehn Testmethoden vor, inklusive Mocks, Randfällen und sprechenden Namen. Die Abdeckungsanzeige springt nach oben, die Pipeline bleibt grün.
Diese Bequemlichkeit hat eine Kehrseite, die der Kern dieses Artikels ist. Ein Sprachmodell, das aus vorhandenem Code Tests ableitet, beschreibt zunächst, was der Code tut, nicht was er tun soll. Enthält der Code einen Fehler, schreibt der generierte Test diesen Fehler als erwartetes Verhalten fest. Hinzu kommen Tests, die zwar Code ausführen, aber kaum etwas prüfen, etwa weil sie nur auf „kein Fehler geworfen“ testen oder Mocks so konfigurieren, dass das Ergebnis vorher feststeht. Solche Tests erhöhen die Abdeckung, ohne die Sicherheit zu erhöhen. Drei Leitgedanken ziehen sich deshalb durch die folgenden Kapitel:
Automatische Testgenerierung ist älter als die heutigen Sprachmodelle. Seit vielen Jahren gibt es Verfahren, die Tests systematisch erzeugen: zufallsbasierte Generatoren wie Randoop, suchbasierte Werkzeuge wie EvoSuite für Java oder Pynguin für Python, symbolische Ausführung und eigenschaftsbasiertes Testen mit Bibliotheken wie Hypothesis, jqwik oder fast-check. Diese Verfahren sind gründlich und reproduzierbar, erzeugen aber oft schwer lesbare Tests mit generischen Namen und wenig fachlichem Bezug.
Sprachmodelle haben die Lage verändert, weil sie Tests schreiben, die aussehen, als hätte ein Mensch sie geschrieben: mit sinnvollen Namen, typischen Testdaten, den im Projekt üblichen Frameworks und lesbaren Zusicherungen. Sie können außerdem Kommentare, Ticketbeschreibungen und Dokumentation einbeziehen und so näher an die eigentliche Absicht des Codes heranrücken. Dafür sind sie weniger systematisch, gelegentlich schlicht falsch und nicht deterministisch. Die interessantesten Werkzeuge kombinieren deshalb beide Welten: Ein Sprachmodell schlägt Tests vor, und klassische Verfahren wie Ausführung, Abdeckungsmessung und Mutationsanalyse filtern, was davon tatsächlich etwas taugt.
Mit Coding-Assistenten und Agenten entsteht in vielen Teams spürbar mehr Code pro Woche als früher. Damit wächst die Menge an Code, der abgesichert werden muss, schneller als die Kapazität der Menschen, die ihn verstehen. Tests sind das wichtigste Werkzeug, um diese Schere zu schließen, denn sie halten das gewünschte Verhalten fest, unabhängig davon, ob ein Mensch oder eine Maschine den Code geschrieben hat. Agenten selbst sind zudem auf gute Tests angewiesen: Ein Agent, der eine Aufgabe erledigen und dabei nichts kaputt machen soll, braucht eine Testsuite, an der er seinen Erfolg messen kann. Wer heute in die Testbasis investiert, schafft also auch die Voraussetzung, um agentische Werkzeuge morgen sicher einsetzen zu können.
Die wichtigste Unterscheidung betrifft die Steuerung. Bei interaktiven Werkzeugen sitzt ein Mensch am Steuer: Er markiert eine Funktion, beschreibt, was getestet werden soll, liest den Vorschlag und entscheidet. Das ist langsamer, aber die fachliche Prüfung geschieht im selben Moment, in dem der Test entsteht. Autonome Werkzeuge arbeiten dagegen auf ganzen Modulen oder Repositorys und liefern Hunderte Tests auf einmal. Sie sind ideal, um schnell ein Sicherheitsnetz unter bestehenden Code zu spannen, verlagern die Prüfung aber in ein nachgelagertes Review, das bei großen Mengen leicht oberflächlich wird.
In der Praxis bewährt sich eine Kombination. Für neuen Code und für fachlich kritische Logik schreiben Menschen die Tests selbst oder mit interaktiver KI-Hilfe, wobei die erwarteten Ergebnisse aus der Anforderung kommen. Für bestehenden Code ohne Tests können autonome Generatoren eine erste Schicht von Charakterisierungstests erzeugen, die das aktuelle Verhalten dokumentiert. Agenten in der Pipeline wiederum eignen sich, um Lücken in einem bereits gut getesteten Bestand gezielt zu schließen, weil dort die vorhandenen Tests als Stilvorlage und als Kontrolle dienen.
Eine zweite Unterscheidung betrifft die Technik. Rein generative Ansätze lassen ein Sprachmodell den Testcode schreiben und verlassen sich darauf, dass er kompiliert und sinnvoll ist. Suchbasierte und analytische Ansätze erzeugen Eingaben systematisch, führen den Code aus und leiten Zusicherungen aus dem beobachteten Verhalten ab. Sie garantieren lauffähige Tests, haben aber weniger Gespür für fachlich sinnvolle Testdaten. Hybride Ansätze lassen ein Modell Vorschläge machen und filtern diese anschließend maschinell: Nur Tests, die kompilieren, stabil grün laufen und die Abdeckung oder den Mutation Score tatsächlich erhöhen, werden übernommen. Dieses Muster wurde unter anderem in Veröffentlichungen aus der Industrieforschung beschrieben und findet sich inzwischen in mehreren Werkzeugen, darunter dem quelloffenen Projekt Qodo Cover. Für Unternehmen ist es das robusteste Muster, weil es die Kreativität des Modells mit einer objektiven Prüfung verbindet.
Am besten funktioniert KI-Testgenerierung bei Funktionen mit klarer Ein- und Ausgabe: Berechnungen, Validierungen, Formatierungen, Parser, Zustandsautomaten. Hier kann ein Modell Grenzwerte erkennen, etwa leere Listen, negative Zahlen, Datumsgrenzen oder Sonderzeichen, und sie systematisch abprüfen. Viele Teams berichten, dass gerade diese Randfälle der eigentliche Gewinn sind, weil Menschen sie aus Zeitdruck oder Gewohnheit gern auslassen. Ein guter Arbeitsablauf ist, das Modell zuerst nur eine Liste der zu testenden Verhaltensweisen erstellen zu lassen, diese Liste fachlich zu prüfen und zu ergänzen und erst dann den Testcode erzeugen zu lassen.
Schwieriger wird es, sobald Klassen viele Abhängigkeiten haben. Modelle neigen dann dazu, alles zu mocken, was nicht bei drei auf den Bäumen ist. Das Ergebnis sind Tests, die im Wesentlichen prüfen, ob bestimmte Methoden in einer bestimmten Reihenfolge aufgerufen wurden. Solche Tests sind eng an die Implementierung gekoppelt und brechen bei jedem Refactoring, obwohl sich das Verhalten nicht geändert hat. Bewährt hat sich die Vorgabe, nur echte Systemgrenzen wie Datenbank, Netzwerk, Dateisystem und Uhrzeit zu ersetzen und ansonsten mit echten Objekten zu arbeiten. Diese Vorgabe gehört in die Projektregeln für den Assistenten, damit sie nicht in jedem Prompt neu formuliert werden muss.
Integrationstests prüfen das Zusammenspiel mehrerer Komponenten, etwa einer Service-Schicht mit einer echten Datenbank oder eines REST-Endpunkts mit Serialisierung, Validierung und Persistenz. KI-Werkzeuge können hier viel Schreibarbeit abnehmen: Testklassen mit Containern für Datenbanken oder Message-Broker aufsetzen, etwa mit Testcontainers, Testdaten anlegen, HTTP-Anfragen formulieren und Antworten prüfen. Der Kontextbedarf ist allerdings deutlich höher als bei Unit-Tests. Das Modell muss Konfiguration, Datenbankschema, Sicherheitsfilter und vorhandene Testinfrastruktur kennen, sonst entstehen Tests, die zwar plausibel aussehen, aber in der konkreten Umgebung nicht laufen.
Für Integrationstests lohnt es sich deshalb, eine gute Vorlage im Projekt zu haben: eine Basisklasse oder ein Beispieltest, an dem sich das Modell orientieren kann. Agentische Werkzeuge, die Tests selbst ausführen und Fehlermeldungen lesen, haben hier einen klaren Vorteil gegenüber reinen Chat-Assistenten. Gleichzeitig steigt die Verantwortung beim Aufräumen. Integrationstests, die Daten hinterlassen, voneinander abhängen oder zeitabhängig sind, werden schnell instabil, und instabile Tests untergraben das Vertrauen in die gesamte Suite.
Ein unterschätztes Einsatzfeld ist das Erzeugen von Testdaten. Sprachmodelle erzeugen glaubwürdige Adressen, Artikelstämme, Auftragsdaten oder Messreihen, die fachlich plausibel sind, ohne echte Personen oder Kundendaten zu enthalten. Das ist für den Datenschutz ein Gewinn, denn in vielen Unternehmen landen aus Bequemlichkeit Kopien echter Produktionsdaten in Testumgebungen. Ebenfalls hilfreich ist KI bei der Analyse fehlschlagender Tests: Sie kann Fehlermeldungen erklären, die wahrscheinliche Ursache benennen und eine Korrektur vorschlagen. Hier ist besondere Vorsicht geboten. Wenn ein Test nach einer Codeänderung fehlschlägt, ist die Frage, ob der Test oder der Code falsch ist, eine fachliche Entscheidung. Ein Assistent, der den Test einfach an das neue Verhalten anpasst, kann damit einen echten Fehler verstecken.
Zeilen- und Zweigabdeckung messen, welcher Code während der Tests ausgeführt wurde. Werkzeuge wie JaCoCo für Java, coverage.py für Python, Istanbul für JavaScript und TypeScript oder die in .NET üblichen Coverage-Werkzeuge liefern diese Zahlen zuverlässig. Eine niedrige Abdeckung ist ein klares Warnsignal: Was nie ausgeführt wird, wird auch nicht geprüft. Der Umkehrschluss gilt aber nicht. Ein Test, der eine Funktion aufruft und das Ergebnis ignoriert, erhöht die Abdeckung genauso wie ein Test mit präzisen Zusicherungen.
Bei KI-generierten Tests ist dieser Unterschied besonders relevant. Modelle optimieren, wenn man sie lässt, gern auf das, was gemessen wird. Wird ein Agent beauftragt, die Abdeckung auf einen Zielwert zu bringen, wird er das schaffen, im Zweifel mit Tests, die wenig prüfen. Abdeckungsziele sind deshalb als Untergrenze für kritische Module sinnvoll, als alleiniges Erfolgskriterium für KI-Testing aber gefährlich. Ergänzend lohnt der Blick auf die Art der Zusicherungen: Tests ohne Assertions, mit sehr allgemeinen Prüfungen oder mit Zusicherungen, die nur das Mock-Verhalten spiegeln, lassen sich teilweise automatisch erkennen.
Mutation Testing dreht die Perspektive um. Ein Werkzeug verändert den Produktionscode an vielen Stellen minimal, etwa indem es ein Kleiner-Zeichen in ein Kleiner-gleich verwandelt, eine Bedingung umkehrt, eine Rückgabe durch einen Standardwert ersetzt oder einen Methodenaufruf entfernt. Jede dieser Varianten heißt Mutant. Anschließend laufen die Tests gegen jeden Mutanten. Schlägt mindestens ein Test fehl, gilt der Mutant als erkannt. Laufen alle Tests weiter grün, hat die Suite eine Lücke: Ein echter Fehler dieser Art würde unbemerkt bleiben. Der Anteil erkannter Mutanten ist der Mutation Score.
Etablierte Werkzeuge sind PIT beziehungsweise PITest für Java, Stryker für JavaScript, TypeScript und C#, mutmut und Cosmic Ray für Python sowie Infection für PHP. Mutation Testing ist rechenintensiv, weil die Tests sehr oft laufen. In der Praxis wird es deshalb meist inkrementell eingesetzt, nur für geänderten Code im Pull Request oder in einem nächtlichen Lauf. Für KI-Testing ist es das ideale Gegengewicht: Ein generierter Test, der keinen zusätzlichen Mutanten erkennt, hat wenig Mehrwert und kann verworfen werden. Umgekehrt sind überlebende Mutanten eine hervorragende Aufgabe für ein Sprachmodell: „Schreibe einen Test, der diese Änderung bemerkt“ ist präziser als jede allgemeine Aufforderung, mehr Tests zu schreiben.
Die meisten Teams beginnen in der IDE. Allround-Assistenten bieten dafür Chat-Befehle oder Kontextmenüs, mit denen sich zu einer markierten Funktion Tests erzeugen lassen; bei GitHub Copilot etwa gibt es dafür einen eigenen Befehl im Chat, andere Assistenten arbeiten ähnlich. Spezialisierte Werkzeuge wie Qodo zeigen vorgeschlagene Verhaltensweisen als Liste, die sich einzeln annehmen oder verwerfen lässt. Entscheidend für die Qualität ist weniger das Werkzeug als der Kontext, den es erhält. Assistenten, die die vorhandenen Tests des Projekts, die verwendeten Bibliotheken und die Konventionen kennen, erzeugen deutlich besser passende Ergebnisse. Fast alle Assistenten unterstützen inzwischen Projektregeln in Form von Dateien im Repository, in denen Testframework, Namensschema, Mocking-Strategie und Verbote festgehalten werden.
Im Pull Request übernimmt KI zwei Rollen. Erstens kann ein KI-Review benennen, wenn eine Änderung keine passenden Tests enthält oder vorhandene Tests geändert wurden, ohne dass die Begründung ersichtlich ist. Zweitens können Agenten auf Anforderung Tests für die Änderung nachliefern. In der Pipeline lassen sich Abdeckung und Mutation Score für geänderten Code messen und als Qualitätstor nutzen. Ein solches Tor sollte mit Augenmaß konfiguriert werden: Ein harter Abbruch bei jeder kleinen Abweichung führt dazu, dass Teams Tests nur noch für die Kennzahl schreiben, und KI-Werkzeuge verstärken diesen Effekt eher, als ihn zu lösen.
Eine wachsende Zahl von Teams setzt Agenten zeitgesteuert ein, etwa nachts: Der Agent liest den Abdeckungs- oder Mutationsbericht, wählt einige Lücken mit hohem Risiko aus, schreibt Tests, prüft sie und eröffnet einen Pull Request. Das funktioniert gut, wenn die Menge pro Lauf begrenzt ist, damit das Review am nächsten Morgen in vertretbarer Zeit möglich bleibt. Für selbst betriebene Git-Server wie GitLab Self-Managed ist wichtig, dass solche Agenten auch in der eigenen Infrastruktur und mit einem selbst gewählten Modellzugang laufen können.
Viele Werkzeuge für KI-Testing erlauben die Wahl des Sprachmodells. Neben den Cloud-Modellen großer US-Anbieter lassen sich in offenen Werkzeugen wie Continue, Aider oder Tabby auch Modelle anbinden, die über Cloud-Anbieter mit EU-Rechenzentren oder vollständig lokal betrieben werden. Für Testgenerierung reichen oft kleinere Modelle mit offenen Gewichten aus, weil die Aufgabe gut abgegrenzt ist und das Ergebnis durch Ausführung und Mutationsanalyse objektiv geprüft wird. Das ist ein wichtiger Unterschied zu freien Programmieraufgaben: Die maschinelle Prüfung gleicht einen Teil der geringeren Modellqualität aus. Wer sensiblen Code nicht in eine Cloud geben möchte, findet hier einen pragmatischen Weg.
GitHub Copilot, JetBrains AI, Gemini Code Assist, Amazon Q Developer, GitLab Duo und Editoren wie Cursor bringen Testgenerierung als eine Funktion unter vielen mit. Für viele Teams ist das der natürliche Einstieg, weil das Werkzeug ohnehin lizenziert und freigegeben ist. Die Qualität hängt stark vom Kontext und von der Disziplin der Nutzenden ab. Ohne Projektregeln und ohne Prüfung durch Mutation Testing entstehen leicht Tests mit vielen Mocks und schwachen Zusicherungen. Mit guten Regeln und einer klaren Arbeitsweise sind Allround-Assistenten aber für den Großteil der täglichen Testarbeit ausreichend.
Qodo, früher CodiumAI, ist mit einem expliziten Testfokus gestartet und strukturiert die Generierung nach Verhaltensweisen, Randfällen und Fehlerpfaden. Ergänzend gibt es KI-Review für Pull Requests und das quelloffene Projekt Qodo Cover, das Tests gezielt zur Erhöhung der Abdeckung erzeugt und nur Tests behält, die tatsächlich etwas beitragen. Diffblue Cover verfolgt einen anderen Ansatz: Es erzeugt für Java-Codebasen automatisch Unit-Tests, die nach Herstellerangaben immer kompilieren und gegen den aktuellen Code grün laufen. Das macht es besonders interessant für große, alte Java-Systeme, in denen schnell ein Sicherheitsnetz entstehen soll. Die erzeugten Tests dokumentieren allerdings konsequent das Ist-Verhalten und ersetzen keine fachliche Spezifikation. Funktionsumfang, unterstützte Sprachen und Produktzuschnitt beider Anbieter ändern sich und sollten aktuell geprüft werden.
Coding-Agenten wie Claude Code, Aider, Cline oder die Agentenmodi von Cursor und Copilot können Tests schreiben, ausführen, Fehler lesen und sich selbst korrigieren. Sie sind die flexibelste Klasse, weil sie jede Sprache und jedes Framework bedienen, das sich auf der Kommandozeile ausführen lässt. Ihre Stärke ist zugleich ihr Risiko: Ein Agent, der Tests grün bekommen soll, kann auch den Produktionscode oder bestehende Tests verändern, wenn man ihn lässt. Offene Werkzeuge wie Aider, Continue oder Tabby haben den Vorteil, dass sie mit selbst gewählten Modellen arbeiten. Chinesische Modellanbieter sind in diesem Zusammenhang besonders kritisch zu sehen: Bei Cloud-Diensten wie denen von DeepSeek oder bei Werkzeugen aus dem ByteDance-Umfeld wie Trae fließt Code in einen Rechtsraum ohne Angemessenheitsbeschluss und mit weitreichenden staatlichen Zugriffsrechten. Für sensiblen Code empfehlen wir dort den Verzicht oder, bei Modellen mit offenen Gewichten, ausschließlich den Betrieb auf eigener Infrastruktur.
Generierte Tests sollten im Review mit denselben Augen gelesen werden wie Produktionscode, mit einigen zusätzlichen Fragen. Stimmen die erwarteten Werte mit der Anforderung überein, oder wurden sie nur aus dem aktuellen Verhalten abgeleitet? Prüft der Test Verhalten oder Implementierungsdetails? Gibt es aussagekräftige Zusicherungen, oder wird nur ausgeführt? Sind Name und Aufbau so verständlich, dass ein anderes Teammitglied den Test in einem Jahr anpassen kann? Und wurde ein bestehender Test geändert, und falls ja, warum? Hilfreich ist es, generierte Tests in eigenen Commits oder mit einer Kennzeichnung im Pull Request auszuweisen, damit Reviewer wissen, worauf sie besonders achten müssen.
Ein Testbestand ist kein einmaliges Ergebnis. Mit KI wächst er schneller, und damit wächst auch der Pflegeaufwand. Teams sollten bewusst entscheiden, welche Tests sie behalten. Doppelte Tests, Tests ohne erkennbaren Mehrwert im Mutation Testing und instabile Tests sollten regelmäßig entfernt werden. Bei lokal betriebenen Modellen kommen klassische Betriebsaufgaben hinzu: Hardware oder GPU-Kapazität bereitstellen, Modelle aktualisieren, Zugriffe verwalten. Für die Akzeptanz ist entscheidend, dass KI-Testing als Entlastung erlebt wird. Wenn Entwicklerinnen und Entwickler stundenlang schlechte Vorschläge aussortieren müssen, kippt die Stimmung schnell. Ein kleiner, gut kuratierter Einsatz mit sichtbaren Erfolgen ist besser als ein großflächiger Rollout mit vielen Fehlversuchen.
Ein typischer Fall ist eine über viele Jahre gewachsene Anwendung für Disposition, Kalkulation oder Produktionsplanung. Der Code funktioniert, aber Tests gibt es nur für wenige zentrale Funktionen, und jede Änderung ist mit der Sorge verbunden, an anderer Stelle etwas zu beschädigen. Mit KI-Unterstützung kann das Team in wenigen Wochen eine Schicht von Charakterisierungstests für die wichtigsten Module aufbauen. Diese Tests sagen nicht, ob das Verhalten richtig ist, aber sie melden zuverlässig, wenn es sich ändert. Damit wird Refactoring wieder möglich.
Wichtig ist, die Tests nicht als Spezifikation misszuverstehen. Wo das Team beim Durchsehen auf merkwürdiges Verhalten stößt, sollte es den Test markieren und die Frage mit dem Fachbereich klären. Oft zeigt sich dabei, dass vermeintliche Fehler in Wahrheit bewusst eingebaute Sonderregeln für einzelne Kunden sind, oder umgekehrt, dass seit Jahren falsch gerechnet wird. Beides ist wertvolles Wissen, das sonst nur in den Köpfen weniger Personen existiert.
Teams, die neue Funktionen entwickeln, können KI auch in umgekehrter Richtung einsetzen. Statt Tests aus fertigem Code abzuleiten, formulieren sie zuerst die Anforderung, lassen die KI daraus Testfälle und Randfälle vorschlagen, prüfen diese gemeinsam mit dem Fachbereich und schreiben erst dann den Code, oft ebenfalls mit KI-Hilfe. Weil die Tests aus der Anforderung stammen und nicht aus der Implementierung, entfällt das Grundproblem festgeschriebener Fehler. Die Tests werden zu einer gemeinsamen Sprache zwischen Entwicklung und Fachbereich. Dieser Ansatz verlangt mehr Disziplin, liefert aber die verlässlichsten Ergebnisse.
Unternehmen, die Software für Kunden entwickeln oder Produkte mit digitalen Elementen herstellen, müssen ihre Qualitätsprozesse zunehmend nachweisen, etwa in Lieferantenaudits, nach Branchenstandards oder im Hinblick auf den Cyber Resilience Act. Eine messbar steigende Testbasis mit dokumentierten Abdeckungs- und Mutationswerten ist dafür ein starkes Argument. Wichtig ist, transparent zu dokumentieren, wie KI-generierte Tests geprüft wurden. Ein Nachweis, der nur aus einer hohen Abdeckungszahl besteht, überzeugt erfahrene Auditoren kaum.
Kosten realistisch einschätzen. Die Lizenzkosten für Allround-Assistenten, die Testgenerierung mitbringen, liegen nach unserer Erfahrung in einem für Entwicklungsteams überschaubaren Rahmen pro Person und Monat; spezialisierte Werkzeuge und Enterprise-Tarife werden teils individuell verhandelt. Konkrete Preise, Kontingente und Tarifgrenzen ändern sich häufig und sollten aktuell beim jeweiligen Anbieter geprüft werden. Bei offenen Werkzeugen mit eigenem Modellzugang fallen nutzungsabhängige Kosten beim Modellanbieter an, bei lokalen Modellen Kosten für Hardware, Strom und Betrieb. Nicht zu vergessen sind Rechenkosten in der Pipeline: Mutation Testing und Agentenschleifen führen Tests sehr oft aus.
Für die Wirtschaftlichkeit zählt weniger der Lizenzpreis als die Wirkung. Ein Fehler, der durch einen Test vor der Auslieferung auffällt, kostet nur einen Bruchteil dessen, was er beim Kunden oder in der Produktion kostet. Ebenso wichtig ist die Zeit, die Entwicklerinnen und Entwickler beim Schreiben von Routinetests sparen. Dem steht der Aufwand für das Prüfen generierter Tests und für die Pflege eines größeren Testbestands gegenüber. Wer beides im Pilot ehrlich misst, kann den Nutzen belastbar bewerten.
Die meisten verbreiteten Coding-Assistenten stammen von Anbietern mit Sitz in den USA, und auch spezialisierte Anbieter aus anderen Ländern nutzen häufig Sprachmodelle von US-Unternehmen. Damit wird Quellcode, je nach Werkzeug auch Testdaten und Kontext aus dem Repository, in Rechenzentren außerhalb der EU verarbeitet. Für den Transfer in die USA kommt das EU-US Data Privacy Framework in Betracht, sofern der Anbieter zertifiziert ist; daneben werden Standardvertragsklauseln genutzt. Unabhängig vom Transfermechanismus unterliegen US-Anbieter Zugriffsrechten der US-Behörden. Für Diffblue mit Sitz im Vereinigten Königreich und Qodo mit Sitz in Israel bestehen nach unserem Kenntnisstand Angemessenheitsbeschlüsse der EU, deren aktuellen Stand Sie prüfen sollten; entscheidend bleibt aber, wo und durch welche Modellpartner der Code tatsächlich verarbeitet wird.
Besonders wichtig ist die Frage der Trainingsnutzung. In kostenlosen oder privaten Tarifen behalten sich manche Anbieter vor, Eingaben zur Verbesserung ihrer Modelle zu verwenden. Business- und Enterprise-Tarife schließen das in der Regel vertraglich aus. Für chinesische Anbieter wie DeepSeek oder Werkzeuge aus dem ByteDance-Umfeld wie Trae ist die Lage deutlich kritischer: Es gibt keinen Angemessenheitsbeschluss, staatliche Zugriffsrechte sind weitreichend, und vertragliche Zusicherungen lassen sich kaum durchsetzen. Für Unternehmenscode raten wir von den Cloud-Diensten dieser Anbieter ab. Modelle mit offenen Gewichten lassen sich dagegen auf eigener Infrastruktur betreiben, ohne dass Daten das Unternehmen verlassen. Die datenschutzfreundlichsten Optionen insgesamt sind Werkzeuge mit EU-Region, Enterprise-Varianten mit dedizierter Umgebung oder Self-Hosting mit lokalem Modell.
Quellcode ist in vielen Unternehmen ein Geschäftsgeheimnis. Wer ihn an ein KI-Werkzeug gibt, sollte prüfen, ob der Anbieter vertraglich zusichert, ihn nur zur Erbringung der Leistung zu verwenden, nicht zu speichern oder nur für eine begrenzte Zeit, und ihn nicht für das Training zu nutzen. Repositorys mit besonders schützenswerten Algorithmen, Zugangsdaten in Konfigurationsdateien oder Kundendaten in Testfixtures sollten ausgeschlossen oder vorher bereinigt werden. Bei generierten Tests stellt sich zudem die Frage nach Rechten am Ergebnis. Testcode ist in der Regel stark funktional und projektspezifisch, das Risiko urheberrechtlich relevanter Übernahmen aus Trainingsdaten ist daher geringer als bei generischem Produktionscode, aber nicht null. Einige Anbieter bieten Filter für Codevorschläge mit Übereinstimmungen zu öffentlichem Code und vertragliche Freistellungen in Enterprise-Tarifen an.
Werden KI-Werkzeuge mit Zugriff auf Repositorys eingeführt, gehört der Vorgang in das Verzeichnis von Verarbeitungstätigkeiten, sofern personenbezogene Daten betroffen sein können, etwa in Commit-Historien, Testdaten oder Protokollen. Weil viele Werkzeuge Nutzungsdaten pro Person erfassen, ist in Unternehmen mit Betriebsrat in der Regel eine Mitbestimmung bei technischen Einrichtungen zu prüfen, die zur Leistungs- oder Verhaltenskontrolle geeignet sind. Der EU AI Act stuft Coding-Assistenten nach unserem Verständnis nicht als Hochrisiko-Systeme ein; relevant sind aber die Pflichten zur KI-Kompetenz der Mitarbeitenden und die Transparenzpflichten der Anbieter. Eine kurze Schulung zur kritischen Prüfung generierter Tests erfüllt hier zugleich einen fachlichen und einen regulatorischen Zweck.
