Wisse genau, was du verschickst, was generierter Code rechtlich wert ist und wie die Verzerrungen der Modelle deine technischen Entscheidungen lenken.
Diese Lektion in Kodokon öffnenJeder Prompt ist eine Datenübermittlung an einen Dritten. Bevor du einen Assistenten beruflich einsetzt, müssen drei Fragen eine dokumentierte Antwort haben. Aufbewahrung: Wie lange behält der Anbieter deine Unterhaltungen, und wer kann darauf zugreifen (Support, Sicherheit, gerichtliche Anordnung)? Training: Werden deine Daten genutzt, um künftige Modelle zu trainieren, und ist der Widerspruch in deinem Konto aktiviert - Privatkundentarife und Unternehmenstarife unterscheiden sich in diesem Punkt fast immer? Vertrag: Erlauben dir dein Arbeitgeber oder deine Kunden, diesen Code zu übermitteln, wo doch die Vertraulichkeitsklauseln, die du unterschrieben hast, auch für einen Prompt gelten? Ein Code-Ausschnitt mag harmlos wirken; zusammen mit internen Domainnamen, Tabellenstrukturen und Fehlermeldungen mit vollständigen Pfaden beschreibt er dein Informationssystem.
Die gute Praxis heißt Minimierung: nur das zu senden, was für die Argumentation unbedingt nötig ist. Das ist eine Fähigkeit für sich - ein minimales, reproduzierbares Beispiel mit generischen Namen zu bauen - und sie hat einen unerwarteten pädagogischen Nutzen: Ein Problem zu isolieren, um es abstrakt zu beschreiben, zwingt dich, es zu verstehen. Der folgende Prompt macht aus dieser Vertraulichkeitsauflage eine Diagnoseübung.
Context: I'm working on proprietary code that I cannot share. I'll describe my problem abstractly, with generic names and without pasting the real code.
Description: [PSEUDO-CODE of the relevant structure, ERROR MESSAGE with paths and identifiers masked, VERSIONS of the libraries involved].
Your mission:
1. If my description is too vague to reason on, tell me exactly what information you're missing and why - I'll decide whether I can provide it in anonymized form.
2. Reason only on my description: never ask me to paste the full file.
3. Propose hypotheses for the cause, ranked by probability, and for each one a precise test I can run locally to confirm or rule it out.
Format: a table of hypothesis / probability / verification test. I'll come back with the test results.Zweites Dossier: die Lizenzierung von generiertem Code. Die Rechtslage ist nicht abschließend geklärt und unterscheidet sich je nach Rechtsraum, aber drei Tatsachen stehen fest. Erstens: Modelle werden auf Code unter ganz unterschiedlichen Lizenzen trainiert, darunter Copyleft-Lizenzen wie die GPL, und können Ausschnitte reproduzieren, die ihrer Quelle sehr nahe kommen - besonders bei berühmten Algorithmen oder vielfach kopierten Schnipseln. Zweitens: In mehreren Rechtsräumen ist eine rein maschinelle Ausgabe ohne menschlichen schöpferischen Beitrag urheberrechtlich kaum schützbar, was deine Ansprüche auf unverändert übernommenen Code untergräbt. Drittens: Manche Anbieter bieten eine vertragliche Freistellung für den Fall einer Verletzungsklage sowie Filter, die Ausgaben blockieren, die dem Korpus zu nahe kommen - prüfe, ob diese Schutzmaßnahmen in deinem Tarif enthalten sind und nicht nur im Prospekt stehen. In der Praxis gilt: Je länger, je spezifischer und je unbearbeiteter ein generierter Ausschnitt ist, desto höher das rechtliche Risiko.
Drittes Dossier: die Verzerrungen. Ein Modell gibt die statistischen Regelmäßigkeiten seines Korpus wieder, und drei Verzerrungen wirken sich unmittelbar auf deine technischen Entscheidungen aus. Die Popularitätsverzerrung: Lösungen, die in den Daten überrepräsentiert sind (vorherrschende Frameworks, Muster, die vor zwei Jahren angesagt waren), werden standardmäßig empfohlen, auch wenn dein Kontext etwas anderes verlangt - das Korpus hinkt dem Stand der Technik immer einen Schritt hinterher. Die Schmeichelverzerrung: Modelle sind darauf optimiert, dem Nutzer zu gefallen, und neigen dazu, deine Prämisse zu bestätigen; frag „warum ist mein Microservices-Ansatz der richtige?“ und du bekommst Bestätigungen, keine Gegenmeinung. Die umgekehrte Autoritätsverzerrung: Die Flüssigkeit des Tons erzeugt einen Eindruck von Sicherheit, der mit der Zuverlässigkeit nichts zu tun hat. Die Gegenmaßnahme ist prozedural: Erzwinge den Widerspruch.
You just recommended [SOLUTION OR TECHNOLOGY] to me. Before I decide, switch stance: you are now an experienced engineer tasked with arguing AGAINST this recommendation.
1. Give the 3 best arguments against your own answer, each illustrated by a concrete scenario where it fails.
2. Cite at least one serious alternative you hadn't mentioned, and explain honestly why it was absent from your first answer.
3. Assess how much your initial recommendation owes to the popularity of this solution in your training data, rather than to my specific context, which I'll remind you of: [YOUR CONTEXT: team size, constraints, existing setup].
Format: two columns For / Against, then your revised recommendation in one sentence, with your confidence level and what could change it.