Delegieren statt Diktieren: der Harness macht den Unterschied

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. Die beiden Erfahrungen – die mittelmäßigen Fragmente im Chat-Fenster und der reviewfähige Branch im Terminal – fanden in unterschiedlichen Arbeitsumgebungen statt. Ob dabei dieselbe Modellversion oder dieselbe Wissensbasis zum Einsatz kam, kann ich nicht belegen; ich habe weder Modellkennung noch Konfiguration protokolliert. Der Vergleich isoliert deshalb keine einzelne Ursache. Repository-Zugriff, Werkzeugaufrufe und ausführbare Prüfungen kommen als Erklärung für die Differenz infrage.

Die praktische Folgerung aus der 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. Der Januar-Nachmittag zeigte im Projekt, dass die Terminal-Umgebung einen reviewfähigen Branch lieferte, während ich aus früheren Chat-Sitzungen oft nur Fragmente erhielt. Für meine Arbeitsweise folgt daraus: mehr Aufwand für Repository-Kontext, Werkzeugzugriffe und Prüfungen statt für die Suche nach dem nächsten Modell.

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. In diesem Artikel bezeichnet Coding-Harness die Verbindung eines Modells mit Kontext, Werkzeugen und Prüfungen. Anthropic unterscheidet in „Building Effective Agents“ feste Workflows von Agenten – Systemen, die Werkzeuge in einer Rückkopplungsschleife selbstständig auswählen und verwenden.

Technisch trenne ich hier Modell und ausführende Umgebung: Das Modell erzeugt Text oder schlägt, abhängig von seiner Schnittstelle, Werkzeugaufrufe vor. Die umgebende Software setzt diese Aufrufe mit den ihr erteilten Rechten um. Im Chat habe ich diese Verbindung von Hand hergestellt: Code hineinkopiert, Vorschläge ausgeführt und Fehlermeldungen zurückgegeben. Ein Harness übernimmt diesen Ablauf als programmatische Schleife. Vier Dinge machen sie aus.

Erstens Tools: 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. Damit kann das Modell Datei- und Kommandozugriffe anfordern und deren Ergebnisse im nächsten Schritt verarbeiten.

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. Fehlt der relevante Ausschnitt, beruhen Änderungen auf Annahmen. Mit den passenden Dateien, Fehlermeldungen und Konventionen kann das Modell seine Vorschläge am tatsächlichen Projektzustand ausrichten.

Drittens Planen und Nachfassen: Für längere Aufgaben sollte ein Harness die vorgesehenen Schritte festhalten und nach jedem Werkzeugergebnis prüfen, ob der Plan noch trägt. So bleibt das Ziel über mehrere Änderungen und Prüfungen hinweg sichtbar, statt nur auf die jeweils letzte Rückmeldung zu reagieren.

Viertens – und für mich der eigentliche Hebel – ausführbare Verifikation: Der Harness startet externe Prüfungen und gibt deren Ergebnisse an das Modell zurück. Tests ausführen, den Compiler befragen, die Fehlermeldung lesen, nachbessern, erneut prüfen. Genau die Schleife, die ich im Chat von Hand gedreht habe, kann der Harness für Prüfungen und Nachbesserungen selbstständig wiederholen. Anthropics eigener Praxisleitfaden zu Claude Code empfiehlt dieses Prinzip: dem Agenten Möglichkeiten geben, seine Arbeit eigenständig zu prüfen, und Aufgaben so schneiden, dass Ergebnisse überprüfbar bleiben.

Als Bild sieht die Schleife so aus:

flowchart TD
    A[Aufgabe<br/>Ziel, Kontext, Abnahmekriterien] --> B[Plan<br/>Aufgabe in Schritte zerlegen]
    B --> C[Tool 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]

Neu ist an diesem Diagramm nichts. 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

Im Januar 2026 hatte ich Claude Code und OpenAIs quelloffene Codex CLI 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 meine Erwartung zurechtrückt: Ich delegiere an einen sehr schnellen, sehr belesenen Mitarbeiter, der jeden Morgen zum ersten Mal im Projekt ist. Repository-Inhalte kann das Werkzeug nachschlagen. Für den jeweiligen Modellschritt ist aber nur verfügbar, was der Harness in den aktiven Kontext aufnimmt; Dateien und Werkzeugzustand bleiben externe Quellen. Was das Modell über unsere Konventionen, Altlasten und Abnahmekriterien berücksichtigen soll, muss deshalb 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 verlangt. Klare Kriterien machen Abweichungen im Diff oder in ausführbaren Prüfungen eher sichtbar.

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 relevante Abweichungen innerhalb ihrer Abdeckung meldet.
• Recherche im Repository: Wo wird dieser Konfigurationswert gesetzt, wer ruft diese Funktion, welche Stellen behandeln diesen Fehlerfall? Der Harness durchsucht das Repository und liefert Fundstellen mit Begründung; ich muss die relevanten Verzeichnisse nicht einzeln abarbeiten.
• 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.

Diese Beispiele haben einen gemeinsamen Nenner: Delegation trägt dort, wo sich das Ergebnis mit vertretbarem Aufwand prüfen lässt – am besten maschinell, notfalls durch einen gezielten 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. Ohne passende Tests können Verhaltensänderungen bis zum Review oder Betrieb unentdeckt bleiben.

Wo sie bricht

In denselben Wochen sind mehrere delegierte Aufgaben gescheitert. Die Ursachen ähnelten sich.

Lange Aufgaben kippen. Das Kontextfenster ist endlich, und irgendwann beginnt der Harness, den bisherigen Verlauf zusammenzufassen, um Platz zu schaffen. Mit jeder Komprimierung können Details verloren gehen – ausgerechnet die Randbedingungen aus dem ursprünglichen Auftrag sind dafür ein naheliegendes Opfer. Ich habe erlebt, wie eine Session nach zwei Stunden eine Konvention verletzte, die sie in der ersten halben Stunde noch sauber eingehalten hatte. Meine Vermutung: Die Regel war bei einer dieser Komprimierungen aus dem Kontext gefallen und damit aus dem Verhalten. Nachweisen kann ich das nicht – ich sehe nur das Ergebnis, nicht den inneren Zustand der Session. Die Konsequenz bleibt dieselbe: 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 nur: Die ausgeführten Assertions bestehen unter den geprüften Bedingungen. Alles jenseits davon fällt zurück an mich: Delegation verschiebt meine Arbeit von der Produktion in die Abnahme. Ich schreibe weniger Code und lese mehr Code, den ich nicht geschrieben habe. Die fachliche Abnahme und die Verantwortung für den Merge bleiben bei mir – kein Prüfschritt in der Schleife nimmt sie mir ab. 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. Das eigentliche Risiko entsteht, wenn eine selbstsicher formulierte Zusammenfassung die tatsächliche Unsicherheit nicht erkennen lässt und der Mensch zugleich immer seltener genau hinsieht. Der einzelne Fehler ist dabei das kleinere Übel. Teuer wird die Gewöhnung.

Das Gehäuse verändert die Arbeit – und stellt die nächste Frage

Die nüchterne Bilanz des Januars: Ob sich die Modellseite unterschied, kann ich nicht sagen. Geändert hat sich meine Art, das Modell einzuspannen. In der Terminal-Umgebung mit Repository-Zugriff, Werkzeugaufrufen und ausführbaren Prüfungen entstand ein prüfbarer Branch – solange die Aufgabe in eine Session passt und ihr Ergebnis prüfbar bleibt. Delegieren statt Diktieren steht in keinem Funktionsmenü; es ist eine Fähigkeit des Auftraggebers und will genauso gelernt sein wie beim Delegieren an Menschen.

Deshalb lautet meine Regel: nur Aufgaben mit klaren, mit vertretbarem Aufwand prüfbaren Abnahmekriterien delegieren und jeden Diff vor dem Merge prüfen.

Je mehr ich delegiere, desto deutlicher wird zugleich 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 schönzureden.

Weiterführende Quellen

• Building Effective Agents – Anthropics Grundlagentext zur Unterscheidung fester Workflows von Agenten, die Werkzeuge in einer Rückkopplungsschleife selbstständig auswählen und verwenden
• Claude Code: Best Practices for Agentic Coding – Anthropics Praxisleitfaden: dem Agenten Selbstprüfung ermöglichen, Aufgaben überprüfbar schneiden
• OpenAI Codex CLI – der quelloffene Terminal-Coding-Agent von OpenAI
• OpenAI debuts Codex CLI – TechCrunch zur Veröffentlichung im April 2025
• Simon Willison über Building Effective Agents – lesenswerte Einordnung des Agenten-Begriffs

Wie fandest du diesen Beitrag?

Kommentare