Noch ein Agent-Harness, wirklich?

Ich bat GPT 5.6 Pro, sich die führenden quelloffenen Coding-Harnesses auf GitHub anzusehen und einen eigenen zu entwerfen, der ihre wichtigsten Funktionen abdeckt. Meine Vorgaben waren einfach: keine Abhängigkeiten, alles in Python.

Das ist sinngemäß wiedergegeben, trifft aber den Grad der Vorbereitung ganz gut. Ich wollte weder ein Unternehmen gründen noch eine sorgfältig recherchierte Marktlücke schließen. Ich wollte sehen, was passiert.

Ein paar Stunden später kam ChatGPT mit einem Ergebnis zurück, das gut genug war, um daran weiterzuarbeiten. Daraus wurde Borealis Coder.

Inzwischen hat das Projekt eine interaktive Terminaloberfläche, unterstützt verschiedene Modellanbieter und speichert Sitzungen. Dazu kommen Werkzeuge zum Bearbeiten von Code, Berechtigungskontrollen, Checkpoints und die Überprüfung von Änderungen. Die ursprüngliche Vorgabe, ohne Abhängigkeiten auszukommen, hat nicht unverändert überlebt: Zur Laufzeit kommt heute neben der Python-Standardbibliothek auch prompt-toolkit zum Einsatz.

Ich erwähne das, weil „Ich habe mir einen kompletten Coding-Agenten herbeigepromptet“ eine bequeme Geschichte wäre. Sie würde allerdings die anschließende Arbeit unterschlagen. Das erste Ergebnis machte es lohnenswert, das Projekt weiterzuverfolgen. Fertig war es damit nicht.

Ein Coding-Harness ist die Software um das Modell herum: Er stellt Werkzeuge und Kontext bereit, verwaltet die Sitzung und regelt, welche Aktionen der Agent ausführen darf. Aus der Ferne sieht die Aufgabe einfach aus. Man gibt einem Modell ein paar Werkzeuge, lässt es ein Repository untersuchen und ruft es so lange auf, bis die Aufgabe erledigt ist.

Fast alle interessanten Probleme stecken in diesem letzten Satz.

Was muss das Modell lesen, bevor es eine sinnvolle Änderung vornehmen kann? Wie viel davon sollte im Kontext bleiben? Welche Aktionen brauchen eine Freigabe? Wie kommt man zurück, wenn eine Änderung schiefgeht? Und woran erkennt man, dass die Aufgabe erledigt ist, statt nur daran, dass das Modell beschlossen hat aufzuhören?

Zwei Produkte können dasselbe Modell verwenden und sich trotzdem unterschiedlich verhalten, weil sie ihm andere Informationen, Werkzeuge, Berechtigungen und Rückmeldungen geben. Beim Bau von Borealis wurden diese Entscheidungen für mich viel greifbarer. Ein Beispiel war besonders lästig.

Eine Zeit lang fasste Borealis seinen Kontext alle paar Runden erneut zusammen. Diese sogenannte Compaction soll Platz für die weitere Arbeit schaffen: Der bisherige Gesprächsverlauf und die Ausgaben der Werkzeuge werden durch eine kürzere Darstellung des Wesentlichen ersetzt.

Als ich mir das genauer ansah, schrumpfte der Kontext nur um ungefähr 20 Prozent. Ein paar Runden später verdichtete der Agent ihn schon wieder. Er unterbrach die Arbeit immer wieder, um gerade genug Platz zu schaffen, dass fast sofort die nächste Aufräumrunde nötig wurde.

Ein Teil des Problems lag, so wurde mir klar, in meinen Vorgaben an die KI, die am Code arbeitete. Ich wollte hohe Effizienz und die bestmögliche Qualität der Ergebnisse. Beides klang vernünftig. Ich hatte nur nicht genau genug gesagt, was passieren sollte, wenn die beiden Ziele in unterschiedliche Richtungen zogen.

Mehr Informationen zu behalten kann verhindern, dass einem Agenten etwas Wichtiges verloren geht. Wer aber so viel bewahrt, dass die Arbeit ständig für die nächste Verdichtung unterbrochen wird, zahlt für diese Vorsicht einen Preis. Stärker zu kürzen birgt wiederum das Risiko, etwas zu verwerfen, das der Agent später noch braucht.

„Mach es effizient, ohne Abstriche bei der Qualität“ löste diesen Zielkonflikt nicht. Damit überließ ich die Entscheidung der KI.

Solche Fälle gab es immer wieder. Ich konnte eine Funktion anfordern und bekam eine Implementierung. Ich musste sie aber weiterhin benutzen, bemerken, wo sich die Software falsch verhielt, und herausfinden, welche meiner Anforderungen genauer werden mussten.

Für die Compaction wäre eine bessere Vorgabe gewesen, festzuhalten, was erhalten bleiben muss: die aktuelle Aufgabe, bereits getroffene Entscheidungen, ungelöste Fehler und Verweise auf relevante Dateien. Davon müsste man Material unterscheiden, das der Agent bei Bedarf erneut nachschlagen kann. Außerdem müsste klar sein, wie viel Platz für die weitere Arbeit entstehen soll. Anschließend müsste ich prüfen, ob der Agent die Aufgabe mit dem verkleinerten Kontext noch zu Ende bringen kann.

Das ist ein Beispiel für eine nützlichere Spezifikation, keine Behauptung, dass es ein passendes Kompressionsverhältnis für jede Aufgabe gibt. Ein kleinerer Kontext ist kein Erfolg, wenn der Agent vergisst, was er gerade tut. Details zu bewahren ist nicht kostenlos, wenn es zu ständigen Unterbrechungen führt.

Für mich ging es dabei darum, wie ich den Agenten anleite, der die Software baut: festlegen, welche Ziele Vorrang haben, wo Kompromisse vertretbar sind und woran ich einen schlechten Kompromiss erkennen werde.

Trotz dieser Arbeit hat mich überrascht, wie wenig nötig war, um einen ernstzunehmenden Ausgangspunkt zu bekommen.

Die Architekturideen waren öffentlich. Bestehende Projekte hatten viele der wichtigen Entscheidungen bereits durchgespielt. Ein leistungsfähiges Modell konnte sich dieses Material ansehen und dabei helfen, daraus eine weitere Implementierung zu machen.

Ich habe keinen Benchmark, der zeigt, dass Borealis mit Claude Code oder Codex mithält. Eine Funktionsliste würde das auch nicht belegen. Dass etwas „Kontextverwaltung“ heißt, sagt wenig darüber aus, wie gut es bei einer schwierigen Aufgabe funktioniert. Das hatte ich mir gerade selbst vorgeführt.

Trotzdem brachte mich die Erfahrung dazu, eine Annahme zu hinterfragen: dass der Aufwand, eine Software zu bauen, ihrem Entwickler zwangsläufig viel Schutz vor Konkurrenz bietet.

Etwas kann beim ersten Mal viel Arbeit kosten und sich trotzdem vergleichsweise leicht nachbauen lassen. Sobald das Verhalten sichtbar ist und die relevanten Ideen zugänglich sind, braucht die nächste Implementierung möglicherweise deutlich weniger Aufwand.

Wenn der eigene Vorsprung vor allem darauf beruht, dass Konkurrenten nicht genug Entwicklungszeit für dieselben Funktionen haben, scheint mir das eine zunehmend unbequeme Position zu sein.

Aus einem Nebenprojekt würde ich nicht schließen, dass Softwareunternehmen keine dauerhaften Wettbewerbsvorteile mehr haben.

Jemanden dazu zu bringen, ein Produkt auszuprobieren, ist eine andere Aufgabe, als es zu implementieren. Ihm einen Grund zu geben, dabei zu bleiben, noch einmal eine andere. Ein Werkzeug kann schwer ersetzbar werden, weil Menschen ihm vertrauen, weil es ungewöhnlich gut zu ihrer Arbeit passt oder weil ein Wechsel Abläufe stören würde, auf die sie angewiesen sind. Nichts davon hat mein Experiment nachgebildet.

Auch das Compaction-Problem macht meine eigene Argumentation weniger eindeutig. Eine plausible Implementierung zu bekommen war überraschend einfach. Die Entscheidungen zu treffen, durch die daraus etwas wurde, das ich selbst benutzen wollte, verlangte mehr von mir. Ob dieses Urteilsvermögen einen dauerhaften Wettbewerbsvorteil ergibt, weiß ich nicht. Überflüssig hatte der Code es jedenfalls nicht gemacht.

Und das offensichtliche Problem mit einer Nische, die größere Produkte übersehen: Ein anderes kleines Team kann dieselbe Nische entdecken. Diese Werkzeuge stehen ihm ebenfalls zur Verfügung.

Ich habe keine befriedigende Antwort darauf, was das für die Softwareentwicklung bedeutet. Aber „Wir haben es gebaut, und das war schwer“ sollte man als Geschäftsargument genauer prüfen.

Und warum ich nun noch einen Coding-Harness gebaut habe: Du brauchst ihn wahrscheinlich nicht. Die meisten Menschen werden ihn vermutlich nie benutzen.

Ich habe weiter daran gearbeitet, weil ich dabei Dinge gelernt habe, die mir beim Zuschauen auf X entgangen wären. Irgendwann war ich selbst derjenige geworden, bei dessen Produktvorstellung ich ursprünglich die Augen verdreht hatte.