Komponenten eines Coding-Agenten

• Coding-Agenten sind Systeme, die aus einer Steuerungsschleife und einem Software-Harness rund um ein LLM bestehen und das Schreiben, Ausführen und Verarbeiten von Feedback für Code wiederholt ausführen
• Das Agent-Harness ist für Kontextverwaltung, Tool-Zugriff, Prompt-Zusammenstellung und Zustandssteuerung zuständig; ein auf Coding-Aufgaben spezialisiertes Coding-Harness verwaltet Repository, Tests und Fehlerprüfung
• Coding-Agenten arbeiten mit sechs Komponenten: Live-Repository-Kontext, Prompt-Cache, Tool-Zugriff, Kontextverwaltung, Session-Memory und Delegation an Subagenten
• Selbst bei demselben LLM unterscheiden sich Leistung und Nutzererfahrung je nach Qualität des Harness-Designs stark; ein gut entworfenes Harness bietet eine kontinuierliche und kontextbewusste Entwicklungsumgebung
• Mini Coding Agent ist ein minimales Beispiel, das diese Struktur in reinem Python implementiert und sich von OpenClaw in der Coding-Spezialisierung und im Betriebsumfang unterscheidet

---

Komponenten eines Coding-Agenten

• Ein Coding-Agent ist ein System, das aus einer auf ein LLM zentrierten Steuerungsschleife und einem darum liegenden Software-Harness besteht; es wiederholt das Schreiben, Ändern, Ausführen und Verarbeiten von Feedback für Code
• Ein LLM ist ein grundlegendes Next-Token-Prediction-Modell, während ein Reasoning Model ein LLM ist, das darauf trainiert wurde, mehr Zwischenschritte beim Schlussfolgern und bei der Verifikation durchzuführen
• Ein Agent ist eine Steuerungsschleife, die zur Zielerreichung wiederholt Modellaufrufe, Tool-Nutzung, Zustandsaktualisierung und Entscheidungen über den Abschluss ausführt
• Das Agent-Harness ist die Software-Struktur, die diese Schleife umschließt, und übernimmt Kontextverwaltung, Tool-Zugriff, Prompt-Zusammenstellung und Zustandssteuerung
• Ein Coding-Harness ist eine auf Code-Arbeit spezialisierte Form davon und verwaltet Repository-Kontext, Code-Ausführung, Tests und Fehlerprüfung

Beziehung zwischen LLMs, Reasoning Models und Agenten

• Das LLM lässt sich als Motor, das Reasoning Model als verstärkter Motor und das Agent-Harness als System zur Steuerung dieses Motors verstehen
• LLMs und Reasoning Models können Coding-Aufgaben auch allein ausführen, doch in realen Entwicklungsumgebungen ist eine komplexe Kontextverwaltung nötig, etwa für Repository-Erkundung, Funktionssuche, Testausführung und Fehleranalyse
• Das Coding-Harness maximiert die Leistung des Modells und bietet ein deutlich leistungsfähigeres Coding-Erlebnis als eine einfache Chat-Oberfläche

Rolle des Coding-Harness

• Es ist die Software-Schicht, die das Modell umgibt, und übernimmt Prompt-Zusammenbau, Tool-Bereitstellung, Nachverfolgung des Dateistatus, Befehlsausführung, Berechtigungsverwaltung, Caching und Speichern von Memory
• Selbst bei demselben LLM unterscheiden sich Leistung und Nutzererfahrung je nach Harness-Design stark
• So kann selbst ein Open-Weights-Modell wie GLM-5 eine ähnliche Leistung wie Codex oder Claude Code erzielen, wenn es in ein Harness auf vergleichbarem Niveau integriert wird
• OpenAI hat Fälle, in denen harness-spezifische Nachbearbeitungsmodelle getrennt gepflegt wurden, etwa GPT-5.3 und GPT-5.3-Codex

Die 6 zentralen Komponenten eines Coding-Agenten

• 1. Live-Repository-Kontext (Live Repo Context)

  • Der Agent muss den aktuellen Git-Repository-Status, Branch, die Dokumentation und Testbefehle kennen
  • Anweisungen wie „Tests reparieren“ unterscheiden sich je nach Repository-Struktur und Kontext; deshalb werden vor der Arbeit zusammenfassende Repository-Informationen gesammelt
  • So startet der Agent nicht jedes Mal bei null, sondern verfügt über stabile Arbeitsgrundlagen (stable facts)

• 2. Prompt-Struktur und Cache-Wiederverwendung (Prompt Shape and Cache Reuse)

  • Repository-Zusammenfassung, Tool-Beschreibungen und allgemeine Anweisungen ändern sich oft kaum und werden daher als „stable prompt prefix“ gecacht
  • Statt bei jeder Anfrage den gesamten Prompt neu zusammenzusetzen, werden nur die geänderten Teile aktualisiert
  • Das reduziert in wiederholten Sessions Rechenverschwendung und hält die Antworten konsistent

• 3. Tool-Zugriff und Nutzung (Tool Access and Use)

  • Statt nur Befehle vorzuschlagen, kann das Modell über den vom Harness definierten Tool-Satz tatsächlich Befehle ausführen
  • Jedes Tool hat klare Ein-/Ausgabeformate und Grenzen, und vor der Ausführung werden Validierung und Freigabeprozesse durchgeführt
  • Beispiele: „Ist es ein bekanntes Tool?“, „Sind die Argumente gültig?“, „Liegt der Arbeits-Pfad innerhalb des Workspace?“
  • Das verbessert Sicherheit und Zuverlässigkeit; die Freiheit des Modells sinkt zwar, die Praxistauglichkeit steigt

• 4. Minimierung von Kontext-Aufblähung (Minimizing Context Bloat)

  • In langen Sessions kann durch wiederholtes Lesen von Dateien, Logs und Tool-Ausgaben das Problem zu langer Prompts entstehen
  • Das Harness verwaltet dies mit zwei Strategien
    • Clipping: Lange Texte, Logs und Notizen werden auf eine bestimmte Länge gekürzt
    • Summarization: Ältere Gesprächsverläufe werden komprimiert zusammengefasst
  • Neuere Ereignisse bleiben detailliert erhalten, ältere Informationen werden entdoppelt und komprimiert
  • Dadurch hat in der Praxis eher die Qualität des Kontexts als die Modellqualität den größeren Einfluss auf die Leistung

• 5. Strukturierter Session-Memory (Structured Session Memory)

  • Der Agent trennt seinen Zustand in Working Memory und vollständiges Gesprächsprotokoll (full transcript)
  • Das vollständige Protokoll enthält alle Anfragen, Antworten und Tool-Ausgaben und erlaubt das Wiederaufnehmen einer Session
  • Das Working Memory speichert aktuell wichtige Informationen wie aktuelle Aufgabe, zentrale Dateien und letzte Notizen in zusammengefasster Form
  • Das komprimierte Gesprächsprotokoll (compact transcript) dient der Rekonstruktion des Modell-Prompts, während das Working Memory die Kontinuität der Arbeit aufrechterhält

• 6. Delegation mit begrenzten Subagenten (Delegation With Bounded Subagents)

  • Der Haupt-Agent erzeugt Subagenten, um Hilfsaufgaben parallel zu verarbeiten
  • Beispiele: den Ort einer bestimmten Symboldefinition, den Inhalt einer Konfigurationsdatei oder die Ursache eines Testfehlers in getrennte Teilaufgaben auslagern
  • Subagenten erben nur den benötigten Kontext und werden durch Regeln wie schreibgeschützt oder begrenzte Rekursionstiefe eingeschränkt
  • Sowohl Claude Code als auch Codex unterstützen Subagenten und setzen Grenzen über Aufgabenbereich und Kontexttiefe

Zusammenfassung der Komponenten

• Die sechs Komponenten sind eng miteinander verbunden, und die Qualität des Harness-Designs bestimmt, wie effizient das Modell genutzt wird
• Ein gut entworfenes Coding-Harness bietet gegenüber einfachem LLM-Chat eine deutlich kontextbewusstere und kontinuierlichere Entwicklungsunterstützung
• Mini Coding Agent (https://github.com/rasbt/mini-coding-agent) ist ein minimales Beispiel, das diese Struktur in reinem Python implementiert

Vergleich mit OpenClaw

• OpenClaw ist weniger ein reiner Coding-Assistent als vielmehr eine allgemeine Agentenplattform
• Gemeinsamkeiten:
  • Nutzung von Prompt- und Anweisungsdateien (AGENTS.md, TOOLS.md usw.) innerhalb des Workspace
  • Enthält JSONL-Session-Dateien, Konversationskomprimierung und Session-Management
  • Hilfs-Sessions und Subagenten können erzeugt werden
• Unterschiede:
  • Coding-Agenten sind für Repository-Erkundung, Code-Bearbeitung und Ausführung lokaler Tools optimiert
  • OpenClaw legt den Schwerpunkt auf den langfristigen Betrieb von Agenten über mehrere Kanäle und Workspaces hinweg

Anhang: Hinweis auf das neue Buch

• Build A Reasoning Model (From Scratch) ist fertig geschrieben; derzeit ist eine Early-Access-Ausgabe verfügbar
• Der Verlag arbeitet am Layout mit dem Ziel einer Veröffentlichung im Sommer
• Das Buch fokussiert sich auf einen Ansatz, bei dem man die Schlussfolgerungsmechanismen von LLMs durch eigene Implementierung versteht

[GN⁺]

Hacker-News-Kommentare

• Langer Context ist immer noch teuer, und wenn zu viele unnötige Informationen enthalten sind, entsteht Rauschen
  Deshalb denke ich, dass spec-basierte Generierung besser ist als interaktives Coding
  Mein Ossature verfolgt den gegenteiligen Ansatz. Zuerst schreibt man eine Spec, die das Verhalten beschreibt; dann werden vor der Code-Generierung Lücken oder Widersprüche geprüft, und es wird ein Build-Plan-TOML erzeugt, das angibt, auf welche Spec-Abschnitte und Dateien sich jede Aufgabe bezieht
  Das LLM sieht nur die benötigten Teile, und es gibt keine angesammelte Gesprächshistorie. Alle Prompts und Antworten werden auf der Festplatte gespeichert, sodass Nachvollziehbarkeit automatisch gewährleistet ist
  Kürzlich habe ich auf diese Weise einen CHIP-8-Emulator vollständig nur aus einer Spec erstellt, und es gibt auch Beispielprojekte

  • Ich denke in letzter Zeit oft, dass heutigen Coding-Agenten eine zentrale Quelle der Wahrheit fehlt
    Früher wusste das ganze Team, woran gearbeitet wurde, heute startet der Agent jedes Mal wieder von vorn
    Deshalb glaube ich, dass ein Ablauf chat → spec → code die Zukunft ist. Die Phase spec → code sollte ohne menschliches Eingreifen laufen
    Wenn die Spezifikation unklar ist, sollte das System den Menschen gezielt um Klarstellung bitten und auf dieser Basis Code erzeugen
    Im Moment wiederholen sich unklare Anfragen, und auch der Mensch lernt nicht, warum das passiert. „Memory“ oder Agent-Dateien sind nur Notlösungen
  • Ich baue etwas Ähnliches. Noch nicht öffentlich, aber es ist eine spec-zentrierte Workflow-Engine
    Statt Konversationen gebe ich dem LLM projizierten Context aus Code und Spec und stelle den Context je nach Schritt unterschiedlich zusammen
    So verhindere ich Drift durch akkumulierten Context, und mein eigener Code statt des LLM steuert den Workflow
    Die Idee, TOML als Artifact für die Übergabe zwischen Schritten zu verwenden, finde ich interessant und werde sie mir abschauen
  • Ich denke genauso. Agent A verändert nur die Spec, und Agent B baut nur anhand der Spec
    Der Nutzer muss dann nur noch den von Agent A erzeugten Diff prüfen und ist von repetitiver Code-Verifikation befreit
    Der Kern ist, die Absicht (Intent) immer zu bewahren. Spezifikation und Kontext müssen unverändert gespeichert werden
    Die Kosten wären wohl 2- bis 3-mal höher, aber langfristig dürfte die Effizienz größer sein
  • Chat-basierte Workflows sind ermüdend und gehen mit viel Informationsverlust einher
    Ich halte einen spec-basierten Ansatz für deutlich besser. Mich interessiert, wie der menschliche Eingriff aussieht — ob Spec- und Audit-Bearbeitung parallel erfolgen, wie hoch die Erfolgsquote bei der Code-Generierung ist und ob das auch für bestehenden Code geplant ist
  • Ich versuche ebenfalls, mit der Kombination Claude Code + Cucumber bei der Spec anzufangen und den Code dann iterativ zu verbessern
    Mich würde interessieren, wie sich Ossature von diesem Ansatz unterscheidet

• Es ist beeindruckend, dass schon ein einfacher State Machine- und Bash-Ansatz das Potenzial von LLMs so gut ausschöpft

  • Deshalb baue ich gerade selbst einen isolierten Coding-Agenten
    Das heutige Agenten-Ökosystem ist voller überladener Funktionen und schlechter Entscheidungen
    Vor zehn Jahren hieß es noch, bei solchen Tools brauche es Verantwortungsbewusstsein, heute ist es eine chaotische Zeit aus Angst und Hype
  • Letztlich geht es um Prompt-/Context-Engineering
    Das Modell hat das Wissen bereits, aber um daraus praktisches Handeln zu machen, ist das Design des Contexts entscheidend
    Vielversprechend ist ein Ansatz, der Nutzeranfragen in die Denk- und Arbeitsschritte erfahrener Entwickler übersetzt und die nötigen Tools verbindet
    Ich denke, auch Open-Source-Modelle können mit gut optimierten Agenten und etwas Tuning absolut konkurrenzfähig sein
  • Wenn man sich den Claude-Code-Leak ansieht, ist die Struktur nicht simpel
    Man braucht ein komplexes Harness, aber genau dadurch funktioniert das LLM als Werkzeug deterministisch
  • Viele CLI-Agenten scheinen zu glauben, dass einfacher Bash-Zugriff nicht reicht, und stopfen deshalb mit Gewalt jede mögliche Funktion in ein JavaScript-TUI
  • Statt Bash war Python für mich nützlicher
    Anstelle von Pipelines kann man die gewünschte Logik frei zusammenbauen

• Die Beispiele sind knapp und klar
  Ich nutze keine Coding-Agenten, aber dieser Artikel hilft dabei, das Wesen von Coding-Agenten zu verstehen
  Er zeigt gut, wie selbst nützlicher Code mit nur 1k LOC in ein Chaos von 500k LOC verwandelt werden kann

• Viele Leute verbinden bereits offene Modelle wie GLM-5 mit Claude Code oder Codex CLI und nutzen sie auf diese Weise
  Auch die offizielle GLM-Dokumentation empfiehlt das

  • Es ist nicht auf Opus-Niveau, aber die Kombination aus GLM und Qwen3.5-plus ist für persönliche Projekte vollkommen stark genug

• Der Artikel war beeindruckend. Ich habe einen E-Mail-basierten Nicht-Coding-Agenten gebaut, und das Prinzip ist ähnlich
  Für jede E-Mail-Schleife startet der Context neu, wodurch das Problem des Context-Aufstaus ganz natürlich gelöst wird
  Entscheidend ist die Balance zwischen dem Context, der in den Initial-Prompt gehört, und dem, der besser als Tool ausgelagert wird
  Auch Caching und Token-Kosten muss man berücksichtigen
  Mehr Details habe ich in meinem Blogpost zusammengefasst

• Das Wort „harness“ gefällt mir nicht. Ich frage mich, ob es keinen besseren Ausdruck gibt

  • Es wird oft im Sinn eines Shim verwendet, das ein Programm steuert, wie bei „test harness“ oder „fuzzing harness“
  • Ironischerweise ist heute alles eine „App“, aber ausgerechnet eine App zur Ausführung von LLMs nennt niemand „App“
  • Letztlich ist „harness“ nur ein schicker Ausdruck für Scaffolding
  • Darauf kam auch die Reaktion, man solle dann doch bitte ein alternatives Wort vorschlagen

• Tool-Output-Truncation ist sehr wirksam, um aufgeblähten Context zu reduzieren
  Ich setze SQLite-basiert den Context zusammen und stelle bei Bedarf abgeschnittene Tool-Aufrufe per Message-ID wieder her
  Zugehörige Experimente habe ich in der Dokumentation beschrieben

• Claude Code mit anderen Modellen zu betreiben, ist üblich
  Das steht auch in der Beispieldokumentation
  Aber meiner Erfahrung nach reicht es nicht an das Niveau der Anthropic-Modelle heran

  • Je nach Projekt kann man mit günstigen Modellen wie MiMo V2 Pro zwar 70–80 % erreichen, aber Sonnet ist in vielen Fällen deutlich besser
    Opus lohnt sich vom Preis-Leistungs-Verhältnis nur in etwa 5 % der Fälle
    Ich finde OpenCode viel besser als Claude Code und habe deshalb OpenRouter-API-Credits gekauft
    OpenCode ist schon mit benutzerdefinierten Befehlen und einfachen Agent-Definitionen stark genug
    Wenn man den Workflow über AGENTS.md, ROADMAP.md usw. definiert, reicht das für die meisten Projekte vollkommen aus
    Ich glaube, dass eine flexible Struktur besser auf die schnellen Veränderungen moderner Modelle reagiert als ein komplexes Harness
  • Mich würde interessieren, ob Anthropic-Modelle einfach wegen ihrer Modellqualität besser sind oder wegen Harness-Optimierung

• Die Fortschritte bei Coding-Agenten kommen stärker aus Verbesserungen der umgebenden Struktur (Scaffolding) als aus dem Modell selbst
  Sobald Tools, Repository-Context und eine einfache Zustandsmaschine vorhanden sind, verschiebt sich der Flaschenhals zur Qualität des Contexts

• Der Artikel hatte Wucht. Ich erkläre Coding-Agenten ebenfalls gern mit der Motor-/Auto-Metapher
  Wer mit den grundlegenden Bausteinen experimentieren möchte, sollte sich das OpenHands software-agent-sdk ansehen