Das Prompt-Engineering-Playbook für Programmierer
(addyo.substack.com)- AI-Coding-Assistenten steigern die Produktivität von Entwicklern, aber die Qualität ihrer Ergebnisse hängt stark vom Prompt Engineering ab
- Um effektive Resultate zu erzielen, sollten Regeln wie reichhaltiger Kontext, konkrete Ziele, Beispiele, Rollenzuweisung und iterative Verbesserung beachtet werden
- Für wichtige Entwicklungsaufgaben wie Debugging, Refactoring und die Implementierung neuer Features werden Prompt-Design-Muster und Beispiele vorgestellt
- Gute Prompts sollten konkrete Informationen wie Ziel, Sprache, Umgebung, Fehlermeldungen sowie Eingabe-/Ausgabe-Beispiele enthalten
- Es handelt sich um eine Prompt-Design-Methode, der auch neue Engineers folgen können, einschließlich Vergleichen realer AI-Antworten und Kommentaren
Überblick: Warum erfolgreiches Prompt Engineering wichtig ist
- In letzter Zeit nutzen Entwickler AI-Coding-Assistenten, um Arbeitsabläufe zu beschleunigen – von der automatischen Vervollständigung von Funktionen über das Beheben von Bugs bis hin zum Schreiben ganzer Module
- Die Qualität der AI-Antworten wird jedoch entscheidend von der Qualität des Prompts bestimmt
- Gute Prompts führen zu klaren und kreativen Code-Lösungen, während vage oder schwache Prompts nur eingeschränkte und wenig hilfreiche Antworten liefern
- Dieses Playbook fasst effektive Methoden zum Entwerfen von Prompts für alltägliche Entwicklungsaufgaben praxisnah zusammen
Grundprinzipien effektiver Code-Prompts
- Reichhaltigen Kontext bereitstellen: Da die AI das Projekt oder die Absicht nicht im Voraus kennt, sollten alle relevanten Informationen wie verwendete Sprache, Framework, Bibliotheken, Fehlermeldungen und der Zweck des Codes ausdrücklich genannt werden
- Klare Ziele oder Fragen formulieren: Statt einer vagen Frage wie „Warum funktioniert der Code nicht?“ sollten das gewünschte Ergebnis und die aktuelle Situation klar beschrieben werden
- Komplexe Aufgaben aufteilen: Größere Vorhaben wie die Entwicklung umfangreicher Features sollten nicht auf einmal angefragt, sondern in kleinere Schritte zerlegt und schrittweise bearbeitet werden
- Ein-/Ausgabe-Beispiele oder erwartetes Verhalten angeben: Konkrete Beispiele für Eingaben, Ausgaben oder Verhalten verbessern das Verständnis der AI erheblich („few-shot prompting“)
- Rollen (Persona) nutzen: Durch Rollenzuweisungen wie „Prüfe den Code wie ein Senior-React-Entwickler“ oder „Optimiere wie ein Performance-Spezialist“ lässt sich das Niveau der AI-Antworten anheben
- Gesprächsbasierte iterative Verbesserung: Auf Basis der ersten AI-Antwort kann man durch zusätzliche Anfragen oder Korrekturwünsche schrittweise zum gewünschten Ergebnis gelangen
- Code-Konsistenz wahren: Da die AI Code-Stil, Benennungen und Kommentare aufgreift, sollte der Code stets konsistent und klar gehalten werden
Prompt-Muster für Debugging
Systematisches Design von Debugging-Prompts
- Problem und Symptome klar beschreiben: Umfangreiche Informationen wie Sprache, Zweck der Funktion, erwartetes Verhalten, tatsächliche Fehlermeldung und Code-Snippets bereitstellen
- Schrittweise oder zeilenweise Analyse anfordern: Bei Logikfehlern oder subtilen Bugs sollte man etwa um „Verfolgung der Variablen Zeile für Zeile“ oder um die Erklärung einzelner Code-Teile bitten, um die Ursache zu finden
- Minimal reproduzierbaren Code verwenden: Statt komplexen, großen Code zu übergeben, sollte die kleinste Code-Einheit extrahiert werden, in der der Fehler auftritt, damit die Diagnose gezielt erfolgen kann
- Direkte Fragen und Folgeanfragen stellen: Klare und wiederholbare Rückfragen wie „Wo tritt der Bug auf?“ oder „Gib den korrigierten Code an“ helfen bei präzisem Feedback
Beispiel: schlechter Prompt vs. verbesserter Prompt
Beispiel für problematischen Code
function mapUsersById(users) {
const userMap = {};
for (let i = 0; i <= users.length; i++) {
const user = users[i];
userMap[user.id] = user;
}
return userMap;
}
const result = mapUsersById([{ id: 1, name: "Alice" }]);
Schlechter Prompt:
„Warum funktioniert die Funktion mapUsersById nicht?“
- AI-Antwort: Vage Vermutungen wie „Das Array könnte leer sein“ oder „user hat möglicherweise keine id“
- Wegen fehlendem Kontext und Unklarheit kommen nur allgemeine Ratschläge heraus
Verbesserter Prompt:
„Die Funktion mapUsersById soll ein Benutzer-Array nach id abbilden, aber bei der Eingabe [ {id: 1, name: "Alice"} ] tritt der Fehler TypeError: Cannot read property 'id' of undefined auf. Der Code lautet wie folgt: [Code enthalten]. Das erwartete Ergebnis ist { "1": ... }. Was ist die Ursache dieses Verhaltens und wie lässt es sich beheben?“
- AI-Antwort: Sie weist darauf hin, dass die Bedingung der Schleife (
i <= users.length) den Bereich überschreitet und im letzten Durchlaufundefinedentsteht, und schlägti < users.lengthals Korrektur vor - Durch konkreten Kontext, Fehlermeldung und erwartetes Verhalten wird eine präzise Lösung möglich
Weitere Debugging-Prompt-Strategien
- Um eine Liste möglicher Bug-Ursachen bitten („Was sind mögliche Ursachen für diesen TypeError?“)
- Die eigene Erklärung der Code-Logik direkt schildern und prüfen lassen („Ist meine Erklärung korrekt, und wo liegt das Problem?“)
- Testfälle für Randfälle anfordern („Schlage nur 2 Eingaben vor, bei denen diese Funktion fehlschlagen könnte“)
- Eine gründliche Code-Reviewer-Rolle zuweisen („Prüfe diesen Code und erkläre Probleme sowie Verbesserungsmöglichkeiten“)
Prompt-Muster für Refactoring/Optimierung
Klare Verbesserungsziele formulieren
- Eine Anweisung wie „Refaktoriere das“ ist zu vage; stattdessen sollten konkrete Ziele wie Lesbarkeit, Performance, Wartbarkeit oder die Beseitigung von Code-Duplikaten genannt werden
- Den gesamten Code (oder den nötigen Kontext) sowie Umgebung, Sprache und Framework-Version ausreichend bereitstellen
- Auch eine Erklärung der Änderungen anfordern („Zeig mir den Code zusammen mit den Verbesserungspunkten“)
- Durch Rollenzuweisung wie „als TypeScript-Experte nach aktuellen Best Practices“ lässt sich die erwartete Qualität erhöhen
Beispiel: Vergleich von Refactoring-Prompts
Originalcode
(enthält Probleme wie doppeltes Fetching, ineffiziente Datenstrukturen usw.)
async function getCombinedData(apiClient) {
// Fetch list of users
const usersResponse = await apiClient.fetch('/users');
if (!usersResponse.ok) {
throw new Error('Failed to fetch users');
}
// ... (im Folgenden ausgelassen)
}
Vager Prompt
„Refaktoriere die Funktion getCombinedData“
- Die AI ändert möglicherweise eigenmächtig Dinge wie paralleles Fetching oder das Zusammenführen von Fehlermeldungen (das Verhalten ist ohne Anforderungen schwer vorhersehbar)
Prompt mit konkreten Zielen
„Beseitige Duplikate, verbessere die Performance, führe die beiden Fetches parallel aus, trenne die Fehlermeldungen und verbessere die Datenzusammenführung mit einer effizienten Methode. Bitte auch Kommentare und eine Erklärung der Verbesserungspunkte hinzufügen.“
- AI-Antwort: Liefert ein Refactoring, das die Ziele klar widerspiegelt, etwa mit parallelem Fetching, getrennten Fehlern und einer effizienten
map-Datenstruktur, plus ausführlicher Erklärung
Weitere Refactoring-Tipps
- Schrittweise anfragen („Zuerst Lesbarkeit verbessern, dann den Algorithmus optimieren“)
- Alternative Ansätze verlangen („Implementiere es auch in funktionalem Stil“)
- Durch die Kombination aus Code und Erklärung Lerneffekt und Tutorial-Charakter erhöhen
- Zusätzliche Tests für den resultierenden Code anfordern
Prompt-Muster für die Implementierung neuer Features
Schrittweise Code-Generierung anstoßen
- Zuerst eine Beschreibung auf hoher Ebene geben, also welches Feature gebaut werden soll, und danach schrittweise weiter verfeinern
- Kontext zur Arbeitsumgebung mitgeben, etwa ähnlichen bestehenden Code, Projektmuster oder verwendete Bibliotheken
- Kommentare oder TODOs als Prompt nutzen, um den AI-Coding-Flow direkt in der IDE zu steuern
- Ein-/Ausgabe-Beispiele oder Testfälle angeben, damit die erwarteten Resultate klar sind
- Falls das erste Ergebnis unzureichend ist, sofort konkrete Verbesserungen oder einen gewünschten Code-Stil ergänzen und erneut anfragen
Beispiel: Erstellen einer React-ProductList-Komponente
„Erstelle eine funktionale React-Komponente namens ProductList. Sie soll ein Produkt-Array von /api/products laden und als Liste ausgeben. Wenn im Eingabefeld ein Produktname eingegeben wird, soll ohne Berücksichtigung der Groß-/Kleinschreibung gefiltert werden. Außerdem werden Ladezustand und Fehlerbehandlung beim Abrufen benötigt.“
- AI-Antwort: Enthält u. a. Daten-Fetching mit
useStateunduseEffect, Verarbeitung der Eingabe, Filterung sowie UI für Fehler- und Ladezustand - Wenn im Projekt benutzerdefinierte Hooks verwendet werden, kann anschließend wiederholt eine Zusatzanweisung folgen wie „Refaktoriere es so, dass der Hook
useProducts()verwendet wird“
Praxisnahe Beispiele zur Verfeinerung von Prompts
- Eine schrittweise Feature-Erweiterung ist möglich, z. B. „Füge eine Sortierfunktion hinzu: Es soll ein A-Z-/Z-A-Dropdown geben“
- Der Implementierungsfluss kann in einzelne Schritte zerlegt werden, wobei pro Schritt unterschiedliche Prompts verwendet werden, um Code-Qualität und Konsistenz zu sichern
Fazit
- Um das Potenzial von AI-Coding-Assistenten maximal auszuschöpfen, ist Prompt-Design eine Schlüsselkompetenz
- Für erfolgreiche Prompts sollten stets konkreter Kontext, Zielsetzung, Beispiele, iteratives Feedback und Rollenzuweisung berücksichtigt werden, um wirksame Ergebnisse zu erzielen
- Wer die AI im Projekt wie einen Junior-Entwickler oder Code Reviewer behandelt, sie also detailliert anleitet und die Qualität schrittweise verbessert, hat den Schlüssel zum Erfolg
1 Kommentare
Hacker-News-Kommentare
Meiner Erfahrung nach gibt es eigentlich nur drei echte Prompt-Engineering-Techniken
In Context Learning (Beispiele innerhalb des Kontexts bereitstellen, also one-shot- oder few-shot-Ansätze im Gegensatz zu zero-shot)
Chain of Thought (anweisen, Schritt für Schritt zu denken)
Structured Output (zum Beispiel das Ausgabeformat wie JSON klar festlegen)
Dazu könnte man wohl noch das in diesem Artikel erwähnte Role Prompting zählen
RAG ordne ich separat ein, weil das Modell dabei den bereitgestellten Kontext zusammenfasst
Am Ende ist der Rest im Grunde nur eine Zusammenfassung davon, wie man in klarer, einfacher Sprache sagt, was man will
Beim Prompt ist der Kontext der wichtigste Faktor
Ich habe zum Beispiel beobachtet, dass ein Modell schlecht antwortet, wenn man mit Typescript anfängt und dann eine Data-Science-Frage stellt
Stellt man exakt dieselbe Frage mit Python als Kontext, kommt eine deutlich bessere Antwort
LLMs tun sich noch immer schwer mit Wissensübertragung zwischen Domänen, deshalb ist ein zum Ziel passender Kontext extrem wichtig
Auch Role Prompting halte ich persönlich für ziemlich sinnlos
Vielleicht war das bei GPT-3 noch anders, aber die meisten LLMs kennen die Rolle des „Experten“ ohnehin schon
Sich zu sehr in „Prompt Engineering“ hineinzusteigern, ist für mich eine Form von Selbsttäuschung
Anforderungen klar kommunizieren, falls nötig Beispiele hinzufügen, das Ergebnis oder den reasoning trace prüfen und bei unpassenden Resultaten nachjustieren und erneut versuchen
Wenn nach mehreren Versuchen noch immer nichts Vernünftiges herauskommt, denke ich lieber selbst über das Problem nach statt mit der AI weiterzumachen
Viele meinen, das eigentliche Problem sei der Versuch, „alles auf einmal in einen einzigen Prompt zu packen“
Statt einen riesigen Request in einem Stück abzuschicken, sollte man ihn lieber in mehrere Prompts mit kleinem Kontext zerlegen und deren klar strukturierte Ausgaben miteinander verbinden
Jeder einzelne Prompt sollte sich auf Ziel und Beispiele konzentrieren, damit es nicht zu Kontext-Überladung kommt
Dann kommen die drei oben genannten Kernmethoden ganz natürlich zur Anwendung
Zum dritten Ansatz (Structured Output) haben meine Kollegen und ich eine Anwendungsfallstudie im wissenschaftlichen Bereich gemacht
Link zum Paper
Zur Einordnung: Unser Team verlässt sich eher auf Fine-Tuning als auf Prompt Engineering
Der few-shot-Prompt-Ansatz hat in unserem Fall nicht funktioniert
Ich habe oft den Eindruck, dass die kognitive Leistung des Modells eher sinkt, wenn Prompts zu lang oder zu kompliziert werden
Komplexe Prompts können zwar das Gefühl vermitteln, mehr Kontrolle zu geben, aber das muss in der Praxis kein Vorteil sein
Deshalb konvergiert mein Nutzungsverhalten ganz natürlich zu sehr einfachen, minimalistischen Prompts, die ich dann iterativ anpasse
Ich habe auch angefangen, genau so vorzugehen
Das ist auch kosteneffizienter
Ich habe zu oft erlebt, dass ich mit einem Agent jedes Mal $30 verbrannt habe und am Ende die Codebase verheddert war oder wieder beim ursprünglichen Code landete
Ich möchte außerdem davor warnen, AI zu viel Code für das eigene Projekt schreiben zu lassen, weil einem dieser Code später oft nicht wirklich im Kopf bleibt und schwerer zu warten ist
Es gibt auch Hinweise darauf, dass Prompts besser funktionieren, wenn man Fachterminologie verwendet
Im Allgemeinen sinkt die Genauigkeit in Umgebungen, in denen in Alltagssprache gesprochen wird, während Vokabular aus spezifischen Fachgebieten zu zuverlässigeren Antworten führt
Die Trainingsdaten spiegeln diese Verteilung ebenfalls wider
Ich habe ähnliche Erfahrungen gemacht
Wenn ich mir aber die System Prompts von Agenten anschaue, sind die oft extrem lang und komplex, was bei mir Fragen aufwirft
Ich frage mich, wie solche Prompts in der Praxis eigentlich funktionieren
Beispiellink für System Prompts
Bei einer Aufgabe hat mein Kollege einen extrem ausschweifenden Prompt verwendet
Während der Integration kam noch eine CRUD operation dazu, und aus Neugier habe ich das auf etwas sehr Kurzes reduziert wie „Analysiere das aus Sicht von <Berufsrolle>“
Im Ergebnis waren beide Ausgaben fast gleich, und der lange Prompt führte sogar eher dazu, dass einzelne Sätze wörtlich in der Ausgabe wiederverwendet wurden
Das Resultat selbst war in Ordnung, aber am Ende scheint das Modell (gemini 2.5) nur die wichtigen Informationen herauszuziehen und den restlichen unnötigen Ballast trotzdem in die Ausgabe einfließen zu lassen
Zumindest bei dieser Aufgabe hatte ich also nicht den Eindruck, dass Ausführlichkeit einen interessanten Einfluss auf die „Denkweise“ des Modells hatte
Ich bin zum selben Schluss gekommen, frage mich aber weiterhin, wie man die Beispiele für lange Prompts interpretieren soll, die AI-Labore selbst veröffentlichen
Anthropic-Beispiel für System Prompts
Ich glaube nicht, dass es so etwas wie „Prompt Engineering“ als eigenständige Sache überhaupt gibt
Seit wann ist das Schreiben sinnvoller Sätze plötzlich Engineering?
Fast noch absurder als „Software Engineering“
Bedauerlich ist nur, dass daraus in Zukunft vielleicht tatsächlich ein Beruf wird (Prompt Engineer) und es als besondere Fähigkeit gilt, Sätze formulieren zu können
Tatsächlich hängen „sinnvolle Sätze“ von unzähligen Variablen ab
Wenn man Tests, Management, Logging und Versionsverwaltung einbezieht, wird daraus eben doch Engineering und nicht bloß Intuition
Struktur wie bestimmte Reihenfolgen, Stil oder das erneute Formulieren des Problems ist dabei sehr wichtig
Wenn man mit Modellfamilien mit vielen Parametern arbeitet, muss man bei API-basierten Modellen mit jedem Versionsupdate die Kompatibilität zu bestehenden Prompts prüfen
Solche Checks und Tests gehören ebenfalls zum Prompt Engineering
Ich habe oft den Eindruck, dass Leute aus Abneigung gegen Trends oder Hype das Wesentliche übersehen
Wenn der Barista in meiner Gegend „Kaffeeingenieur“ hinter seinen Namen schreiben würde, würde das fast noch vertrauenswürdiger klingen
Der Einfluss algorithmischer Abhängigkeit ist wohl, dass heutige Konsumenten nicht einmal mehr ganze Sätze lesen können
Ich glaube nicht, dass man sich um Stellenausschreibungen für „Prompt Engineers“ Sorgen machen muss
AI sloperators geben sich alle Mühe, ihre Arbeit wichtiger aussehen zu lassen
Meiner Erfahrung nach bringt selbst das beste Prompt-„Engineering“ oft nichts, wenn ein LLM ein Problem grundsätzlich nicht lösen kann
Dann bleibt meist nur, es in Teilprobleme zu zerlegen und Schritt für Schritt vorzugehen
Falls jemand gegenteilige Erfahrungen gemacht hat, würde ich gern Beispiele hören
Ein wichtiger Teil der LLM-Nutzung ist ein Gespür dafür, wie man Probleme sinnvoll zerlegt
Man braucht ein Urteilsvermögen dafür, wann und wie man etwas aufteilt und wann man es einfach komplett dem Modell überlassen kann
Wie auch im Artikel erwähnt, ist genau dieses Know-how entscheidend
In Zukunft wird es wohl auch mehr Methoden geben, Code besser zu organisieren und zu kommentieren, um die Interaktion mit LLMs zu verbessern
Die LLMs selbst werden sich in genau diese Richtung weiterentwickeln und vielleicht sogar Vorschläge machen können, wie ein Problem zu zerlegen ist
Das Ziel von Prompt Engineering ist, schneller gute Lösungen im gewünschten Format zu bekommen
Im Idealfall sollte das Modell einfach von selbst die richtige Antwort liefern, aber realistisch gesehen muss man eben auch die Frage selbst optimieren
Beim Schreiben von Prompts fühlt es sich wegen meiner Gewohnheiten immer noch etwas seltsam an, in natürlicher Sprache Anweisungen zu geben
Ich habe das Gefühl, ich müsste eher exakte Argumente oder etwas wie eine SQL query schreiben
Es ist auch irgendwie erstaunlich, einem Tool so zu schreiben, als würde man chatten
Trotzdem hat die Fähigkeit solcher Tools, Anweisungen in natürlicher Sprache zu verstehen, die Zugänglichkeit drastisch erhöht
Und trotzdem finde ich es manchmal ein bisschen albern, dass ich Prompts formuliere, als würde ich mit einem Menschen reden
In letzter Zeit gibt es unglaublich viele Prompt-Guides
Ich glaube aber nicht, dass man sie in der Praxis besonders braucht
Wenn man das Tool einfach selbst benutzt, sich damit vertraut macht und lernt, wie es funktioniert, entwickelt man ganz natürlich ein Gefühl dafür, was ein guter Prompt ist
Das erinnert mich an die Zeit, als Google groß wurde und überall FOMO herrschte
Damals hieß es, wer die entsprechenden Bücher nicht kaufe, bleibe wie ein Höhlenmensch zurück, dabei war das Ganze in Wirklichkeit ein so simples Gebiet, dass man es an einem Tag lernen konnte, ohne groß darüber nachdenken zu müssen
Guides und Tipp-Videos helfen manchen Leuten ganz sicher wirklich
Viele sind nicht besonders motiviert, sich selbst zu verbessern, aber schon ein einziges Guide oder das Video eines Profis kann ihre Fähigkeiten deutlich steigern
Ich selbst lerne auch immer wieder Tipps aus der Arbeitsweise anderer oder aus Community-Erfahrungen
Solche Hinweise bekommt man beim Üben allein eben nur begrenzt
Früher gab es wie bei „Guides zum Schreiben von User Stories“ die Formel „As a [role], I want to [task] so I can [objective]“
Sowohl Könner als auch Anfänger brauchen meist Hilfe dabei, Anforderungen klar zu kommunizieren
Selbst hervorragende Entwickler können bei unstrukturierten Anforderungen Fehler machen oder Dinge missverstehen
Es ist auch ziemlich nützlich zu sehen, wie andere mit diesem Tool produktiv werden
Dabei entdeckt man Ideen, die man selbst übersehen hat
Es ist effizienter, zumindest ein bisschen von Erfahrungen zu lernen, die andere bereits gemacht haben, statt alles per Trial-and-Error selbst auszuprobieren
Für jemanden wie mich, der nicht die Zeit hat, alles eigenhändig durchzutesten, sind solche geteilten Erfahrungen wirklich wertvoll
Es gibt definitiv auch weniger offensichtliche Tricks
Zum Beispiel die Erfahrung, dass man Höflichkeitsfloskeln wie „please“ im Prompt komplett weglassen kann
Schon vor langer Zeit im Informatik-Master habe ich im Kurs über Science of programming Verifikationsverfahren gelernt, die ich heute gut beim Schreiben von Data-Engineering-Prompts anwenden kann
Zum Beispiel kann man „mit input(…) und Voraussetzungen(…) Spark-Code erzeugen lassen, der post-condition(…) erfüllt“
Wenn Eingaben, Voraussetzungen und Ergebnisbedingungen klar spezifiziert sind, kann das Modell guten Code ausgeben
Empfohlene Lehrbücher
Ich finde, um Prompt Engineering wird zu viel Aufhebens gemacht
Heutzutage können die meisten Modelle einfach Code oder Fehlermeldungen verarbeiten, die man hineinkopiert, und mit einer schlichten Frage schon ziemlich gut umgehen
Ich sehe keinen Bedarf, das unnötig kompliziert zu formulieren
Vor ein paar Tagen sagte Sergey Brin über eine in AI-Communities selten erwähnte Tatsache, dass Modelle besser funktionieren, wenn man ihnen physisch droht
Passender Artikel
Das erinnert mich an den Scherz eines professionell wirkenden vibe coders auf YouTube („Programmers are also human“), der an jedes LLM-Kommando immer „.. oder du kommst ins Gefängnis“ anhängt
Vielleicht hat Google deshalb „Don't Be Evil“ still und leise aufgegeben
Prompt-Schreiben als „Engineering“ zu bezeichnen, wirkt auf mich überhaupt nicht besonders ernstzunehmend
Als der Hype um Prompt „Engineering“ aufkam, habe ich mal einen witzigen Vergleich gehört
Im Grunde ist das dieselbe Debatte, die bei Software Engineering immer wieder aufkommt
Vielleicht liegt es auch daran, dass die Vorstellungskraft vieler Leute beim Anfordern von Katzenbildern in einem Chat-Interface stehenbleibt
In Wirklichkeit gibt es aber auch Prompts für APIs und automatisierte Workflows, also geht es um weit mehr als das
In den USA gibt es auch den Titel „sales engineer“, und meiner Erfahrung nach wissen solche Leute oft überhaupt nicht, wie das von ihnen verkaufte Produkt eigentlich funktioniert
IT ist ein Ort, an dem Wörter und ihre Bedeutungen verschwinden
Man fragt sich irgendwann, ob Wörter überhaupt noch ihre ursprüngliche Bedeutung behalten müssen