Warum Prompt Engineering eigentlich Kon-Textarbeit ist.

«Prompt Engineering» klingt nach Ingenieurskunst. Nach Präzision, nach Code, nach etwas, das man studiert haben muss. Das Wort hat eine Abschreckungswirkung, die ich in Workshops immer wieder beobachte: Menschen, die hervorragend mit Sprache umgehen können, zweifeln an sich, weil sie annehmen, der Begriff bezeichne etwas Technisches, das sie nicht beherrschen.

Das ist ein Missverständnis. Und es kostet Organisationen täglich Zeit und Qualität.

Was das Modell wirklich braucht

Ein grosses Sprachmodell generiert seine Antworten nicht aus dem Nichts. Es berechnet, auf Basis statistischer Muster in riesigen Textmengen, was die wahrscheinlichste Fortsetzung einer Eingabe ist. Was diese Eingabe enthält und wie sie aufgebaut ist, bestimmt massgeblich, was herauskommt.

Der eigentliche Hebel ist nicht der einzelne Satz, den man tippt. Es ist der Kontext: alle Informationen, die dem Modell zur Verfügung stehen, bevor es antwortet. Wer ist der Absender? Was ist das Ziel? Welches Format, welcher Ton? Was darf das Modell annehmen, und was nicht?

Das ist keine Technik. Das ist Textarbeit. Genauer: Kon-Textarbeit.

Der Paradigmenwechsel: von Prompts zu Kontext

Andrej Karpathy, ehemaliger KI-Forschungsleiter bei Tesla und OpenAI, hat diesen Shift 2025 pointiert benannt:¹

Seine Analogie: Das Sprachmodell ist die CPU. Das Kontextfenster (der Informationsraum, den das Modell «sieht») ist der Arbeitsspeicher. Und wer professionell mit KI arbeitet, ist das Betriebssystem: zuständig dafür, was in diesen Arbeitsspeicher geladen wird.

Was dort hineinkommt, entscheidet über Qualität und Verwendbarkeit des Outputs, weit mehr als die Formulierung des einzelnen Satzes. Das hat praktische Konsequenzen: LLMs verarbeiten Informationen am Anfang und Ende eines Kontextfensters zuverlässiger als in der Mitte; dieses Phänomen bezeichnet die Forschung als «Serial Position Effect».² Wer das weiss, baut Eingaben entsprechend.

Was konkret in den Kontext gehört

Gut aufgebaute Eingaben für professionelle Anwendungen enthalten typischerweise mehrere Schichten: relevante Hintergrundinformationen, das gewünschte Format und den Ton, klare Einschränkungen sowie bei längeren Aufgaben den bisherigen Gesprächsverlauf.

Das klingt nach Common Sense. Und das ist es. Es ist die gleiche Sorgfalt, die man beim Briefen einer neuen Mitarbeiterin aufwendet. Oder beim Schreiben einer präzisen Aufgabenstellung. Der Unterschied: Hier ist das Gegenüber ein System, das ausschliesslich auf das reagiert, was im Eingabefeld steht: ohne geteilten Erfahrungshorizont, ohne Nachfragemöglichkeit, ohne Interpretation.

Es kommt auch auf das Modell an

Ein Punkt, der in der Praxis oft unterschätzt wird: Kontext-Arbeit ist nicht modellunabhängig. Dasselbe Prompt verhält sich je nach System unterschiedlich. Selbst innerhalb derselben Modellfamilie kann sich zwischen Versionen Relevantes ändern.

Ein aktuelles Beispiel: OpenAI hat im April 2026 GPT-5.5 veröffentlicht. Im Vergleich zu GPT-5.4 folgt das Modell Anweisungen deutlich wörtlicher: Es rät bei Unklarheiten nicht mehr, sondern fragt nach. Was bei einer früheren Version als hilfreiche Eigeninitiative durchging, produziert jetzt eine Rückfrage oder ein unerwartetes Ergebnis. OpenAI hat Entwicklerinnen und Entwickler explizit gewarnt, alte Prompts nicht zu übernehmen: «Begin with a fresh baseline instead of carrying over every instruction from an older prompt stack.»³

Auch zwischen verschiedenen Systemen gibt es strukturelle Unterschiede: Claude reagiert besonders zuverlässig auf klar gegliederte Eingaben mit XML-Tags. GPT bevorzugt kurze, ergebnisorientierte Anweisungen. Gemini profitiert von konkreten Beispielen, die zeigen, wie eine Antwort aussehen soll.⁴ Wer mit mehreren Modellen arbeitet oder ein Modell regelmässig wechselt, muss die eigenen Eingaben entsprechend anpassen.

Das bedeutet nicht, dass man für jedes System von Null anfangen muss. Die Grundlogik bleibt dieselbe: klarer Kontext, präzise Aufgabe, explizites Format. Aber das Feintuning ist modellspezifisch. Und wer das ignoriert, verliert ohne eigenes Zutun an Output-Qualität.

Warum Sprachkompetenz der eigentliche Vorteil ist

Es gibt einen Befund, den ich regelmässig in der Zusammenarbeit mit Unternehmen beobachte: Wer präzise schreiben kann, wer Sachverhalte strukturiert und Ziele klar formuliert, liefert bessere KI-Outputs als jemand, der technische Begriffe kennt, aber verschwommen kommuniziert.

Das ist kein Zufall. Sprachmodelle wurden auf menschlichen Texten trainiert. Sie reagieren auf Präzision, auf Struktur, auf Widerspruchsfreiheit: genau das, was gutes Schreiben auszeichnet. Die Forschung bestätigt, dass Outputs sich messbar verbessern, wenn Prompts klar gegliedert sind, wenn Ziel, Kontext und Format explizit benannt werden, und wenn Mehrdeutigkeiten vermieden werden.²

Was nicht hilft: vage Imperative wie «schreib mir etwas über X», fehlende Kontextangaben, oder die Annahme, das Modell verstehe implizit, was gemeint ist. Ein LLM hat keinen geteilten Erfahrungshorizont. Es hat nur das, was im Kontextfenster steht.

Was das für die Praxis bedeutet

In der Beratungsarbeit sehe ich regelmässig zwei Typen von KI-Einsatz: Den, bei dem jede Person das gleiche Tool benutzt und trotzdem vollkommen unterschiedliche, teils brauchbare, teils unbrauchbare Resultate erzielt. Und den, bei dem ein Team gemeinsame Eingabestandards entwickelt hat, die Qualität und Wiederholbarkeit sichern.

Der Unterschied zwischen beiden ist kein technischer. Es ist ein sprachlicher. Und er ist erlernbar.

Der erste Schritt: nicht fragen «Was soll ich schreiben?», sondern «Was muss das Modell wissen, damit die Antwort stimmt?» Das ist der Einstieg in Kontextarbeit. Er kostet keine Programmierkenntnisse, nur Sorgfalt.