PlagiatScanner.de

KI-Transparenz · Handlung · KIT-11

KI-generierten Code in der Thesis dokumentieren

Direktantwort: Dokumentieren Sie KI-unterstützten Code pro Datei oder Funktion: Ausgangsproblem, Werkzeug und sichtbare Version, wesentliche Eingabe, erhaltenen Vorschlag, eigene Änderungen, Herkunft externer Bestandteile und bestandene Tests. Ein Code-Provenienzblatt verbindet Entstehung und Prüfung. Es ersetzt weder die Lizenzprüfung noch den Nachweis, dass der Code die Forschungsfrage korrekt beantwortet oder in Ihrer Prüfung zulässig war.

Code-Provenienzblatt mit Testnachweis

Nachweis für eine KI-unterstützte Codeeinheit
Feld Eintrag
Bezug Repository, Datei, Funktion, Commit oder Version
Zweck Fachliches Problem und erwartetes Verhalten
KI-Nutzung Dienst, sichtbares Modell, Datum, Prompt-Referenz
Vorschlag Erzeugter oder geänderter Codeumfang
Eigenleistung Verworfene Teile, Umbauten, Architekturentscheidungen
Abhängigkeiten Bibliotheken, Versionen, Lizenzen und fremde Snippets
Test Testfall, Eingabe, erwartetes und tatsächliches Ergebnis
Grenzen Nicht geprüfte Plattformen, Datenbereiche oder Fehlerfälle

Füllen Sie ein Blatt für zusammenhängende Änderungen, nicht zwangsläufig für jede Codezeile. Entscheidend ist, dass eine prüfende Person den Beitrag lokalisieren und die Prüfung nachvollziehen kann.

Was genau als KI-Beitrag erfasst wird

Codeassistenz reicht von einer einzelnen regulären Expression bis zu ganzen Modulen. Beschreiben Sie nicht bloß „Programmierung mit KI“, sondern Funktion und Einfluss. Hat das System einen Algorithmus ausgewählt, nur Syntax vorgeschlagen, Tests formuliert, einen Fehler erklärt oder vorhandenen Code refaktoriert? Diese Rollen betreffen Eigenleistung und Fehlerrisiko unterschiedlich.

Sichern Sie den Zustand vor dem Vorschlag und den ersten erhaltenen Entwurf. In einer Versionsverwaltung lassen sich Änderungen als eigener Commit oder klar markierter Diff festhalten. Danach dokumentieren Sie Ihre Entscheidungen: Warum wurde eine Bibliothek ersetzt? Welche Randfallbehandlung kam hinzu? Welche generierte Annahme war falsch? Gerade verworfener Code zeigt, dass der Vorschlag geprüft und nicht als Autorität behandelt wurde.

  • Datei und Funktion statt nur Programmiersprache nennen.
  • Prompt so sichern, dass keine Secrets oder personenbezogenen Daten offengelegt werden.
  • Vom System behauptete APIs in offizieller Dokumentation prüfen.
  • Übernommene Abhängigkeiten und Lizenzhinweise erfassen.
  • Eigene Änderungen in einem Diff oder Änderungsprotokoll erklären.

Testnachweis statt „funktioniert bei mir“

Ein erfolgreicher Programmstart beweist wenig. Leiten Sie Tests aus dem fachlichen Zweck und bekannten Randfällen ab. Für eine Datenbereinigung gehören normale, fehlende, ungültige und extreme Werte dazu. Für eine Berechnung sollten einfache Fälle mit manuell nachvollziehbarem Ergebnis vorliegen. Bei zufallsabhängigem Code dokumentieren Sie Seed, Softwareumgebung und Toleranzen. Bei Nutzeroberflächen können Tastaturbedienung und Fehlermeldungen relevant sein.

Das Provenienzblatt nennt Testbefehl oder Vorgehen, Eingabe, erwartetes Ergebnis, tatsächliches Ergebnis und Datum. Ein fehlgeschlagener Test wird nicht gelöscht: Verknüpfen Sie ihn mit Korrektur und erneutem Lauf. Tests aus demselben KI-Dialog sind nützliche Kandidaten, aber keine unabhängige Bestätigung. Ergänzen Sie eigene Fälle aus Anforderungen, Literatur, Referenzdaten oder manueller Rechnung.

  1. Fachliche Invariante formulieren: Was muss immer gelten?
  2. Mindestens einen leicht nachrechenbaren Referenzfall wählen.
  3. Grenz- und Fehlerfälle aus realen Daten ableiten.
  4. Test in einer sauberen Umgebung wiederholen.
  5. Ausgabe, Version und offene Abdeckung dokumentieren.

Beispiel: Funktion zur Normalisierung von Messwerten

Ein System schlägt eine Funktion vor, die fehlende Werte entfernt und anschließend z-standardisiert. Die Studentin erkennt, dass das kommentarlos die Stichprobe verändert. Sie trennt die Entscheidung über fehlende Werte von der Transformation, ergänzt eine Prüfung auf konstante Spalten und lässt die Zahl ausgeschlossener Beobachtungen ausgeben. Der generierte Ausgangscode, der eigene Diff und zwei Referenzfälle werden gespeichert.

Im Methodenteil beschreibt sie die tatsächliche Behandlung fehlender Daten und die mathematische Transformation, nicht den Chat. In der Nutzungserklärung nennt sie die Codeassistenz und ihre Validierung. Im Provenienzblatt steht, dass Tests für leere, konstante und teilweise fehlende Spalten bestanden, während große Datensätze nicht auf Speicherverbrauch geprüft wurden. Diese Grenze ist informativer als ein pauschales Qualitätsversprechen.

Repository, Anhang und Nutzungserklärung abstimmen

Das Repository sollte eine README mit Ausführungsweg, Umgebung und Datenvoraussetzungen enthalten. Verlinken Sie Provenienzblätter auf stabile Commits oder Releases. Wenn der Code nicht öffentlich sein darf, kann ein archiviertes Abgabepaket innerhalb der zugelassenen Prüfungsumgebung dieselbe Funktion erfüllen. Veröffentlichen Sie keine Zugangsdaten, personenbezogenen Daten oder vertraulichen Prompts.

Prüfen Sie die konkreten Regeln Ihrer Einrichtung und die Lizenzen aller übernommenen Bestandteile. Eine Offenlegung macht unzulässige Hilfe nicht zulässig und ist keine Rechtsberatung.

Für den allgemeinen Wortlaut hilft das Muster der KI-Nutzungserklärung. Wie Software selbst dauerhaft zitiert wird, erklärt Code und Forschungssoftware zitieren. Der Hub KI-Transparenz verbindet Code-, Modell- und Promptnachweise. Als genau eine technische Grundlagenseite dient KI-Erkennung; sie kann einen Entwicklungsverlauf nicht feststellen.

Abschlusskontrolle

Können Sie jede zentrale Funktion erklären, ohne die KI-Antwort aufzurufen? Lässt sich der verwendete Codezustand eindeutig identifizieren? Decken Tests fachliche Anforderungen und Fehlersituationen ab? Sind bekannte Grenzen sichtbar? Stimmen Thesis, README, Repository und Erklärung überein? Sind fremde Bibliotheken, Daten und Snippets korrekt zugeordnet? Erst das Zusammenspiel dieser Antworten macht den Nachweis belastbar.

Praxisnotiz: negative Testfälle

Ein Provenienzblatt wird aussagekräftiger, wenn es nicht nur Erfolgspfade enthält. Notieren Sie Eingaben, die bewusst eine Fehlermeldung auslösen: falscher Datentyp, fehlende Spalte, leere Datei, unerlaubter Wert oder beschädigtes Format. Halten Sie fest, ob der Code kontrolliert abbricht, Daten still verändert oder irreführend Erfolg meldet. Verknüpfen Sie Fehler mit dem korrigierenden Commit und wiederholen Sie betroffene Tests nach späteren Änderungen. Damit zeigen Sie, dass Sie erwartetes Verhalten und Grenzen aktiv definiert haben.

Quellen

Quellenstand: 4. September 2026.