Context Engineering
Beim Prompt Engineering geht es um die Worte, die du wählst. Bei Context Engineering geht es um den Arbeitsbereich, den du dem Modell übergibst — was darin ist, in welcher Reihenfolge, und was du bewusst weggelassen hast.
Die Unterscheidung ist wichtig, weil ein Kontextfenster kein Notizblock ist. Es ist eine begrenzte, teure, aufmerksamkeitsbezogene Ressource. Wie du es füllst, verändert, worauf sich das Modell konzentriert, wie viel es dich kostet und ob es nützlich bleibt, während die Sitzungen wachsen.
Das Kontextbudget
Jedes Modell hat eine maximale Kontextgröße — eine harte Obergrenze, gemessen in Tokens. Stell es dir als Budget vor. Du gibst es aus für:
- Deinen System-Prompt und stehende Anweisungen
- Abgerufene Dokumente, Codebasis-Ausschnitte, Werkzeugdefinitionen
- Den Gesprächsverlauf
- Die Ausgabe des Modells (die in mehrstufigen Sitzungen ebenfalls auf das Fenster angerechnet wird)
Wenn dir das Budget ausgeht, muss etwas weichen. Entweder werden alte Inhalte verworfen, oder die Sitzung läuft gegen eine Wand.
Die meisten Einsteigerleitfäden behandeln das Kontextfenster nach dem Motto „mehr ist besser". Context Engineering behandelt es als Ressource, die sorgfältig zugeteilt werden muss: Gib es für das aus, was das Modell für diesen Schritt tatsächlich braucht, nicht für alles, was relevant sein könnte.
Context Rot und „Lost in the Middle"
Es gibt ein gut dokumentiertes Phänomen bei LLMs mit langem Kontext: Modelle schenken Inhalten nahe dem Anfang und Ende ihres Kontexts überproportionale Aufmerksamkeit, und ihre Erinnerung an Inhalte, die in der Mitte vergraben sind, verschlechtert sich. Forscher, die diesen Effekt untersuchten, nannten ihn „Lost in the Middle".
Die praktische Konsequenz: Wenn du einen Kontext mit 100.000 Tokens voller Dokumente stopfst und die wichtigste Anweisung an Position 60.000 vergräbst, ignoriert das Modell sie womöglich faktisch — nicht weil es unfähig wäre, so weit zu lesen, sondern weil die Aufmerksamkeit nicht gleichmäßig über das Fenster verteilt ist.
„Context Rot" ist das umfassendere Muster: Während eine Sitzung wächst, neigt die Qualität der Antworten zum Abdriften. Frühe Anweisungen werden verwässert. Wiederholtes Hin und Her verdrängt die ursprüngliche Aufgabe. Das Modell beginnt, sich abzusichern, sich zu wiederholen oder den Faden dessen zu verlieren, worum du eigentlich gebeten hast.
Das sind keine Bugs, die du mit einem besseren Prompt vollständig beheben kannst. Es sind strukturelle Eigenschaften davon, wie Aufmerksamkeit im großen Maßstab funktioniert. Die ingenieurmäßige Antwort lautet, den Kontext kleiner und schärfer zu halten, statt ihn zu füllen und zu hoffen.
Reihenfolge zählt
Wo du Inhalte platzierst, ist genauso wichtig wie das, was du einbeziehst. Etablierte gute Praxis:
| Position | Was dort hingehört |
|---|---|
| Ganz oben (System-Prompt) | Stabile, beständige Anweisungen. Persona, Regeln, Formatanforderungen. |
| Nach dem System-Prompt | Die aktuelle Aufgabe, in klaren Worten. |
| Direkt vor dem letzten Nutzer-Turn | Der wichtigste, spezifischste Kontext für genau diese Anfrage. |
| Mitte | Stützdokumente, abgerufene Chunks — nach Relevanz geordnet, nicht chronologisch. |
| Gesprächsverlauf | Nur, was für die Kontinuität nötig ist. Aggressiv ausdünnen. |
Die allgemeine Regel: Je näher am aktuellen Turn, desto mehr Aufmerksamkeit bekommt es. Kritische Anweisungen, die nur in der Mitte eines langen Verlaufs leben, sind gefährdet.
Retrieval statt Vollstopfen
Die Versuchung ist, alles hineinzupacken: alle Dokumente, die gesamte Codebasis, das ganze Gespräch. Widerstehe ihr.
Der bessere Ansatz ist selektives Retrieval: Identifiziere, was das Modell für genau diese Anfrage tatsächlich braucht, und füge nur das ein. Ein gut abgerufener 2.000-Token-Ausschnitt des richtigen Dokuments schlägt einen 40.000-Token-Dump, bei dem die Antwort irgendwo in der Mitte steckt.
Genau dafür existiert Retrieval-Augmented Generation (RAG) — nicht nur, um Kontextgrenzen zu überwinden, sondern um die Qualität zu verbessern, indem der Kontext kuratiert bleibt.
Für interaktive Sitzungen gilt dieselbe Logik: Statt alles anzuhäufen, verdichte oder lösche den Verlauf regelmäßig, um Inhalte zu entfernen, die für die aktuelle Aufgabe nicht mehr relevant sind. Die Befehle /compact und /clear von Claude Code sind Context-Engineering-Werkzeuge, nicht bloß Sitzungsverwaltung.
Der Kostenaspekt
Tokens, die du sendest, sind Tokens, für die du bezahlst — sowohl in Geld als auch in Latenz. Den Kontext mit lose relevantem Material vollzustopfen, treibt beides in die Höhe. Context Engineering und Kosteneffizienz sind dasselbe Problem.
Konkreter:
- Ein aufgeblähter System-Prompt, den du aus einer Vorlage kopierst, wird bei jedem einzelnen Aufruf bezahlt.
- Alter Gesprächsverlauf, den du mitschleppst, weil „er nützlich sein könnte", wird bei jedem einzelnen Aufruf bezahlt.
- Dokumente, die du „nur für den Fall" einfügst, werden bei jedem einzelnen Aufruf bezahlt.
Das wegzukürzen, was nicht da sein muss, ist gleichzeitig besser für die Qualität und günstiger im Betrieb.
Praktische Taktiken für Claude-Nutzer
In Claude.ai:
- Nutze für unterschiedliche Aufgaben unterschiedliche Gespräche. Lass nicht einen Nachmittag voller Abschweifungen den Kontext eines fokussierten Projekts verseuchen.
- Fasse lange Threads zusammen, bevor du eine komplexe Frage stellst, die von ihnen abhängt. Eine explizite Zusammenfassung ist oft nützlicher als der rohe Verlauf.
- Setze das konkrete Anliegen ans Ende einer langen Nachricht, nicht in die Mitte vergraben.
In Claude Code:
- Halte deine
CLAUDE.md-Datei schlank. Jede Zeile darin wird in jede Sitzung eingefügt. Siehe CLAUDE.md und Kontextverwaltung. - Nutze
/clear, wenn du zu einer wirklich anderen Aufgabe wechselst. Nutze/compact, wenn du weitermachen willst, die Sitzung aber wächst. - Verweise auf Dateien über ihren Pfad, statt ihren Inhalt einzufügen, wenn die vollständige Datei für den aktuellen Schritt nicht gebraucht wird.
Auf API-Ebene:
- Gestalte System-Prompts so, dass sie nur das enthalten, was jede Anfrage wirklich braucht. Verschiebe aufgabenspezifische Anweisungen in den Nutzer-Turn.
- Rufe bei dokumentenlastigen Anwendungsfällen die relevanten Chunks ab und füge sie ein, statt einen ganzen Korpus hochzuladen.
- Strukturiere den Prompt so, dass der stabile, wiederverwendbare Präfix zuerst kommt — das ermöglicht außerdem Prompt-Caching, einen natürlichen Begleiter von Context Engineering.
Der Wandel der Denkweise
Prompt Engineering fragt: „Was sollte ich sagen?" Context Engineering fragt: „Was sollte das Modell sehen, in welcher Reihenfolge, und was sollte ich bewusst draußen lassen?"
Die zweite Frage ist schwerer, aber sie ist diejenige, die die Qualität im großen Maßstab tatsächlich bestimmt.