Kontext, Konstruktion und Rekonstruktion

Eine grüne Spielfigur auf einem zentralen Feld, umgeben von versetzten braunen Spielbrettsegmenten.

Notizen zu einer Arbeitsweise mit Coding-Agenten · September 2026

Ich arbeite seit über zwanzig Jahren als Entwickler, und ich lese die Algorithmen nicht mehr. Ich habe die Kapazität dafür nicht mehr, wenn ich sie für das brauche, was mir wichtiger ist: die Architektur, die Struktur, die Frage, ob eine Konstruktion die nächsten drei Anforderungen trägt. Den Rest lasse ich prüfen – von Agenten, gegeneinander, in einem Verfahren, das aus der Praxis entstanden ist und dessen Begründung ich erst hinterher gefunden habe. Diese Notizen sind der Versuch, sie aufzuschreiben.

Kontext und Entscheidungsprotokoll

Ein Coding-Agent hat kein Gedächtnis. Was er hat, ist der Verlauf der Session: Anweisungen, Antworten, gelesene Dateien, Testergebnisse, seine eigenen Überlegungen. Im Lauf einer Aufgabe entsteht daraus ein Zusammenhang, der über den Code hinausreicht – welche Alternative verworfen wurde, wo ein Randfall auftrat, wie eine Lücke in der Spezifikation gefüllt wurde. Aus dem Code allein lässt sich das nicht mehr erschließen. Der Code ist, was übrig bleibt, wenn man den Kontext wegwirft.

Deshalb leere ich den Kontext nie. Reviews, Rückfragen und Korrekturen gehen immer in die Session, in der gebaut wurde. Entgegen zur üblichen Empfehlung: Sessions oft leeren, Aufgaben in kontextfreie Häppchen schneiden. Diese Empfehlung ist richtig, zielt aber auf ein anderes Arbeitsmuster: auf Kontexte, die aus Umwegen bestehen, aus seitenweise Tool-Output und gescheiterten Debugging-Anläufen, die im Fenster stehen bleiben und weiterwirken. Ein Kontext, der aus Entscheidungen besteht, wird durch Länge nicht schlechter. Er wird dichter. Und seit etwa Herbst 2025 erkennen die Modelle einen Irrweg nach Minuten statt nach Stunden; was an Umwegen im Kontext bleibt, ist kurz und als verworfen markiert – Information, kein Rauschen.

Der stille Gegner ist die Kompaktierung. Sie hält fest, was geändert wurde, und verliert das Warum, weil eine Zusammenfassung nicht wissen kann, welche Begründung später einmal gebraucht wird. Der Agent danach hält sich für denselben; er ist ein neuer mit einer guten Zusammenfassung. Die Absicherung dagegen ist nicht das Leeren, sondern das Sichern: Ich lasse wesentliche Entscheidungen während der Arbeit in einer Datei im Projekt festhalten – die gewählte Lösung, die Gründe, die verworfenen Alternativen, die offenen Fragen. Anthropic beschreibt das Erhalten von Architekturentscheidungen als Ziel der Kompaktierung und ergänzt sie durch dauerhaft gespeicherte Arbeitsnotizen. Meine Erfahrung ist, dass die Notizen das Zuverlässigere von beidem sind.

Absicht und Umsetzung

Die Schleife ist: bestimmen, was gebaut wird – autonom bauen lassen – begutachten – korrigieren lassen. Das Was gehört mir, das Wie dem Agenten. Wo die Grenze liegt, verschiebt sich mit jedem Modell. Ob an einer Stelle eine Queue gehört, war vor einem Jahr eine Architekturentscheidung, die ich vorgeben musste; heute sieht der Agent es selbst. Meine Aufgabe ist, über dieser steigenden Linie zu bleiben.

Jede Aufgabe beginne ich mit derselben Frage: „Wie würdest du das lösen?" An der Antwort sehe ich, bevor eine Zeile Code existiert, ob die Absicht angekommen ist und welche Annahmen der Agent mitbringt. Ein Missverständnis kostet an dieser Stelle zwei Sätze; nach dem Bauen kostet es eine Review-Runde und Refactoring. Und die Frage macht das Wie zum eigenen Entwurf des Agenten. Er baut nicht nach Vorschrift, er baut seinen Vorschlag, den ich abgenickt oder korrigiert habe. Die Begründung steht damit ausgesprochen im Kontext, nicht nur implizit im Code – und sie ist der erste Eintrag ins Entscheidungsprotokoll.

Daraus folgt, wo ich Aufwand hineinstecke und wo nicht. Es gibt Struktur, die gegenwärtige Modellschwächen kompensiert: Prompt-Ketten, handgeschnitzte Rollen, Gerüste um das Modell herum. Die verfällt mit dem nächsten Modell, und ich habe aufgehört, in sie zu investieren. Und es gibt Struktur, die die Absicht festhält – Ziele, Randbedingungen, Gründe. Die verfällt nicht, weil kein noch so gutes Modell weiß, was ich wollte, wenn es nirgends steht. Dirigieren statt strukturieren ist eine Wette darauf, dass die Modelle jeden Monat besser werden. Sie hat bisher jeden Monat gewonnen.

Review und Rekonstruktion

Auf die Selbstprüfung des Coders folgt ein Review durch ein anderes Modell – in meinem Fall Claude gegen Codex. Die Einwände gehen an den Coder zurück, der Stellung nimmt. Seine Korrekturen oder seine Verteidigung gehen an den Reviewer. Was danach noch offen ist, entscheide ich.

Was mich an diesem Verfahren überrascht hat: Der Coder kapituliert nicht. Ich hatte erwartet, dass er Review-Punkte übernimmt, weil sie kompetent klingen. Stattdessen verweist er auf Gründe, die während der Umsetzung besprochen wurden und die der Reviewer nicht kennt, und gibt nach, wo er keine hat. Das Ergebnis ist deutlich besser, als wenn ich den Reviewer seine Vorschläge selbst umsetzen lasse. Die Erklärung, die ich dafür habe, ist der Kontext: Kapitulation passiert, wenn ein Agent Code verteidigen soll, den er nicht selbst gebaut hat – frische Session, „hier ist ein Diff und ein Review, arbeite die Punkte ab". Dann hat er keine eigene Begründung für irgendeine Entscheidung, und der Review ist die einzige Meinung im Raum. Der Coder in seinem Kontext trifft jeden Einwand mit Wissen, das dem Reviewer fehlt. Der Reviewer als Fixer hat die Asymmetrie in die andere Richtung: Er sieht das Symptom, nicht die Entstehung, und seine Fixes sind lokal richtig und global inkohärent. Ob der Kontext den Unterschied allein erklärt, kann ich aus meiner Erfahrung nicht sagen. Dass der Unterschied da ist, schon.

Dasselbe gilt für Subagenten. Was ein Subagent gebaut hat, kennt der Hauptagent nur aus dem Abschlussbericht. Die Verteidigung im Review trägt nur für das, was im Hauptkontext entstanden ist.

Und ich am Ende der Schleife brauche nicht den Code. Ich brauche den Dialog. Ein Einwand und eine Stellungnahme dazu sind in Sekunden zu beurteilen: struktureller Einwand oder Geschmacksfrage, überzeugt oder nur nachgegeben. Das ist die Ebene, auf der meine Aufmerksamkeit noch sitzt. Der Dialog beweist nicht, dass alle lokalen Fehler gefunden wurden; wo eine strittige Aussage von der tatsächlichen Funktionsweise abhängt, muss ein Test sie klären. Aber lokale Fehler sind das, was die Schleife fängt. Architektur ist global, und die sieht kein Agent aus einem Task heraus.

Modellhandschrift und Modellwechsel

Der Reviewer ist ein anderes Modell, möglichst aus einer anderen Familie. Zwei Instanzen desselben Modells haben korrelierte blinde Flecken; was die eine plausibel findet, findet die andere auch. Ein Modellwechsel garantiert keine unabhängige Prüfung – auch verschiedene Modelle übersehen gelegentlich dasselbe –, aber er verkleinert die Schnittmenge.

Daneben gibt es einen Effekt, den ich beobachte und nicht beweisen kann: Ein Modell rekonstruiert Code leichter, den es selbst geschrieben hat. Nicht, weil es sich erinnert – es erinnert sich an nichts –, sondern weil der Code in seinem eigenen Dialekt vorliegt: Modulschnitt, Benennung, Fehlerbehandlung, Abstraktionsebene, alles dort, wo das Modell es selbst hinlegen würde. Es liest die eigene Handschrift mit geschlossenen Augen.

Die Forschung liefert dafür einen begrenzten Anhaltspunkt. Panickssery, Bowman und Feng zeigten 2024, dass Modelle eigene Zusammenfassungen überzufällig gut wiedererkennen und bei Bewertungen bevorzugen. Untersucht wurden Zusammenfassungen, nicht Code; ein besseres Verständnis selbst erzeugten Codes ist damit nicht nachgewiesen, und Chen und Kollegen weisen 2025 darauf hin, dass eine Bevorzugung eigener Antworten erst nach Kontrolle ihrer tatsächlichen Qualität als Verzerrung gelten kann. Die Handschrift-These bleibt also eine Hypothese. Die Kehrseite dagegen ist gut belegt und für die Praxis wichtiger: Ein Modell, das seinen eigenen Code liest, hält ihn tendenziell für richtig, weil er vertraut aussieht. Flüssig fühlt sich wie korrekt an. Genau deshalb muss der Reviewer fremde Handschrift lesen.

Daraus leite ich eine Regel ab, die unsymmetrisch aussieht: Den Coder wechsle ich nur mit Grund. Den Reviewer wechsle ich, gerade weil ich keinen brauche. Die Kontinuität beim Coder ist schon durch den erhaltenen Kontext begründet; ob die Handschrift darüber hinaus über Sessions hinweg hilft, ist die offene Hypothese – und sie wäre kein Grund, ein nachweislich besseres Modell vom Projekt fernzuhalten.

Was übrig bleibt

Alles zusammen ist die Wette, dass jede Investition ins Wie verloren ist und jede Investition ins Was gewinnt. Ziele, Randbedingungen, Entscheidungsgründe müssen zugänglich bleiben, wenn Modelle und Werkzeuge wechseln; alles andere darf wechseln.

Und was von meiner Rolle bleibt, wenn man das Tippen abzieht, ist ziemlich genau das: derjenige, der weiß, was gebaut werden soll, fragt, wie der andere es machen würde, das Ergebnis begutachtet – und erkennt, wann das Wie nicht mehr seine Sache ist. Das ist die Arbeitsteilung zwischen einem Auftraggeber und einem Handwerker, die einander trauen. Dass sie mit Agenten funktioniert, hat mich weniger überrascht als die Tatsache, dass ich dafür aufhören musste, den Code zu lesen.