Die Frage ist nicht, ob Ihr Quelltext geheim ist. Die Frage ist, was außer dem Quelltext noch mitgeht.
Was in einem Ausschnitt steckt
Eine Fehlermeldung mit Stapelverfolgung enthält den vollständigen Pfad auf dem Server, die Verzeichnisstruktur des Projekts, die eingesetzten Bibliotheken samt Version und häufig den Benutzernamen. Eine Konfigurationsdatei enthält Hostnamen, Ports, Datenbanknamen. Eine Funktion enthält Bezeichner, aus denen sich das Geschäftsmodell ableiten lässt.
Nichts davon ist ein Geheimnis im engeren Sinn. Zusammen ergibt es eine Bauzeichnung.
Verbindungszeichenfolgen und Schlüssel in Ausschnitten, die eigentlich nur die Fehlerursache zeigen sollten. Das passiert nicht selten und nicht nur Anfängern – es passiert immer dann, wenn jemand unter Zeitdruck markiert und kopiert.
Warum das rechtlich unangenehmer ist, als es sich anfühlt
Bei Auftragsprojekten ist der Quelltext regelmäßig Gegenstand einer Geheimhaltungsvereinbarung. Diese Vereinbarungen enthalten fast immer eine Klausel, dass Dritte nur mit Zustimmung eingebunden werden dürfen.
Ein Codeassistent ist ein Dritter. Er wird nicht dadurch zu keinem, dass die Nutzung praktisch ist. Wer ihn ohne Zustimmung einsetzt, verletzt die Vereinbarung – auch dann, wenn nie etwas passiert.
Kommen personenbezogene Daten dazu – ein Datenbankauszug zur Fehlersuche, ein Protokoll mit E-Mail-Adressen –, ist zusätzlich die DSGVO betroffen. Dann braucht es einen Auftragsverarbeitungsvertrag, und der Kunde muss den Unterauftragsverarbeiter kennen.
Die vier üblichen Auswege, bewertet
| Weg | Was er löst | Was bleibt |
|---|---|---|
| Gar keine Codeassistenz | Alles | Ein Produktivitätsnachteil, den Wettbewerber nicht haben |
| Nur anonymisierte Ausschnitte | Viel, wenn es konsequent geschieht | Es geschieht nicht konsequent – unter Zeitdruck nie |
| Anbieter mit Zero-Retention-Zusage | Die Speicherung | Verarbeitungsort, Unterauftragsverarbeiter, Konzernzugriff |
| Eigene oder exklusiv gemietete Hardware | Verarbeitungsort und Zugriff | Kosten und etwas schwächere Modelle |
Der zweite Weg ist der beliebteste und der unzuverlässigste. Vorsätze halten der Fehlersuche um 23 Uhr nicht stand.
Was offene Modelle heute können
Der ehrliche Stand: Die kommerziellen Spitzenmodelle sind beim Programmieren weiterhin besser. Der Abstand hat sich in den letzten zwei Jahren allerdings so verkleinert, dass er für die häufigsten Aufgaben nicht mehr ausschlaggebend ist.
- Testfälle zu vorhandenem Code schreiben
- Fehlermeldungen einordnen und die wahrscheinliche Ursache benennen
- Fremden Code erklären – die unterschätzteste Anwendung überhaupt
- Umbenennungen und Umstrukturierungen über mehrere Dateien
- Reguläre Ausdrücke schreiben, lesen und, wichtiger, kommentieren
Für das alles reicht ein Modell wie Qwen3.6 mit 35 Milliarden Parametern, von denen je Token nur rund drei rechnen. Es steht unter Apache 2.0, läuft auf einer einzelnen Karte und fasst mehrere Dateien gleichzeitig im Kontext.
Wo es nicht reicht
Bei Architekturentscheidungen über ein ganzes System, bei sehr großen Umbauten und bei Sprachen und Bibliotheken abseits der verbreiteten. Dort merkt man den Unterschied deutlich.
Die brauchbare Aufteilung ist deshalb keine Entweder-oder-Entscheidung: Was Kundendaten oder fremden Quelltext enthält, läuft auf eigener Hardware. Was rein intern und unkritisch ist, kann laufen, wo es am besten funktioniert. Diese Trennung kostet zwei Minuten Nachdenken je Aufgabe und löst das Problem vollständig.