Einige meiner Prompts liegen seit Monaten in derselben Datei. Als ich sie schrieb, lösten sie echte Probleme. Bei sprunghaften Antworten kam „Schritt für Schritt“ hinzu. Wenn das Format schwankte, ergänzte ich Beispiele und ein genaueres Verfahren. Jede neue Zeile fühlte sich wie eine zusätzliche Sicherung an.
Irgendwann wurde diese Sicherung selbst zum Hindernis. Die Antworten waren nicht offensichtlich falsch, aber zu lang und umständlich. Selbst eine kleine Korrektur begann mit einem Plan. Dinge, die ein Werkzeug direkt prüfen konnte, wurden noch einmal ausformuliert. Für die eigentliche Entscheidung blieb weniger Platz.
Zuerst hielt ich das für einen Rückschritt des Modells. In einem neuen Chat stellte ich denselben Auftrag in vier klaren Sätzen. Das Ergebnis ließ sich schneller prüfen. Nicht das Alter des Prompts war das Problem, sondern die Aufgaben, die er noch immer für eine längst veränderte Umgebung übernahm.
Mein erster Verdacht galt dem Modell
Der Auftrag war überschaubar: einen Störungsbericht lesen, wahrscheinliche Ursachen eingrenzen und den nächsten Diagnosebefehl nennen. Mein alter Prompt war länger als 40 Zeilen. Er legte Rolle, Denkweg, Ausgabeformat und den Einsatz bereits angebundener Werkzeuge fest.
Die Antwort wirkte gründlich, war aber mühsam zu kontrollieren. Beobachtungen aus den Logs und Vermutungen standen im selben langen Text. Zusätzlich schlug das Modell Werkzeuge vor, die es gar nicht verwendet hatte. Beim zweiten Versuch blieben nur Ziel, die Grenze des Belegbaren und das Abnahmekriterium. Die Antwort nannte weniger Ursachen, dafür brauchbarere Diagnosebefehle. Der Unterschied zeigte sich nicht im Stil, sondern in der Zeit bis zur nächsten belastbaren Entscheidung.
Ein einzelner Versuch reicht dafür nicht. Ich wiederholte den Vergleich mit Dokumentenprüfung, Fehleranalyse und Tabellenkontrolle. Entfernt wurden nur Regeln, die wiederholt Prüfaufwand erzeugten, ohne das Ergebnis zu verbessern.
Überholt ist meist die Rollenverteilung, nicht das Datum
Heute ordne ich jede Anweisung zuerst einer Aufgabe zu.
Der Prompt beschreibt Ziel und Grenzen. Der Context liefert das für diesen Auftrag nötige Material. Der Harness übernimmt wiederholbare Ausführung und Prüfung. Werden alle drei Rollen vermischt, ist auch die Fehlerdiagnose unnötig schwer.
Im Prompt stehen Zweck, Grenzen, Belegstandard und Definition of Done. Der Kontext enthält aktuelle Dateien, projektspezifische Regeln und die für diesen Fall relevanten Fakten. Der Harness plant, ruft Werkzeuge auf, führt Tests aus, wiederholt Schritte und stoppt an Freigabegrenzen.
Viele ältere Prompts enthalten alle drei Ebenen. Geht etwas schief, sieht alles nach einem Prompt-Problem aus. Tatsächlich kann das Material veraltet sein oder ein Test nie gelaufen sein. Die Trennung macht den Fehler lokalisierbar.
Welche Sätze zuerst verschwanden
Zuerst entfernte ich Rollenspiele ohne Entscheidungskriterium. „Du bist ein Experte mit zehn Jahren Erfahrung“ erzeugt bestenfalls Tonfall. Hilfreich wird die Rolle erst, wenn klar ist, welches Risiko zählt, welche Belege gelten und wann ein Mensch übernehmen muss.
Danach folgten Anweisungen, den gesamten Denkweg auszuschreiben. Ich brauche keine lange Erzählung über interne Überlegungen. Ich brauche überprüfbare Belege aus Logs, Quellen oder Tests und eine klare Kennzeichnung dessen, was nicht belegt ist.
Auch wiederholte Werkzeuganleitungen flogen heraus, wenn Definition und Schema bereits im System lagen. Ein Beispiel bleibt nur, wenn es ein sonst instabiles Verhalten tatsächlich begrenzt.
Fest eingetragene Datumsangaben waren ein einfacher Fall. „Heute ist August 2025“ wird beim Kopieren sofort zur Altlast. Bei zeitkritischen Recherchen übergebe ich das aktuelle Datum und notiere Veröffentlichungs- und Prüfdatum der Quellen.
Schließlich kürzte ich detaillierte Abläufe und Schemas, die nur Sicherheit ausstrahlten. Ein festes Schema bleibt, wenn ein nachgelagertes System es parsen muss. Eine Reihenfolge bleibt, wenn eine Richtlinie sie verlangt. Ansonsten prüfe ich das Ergebnis und die Abbruchbedingungen statt einen einzigen Lösungsweg vorzuschreiben.
Diese Angaben dürfen nicht verschwinden
Auch das beste Modell kennt interne Betriebsbedingungen nicht:
- den Schaden einer falschen Kundenaussage
- die Grenze zwischen automatischer Ausführung und Freigabe
- messbare Erfolgskriterien und Abbruchbedingungen
- vertragliche oder interne Vorgaben, die nicht geraten werden dürfen
- das Format, das der nächste Prozessschritt benötigt
Das sind keine Prompt-Tricks, sondern Wissen über die Arbeit. Ein gekürzter Prompt ist nur dann besser, wenn dieses Wissen anschließend klarer sichtbar ist.
Ein Teil der alten Anweisung gehört heute in Werkzeuge
OpenAI warnt im Beitrag zum Harness Engineering davor, AGENTS.md zu einem tausendseitigen Handbuch auszubauen. Stattdessen soll eine kurze Datei zu den jeweils relevanten Unterlagen führen. Regeln, die sich prüfen lassen, gehören in Linter, Tests und den Harness, nicht in wiederholte Prosa.
Quelle: OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11. Februar 2026. Der Beitrag behandelt kurze Wegweiser, progressive disclosure und durch Werkzeuge durchgesetzte Regeln.
„Führe die Tests aus“, „behebe Fehler“ und „verwende diese Abhängigkeit nicht“ sind als Bitte schwach. Ein Harness kann den Test wirklich starten und bei einem Verstoß stoppen. Der Prompt formuliert den Auftrag; der Harness macht die Regel wirksam.
Sobald ein Mensch dieselbe Kontrolle mehrfach durchführen muss, prüfe ich, ob sie in einen Test, ein Skript, eine Berechtigungsgrenze oder eine Checkliste gehört. Was dort zuverlässig funktioniert, muss nicht bei jedem Lauf erneut erbeten werden.
Mehr Kontext ist nicht automatisch besser
Alle Richtlinien, Sitzungsnotizen und alten Chats zu laden wirkt gründlich. Es kann aber den aktuellen Auftrag verwässern. Anthropic beschreibt Kontext als begrenzte Ressource und weist auf context rot hin: Mit wachsendem Kontext kann die Fähigkeit sinken, relevante Informationen zuverlässig wiederzufinden.
Quelle: Anthropic, Effective context engineering for AI agents, 29. September 2025. Der Beitrag betrachtet Systemanweisungen, Werkzeuge, externe Daten und Verlauf als gemeinsames Context-Problem.
Ich trenne deshalb dauerhaften Context von abrufbaren Unterlagen. Dauerhaft bleiben Projektziel, unverhandelbare Regeln und Verweise auf die Quellen. Detailrichtlinien, Retrospektiven und Werkzeugbeschreibungen liegen separat und werden nur für passende Aufgaben gelesen. Das Wissen verschwindet nicht; es wird gezielt auffindbar.
Ein Prompt vor und nach der Überarbeitung
Die alte Fassung lautete:
Du bist ein erfahrener Experte mit zehn Jahren Berufserfahrung. Denke Schritt für Schritt und erläutere jede Stufe. Erstelle zuerst einen Plan, warte auf die Freigabe und beginne dann mit der Arbeit.
Das klingt pflichtbewusst, nennt aber weder Material noch Belegstandard oder Ende. Die neue Fassung ist konkreter:
Prüfe den beigefügten Störungsbericht und ordne die wahrscheinlichsten Ursachen nach ihrer Plausibilität. Belege jede Ursache. Behaupte nichts, was sich aus den Logs nicht stützen lässt. Fertig ist die Aufgabe, wenn der Operator den nächsten Diagnosebefehl unmittelbar ausführen kann.
Die neue Fassung schreibt keinen Denkstil vor. Sie benennt Material, Beleggrenze und Zielzustand. Falls ein Plan nötig ist, kann der Agent ihn erstellen. Falls eine Freigabe zwingend ist, stoppt der Harness an dieser Stelle.
Mein Test nach einem Modellwechsel
Bei einem neuen Modell schreibe ich nicht die gesamte Bibliothek um. Ich wähle drei typische Aufgaben und lasse bestehende sowie gekürzte Fassung unter denselben Bedingungen laufen. Danach prüfe ich:
- Ist das Ergebnis für den Nutzer besser?
- Gibt es weniger unbelegte Behauptungen?
- Sinkt die menschliche Prüfzeit?
- Sind weniger Korrekturrunden nötig?
- Lässt sich ein Fehler Prompt, Context oder Harness zuordnen?
Die Eingaben dürfen dabei nicht nur sauber sein. Dokumente variieren in Länge und Schwierigkeit; Daten enthalten fehlende Werte und Formatfehler. Verschlechtert das Entfernen einer Regel nur eine Aufgabenklasse, kommt sie mit engerer Bedingung zurück. Auch Löschen braucht Versionskontrolle.
Was ein alter Prompt wirklich abgeben sollte
Nicht jede ein Jahr alte Anweisung ist schlecht. Ein Kundenversprechen oder eine harte Abbruchschwelle kann weiterhin der wertvollste Satz sein. Unnötig ist nur, den Prompt mit Fähigkeiten zu belasten, die das Modell bereits mitbringt, die ein Werkzeug sicherer prüft oder die als Unterlage bei Bedarf geladen werden können.
Sichtbar bleiben bei mir vier Dinge: gewünschtes Ergebnis, unverletzbare Grenzen, zulässige Belege und Abnahmekriterium. Material wird für den Auftrag geladen. Wiederholbare Ausführung übernimmt der Harness.
Der größte Gewinn war kein schönerer Ton. Nach einem Fehler kann ich entscheiden, ob der Auftrag, das Material oder die Ausführung geändert werden muss. Diese Klarheit war wertvoller als jede neue Prompt-Formel.
