Jeder kann sein eigenes „DeepSeek Harness“ bauen – wieso zahlen wir dann noch für die Premium-Mitgliedschaft von Claude Code und vergleichbaren Diensten?
„Wenn du Cursor nicht innerhalb weniger Stunden neu aufbauen kannst, wird dein nächstes Vorstellungsgespräch sehr schwierig – es handelt sich lediglich um eine while-Schleife mit 300 Zeilen Code.“
Geoffrey Huntley, der Schöpfer von Ralph Loop, legt die Untergrenze für Software-Ingenieure bei 300 Zeilen fest. Das scheint absurd, aber die Leute haben festgestellt, dass er wahrscheinlich Recht hat.
Im vergangenen Jahr sind die grundlegenden Pfade von Großunternehmen-Produkten wie Claude Code, Codex und Antigravity immer ähnlicher geworden: Die Agent Loop liest und schreibt Kontext, ruft Tools auf, führt wiederholt aus und sichert das Ganze durch Tests und Berechtigungen ab. Kontext, Tools, Loop, Gedächtnis und Multi-Agent sind nach und nach zu einem öffentlichen Standard-Kartenspiel geworden.
Neben den Großunternehmen tauchen auch persönliche Harness-Projekte in rasanter Geschwindigkeit auf.
Pi und Aider, die heute über eine riesige Community verfügen, haben beide als persönliche Projekte begonnen: Pi wurde von dem 41-jährigen österreichischen Software-Ingenieur Mario Zechner unabhängig entwickelt, Aider wurde von dem etwa 54-jährigen kanadischen Software-Ingenieur Paul Gauthier allein initiiert. Reasonix, das für DeepSeek optimiert ist, wurde von YHH, einem Entwickler von Spiel-Engines, persönlich ins Leben gerufen und entwickelte sich schnell zu einem Community-Projekt mit Zehntausenden von Sternen.
Nachdem DeepSeek die Rekrutierung für die interne Testphase von Harness angekündigt hatte, wurde der Kommentarbereich schnell zu einer „Messe für persönliche Harness“. Die Community hat Tausende von Antworten unter den Beiträgen zusammengestellt, darunter Hunderte von Open-Source-Repositories, die Bereiche wie Coding Agent, Gedächtnis, Fähigkeiten, Bewertung und Sicherheit abdecken. Fast jeder kam mit seinem selbstgebauten Harness, um sich selbst zu empfehlen.
Die Welt ist so wunderbar: Vor ein paar Monaten lag der Unterschied der Leute noch darin, „ob die Produktivitätssteigerung von KI-gestützten Entwicklern das Zweifache oder Hundertfache beträgt“, jetzt liegt der Unterschied darin, „ob man ein eigenes Harness schreiben kann“.
Aber wenn das Modell ausgetauscht werden kann, Harness nachgeahmt werden kann, gängige Komponenten bereits konvergieren und selbst einzelne Entwickler ein funktionsfähiges System zusammenstellen können, womit kann der Coding Agent noch Unterschiede schaffen? Dazu haben wir Tang Liu von TiDB, Ru Bingsheng vom Tencent Research Institute, Remy, den Architekten von Floatboat Harness, sowie Tianzhu von ByteDance Trae interviewt.
Es ist besser, ein Harness zu bauen als dem Modell nachzujagen?
In diesem Jahr haben viele Gründer bekannter Coding-Tools über ein Thema gesprochen: Bei täglichen Programmieraufgaben können die Modelle keine großen Unterschiede mehr erzeugen.
Thorsten Ball, Mitbegründer von Amp, sagte: „Das Modell ist tot.“ Die Belohnung für das direkte Verwalten eines einzelnen Modells wird immer geringer. Wir müssen nicht mehr ständig verschiedene Modelle anpassen und testen – sie werden alle schließlich das Niveau erreichen, wo man „einen Knopf drückt und einen John Carmack bekommt“.
Dax Raad, Mitbegründer von OpenCode, hat ein ähnliches Gefühl: Die Modelfirmen haben einen perfekten Bereich in Bezug auf die Benutzerfreundlichkeit gefunden. Wenn man neuere Modelle ausprobiert und dann zu dieser Generation zurückkehrt, merkt man, dass sie sich alle ähneln – „es ist egal, welches man benutzt“.
Mario Zechner, Gründer von Pi, glaubt, dass die Modelle heute nicht nur ihren Höhepunkt erreicht haben, sondern dass die Fähigkeiten neuer Versionen sogar zurückgehen können. Je leistungsfähiger das Modell ist, desto schwieriger ist es für die Hersteller, sicherzustellen, dass alte Fähigkeiten nicht verschlechtern – es gibt zu viele Anwendungsfälle in der realen Welt, die von Bewertungen nicht vollständig abgedeckt werden können. Daher werden Modelfirmen sich dafür entscheiden, ihr eigenes Harness zu fördern, da Harness der einzige Teil ist, den sie kontrollieren können, um zumindest die Änderungen einzudämmen.
Vor einigen Monaten hat ein inländischer Experte für Coding-Tools zu InfoQ gesagt: „Wenn das (inländische) Modell nicht gut genug ist, muss man es mit Tools ergänzen. Das Modell ist für die Entscheidungsfindung zuständig, das eigentliche Codieren, Debuggen und Refaktorisieren wird von den Tools im Harness erledigt.“
Aber jetzt hat sich die Situation geändert. Die Modelle können bereits die Komplexität der meisten täglichen Arbeiten bewältigen. Wenn alltägliche Aufgaben die Obergrenze der Fähigkeiten des Modells überhaupt nicht erreichen, ist es nicht mehr so wichtig, wessen Obergrenze höher ist wie früher.
Da die Modelle keine Unterschiede mehr erzeugen können, tritt der Wettbewerb in die Harness-Ebene ein.
Auch Harness konvergiert, aber die Konvergenz ist nicht das Ende
Harness ist kein neues Konzept. Bereits 2022, als ChatGPT gerade auf den Markt kam, zwang das Kontextfenster von 4000 Token die Entwickler, Tool-Aufrufe, MCP und RAG zu verwenden, um den Kontext zu verwalten – Cursor, Windsurf, Cline und Aider sind alle Produkte aus dieser Zeit. Später wurde das Kontextfenster größer, die Aufgaben wurden länger, und der Agent begann nach einigen Stunden Laufzeit, Zusammenfassungen zu komprimieren und wichtige Informationen zu verpassen. Einige haben Sub-Agenten eingeführt, andere haben Agent Swarm entwickelt – im Wesentlichen tun alle dasselbe: Eine bessere Laufzeitumgebung für das zugrundeliegende Modell zu schaffen.
Der Begriff „Harness“ wurde Anfang 2026 weit verbreitet, aber nach nur einem halben Jahr sind die Entwicklungsrichtungen aller bereits konsistent geworden.
Die innerste Schicht der Agent Loop, die für die Modellschleife, das Lesen und Schreiben von Dateien, die Kontextverwaltung und die Sicherheitssteuerung zuständig ist, kann nur etwa 200 Zeilen Code umfassen. Thorsten Ball, Mitbegründer von Amp, hat mit 315 Zeilen Go-Code von Grund auf einen Coding Agent geschrieben, der Dateien im Terminal lesen, suchen und bearbeiten kann.
Obwohl der Kern nur aus Hunderten von Zeilen Code besteht, muss ein vollständiges Harness noch viele Komponenten nach außen hin hinzufügen. Planner, Coder, Reviewer, Suche, Bearbeitung, Shell, Sub-Agent, MCP – Tang Liu vom TiDB-Team nannte eine Reihe von Namen und sagte dann: „Diese Dinge werden nach und nach zu Standardkomponenten.“
Er benutzte Datenbanken als Vergleich: MySQL, TiDB, PostgreSQL und Snowflake haben alle SQL, alle haben einen Optimizer, alle haben eine Storage Engine, aber niemand glaubt, dass sie gleich sind. Der echte Unterschied liegt nie darin, „ob diese Komponente vorhanden ist“, sondern darin, wie diese Komponenten zu einem System zusammengesetzt werden, das Probleme wirklich lösen kann.
Wie das konkret umzusetzen ist, hat das TiDB-Team seine eigene Antwort. Ihr neues Produkt TiDB Cloud Filesystem. Das Projekt selbst ist eine Erkundung – das Team hat es schrittweise weiterentwickelt und im Prozess der Zusammenarbeit mit KI gleichzeitig ein Harness verfeinert. Es wurde nicht im Voraus entworfen, sondern entstand schrittweise, als das Projekt immer wieder auf Engpässe stieß, Probleme identifizierte und die Ausführungsmethoden anpasste. Die Fertigstellung dieses Harness erfolgte sogar vor der Veröffentlichung des dynamischen Workflows von Claude Code.
Sie haben die innerste Agent Loop nicht von Grund auf neu geschrieben, sondern basieren hauptsächlich auf dem Open-Source-Projekt Pi. Aber Aufgabenorchestrierung, Berechtigungen, persistenter Status, Sandbox und Fehlerwiederherstellung wurden selbst implementiert. Die Designphilosophie lautet in einem Satz: Dünne Agent Loop, dicke Control Plane.
Warum nicht die Loop selbst schreiben? Weil die Agent Loop die Schicht ist, die sich am schnellsten ändert und am leichtesten homogenisiert wird. Modellprotokoll, Tool Calling, Streaming und Reasoning ändern sich ständig, und LLM-Unternehmen sowie Cloud-Anbieter werden sie früher oder später immer besser machen. „Wir brauchen uns hier nicht zu überbieten. Es reicht, auf den Schultern von Riesen zu stehen.“
Was wirklich selbst umgesetzt werden muss, sind die Probleme, mit denen Datenbankteams seit zwanzig Jahren zu kämpfen haben: Wie der Status persistiert wird, wie Berechtigungen zentralisiert werden, wie Nebenwirkungen gesteuert werden, wie nach einem Fehler wiederhergestellt wird, wie man nachweisen kann, dass ein Ergebnis wirklich korrekt ist, und wie man nach einem Problem Audits und Nachbesprechungen durchführt.
Der Hauptvorteil dieses Designs besteht darin, dass man bei einem Wechsel des Modells oder des Agent Core nicht von vorne anfangen muss. Anfangs verwendeten sie OpenCode, später wechselten sie zu Pi. Aber egal, wie der Agent oben wechselt, die Sandbox, Berechtigungen, Status und Steuerungsebene unten müssen nicht neu geschrieben werden. Je leistungsfähiger das Modell ist, desto mehr kann der Erkundungsraum in der Sandbox erweitert werden, aber es ist überhaupt nicht notwendig, gleichzeitig die Grenzen der Nebenwirkungen für echte Produktionssysteme aufzuheben.
Das ähnelt sehr Datenbanken. Komponenten wie SQL und Optimizer können immer intelligenter werden, aber Grenzen wie Transaktionen, Berechtigungen und Dauerhaftigkeit dürfen nicht verschwinden, nur weil „die obere Schicht intelligenter ist“. Das Agent Framework kann sich ständig ändern, aber die Grenzen von Status, Berechtigungen und Nebenwirkungen müssen stabil bleiben.
Dieses Harness unterstützte schließlich die Entwicklung und Inbetriebnahme von TiDB Cloud Filesystem innerhalb von drei Monaten. Persistente Workspaces über Session, Sandbox und Executor hinweg, Versionen, Zweige, Checkpoint, Rollback, Berechtigungen, Kontingente und Mandantenisolation – alles wird von Agenten erledigt, Menschen haben keine einzige Zeile Code geschrieben und keine einzige PR geprüft. Nach der Inbetriebnahme werden bereits Millionen von Agent-Workspaces darauf ausgeführt.
Die Unterschiede liegen in diesen unsichtbaren Stellen
Auch Harrison Chase, Mitbegründer von LangChain, hat den gleichen Trend beobachtet, nur mit einer zusätzlichen Einschätzung: Die Konvergenz findet statt, aber sie wird zu einem kontinuierlichen Spektrum führen.
Seine Beobachtung ist, dass allgemeine Harness bereits für viele grundlegende Aufgaben geeignet sind – dem Agent den Zugriff auf das Dateisystem zu ermöglichen und Sub-Agenten aufzurufen, reicht für die meisten Szenarien aus. Aber je ungewöhnlicher die Aufgabe ist, desto mehr braucht man ein angepasstes Harness. An einem Ende des Spektrums befinden sich fertige allgemeine Produkte, am anderen Ende vollständige angepasste kognitive Architekturen, und dazwischen gibt es unzählige Zustände der Anpassung über Hooks oder Middleware. Die Menschen treten meistens nicht wegen der Leistung zum angepassten Ende, sondern wegen der Vorhersehbarkeit und Kontrollierbarkeit, zum Beispiel in der Finanzbranche – Kunden opfern lieber ein wenig Intelligenz, um Kontrollierbarkeit zu erhalten.
Das andere Ende, die angepasste kognitive Architektur, bedeutet im Klartext, dass Domänenwissen, professionelle Tools und Expertenprozesse gemeinsam in das Harness integriert werden – das ist besonders entscheidend in vertikalen Bereichen.
Konkret zum Coding Agent meint Ru Bingsheng vom Tencent Research Institute, dass das Wissensengineering seine Fähigkeiten bestimmt.
Die meisten KI-Programmierarbeiten bestehen nicht darin, neue Projekte von Grund auf zu entwickeln, sondern Funktionen zu bestehendem Code hinzuzufügen oder Fehler zu beheben. Daher ist die Kernfähigkeit von Coding Harness, zuerst das bestehende System zu verstehen, dann nach softwaretechnischen Methoden zu beurteilen, wo welche Änderungen vorgenommen werden sollen, und durch schnelles Ausprobieren und Validieren einen geschlossenen Zyklus zu bilden.
Er teilt die Dinge, die ein gutes Harness erreichen muss, in drei Ebenen auf.
Erste Ebene: Verständnis des bestehenden Systems. Der Code vieler Projekte ist selbst ungeordnet, das Lesen des Codes allein reicht nicht aus. Am besten kombiniert man die ursprünglichen Anforderungen, das Systemdesign und den Code, um die ursprünglichen Funktionen, Geschäftslogik und spezifische Implementierungen zu verstehen. Nur dann kann der Agent verstehen, „warum dieses Ding so aussieht wie es aussieht“, und gezielt Schlussfolgerungen ziehen.
Das erfordert eine Menge Arbeit von Harness: Wie Wissen eingebunden wird, wie Code und Design abgebildet werden. Bei großen Projekten kann nicht der gesamte Code auf einmal in den Kontext geladen werden – man muss eine Top-Level-Modellierung durchführen, einen Code-Graph-Mechanismus aufbauen, um bei Bedarf relevante Module zu lokalisieren und dann innerhalb der Module durch Methoden wie grep feinere Code-Fragmente zu finden. All das muss von Harness erledigt werden.
Zweite Ebene: Projektbeschränkungen und Schlussfolgerung. Das Modell selbst muss softwaretechnische Fähigkeiten besitzen und gleichzeitig die Beschränkungen des spezifischen Projekts und des Code-Repositories verstehen. Harness muss diese Regeln für das Modell sichtbar machen, sicherstellen, dass es die Regeln während der Ausführung einhält, und nach Abschluss prüfen, ob die Regeln wirklich umgesetzt wurden.
Aber es reicht nicht, nur im Prompt zu schreiben „die Regeln einhalten“ – nachdem die Generierungsregeln festgelegt sind, braucht es auch einen Mechanismus zur Regelprüfung und Reflexion. Reflektieren Sie die generierten Ergebnisse, und die Reflexion kann mehr als eine Runde dauern. Die Ergebnisse mehrerer Reflexionsrunden werden zusammengeführt und dann iteriert, bis die Projektbeschränkungen erfüllt sind.
Dritte Ebene: Deterministische Validierung. Die Code-Generierung ist nur der Ausgangspunkt. Es hat keinen Sinn, wenn der Agent sagt „ich habe es repariert“ – man muss mit externen Invarianten nachweisen, dass es korrekt ist. Daher muss Coding Harness mit dem Continuous-Integration-System verbunden werden, um Testgenerierung, Testausführung, Ergebnisanalyse und Fehlerfeedback abzudecken und dann den Code basierend auf den Laufzeitergebnissen zu korrigieren. Um dies zu erreichen, benötigt Harness auch Fähigkeiten wie Unit-Test-Umgebungen, containerisierte Testumgebungen, Kompilierung und Ausführung, Ergebnisanalyse und Ergebnisdarstellung.
Nach der Code-Generierung können Kompilierung, Ausführung, Start der Umgebung und Beurteilung der Ergebnisse durch deterministische technische Mittel erledigt werden. Diese technischen Fähigkeiten sollten zu einem unverzichtbaren Bestandteil von Coding Harness werden.