Mike Bild
post

Delegieren statt Diktieren: der Harness macht den Unterschied

Warum dasselbe Sprachmodell im Chat mittelmäßige Schnipsel liefert und als delegierter Agent solide Arbeit – und wo die Schleife aus Werkzeugen, Plan und Selbstprüfung an ihre Grenzen kommt.

≈ 10 Min. Lesezeit
SoftwareKIMethodik
Markdown In Claude öffnenIn ChatGPT öffnen

Diesen Beitrag anhören (13 Min.)

MP3 herunterladen

Im Januar lag in einem Projekt ein Refactoring an, das ich seit Wochen vor mir herschob: ein Node-Service, in dem sich über die Jahre drei Generationen von Fehlerbehandlung angesammelt hatten – error-first-Callbacks, nackte Promise-Ketten, dazwischen frisches async/await. Nichts davon war schwer. Es war nur viel: rund sechzig Dateien, jede einzeln anzufassen, jede mit der Chance, beim Umbau einen Randfall zu zerlegen. Klassische Arbeit für einen verregneten Nachmittag und zwei Kannen Tee.

Teil 3 der Serie „Von der Session zum System“ – hier geht es zum Auftakt.

An diesem Nachmittag habe ich etwas anderes versucht. Statt die Dateien nacheinander in ein Chat-Fenster zu kopieren, Vorschläge zurückzukopieren und dabei langsam den Verstand zu verlieren, habe ich Claude Code im Terminal geöffnet und die Aufgabe in sechs Sätzen beschrieben: was umgebaut werden soll, welche Konventionen im Repository gelten, dass die bestehende Testsuite nach jedem Teilschritt grün bleiben muss, und dass ich bei Unklarheiten lieber eine Rückfrage will als eine mutige Annahme. Dann bin ich in ein Meeting gegangen.

Als ich zurückkam, lag da ein Branch. Ein sauberer Diff über die betroffenen Dateien, die Testsuite grün, dazu eine kurze Zusammenfassung: was geändert wurde, in welcher Reihenfolge, und zwei Stellen, die das Werkzeug als unsicher markiert hatte – mit konkreten Fragen an mich. Eine der Fragen war berechtigt und hätte mich beim Selbermachen vermutlich auch aufgehalten. An einer dritten Stelle hatte es eine Eigenheit unseres Codes übersehen, die kein Test abdeckte; die habe ich im Review gefunden und nachgezogen. Unterm Strich: Arbeit, für die ich einen halben Tag veranschlagt hatte, in gut vierzig Minuten Maschinenzeit plus einer halben Stunde Review. In einer Qualität, die ich von einem soliden Pull Request eines neuen Kollegen erwartet hätte.

Der Moment, der hängen blieb, war aber nicht die Zeitersparnis. Es war die Erkenntnis, dass dahinter dasselbe Modell steckte, das mir im Chat-Fenster so oft mittelmäßige Fragmente geliefert hatte. Gleiche Modellfamilie, gleicher Anbieter, gleiche Wissensbasis. Der Unterschied war nicht das Gehirn. Der Unterschied war das Gehäuse.

Der empirische Beleg für die These vom Dezember

Im Dezember habe ich argumentiert, dass die Modelle für die meisten Aufgaben in meinem Arbeitsalltag längst gut genug sind – und dass der Engpass woanders liegen muss, wenn die Ergebnisse trotzdem enttäuschen. Das war im Dezember eine These, abgeleitet aus Beobachtungen. Dieser Januar-Nachmittag war der empirische Beleg. Wenn dasselbe Modell im einen Setting Schnipsel produziert, die ich mühsam zusammensetzen muss, und im anderen Setting einen review-fähigen Branch abliefert, dann erklärt das Modell die Differenz nicht. Dann erklärt sie das, was um das Modell herum gebaut ist.

Für dieses Drumherum hat sich im Englischen ein Wort etabliert, das ich seither ständig benutze: Harness.

Was ein Harness ist

Das Wort kommt vom Zuggeschirr – dem Lederzeug, das ein Pferd mit dem Wagen verbindet und seine Kraft in eine Richtung lenkt. Softwareentwickler kennen den Begriff vom Test-Harness: der Apparat, der Testfälle einspannt, ausführt und Ergebnisse einsammelt. Bei Sprachmodellen meint Harness genau das: alles, was das rohe Modell einspannt und seine Fähigkeit in nutzbare Arbeit übersetzt. Werkzeuge wie Claude Code oder OpenAIs Codex CLI sind im Kern genau das – ein Harness um ein Modell, das es auch im Chat gibt.

Ein Sprachmodell für sich genommen kann nur eines: Text fortsetzen. Es kann keine Datei öffnen, keinen Test ausführen, keine Fehlermeldung sehen. Im Chat bin ich derjenige, der diese Lücke füllt – ich kopiere Code hinein, führe Vorschläge aus, kopiere die Fehlermeldung zurück. Ein Harness ersetzt mich in dieser Rolle durch eine Schleife. Vier Dinge machen sie aus.

Erstens Werkzeuge: Das Modell bekommt die Fähigkeit, Aktionen anzufordern – eine Datei lesen, eine Datei ändern, im Repository nach einem Bezeichner suchen, ein Kommando ausführen, die Testsuite starten. Der Harness führt die Aktion aus und gibt das Ergebnis als Text zurück. Aus einem Textfortsetzer wird ein Akteur mit Händen und Augen.

Zweitens Kontextverwaltung: Das Kontextfenster eines Modells ist endlich, ein reales Repository passt nicht hinein. Ein guter Harness entscheidet deshalb laufend, was das Modell zu sehen bekommt – er lässt es gezielt suchen statt alles einzulesen, hält Zwischenergebnisse fest und fasst lange Verläufe zusammen, wenn der Platz knapp wird. Das ist unspektakulär und entscheidet doch über alles: ein Modell mit dem falschen Ausschnitt vor Augen rät, eines mit dem richtigen liest ab.

Drittens Planen und Nachfassen: Die brauchbaren Werkzeuge zerlegen eine Aufgabe erst in Schritte, bevor sie loslegen, arbeiten die Schritte einzeln ab und gleichen nach jedem Schritt ab, ob der Plan noch trägt. Das klingt banal, unterscheidet aber einen Auftragnehmer von einem Reflex: Der Chat antwortet auf meine letzte Nachricht, der Harness verfolgt ein Ziel.

Viertens – und für mich der eigentliche Hebel – Selbst-Verifikation: Der Harness lässt das Modell seine eigene Arbeit prüfen. Tests ausführen, den Compiler befragen, die Fehlermeldung lesen, nachbessern, erneut prüfen. Genau die Schleife, die ich im Chat von Hand gedreht habe, dreht sich jetzt von selbst – und zwar zwanzig Mal hintereinander, ohne dass jemand die Geduld verliert.

Als Bild sieht die Schleife so aus:

flowchart TD
    A[Aufgabe<br/>Ziel, Kontext, Abnahmekriterien] --> B[Plan<br/>Aufgabe in Schritte zerlegen]
    B --> C[Werkzeug ausführen<br/>lesen, ändern, suchen, testen]
    C --> D{Ergebnis prüfen<br/>Tests grün? Fehler? Plan noch gültig?}
    D -->|Fehler oder Abweichung| E[Nachbessern<br/>Fehlermeldung lesen, Schritt anpassen]
    E --> B
    D -->|Kriterien erfüllt| F[Fertig<br/>Diff und Zusammenfassung an den Menschen]

Nichts an diesem Diagramm ist intellektuell aufregend. Es ist dieselbe Schleife, mit der jeder von uns arbeitet: verstehen, planen, ändern, prüfen, nachbessern. Das Bemerkenswerte ist, wo sie läuft. Im Chat verläuft jede Runde dieser Schleife durch mich – ich bin ihre Latenz, ihre Fehlerquelle und ihr Flaschenhals. Ich kopiere unvollständigen Kontext hinein, ich übersehe beim Zurückkopieren eine Zeile, ich habe nach der fünften Runde keine Lust mehr. Der Harness nimmt mich aus der Schleife heraus und setzt mich an ihre Enden: Auftrag vorn, Abnahme hinten.

Diktieren und Delegieren sind zwei verschiedene Tätigkeiten

Die Werkzeuge dafür waren im Januar 2026 nicht neu. Claude Code gab es seit Februar 2025, zunächst als Research Preview, seit Mai regulär; OpenAI hatte seine Codex CLI im April 2025 als Open Source veröffentlicht. Ich hatte beide seit Monaten installiert. Benutzt habe ich sie trotzdem lange wie einen besseren Chat: jeden Schritt beobachtet, jede Dateiänderung einzeln abgenickt, zwischendurch hineinregiert. Ich saß daneben wie ein Fahrlehrer mit dem Fuß über dem Zweitpedal.

Die eigentliche Umstellung war deshalb keine Werkzeug-, sondern eine Haltungsfrage – und sie hat länger gedauert als jede Installation. Diktieren heißt: „Ändere in dieser Datei die Funktion so.“ Ich behalte die Lösung, das Modell übernimmt das Tippen. Delegieren heißt: „Hier ist das Ziel, hier sind die Rahmenbedingungen, so erkennst du, dass du fertig bist.“ Ich behalte das Problem, das Werkzeug übernimmt die Lösung – und ich prüfe das Ergebnis.

Das ist exakt die Unterscheidung, die man aus der Zusammenarbeit mit Menschen kennt, und sie stellt dieselben Anforderungen an den Auftraggeber. Ein schlecht formulierter Auftrag liefert schlechte Ergebnisse, bei Menschen wie bei Maschinen – nur beschwert sich die Maschine nicht, sie liefert einfach selbstbewusst das Falsche. Ich habe für mich ein Bild gefunden, das die Erwartung richtig einstellt: Ich delegiere an einen sehr schnellen, sehr belesenen Mitarbeiter, der jeden Morgen zum ersten Mal im Projekt ist. Er kann alles nachschlagen, aber er erinnert sich an nichts. Was er über unsere Konventionen, unsere Altlasten und unsere Abnahmekriterien wissen soll, muss im Auftrag stehen oder im Repository auffindbar sein.

Mit dieser Haltung ändert sich, was ich überhaupt aufschreibe. Meine Aufträge an Claude Code sehen inzwischen aus wie gute Tickets: ein Ziel, der relevante Kontext, explizite Rahmenbedingungen, ein prüfbares Fertig-Kriterium. Der Aufwand, den ich früher ins Zerlegen und Diktieren gesteckt habe, steckt jetzt in der Auftragsklärung. Das fühlt sich zunächst wie Mehrarbeit an. Es ist dieselbe Sorgfalt, die gutes Delegieren an Menschen auch verlangt – nur dass sie hier sofort und messbar belohnt oder bestraft wird.

Wo Delegation trägt

Nach einigen Wochen mit dieser Arbeitsweise zeichnet sich für mich klar ab, welche Aufgaben sich gut delegieren lassen:

  • Mechanische Refactorings mit Sicherheitsnetz: eine API-Migration über viele Dateien, eine konsequente Umbenennung, das Vereinheitlichen von Mustern – überall dort, wo eine Testsuite oder der Compiler jeden Fehltritt sofort meldet.
  • Recherche im Repository: Wo wird dieser Konfigurationswert gesetzt, wer ruft diese Funktion, welche Stellen behandeln diesen Fehlerfall? Der Harness durchsucht in Minuten, wofür ich mich stundenlang durch Verzeichnisse hangeln würde – und liefert die Fundstellen mit Begründung.
  • Testabdeckung erweitern: Für bestehendes Verhalten Tests nachziehen ist Fleißarbeit mit eingebauter Verifikation – der neue Test muss laufen und bei mutwillig kaputtem Code fehlschlagen.
  • Routinearbeit mit klarer Vorlage: Boilerplate, Migrationsskripte, das Nachziehen eines Musters, das im Repository schon dreimal existiert, kleine Bugfixes mit reproduzierbarem Fehlerbild.

Der gemeinsame Nenner ist unübersehbar: Delegation trägt dort, wo das Ergebnis billig zu verifizieren ist – am besten maschinell, notfalls durch einen schnellen Review. Die Schleife im Diagramm oben hat einen Prüfschritt, und die ganze Konstruktion ist genau so gut wie dieser Schritt. Ein mechanischer Refactor unter einer dichten Testsuite spielt alle Stärken des Harness aus. Dieselbe Aufgabe ohne Tests verwandelt ihn in einen sehr fleißigen Produzenten von plausibel aussehendem Risiko.

Wo sie bricht

Womit ich bei der anderen Hälfte der Wahrheit wäre, denn die gehört in denselben Text. Ich bin in denselben Wochen mehrfach auf die Nase gefallen, und die Muster ähneln sich.

Lange Aufgaben kippen. Das Kontextfenster ist endlich, und irgendwann beginnt der Harness, den bisherigen Verlauf zusammenzufassen, um Platz zu schaffen. Mit jeder Komprimierung gehen Details verloren – ausgerechnet die Randbedingungen aus dem ursprünglichen Auftrag sind oft die ersten Opfer. Ich habe erlebt, wie eine Session nach zwei Stunden eine Konvention verletzte, die sie in der ersten halben Stunde noch sauber eingehalten hatte. Können hatte damit nichts zu tun: Die Regel war aus dem Kontext gefallen und damit aus dem Verhalten. Große Vorhaben muss ich selbst in Etappen schneiden, die einzeln in eine Session passen – diese Zerlegung kann ich bisher nicht delegieren.

Gravierender ist die Verifikationslücke. Die Selbstprüfung des Harness reicht exakt so weit wie das, was sich ausführen und messen lässt. Ob die Tests grün sind, kann er prüfen. Ob der Schnitt eines Moduls klug ist, ob eine öffentliche API in zwei Jahren noch tragfähig ist, ob eine Namensgebung das Fachliche trifft, ob der Code unter Last hält, ob eine Änderung ein Sicherheitsproblem aufreißt, das kein Test kennt – all das prüft niemand, wenn ich es nicht tue. Grüne Tests heißen: Das Verhalten, das jemand für prüfenswert hielt, ist erhalten. Mehr nicht. Alles jenseits davon fällt zurück an mich, und zwar wortwörtlich: Delegation verschiebt meine Arbeit von der Produktion in die Abnahme. Ich schreibe weniger Code und lese mehr Code, den ich nicht geschrieben habe. Wer schon einmal große Pull Requests reviewt hat, weiß, dass das die anstrengendere Tätigkeit ist – und die, bei der Nachlässigkeit am teuersten wird.

Und schließlich das Übervertrauen, auf beiden Seiten. Der Harness fragt seltener nach, als er sollte; im Zweifel trifft er eine plausible Annahme und arbeitet souverän weiter. Die Zusammenfassung am Ende klingt bei einem tadellosen Ergebnis genauso überzeugt wie bei einem, das an einer übersehenen Eigenheit vorbeigebaut ist – meine dritte Stelle aus der Eingangsszene stand in keiner Selbstauskunft. Auf meiner Seite wächst parallel eine bequeme Nachgiebigkeit: Je öfter die Ergebnisse gut sind, desto flüchtiger wird mein Review. Genau in dieser Schere – ein System, das nie unsicher klingt, und ein Mensch, der immer seltener genau hinsieht – liegt das eigentliche Risiko dieser Arbeitsweise. Der einzelne Fehler ist dabei das kleinere Übel. Teuer wird die Gewöhnung.

Das Gehäuse macht den Unterschied – und stellt die nächste Frage

Die nüchterne Bilanz des Januars: Das Modell ist dasselbe geblieben. Gesprungen ist meine Art, es einzuspannen. Dieselben Fähigkeiten, die im Chat-Fenster als Schnipsellieferant verpuffen, werden in einer Schleife aus Werkzeugen, Kontextverwaltung, Plan und Selbstprüfung zu etwas, dem ich echte Arbeit anvertrauen kann – solange die Aufgabe in eine Session passt und ihr Ergebnis prüfbar ist. Delegieren statt Diktieren steht in keinem Funktionsmenü; es ist eine Fähigkeit des Auftraggebers und will genauso gelernt sein wie beim Delegieren an Menschen.

Ich merke aber auch: Je mehr ich delegiere, desto lauter wird ein Unbehagen. Es hat nichts mit der Qualität der Ergebnisse zu tun – die wird eher besser. Es hat damit zu tun, was auf meiner Seite passiert, während die Schleife läuft: was ich nicht mehr selbst durchdenke, was ich nur noch abnicke, wovon ich mich abhängig mache. Diesem Unbehagen will ich in der nächsten Folge in Ruhe nachgehen, statt es wegzuloben.

Weiterführende Quellen

Kommentare