Coding-Harness · Anatomie eines Turns

Das Modell denkt. Der Harness haftet.

Ein Coding-Harness ist die Maschinerie um ein Sprachmodell: Er montiert den Kontext, prüft jeden Werkzeugaufruf, führt ihn aus und schreibt das Ergebnis zurück. Sechs Stationen, ein gemeinsamer Speicher — und genau eine Stelle, an der aus Absicht Wirkung wird.

Ein Turn im Coding-Harness Sechs Stationen laufen im Uhrzeigersinn von Auftrag über Modell, Kontrolle, Werkzeug und Umgebung zur Verifikation und zurück zum Auftrag. Jede Station schreibt in ein gemeinsames Kontextfenster in der Mitte; die Station Kontrolle ist als Freigabepunkt zwischen Vorschlag und Vollzug hervorgehoben. AUFTRAG FREIGABE BEFUND 01 Auftrag mensch · absicht 02 Modell plan · werkzeugwahl 03 Kontrolle rechte · hooks · sandbox 04 Werkzeug read · edit · bash 05 Umgebung repo · shell · netz 06 Verifikation tests · lint · diff Kontextfenster ENDLICH · GEMEINSAM Ohne Rücklauf ist es ein Chat, kein Harness. Hier endet Absicht, hier beginnt Wirkung. LEGENDE STATION KONTROLLPUNKT GETEILTER SPEICHER TURN-ABLAUF RÜCKSCHREIBEN

Abb. 1  Ein Turn im Coding-Harness. Im Uhrzeigersinn laufen Auftrag, Modell, Kontrolle, Werkzeug, Umgebung und Verifikation; die gestrichelten Speichen zeigen, was jede Station in das gemeinsame Kontextfenster zurückschreibt. Zeigen Sie auf eine Station oder eine Erläuterung — beide sind gekoppelt.

01

Auftrag

mensch · absicht

Ein Satz Absicht, meist unterspezifiziert. Der Harness übersetzt ihn nicht — er stellt ihn zu, zusammen mit allem, was das Modell sonst über dieses Repo wissen muss: Projektgedächtnis, Konventionen, offene Aufgaben.

FehlermodusDer Auftrag wird geraten statt geklärt.

02

Modell

plan · werkzeugwahl

Die einzige Station ohne Gedächtnis. Sie sieht ausschließlich, was im Kontextfenster steht, und antwortet mit Text: einer Absicht und dem nächsten Werkzeugaufruf. Alles, was sie „weiß“, hat eine andere Station hineingeschrieben.

FehlermodusWas nicht im Fenster steht, existiert nicht.

03

Kontrolle

rechte · hooks · sandbox

Der Punkt zwischen Vorschlag und Vollzug: Rechtemodus, Hooks, Sandbox, Pfad- und Netzgrenzen. Hier wird ein Aufruf zugelassen, umgeschrieben oder abgelehnt — und nur hier lässt sich später begründen, warum etwas passiert ist.

FehlermodusWer alles erlaubt, hat keinen Harness, sondern eine Fernbedienung.

04

Werkzeug

read · edit · bash

Ein schmales, scharfes Set. Jedes Werkzeug hat eine Signatur, ein Limit und eine Fehlermeldung, die das Modell lesen kann. Die Werkzeuge sind die eigentliche Schnittstelle des Harness — nicht der Prompt.

FehlermodusVierzig Werkzeuge, keine Auswahlhilfe.

05

Umgebung

repo · shell · netz

Der Ort, an dem tatsächlich etwas geschieht: Dateien ändern sich, Prozesse laufen, Zeit vergeht. Sie ist entweder reproduzierbar — gleiche Aufgabe, gleicher Container, gleiches Ergebnis — oder sie ist keine Grundlage.

FehlermodusGrün auf dem Laptop, rot im Container.

06

Verifikation

tests · lint · diff

Die Runde endet erst, wenn etwas widerspricht oder bestätigt: Testlauf, Linter, Typprüfung, gelesener Diff. Diese Station erzeugt den einzigen Text im Kontextfenster, den das Modell nicht selbst geschrieben hat.

FehlermodusDer Agent erklärt, statt zu prüfen.

Was der Harness beiträgt

  • Kontextmontage — Systemregeln, Projektgedächtnis, Skills, Verlauf, alles in ein endliches Fenster
  • Werkzeugvertrag — Signatur, Limit, lesbare Fehlermeldung
  • Durchsetzung — zulassen, umschreiben, ablehnen; Hooks statt Hoffnung
  • Rücklauf — Exit-Code, Diff und Testausgabe zurück in den Kontext

Woran er scheitert

  • Das Fenster läuft über — die Kompaktierung verwirft genau das Entscheidende
  • Werkzeugwildwuchs — jedes zusätzliche Werkzeug verteuert jede Entscheidung
  • Blinder Vollzug — alles erlaubt, nichts geprüft, nichts nachvollziehbar
  • Kein Befund — Erfolg wird behauptet statt gemessen

Woran man ihn misst

  • Turns bis zum grünen Testlauf p50 / p90
  • Anteil abgelehnter Aufrufe guard_rate
  • Fensterauslastung je Turn ctx_used
  • Wiederholbarkeit same task → same diff