Kontext als versioniertes Artefakt

Unsere Position. Wir geben jeder Regel und jedem Skill genau eine Owner-Rolle (öffnet in einem neuen Tab): die Rolle, deren Arbeit sie beschreiben. Nutzen dürfen sie alle. Eine Änderung geht an diese Rolle und landet als Commit, durch dieselben Checks wie Code. Schwer war nie die Datei. Schwer war die Owner-Rolle.

Jede Stufe im Lebenszyklus des Kontexts übernimmt eine Praxis aus dem Engineering. Aus Tests werden gestufte Evals mit Error Budget. Geteilte Skills bringen Supply-Chain-Risiken mit, etwa geleakte Zugangsdaten und Prompt Injection.

Was ändert sich, wenn ihr Kontext wie Code behandelt?

Verwaltet ein Team viele Kontextteile, statt eine einzelne Datei von Hand feinzujustieren, verhält sich das Artefakt wie Code. Um es herum entsteht wieder der Software-Lebenszyklus: Kontext wird erzeugt, getestet, verteilt, beobachtet und angepasst. Jede Stufe übernimmt dabei eine Praxis aus dem Engineering (Context is the New Code - Talk auf der AI Engineer (öffnet in einem neuen Tab)).

Selbst das Projekt-Setup wird zu einem lebenden Dokument, das ausgeführt wird. Ein Setup-Hook des Harness startet es vor der Sitzung, damit die Vorbereitung der Umgebung nie Platz im Kontextfenster kostet (Setup-Hooks in Claude Code und just (öffnet in einem neuen Tab)). Die Basis ist, Kontext selbst zu besitzen: als vollwertigen Code, nicht ausgelagert in die Blackbox eines Frameworks (AOE - Context Engineering (öffnet in einem neuen Tab)).

Kontext testen heißt Evals schreiben, gestuft wie eine Testpyramide:

• Ein günstiger Linter prüft mechanische Eigenschaften, etwa ob die Beschreibung eines Skills vorhanden ist und die Länge einhält.
• Eine teurere Lesbarkeitsprüfung fragt ein Modell, ob der geschriebene Kontext überhaupt verständlich ist.
• Verhaltens-Evals lassen den Agenten gegen bekannte Fälle laufen (Context is the New Code - Talk auf der AI Engineer (öffnet in einem neuen Tab)).

Diese Läufe sind nicht deterministisch. Die Einheit ist deshalb ein Error Budget statt bestanden oder durchgefallen: Ihr lasst einen Fall mehrmals laufen und verlangt eine Erfolgsquote.

Darunter liegt eine harte Grenze. Der Disziplin fehlt noch eine gemeinsame Methode, um zu messen, ob eine Kontextänderung wirklich geholfen hat. Die Varianz der Agenten kann den Effekt überdecken: Derselbe Agent liefert mit identischem Kontext teils sehr unterschiedliche Ergebnisse. Das passt zum breiteren Befund, dass KI mehr Code erzeugt, aber nicht mehr produktionsreifen Code (Faros - Context Engineering for Developers (öffnet in einem neuen Tab)).

Eine Schleife schließt die Lücke, indem sie die Evaluation in die Regeln zurückführt. Ein LLM-as-Judge erklärt auf Englisch, warum ein Lauf gescheitert ist. Ein Meta-Prompt macht aus dieser Erklärung eine angehängte Regel. Berichtet wird, dass das die Quote gelöster Issues eines Coding-Agents um 5 bis 15 Punkte hebt (Talk über eval-getriebenes Prompt Learning (öffnet in einem neuen Tab)).

Mit der Verteilung kommen Supply-Chain-Fragen. Wiederverwendbare Skills und Regeln werden versioniert und über Registries geteilt. Das bringt Dependency Management mit sich, Scans nach geleakten Zugangsdaten und Prompt-Injection-Payloads sowie eine KI-SBOM. Es hält fest, welche Person und welches Modell einen Skill verfasst hat. Das ist umso nötiger, weil die meisten geteilten Skills von geringer Qualität sind. Und ist ein bösartiger Skill einmal geladen, blockiert ihn nichts (Context is the New Code - Talk auf der AI Engineer (öffnet in einem neuen Tab)).

Kommerzielle Plattformen verpacken dieselbe Idee für Unternehmen. Sie fassen verstreute Team-Standards in einem versionierten Playbook zusammen und verteilen es als KI-Kontext über Repos und Agenten. Verstöße fangen sie vor dem Commit ab und schreiben sie automatisch um (Packmind (öffnet in einem neuen Tab), Anbieter).

Das Schreiben selbst hat eine eigene, wiederholbare Schleife, getrennt vom Lebenszyklus des Artefakts. Ohne Feinabstimmung tendiert die Ausgabe eines Modells zu Convergent Defaults. Das sind die statistisch sicheren Entscheidungen, die seine Trainingsdaten dominieren und niemanden stören. Derselbe Sog der Verteilung lässt einen Coding-Agent generischen Boilerplate ausgeben.

Um diese Defaults zu überschreiben, benennt ihr zuerst die konkreten Defaults, die euch stören. Dann sucht ihr die Ursache: Fragt ihr das Modell in einem Turn im “debug mode”, warum es diese Ausgabe erzeugt hat, zeigt sich die falsche Annahme dahinter. Zuletzt liefert ihr konkrete Alternativen auf der richtigen Flughöhe.

Die Flughöhe ist die entscheidende Bedingung. Schritt-für-Schritt-Instruktionen, die ein Szenario überspezifizieren, laufen ins Overfitting und machen den Agenten bei Longtail-Fällen fragil. Vage Hinweise verändern das Verhalten dagegen gar nicht. Die haltbare Form erklärt deshalb die Begründung hinter dem gewünschten Verhalten, statt Schritte aufzuzählen.

Ergänzt nur Abschnitte, die die Ausgabe messbar verändern. Eine Verbesserung an einer Stelle zieht oft andere nach sich, und jeder neue Abschnitt kann stören, was schon funktioniert hat. So bläht sich das Token-Budget nicht auf, während das Artefakt wächst. Reasoning-Modelle verschärfen diese Disziplin. Ein voll gepackter Prompt kann sie verschlechtern: Sie reagieren am besten auf direkte, knappe Instruktionen und zerdenken eine überkomplexe Instruktion (Prompting für Reasoning-Modelle und die Methode der Convergent Defaults (öffnet in einem neuen Tab)).

Eine Warnung spricht gegen reflexhaftes Komprimieren. Stanfords ACE-Framework argumentiert, Agenten-Kontext solle sich wie ein umfassendes, wachsendes Playbook lesen, nicht wie eine knappe Zusammenfassung. Anders als ein Mensch kann ein LLM zur Inferenzzeit filtern, was relevant ist, aber nur, wenn das Detail vorhanden ist. ACE trennt die Rollen Generator, Reflector und Curator. Es führt inkrementelle Delta-Updates zusammen, damit wiederholtes Umschreiben keine Details abträgt (Faros - Context Engineering for Developers (öffnet in einem neuen Tab)).

Diese Spannung zum Instinkt, Tokens zu sparen, löst sich wie bei der Reihenfolge: über Relevanz und Struktur, nicht über pauschale Kürze. Manche Verhaltensweisen widersetzen sich Regeln ganz. Steht anschaulich und konkret da, was auf dem Spiel steht, kann eine Konvention greifen, wo eine abstrakte Formulierung wirkungslos bleibt. Die Neigung eines Modells zuzustimmen ist dagegen so hartnäckig, dass eine eigene Regel sie kaum ankratzt (Current Prompting Practices (öffnet in einem neuen Tab)).

Verwandte Seiten

• Skills schreiben: wie ihr die Skills schreibt, die dieser Lebenszyklus steuert.
• Governance und Betrieb: Ownership und Review von Kontext in einer ganzen Organisation.
• Nicht-deterministische Systeme evaluieren: wie ihr eine Kontextänderung testet, wenn Läufe variieren.
• Persistentes Agenten-Memory: der Kontext, den ein Agent für sich selbst schreibt.
• Memory und Context Engineering: die umfassendere Disziplin, zu steuern, was Agenten sehen.

Quellen

Artikel

• Context Engineering (öffnet in einem neuen Tab) - Eintrag im AOE AI Radar, der Context Engineering als Architekturmuster behandelt. Kontext gilt dort als vollwertiger Code, nicht als Interna eines Frameworks.
• Context Engineering for Developers (öffnet in einem neuen Tab) - Artikel von Faros darüber, wie man Kontextänderungen trotz der Varianz von Agenten misst, samt Stanfords ACE-Framework für wachsende Agenten-Playbooks.
• Current Prompting Practices (öffnet in einem neuen Tab) - Newsletter-Beitrag über Prompting-Gewohnheiten, die haften, etwa anschaulich konkrete Einsätze, und über die Zustimmungsneigung, die keine Regel beseitigt.

Posts

• Jeder Regel und jedem Skill eine Owner-Rolle (öffnet in einem neuen Tab) - LinkedIn-Post mit dem Argument, dass jede Regel und jeder Skill genau eine verantwortliche Rolle braucht und Änderungen durch dieselben Checks wie Code als Commit eingehen.

Talks und Videos

• Context Is the New Code (öffnet in einem neuen Tab) - Talk von Tessl auf der AI Engineer über den Lebenszyklus von Kontext, von gestuften Evals mit Error Budget bis zu Supply-Chain-Risiken in geteilten Skills.
• One Prompt Every AGENTIC Codebase Should Have (For Engineering Teams) (öffnet in einem neuen Tab) - Video über Setup-Hooks in Claude Code, die die Projektvorbereitung vor dem Sitzungsstart ausführen, damit sie nie Platz im Kontextfenster kostet.
• The Unreasonable Effectiveness of Prompt Learning (öffnet in einem neuen Tab) - Talk von Arize auf der AI Engineer darüber, wie Erklärungen eines LLM-Judge zu gescheiterten Läufen zu angehängten Regeln für einen Coding-Agent werden.
• okay, but I want Gemini3 to perform 10x for my specific use case - Here is how (öffnet in einem neuen Tab) - Video darüber, wie ihr die Convergent Defaults eines Modells überschreibt: Ursache verfolgen, Alternativen auf der richtigen Flughöhe liefern.

Tools und Repositories

• Packmind (öffnet in einem neuen Tab) - Kommerzielle Plattform, die Team-Standards in einem versionierten Playbook erfasst, es als KI-Kontext verteilt und Verstöße vor dem Commit abfängt.