November 2023. OpenAI hat die Function-Calling-API mit stabilem Support gestartet, und ohne formelle Ankündigung begann der Niedergang des “Prompt Engineers”. Nicht weil Prompts aufgehört hätten zu zählen, sondern weil sie aufgehört hatten, das Wichtigste zu sein.
Bei Soamee bauen wir seit Jahren Produkte mit LLMs. Wir haben die Phase der magischen Prompts durchgemacht, den blinden Glauben, dass die perfekte Formulierung der Nachricht das Geheimnis des Erfolgs sei. Und wir haben gelernt, manchmal auf schmerzhafte Weise, dass dieser Glaube falsch war.
Dieser Artikel ist meine direkte Meinung dazu, was passiert ist, warum Prompt Engineering als isolierte Disziplin tot ist, und was in KI-Produkten 2026 wirklich den Unterschied macht.
Die Ära der magischen Prompts (2022-2024)
Als GPT-3 zum Mainstream wurde und GPT-4 es popularisierte, spaltete sich die Tech-Welt in zwei Gruppen: Skeptiker, die dachten, es sei alles Rauch, und Enthusiasten, die glaubten, das ultimative Orakel gefunden zu haben. Die Enthusiasten hatten in einer Sache recht: LLMs waren genuinen leistungsfähig. Aber sie zogen die falsche Schlussfolgerung darüber, warum sie funktionierten.
Die dominierende Erzählung lautete: “Der Schlüssel liegt darin, zu wissen, wie man mit dem Modell spricht.” Es entstanden “Prompt Engineering”-Kurse für Hunderte von Dollar. Es erschienen Repositories mit Tausenden von Sternen voller “definitiver Prompts”. LinkedIn füllte sich mit Profilen, die sich selbst als “Prompt Engineer” bezeichneten, als wäre es der Beruf der Zukunft.
Das Problem war nicht, dass Prompts nicht zählten. Das Problem war die Schlussfolgerung, die gezogen wurde: dass der Unterschied zwischen einem exzellenten KI-Produkt und einem mittelmäßigen darin lag, die richtige Formulierung der Nachricht gefunden zu haben. Dass es magische Prompts gab, die darauf warteten, entdeckt zu werden.
Diese Idee war falsch. Und es dauerte 18 bis 24 Monate, bis der Markt das erkannte.
Was Prompt Engineering getötet hat
1. Structured Outputs haben Format-Prompts obsolet gemacht
Jahre lang war ein wichtiger Teil der “Prompt Engineering”-Arbeit, das Modell dazu zu bringen, im richtigen Format zu antworten. Man bat um JSON und bekam manchmal JSON, manchmal Text mit JSON darin, manchmal etwas, das wie JSON aussah, aber keines war. Es gab ganze Bibliotheken, die sich dem Parsen und Korrigieren von Modellausgaben widmeten.
Heute unterstützen OpenAI, Anthropic und Google nativ Structured Outputs: Man definiert ein JSON-Schema und das Modell garantiert, dass seine Antwort diesem Schema entspricht. Keine Magie, keine perfekte Formulierung. Ein technischer Vertrag.
# Vorher: beten, dass das Modell in JSON antwortet
response = client.messages.create(
model="claude-3-5-sonnet",
messages=[{"role": "user", "content": "Extrahiere Name und E-Mail. Antworte NUR in JSON mit den Feldern 'name' und 'email'. Kein zusätzlicher Text."}]
)
# Ergebnis: unvorhersehbar
# Jetzt: den Vertrag definieren
class ExtractedContact(BaseModel):
name: str
email: str
response = instructor.from_anthropic(client).messages.create(
model="claude-3-5-sonnet",
response_model=ExtractedContact,
messages=[{"role": "user", "content": "Extrahiere den Kontakt aus dem Text"}]
)
# Ergebnis: garantiertDer Format-Prompt ist tot. Das Engineering hat ihn getötet.
2. Tool Use hat Action-Prompts obsolet gemacht
Der zweite große Pfeiler des Prompt Engineerings war es, das Modell dazu zu bringen, die richtigen Entscheidungen zu treffen: “Wenn der Nutzer X fragt, tue Y. Wenn er Z fragt, tue W.” Prompts mit Bedingungen, in natürlicher Sprache geschriebene Entscheidungsbäume.
Function Calling hat das elegant ersetzt. Anstatt zu versuchen, dass das Modell Geschäftslogik durch Text simuliert, gibt man ihm echte Tools und lässt es entscheiden, wann es sie verwendet. Das Modell ist gut darin, Entscheidungen auf hoher Ebene zu treffen; Code ist gut darin, Aktionen präzise auszuführen.
tools = [
{
"name": "bestellung_suchen",
"description": "Sucht eine Bestellung nach ID oder Kunden-E-Mail",
"input_schema": {
"type": "object",
"properties": {
"query": {"type": "string"},
"typ": {"enum": ["id", "email"]}
}
}
},
{
"name": "status_aktualisieren",
"description": "Aktualisiert den Status einer Bestellung",
"input_schema": {
"type": "object",
"properties": {
"bestellung_id": {"type": "string"},
"neuer_status": {"enum": ["in_bearbeitung", "versendet", "storniert"]}
}
}
}
]Man muss nicht schreiben: “Wenn der Nutzer eine Bestellnummer erwähnt, suche sie zuerst, bevor du antwortest.” Das Modell schließt es aus dem Tool-Kontext. Was einmal ein Absatz mit Anweisungen im Prompt war, ist jetzt eine Funktionsdefinition.
3. Context Engineering ist wichtiger als die Prompt-Formulierung
Hier ist die Erkenntnis, die unsere Branche am meisten gekostet hat zu verinnerlichen: Was man in den Kontext einspeist, ist viel wichtiger als die Formulierung der Frage.
Man kann den elegantesten Prompt der Welt haben, aber wenn das Modell keinen Zugang zu den relevanten Informationen hat, wird es halluzinieren oder generische Antworten geben. Und man kann einen grundlegenden, fast telegrafischen Prompt haben, aber wenn man dem Modell die richtigen Informationen gibt, wird es gut abschneiden.
Context Engineering ist die Disziplin, zu gestalten, was das Modell erhält, bevor es antwortet:
- Gut implementiertes RAG: Nicht nur Embeddings und Cosine Similarity. Auswahl relevanter Chunks, Reranking, Filterung nach Metadaten, ausreichend Kontext ohne das Limit zu überschreiten.
- Dynamische Few-Shot-Beispiele: Keine statischen Beispiele im Prompt. Dynamisch ausgewählte Beispiele basierend auf der aktuellen Anfrage.
- Verwaltung des Gesprächskontexts: Welche vorherigen Gesprächsrunden beizubehalten sind, welche zu komprimieren, welche zu verwerfen.
- Strukturierte Daten vs. Text: Manchmal ist es besser, dem Modell eine gut formatierte Tabelle zu geben als einen Absatz, der die Daten erklärt.
In unseren Projekten sind 80% der Qualitätsverbesserungen durch Verbesserung des Kontexts entstanden, nicht durch Umschreiben des Prompts.
4. Evaluation hat das Bauchgefühl ersetzt
Klassisches Prompt Engineering war grundlegend intuitionsgesteuert. Man probierte eine Variation, sie schien besser, man veröffentlichte sie. Es gab keine rigorose Möglichkeit zu messen, ob sie wirklich in allen Fällen besser war oder nur in den manuell getesteten.
Die Reife des Feldes hat Evals gebracht: Mengen von Testfällen mit expliziten Bewertungskriterien, oft von einem anderen LLM bewertet. Frameworks wie RAGAS, LangSmith, Braintrust oder PromptFoo ermöglichen dies systematisch.
Wenn man Evals hat, kann man das tun, was man mit Code machte: vor dem Ändern messen, Versionen vergleichen, Regressionen erkennen. Der Prompt hört auf, ein handwerkliches Artefakt zu sein, das niemand aus Angst, etwas zu brechen, anfasst, und wird zu versioniertem Code mit Tests.
Das verändert die Natur der Arbeit. Es ist keine Intuition, es ist Engineering.
Was Prompt Engineering ersetzt hat: LLM Engineering
Was entsteht, ist kein weiterentwickeltes Prompt Engineering. Es ist eine völlig andere Disziplin, die sich den Namen vom Software Engineering leiht, weil das im Wesentlichen ist, was es ist.
LLM Engineering behandelt das Sprachmodell als einen weiteren Systemkomponenten: mit definierten Schnittstellen, Datenverträgen, automatisierten Tests, Observability und Continuous Deployment. Der Prompt ist eine versionierte Konfigurationsdatei in Git, kein Text, der in einer Umgebungsvariable gespeichert ist und nur vom Team-Experten angefasst wird.
Die Säulen dieser Disziplin:
System Prompts als Software-Spezifikationen: In Git versioniert, in Pull Requests überprüft, mit Regressionstests. Wenn jemand den System Prompt ändert, führt die CI-Pipeline die Evals aus und blockiert den Merge, wenn die Qualität sinkt.
Structured Outputs als API-Verträge: Das Modell ist ein interner Service mit einer definierten Schnittstelle. Was es zurückgibt, hat ein Schema. Der Rest des Systems vertraut diesem Schema, nicht dem Parsen von freiem Text.
Tool Use als Agenten-Architektur: Anstatt zu versuchen, dass das Modell alles macht, gibt man ihm spezialisierte Tools und lässt es orchestrieren. Geschäftslogik lebt in den Tools (testbarer Code), nicht im Prompt.
Observability und Rückverfolgbarkeit: Jeder Modellaufruf wird mit seinem vollständigen Kontext, verwendeten Tokens, Latenz und Ergebnis protokolliert. Wenn in der Produktion etwas fehlschlägt, gibt es einen Trace, der genau sagt, was passiert ist.
Evals als CI/CD für Prompts: Bevor eine Änderung am System Prompt oder an der RAG-Architektur deployiert wird, führt man die Eval-Suite aus. Wenn der Score sinkt, wird nicht deployiert.
Wo Prompting noch wichtig ist
Es wäre unehrlich zu sagen, dass Prompts überhaupt nicht wichtig sind. Das sind sie. Aber in spezifischen Kontexten:
Kreative Aufgaben: Wenn man möchte, dass das Modell Text mit einem bestimmten Stil generiert, bleibt die Formulierung des Prompts eine Kunst. “Schreibe im Stil eines Economist-Journalisten, der über Technologie berichtet” erzeugt andere Ergebnisse als “Schreibe einen Artikel über Technologie”. Hier zählt die sprachliche Nuance.
Schnelles Prototyping: Wenn man eine Idee in wenigen Stunden validiert, macht es keinen Sinn, die gesamte Eval-Infrastruktur und Structured Outputs aufzubauen. Ein gut formulierter Prompt in Cursor oder der Anthropic-Konsole ist vollkommen legitim, um die Machbarkeit zu erkunden.
Edge Cases und Reasoning-Verhalten: Für Aufgaben, die Chain-of-Thought-Reasoning erfordern, hat die Art, wie man das Problem im Prompt strukturiert, weiterhin Auswirkungen. “Denke Schritt für Schritt” und seine Variationen sind keine Magie, aber sie sind Anweisungen, die den Reasoning-Prozess beeinflussen.
Modelle ohne Tool Use oder Structured Outputs: Wenn man aus irgendeinem Grund mit kleineren oder lokal deployierten Modellen arbeitet, die diese Fähigkeiten nicht unterstützen, bleibt klassisches Prompting relevant.
Was gestorben ist, ist nicht der Prompt selbst. Was gestorben ist, ist die Idee, dass der Prompt das zentrale Artefakt ist, um das sich alles andere dreht.
Was Ihr Team lernen sollte
Wenn Sie 2026 Produkte mit LLMs aufbauen, sind dies die Fähigkeiten, die wirklich zählen:
1. JSON-Schema-Design: Klare Datenstrukturen für Modellausgaben definieren können. Pydantic, Zod, JSON Schema. Dies ist wichtiger als das Wissen, wie man Prompts formuliert.
2. Agenten-Architekturen: Verstehen, wie man Systeme entwirft, in denen der LLM spezialisierte Tools orchestriert. Muster wie ReAct, Plan-and-Execute und wann man welches verwendet.
3. RAG in der Produktion: Nicht das 5-Minuten-Tutorial mit ChromaDB und grundlegenden Embeddings. Echtes RAG umfasst strategisches Chunking, Reranking, Relevanzbewertung und Qualitätsüberwachung.
4. Eval-Design und -Ausführung: Wissen, was “gut” für den eigenen Anwendungsfall bedeutet, repräsentative Testmengen aufbauen und Bewertungen systematisch durchführen.
5. LLM-Observability: Tracing, Logging, Kosten- und Latenzüberwachung. Tools wie LangSmith, Langfuse oder Helicone. Man kann nicht verbessern, was man nicht messen kann.
6. Kontextverwaltung: Kontextgrenzen verstehen, wann und wie zu komprimieren, wann externes Gedächtnis vs. In-Context-Kontext zu verwenden.
Prompts sind Teil von all dem. Aber sie sind eine Komponente unter vielen, nicht das Zentrum.
Fazit: Baut Systeme, nicht Prompts
Der Unterschied zwischen einem Team, das KI produktiv einsetzt, und einem, das es nicht tut, liegt nicht darin, wer bessere Prompts schreiben kann. Er liegt darin, wer die richtige Infrastruktur rund um das Modell aufgebaut hat: die Datenverträge, die Tools, die Evaluierungspipeline, die Observability.
Der Prompt Engineer, der nur Nachrichten formulieren kann, ist das Äquivalent zu einem Frontend-Entwickler, der nur Code von Stack Overflow kopieren kann, ohne zu verstehen, warum er funktioniert. Nützlich für punktuelle Aufgaben, unzureichend für den Aufbau qualitativ hochwertiger Produkte.
Was der Markt jetzt verlangt, sind Ingenieure, die LLMs als Systemkomponenten verstehen: ihre Fähigkeiten, ihre Grenzen und wie man sie in echte Software-Architekturen integriert.
Bei Soamee arbeiten wir seit geraumer Zeit genau so. Wir verkaufen keine magischen Prompts und keine ChatGPT-Workshops. Wir bauen Produkte für künstliche Intelligenz mit der gleichen Engineering-Disziplin, mit der wir jedes andere Software-System aufbauen würden: mit definierten Verträgen, Tests, Observability und Continuous Deployment.
Wenn Ihr Unternehmen evaluiert, wie es KI ernsthaft integrieren kann, über den ersten Prototyp hinaus, erzählen Sie uns davon. Buchen Sie eine kostenlose Beratung und wir sprechen über Architektur, nicht über Prompts.