Harness-Pflege

Wie ihr Konfigurationsverfall verhindert, veraltete Maschinerie entfernt und Anti-Patterns im Harness erkennt.

Garbage Collection ist Pflicht

Beim Kontextmanagement lassen Teams die Hälfte aus, die das Gedächtnis betrifft. Dort verrottet der Kontext eines Harness. LLMs haben null Intuition und nehmen jede Datei als absolute Wahrheit. Eine veraltete v1_architecture.md oder fünfzig Zeilen auskommentierter Legacy-Code gelten für sie als aktuell gültig. Der Agent halluziniert dann eine Implementierung gegen eine Datenbank, die es nicht mehr gibt.

Garbage Collection ist deshalb eine fortlaufende Pflichtaufgabe, die der Harness selbst ausführt. Eine Erinnerung, von Hand aufzuräumen, ersetzt sie nicht. Diese Strategien bauen sie ein:

• Pre-flight-Cleanup: Ein Skill, den ein Hook auslöst, sucht per statischer Analyse toten Code, etwa mit vulture in Python. Er prüft auch die Harness-Konfiguration selbst auf Regeln, die nicht mehr gelten, und auf abgedriftete Maps.
• Kontext-Archivierung: Ein überholtes ADR wandert in ein Verzeichnis archive/. Es bleibt im Repo, liegt aber außerhalb der Menge, die der Agent durchsucht.
• Post-flight-Retrospektive: Der Agent prüft, welche Iterationen ihr Ziel in ein paar Feedback-Loops erreicht haben und welche viele Runden gedreht haben. Die Antwort fließt in Regeln, Kontext oder Tests zurück, damit der nächste Lauf dieser Art weniger Loops braucht.

Über die Retrospektive lernt der Harness aus seiner eigenen Geschichte, statt teure Korrekturen zu wiederholen. Im Maßstab einer Factory wird dasselbe Ritual zur Compound Factory. Dort hält das System nach jedem Zyklus eine Retro und wertet seine eigenen Logs aus, um Monat für Monat besser zu werden. Die Disziplin hat eine theoretische Untergrenze: Vergessen gehört zu jedem funktionierenden Gedächtnisspeicher. Eine Factory, deren Kontext nur wächst, verschlechtert sich irgendwann. Sie muss so bewusst vergessen, wie sie wächst (Inside a Software Factory (öffnet in einem neuen Tab), 2026).

Das Codex-Team von OpenAI berichtet dasselbe Ritual aus einer Codebase, die komplett von Agents generiert ist. Früher fraß ein fester Cleanup am Freitag 20 Prozent der Woche. Heute erledigen das “doc-gardening”-Agents im Hintergrund und kodifizierte “golden principles”. Sie suchen nach Drift und öffnen in festem Takt kleine Refactoring-PRs. Technische Schulden behandelt das Team wie einen hochverzinsten Kredit, den es laufend tilgt statt in schmerzhaften Schüben. Zwei seiner Lektionen zum Kontext stützen die Regel, eine Map statt eines Handbuchs zu schreiben:

• Ein einziges riesiges AGENTS.md verrottet zu “a graveyard of stale rules”. Das Team hält es deshalb als Inhaltsverzeichnis von rund 100 Zeilen. Es zeigt in ein strukturiertes docs/ als System of Record, und Agents laden tiefere Quellen bei Bedarf nach (Progressive Disclosure).
• Was ein Agent nicht im Kontext erreicht, existiert für ihn praktisch nicht. Wer ihn auf eine Entscheidung aus einem Slack-Thread ausrichten will, schreibt sie ins Repository. Neue Kolleg:innen lernen genauso nur, was die Codebase festhält (Harness Engineering: Leveraging Codex in an Agent-First World (öffnet in einem neuen Tab), OpenAI über sein eigenes Codex, 2026).

Ein Continuous-Delivery-Leitfaden ergänzt den Blick der Änderungskontrolle. System-Prompts, Session-Templates, Agent-Konfiguration und Skills sind Delivery-Artefakte. Sie liegen in der Versionskontrolle neben dem Code, den sie erzeugen. Ein unversionierter Prompt oder ein veralteter Skill ist eine Änderung am Delivery-Prozess, die niemand reviewt hat. Deshalb kommt die Konfiguration im Takt der Pipeline ins Review. Wird der Output seltsam, prüft ihr zuerst die Konfiguration und erst danach das Modell. Jeder Skill trägt ein Aktualisierungsdatum, damit veraltete Skills auffallen. Brauchte sein Output starke Korrekturen, reparieren Teams den Skill vor dem nächsten Lauf. Sonst wiederholt jede spätere Session dieselben Korrekturen. Kontextdokumente pro Workstream kommen quartalsweise ins Review. Zusammenfassungen abgeschlossener Arbeit wandern ins Archiv, und die Beschreibung des Ist-Zustands wird passend zum Code neu geschrieben (MinimumCD.org and DojoConsortium.org - Pitfalls and Metrics (öffnet in einem neuen Tab), Stand September 2026).

Eine Komponente zu entfernen braucht dieselbe Evidenz, wie sie hinzuzufügen. Ein Webbuch über Delegation spielt das an einer Erinnerung durch. Sie schickte ein früheres Modell zu den freigegebenen Beispielkomponenten, bevor es ein Interface anfasste. Vergleicht das neue Modell mit und ohne diese Erinnerung auf repräsentativen Aufgaben, auch auf denen, die sie früher brauchten. Akzeptanzkriterien und unabhängiges Review bleiben dabei unverändert. Qualität, Korrekturaufwand und Gesamtkosten lest ihr zusammen. Greift eine Erinnerung selten, ist sie vielleicht überflüssig, oder der Aufgabenmix hat sich verschoben. Prüft deshalb, ob das Log ihre Nutzung erfasst, bevor ihr etwas in die Stille hineinlest. Entfernt sie über den Release-Prozess und behaltet die vorherige Konfiguration, falls spätere Arbeit schlechter wird. Die freigegebenen Komponenten selbst bleiben. Sie sind Produktkontext und kein Workaround für ein Modell (The Elastic Loop: Harness (öffnet in einem neuen Tab)).

Ein Konferenzbericht liefert einen Auswahltest für das, was in die immer geladene AGENTS.md gehört. Hinein kommen nur Fakten, die über Monate oder Jahre wahr bleiben. Das genannte Beispiel sind die Schichten des teameigenen Compilers. So liest sich die Datei als feste Invariante, egal welches Modell oder Coding-Tool jemand gerade nutzt. Ein Styleguide, der abdriftet, wird sie so nicht. Das Team ergänzt die geschriebene Invariante um eine soziale Regel statt um mehr Prosa. Wer sie ändern will, spricht vorher mit mindestens einer anderen Person. Das bremst riskante Änderungen, ohne einen zusätzlichen Token zu kosten (fighting slop with slop (öffnet in einem neuen Tab), Juli 2026, Praxisbericht).

Charlie Labs macht die Idee der ständigen Wartung explizit. Sein “daemon” ist eine Rolle mit fortlaufender Verantwortung und keine einmalige Aufgabe. Er beobachtet Systeme wie GitHub, Linear, Slack und Sentry. Wiederkehrende Signale macht er zu PRs, Issue-Updates, Reports, Eskalationen, Fixes oder bewussten No-op-Entscheidungen (Charlie Labs – Daemons work 24/7 (öffnet in einem neuen Tab), Anbieterangabe, 2026). Die Rolle steht einmal in einer DAEMON.md im Repository. Dort deklariert ihr, worauf er achtet, dazu Routinen, Verbotsregeln, Zeitpläne, Richtlinien und Erwartungen an den Output. Charlie beschreibt das Format als offen und portabel zwischen Anbietern, die es unterstützen (Charlie Labs – Daemons work 24/7 (öffnet in einem neuen Tab), Anbieterangabe, 2026).

Sein Ausführungsmodell taugt als Checkliste für jeden Wartungs-Loop im Hintergrund:

• Intake
• Kontext sammeln
• Planung mit Scope und Grenzen
• Ausführung oder Delegation
• Verifikation
• Reporting
• Fortsetzung aus gespeichertem Zustand

Menschliche Entscheidungen liegen an expliziten Freigabe-Gates für folgenreiche oder irreversible Änderungen. Routinearbeit läuft automatisch, und ihre Artefakte bleiben an jedem Checkpoint dauerhaft erhalten (Charlie Labs – How Charlie Daemons Work (öffnet in einem neuen Tab), Anbieterangabe, 2026). Die Angaben zur Zuverlässigkeit sind ebenso konkret:

• Doppelte Events führen zu einem einzigen Ergebnis.
• Retries sind begrenzt und laufen mit Backoff.
• Nach einer Unterbrechung geht es ab der letzten gespeicherten Stufe weiter.
• Unvollständiger Kontext oder fehlgeschlagene Checks lösen eine explizite Eskalation aus, statt still abzuschließen (Charlie Labs – How Charlie Daemons Work (öffnet in einem neuen Tab), Anbieterangabe, 2026).

Anti-Patterns im Harness

Vier Fehlermuster betreffen speziell den Bau eines einzelnen Harness. Die Fehler im Factory-Maßstab beschreibt Dark Factory Patterns.

• Der Agent macht den Job eines Skripts: Er entscheidet Dinge, die ein deterministisches Tool klären sollte. Formatierung ist der klarste Fall. Ein Formatter beim Speichern korrigiert die Art der Anführungszeichen jedes Mal kostenlos. Fragt ihr den Agent, verbrennt er Token mit Nachdenken darüber und liegt trotzdem daneben. Schiebt alles Mechanische in Linter, Formatter oder Hook. Das Denken des Agents spart ihr für Logik und Datenintegrität auf, die kein Skript klären kann.
• Der zu restriktive Harness: Jeder Linter steht auf Maximum, und der Agent kämpft mit der Konfiguration statt mit dem Problem. Er verbraucht seine Aufrufe für alphabetische Imports und Zeilenlängen. Der Merge scheitert, weil er doppelte Anführungszeichen nutzt, wo die Konfiguration einfache verlangt. Überlasst stilistische Formatierung einem automatischen Tool. Strenge Constraints wie mypy reserviert ihr für Logik und Datenintegrität.
• Der vernachlässigte Kontext: Der Harness geht den Kontextverfall nie an. Sechs Monate nach dem Umzug auf OAuth sagt seine Architektur-Map noch, die Authentifizierung laufe über eine lokale Datenbank. Der Agent liest die veraltete Map und halluziniert gegen eine Datenbank, die es nicht mehr gibt. Macht Kontextpflege zum Teil der Definition of Done. Verschiebt eine Änderung eine Grenze, aktualisiert dieselbe Änderung die Map.
• Review statt Loops: Ihr lest jeden Diff auf Dinge, die ein Test fangen könnte, und bleibt so für immer im Loop. Jede wiederkehrende Bug-Klasse, die ihr per Auge findet, ist ein noch nicht gebauter Loop. Wer denselben Fehler zweimal korrigiert, baut den Check ein, statt härter zu reviewen. Prüft öffentliches Verhalten statt Implementierungsdetails, damit ein Refactoring den Test nicht aus dem falschen Grund bricht.

Quellen

Kontextpflege

• fighting slop with slop (öffnet in einem neuen Tab) - Konferenz-Talk darüber, eine Architekturdatei auf Invarianten zu beschränken, die über Monate stabil bleiben, und Änderungen daran an ein Gespräch zu knüpfen.