Nach einem Artikel von AI Times zum Thema Harness Engineering Harnesslosigkeit von Big Tech haben mehrere Tech-Führungspersonen ihre Meinungen dazu ausgetauscht. Der Bericht besagte, dass nach Google auch OpenAI äußerte, dass die Modelle der nächsten Generation erhebliche Teile der aktuellen Harness-Funktionalität absorbieren könnten.
Dieser Beitrag trägt zu dieser Diskussion bei. Um das Fazit vorwegzunehmen: Ich stimme der Prognose zu, dass die meisten Harnesses nutzlos werden. In meinem Artikel Harness Engineering umfassend erklärt — Ursprünge, Konzepte, Lücken und Zukunft auf einen Blick habe ich selbst geschrieben, dass komplexe Harnesses, die zur Korrektur von Modellschwächen entwickelt wurden, schnell ersetzt werden, wenn das Modell besser wird.
Doch wenn man daraus ableitet, dass alle Harnesses bald überflüssig werden, verpasst man das Wesen des Harnesses. Das Problem der Modellfunktionsabsorption ist ein anderes als das Problem der Verantwortungsverwaltung, wenn Menschen und Organisationen Arbeit an KI delegieren.

Zuerst müssen wir sehen, wie Schlüsselwörter zirkuliert werden
Allerdings zirkulieren Tech-Schlüsselwörter in den meisten Fällen anders im In- und Ausland. Daher habe ich zuerst Überprüfungen durchgeführt. Auch diesmal müssen wir zwischen den ursprünglichen Aussagen, den tatsächlichen technischen Diskussionen und dem im Inland gebildeten Rahmen unterscheiden.
Das Folgende ist ein Vergleich der globalen und einheimischen Konsumption des Schlüsselworts Harness Engineering aus meinem Artikel Harness Engineering umfassend erklärt — Ursprünge, Konzepte, Lücken und Zukunft auf einen Blick.
| Kategorie | Global | Korea |
|---|---|---|
| Diskursführung | Öffentliche Analysen von Ingenieuren und Praktikern stehen im Mittelpunkt. Artikel und Fallstudien von Praktikern wie Hashimoto und Martin Fowler bilden die Achse. | Medien, Bildungsplattformen und einige Tech-Influencer verbreiten Artikel, Zusammenfassungen und Erklärungen schnell. |
| Primäre Kanäle | GitHub, Tech-Blogs, X (Twitter), offizielle Fallstudien | YouTube, Brunch, Blogs, Artikel |
| Vertiefungsmaterial | Fallstudien wie OpenAI und Analysen von Martin Fowler behandeln Originaltext, Code und Betriebserfahrung zusammen. | Der Umlauf konzentriert sich auf Übersetzungen und Zusammenfassungen, und die primäre Fallproduktion ist relativ begrenzt. |
| Praktische Erfahrungsteilung | Unternehmen wie Stripe mit über 1.000 PRs pro Woche und Salesforce veröffentlichen operative Zahlen und Fehlererfahrungen. | Einige führende Unternehmen wie Toss und Channel Talk teilen praktische Erfahrungen, aber es ist schwierig, dies auf die gesamte Branche zu verallgemeinern. |
Der Grund für die Vorsicht bei einer überinterpretation liegt darin, dass es in der englischsprachigen Welt keinen klaren Beweis für die weit verbreitete Verwendung von Begriffen wie „harness is dead" oder „harness is useless" gibt. Es ist näher an einer Diskussion, dass die Fähigkeit von Modellen zur Werkzeugnutzung besser wird und einige Gerüste von Modellen oder Plattformen absorbiert werden, was die Lebensdauer von komplexen, handgestrickten Abstimmungsschichten verkürzen könnte. Außerdem habe ich die ursprüngliche Quelle der Aussage von Vizepräsident Noam Brown nicht direkt überprüft; ich bin auf sie nur durch nationale und internationale Berichterstattung gestoßen. Daher möchte ich mich auf den Rahmen der „Harness-Harnesslosheitsthese" konzentrieren, der schnell im Inland verfestigt wurde.
Harnesses, die verschwinden, sind anders als Harnesses, die bleiben
Es ist klar, welche Harnesses verschwinden. Die Praxis, Prompts in mehrere Schritte aufzuteilen, temporäre Regeln zur Umgehung spezifischer Modellschwächen, flache Arbeitsabläufe, in denen die Reihenfolge der Werkzeugaufrufe von Menschen festgelegt wird – diese können absorbiert werden, wenn das Modell besser wird. Es ist richtig, dass diese Art von Harnesses verschwinden.
Doch wie die Zusammenfassung von Lee Dong-soo von A2Sys zeigt, ist es meines Erachtens riskant, dies auf alle Harnesses zu verallgemeinern. Zusammengefasst sieht es so aus:
- Prompt- und Arbeitsablauf-Harnesses können vom Modell absorbiert werden. Ich stimme zu.
- Werkzeugausführungs-Harnesses befassen sich mit Berechtigungen, Genehmigungen und Fehlerwiederherstellung. Sind das wirklich Harnesses, die verschwinden werden?
- Laufzeit-, Speicher- und Infrastruktur-Harnesses befassen sich mit Kontext, Caching, Modell-Routing, Kosten, Latenz und Audit-Protokollen. Ich glaube auch, dass es schwierig ist, diese Art von Harnesses als Harnesses zu sehen, die verschwinden.
Der Kern des Harnesses, den ich in den Kapiteln 7 bis 11 von 「Harness Engineering: Re:Start from Zero AI Software Engineering」 beschrieben habe, liegt genau hier. Verträge legen zulässige Bereiche fest, Struktur und Isolation begrenzen Änderungsbereiche, und Nachverfolgbarkeit und Validierung verbinden ursprüngliche Ziele mit tatsächlichen Ergebnissen. Messungen und Betrieb verwalten Kosten, Berechtigungen, Ausfallzeiten und Wiederherstellung. Harness Engineering in diesem Bereich ist nicht etwas, das durch bessere Modelle gelöst wird.
Andererseits ist die Behauptung, dass Harness, Schleifen und Prompt Engineering menschliche Heuristiken sind, ebenfalls wahr. Alle Methodologien beginnen mit Heuristiken. Typen, Tests, CI, Code Reviews und Berechtigungstrennung sind alle von Menschen geschaffene Methoden, um komplexe Systeme zu handhaben. Aber noch wichtiger ist hier: Können wir Transparenz und Verantwortung wirklich dem Flaggschiff-Modell überlassen? Wenn wir etwas delegiert haben, kann die KI nicht selbst überprüfen, ob die Absicht umgesetzt wird, oder ob Verantwortung überschritten wird und Probleme auftreten. Natürlich könnte es eine KI geben, die dies überwacht und korrigiert, aber dann wäre das ein Harness.
In einem Kommentar unter der Nachricht von Professor Han Sang-ki schrieb ich diese Position folgendermaßen auf:
Harness Engineering hängt davon ab, wie weit es reicht. Solange es die Absicht von Organisationen und Entwicklern gibt, wird es schwer sein, es zu beseitigen.
Je intelligenter das Modell wird, desto größer ist die Möglichkeit, dass die KI etwas noch Seltsameres noch wunderschöner bis zum Ende macht. Daher ist Harness kein Gerät zur Korrektur von Modellschwächen, sondern ein Betriebsgerät zur Fixierung von Richtung und Verantwortung.
In der praktischen Betriebspraxis kommt die Verantwortungsgrenze vor der Modellfähigkeit
Nextain führt Entwicklungsprojekte mit Kunden über Discord durch. Und heute habe ich hier einen Claude Code-Agenten, der auf einem bestimmten Problem arbeitet, eingegeben. Der auf dem Server bereitgestellte Nextain-Agent (tatsächlich Claude Code) liest den Discord-Kanal und antwortet.
Eine nicht-technische Betreiberin im Kanal übermittelte Testergebnisse, Mängel und Anforderungen. Und als sie anfangen, das zu bearbeiten, das verarbeitet werden kann, frage ich um Genehmigung, wenn wichtige Deployments oder Ressourcen berührt werden müssen, auf die nicht zugegriffen werden darf.
Da die Person, die die Anfrage gestellt hat, zunächst frustriert war, weil die Anfrage gestellt wurde und die Arbeit sofort begann, erteilte ich Anweisungen zum Arbeitsprozess. Wenn die Anforderung empfangen wird, bestätigen Sie zunächst den Erhalt, führen Sie eine Analyse durch, erstellen Sie einen Plan, berichten Sie dann erneut über den Plan im Discord-Kanal, führen Sie die Arbeit durch. Und wenn die Arbeit abgeschlossen ist, geben Sie einen Abschlussbericht ab, und wenn während des Prozesses Probleme auftreten, rufen Sie mich (den Entwicklungsleiter) auf und fragen Sie nach Entscheidungen auf Discord.
Der Kern dieses Harnesses ist die Entwicklungsprozesse von Nextain und die Behörden der einzelnen Mitglieder. Wenn dies ein Flaggschiff wäre, würde es von selbst auf die beste Art und Weise arbeiten? Ist die beste Methode wirklich die einzige? Konsistenz in Organisation und Arbeitsprozess ist letztlich ein Harness. Diese Verantwortungsgrenze unterscheidet sich von der Modellfähigkeit. Je mehr die KI tun kann, desto strenger müssen wir zwischen dem, was getan werden kann und wo es aufhören muss, unterscheiden.
Das Problem in der Praxis ist Drift und Kosten
Das Problem, dem Entwickler, die Codex und Claude verwenden, gegenüberstehen, ist immer noch Drift. Auch wenn das Ziel eingegrenzt wird, treibt es eine andere Richtung, nimmt Änderungen vor, die nicht gemacht werden sollten, ändert Tests, um Erfolg zu beanspruchen, und verpasst die Grenzen der Betriebsgenehmigungen. Je ausgefeilter das Modell wird, desto gleichmäßiger kann dieses Problem verborgen werden.
In dieser Situation ist die Antwort „einfach mehr laufen" für Big Tech möglich. Sie können Inferenzzeiten verlängern, mehr Kandidaten erstellen, fehlgeschlagene Pfade verwerfen und externe Validierung hinzufügen. Aber ein durchschnittlicher Entwickler und ein kleines Startup, das jeden Cent sparen muss, können das nicht tun. Das Gleiche gilt für die Realität inländischer Unternehmen.
In den Kommentaren oben mit Professor Han Sang-ki wies Jeong-woo Ha, ehemaliger AI Future Planning Secretary, auf „Token-Gesamtkosteneffizienz" hin. Harness ist kein Gerät zur Ablehnung von Flaggschiff-Modellen. Es ist ein Kostenregelungsgerät, um teure Modelle nur für wirklich notwendige Urteile zu verwenden und wiederholbare Arbeiten in kleine Modelle, lokale Tools, Scripts und deterministische Validatoren aufzuteilen.
Die kürzlich angekündigten mathematischen Erfolge von OpenAI müssen auch in zwei Zeitpunkten unterschieden werden. Ich schätze den ersten Erfolg im Zusammenhang mit dem Erdős-Ebenenabstandsproblem-Gegenbeispiel hoch ein, da es die Möglichkeit zeigt, dass die KI allein eine neue mathematische Verbindung finden könnte, die sich von bisherigen Ansätzen unterscheidet.
Im Gegensatz dazu wird das später stärker betonte Test-Time-Computing in Richtung der Investition von mehr Berechnungen, Kandidatenerkundung, Validierung und Iteration bei der Inferenzzeit durchgeführt. Das ist auch eine wichtige Technologie. Aber wenn man es nur als reine Intelligenzsteigerung eines einzelnen Modells darstellt, verschwindet die Kostenstruktur. Es ist eine Bulk-Strategie, aber eine Technologie, die besonders für Big Tech vorteilhaft ist.
Harness ist eine Verteidigungslinie gegen Kosten und Daten
„Das Modell wird das Harness auffressen" ist eine reißerische Aussage. Aber die Frage, wer das Modell und zu welchem Preis benutzt, ist ein anderes Problem. Mit der Absorption von mehr Funktionen durch Modelle kann der Code des Benutzers einfacher werden. Gleichzeitig kann es auch bedeuten, dass mehr auf teurere Modellaufrufe angewiesen ist. Komplexität verschwindet nicht, sondern verlagert sich vom Arbeitsbereich des Benutzers auf die Abrechnungsschicht des Modellanbieters.
Es ist das Gleiche mit Daten. Damit ein Agent wirklich nützlich wird, muss er Dokumente, Code, Zeitpläne, E-Mails, operative Protokolle, Fehlerhistorie, Genehmigungsflüsse und Kundendaten sehen. Wenn der Agent zum Arbeitsbereich wird, wird die gesamte Arbeit des Benutzers zur Eingabe.
Ein gutes Harness sendet nur den notwendigen Kontext an externe Modelle und bewahrt den Rest im Arbeitsbereich des Benutzers. Es routet Modelle, verwendet Cache erneut, teilt Berechtigungen auf und fügt wiederholbare Validierung hinzu. Daher ist Harness eine Verteidigungslinie gegen Kosten und eine Verteidigungslinie gegen Daten.
Aus dieser Perspektive ist es möglich, dass globale Modellunternehmen ein starkes Benutzer-seitiges Harness unangenehm finden. Wenn Benutzer zuerst kleine Modelle und lokale Tools verarbeiten und nur bei Bedarf das Flaggschiff aufrufen, verringern sich Aufrufe und übertragener Kontext. Dies ist nicht wirklich eine voreilige Schlussfolgerung, sondern ein natürlicher Überlegungspunkt in einer Industriestruktur, in der die Frontier-Modellentwicklung, Inferenz, GPU und Stromkosten steigen.
OpenAI und Anthropic befinden sich mit Codex und Claude Code an der Spitze des Harness-Wettbewerbs. Google hingegen ist sowohl ein Modellunternehmen als auch ein Cloud-Dienst. Es ist unmöglich zu sagen, dass jedes Unternehmen genau die gleichen Interessen hat, aber es ist klar, dass dieser Streit nicht nur als reine technische Vorhersage zu hören ist. Ein gutes Harness reduziert das „Verlangen der Big Tech, den Arbeitsbereich zum Modell zu verschieben, Daten zu sammeln und sich auf die Nutzung des Flaggschiffs zu verlassen".
Schleifen sind nicht der Standard der nächsten Generation
Das Gleiche gilt für Schleifen. Ich verwende Schleifen, aber ich denke, dass für die meisten Missionen es besser ist, keine Schleifen zu verwenden. Wenn es sich um ein Stück Arbeit handelt, das gute Ergebnisse erzielen kann, wenn es einem normalen Entwickler anvertraut wird, ist es wahrscheinlich billiger und schneller, ein gutes Modell einmal richtig zu verwenden. Überraschenderweise ist der Fall, in dem Schleifen effektiv sind, eng.
Erstens, Forschung und Entwicklung. Arbeit, bei der es keine Antwort gibt, die Hypothese sich je nach Versuchsergebnis ändert und das nächste Experiment die vorherigen Ergebnisse aktiv lesen und ändern muss. Das ist der Fall bei unserer internen Audio- und Gesangsforschung. In diesem Fall überprüfen mehrere AIs die Versuchsergebnisse und Gesamtdaten, und bestimmen die Kontinuität der vorherigen Experimente, Drift und die Notwendigkeit des nächsten Zyklus. Das Endziel ist nicht plausibles Ergebnis, sondern eine Beurteilung, dass die Indikatoren nicht mehr steigen. Da Konvergenz der Exploration das Ziel ist, sind Schleifen angemessen.
Zweitens, wenn Sie kleine Modelle in eingeschränkten Umgebungen verwenden. Kleine LLMs neigen dazu, das Ziel zu reduzieren und zu denken, dass „das so weit ausreicht". Aber was notwendig ist, ist in diesem Fall eher ein Gerät, das Ziel und Endbedingung schließt als eine lange Schleife. Es ist näher an Claude Codes Goal-Funktion als an einer Schleife – ein Harness. Wenn Sie Schleifen bei alltäglichen Aufgaben regelmäßiger Benutzer verbreiten, wird dies zu Kostenverschwendung. Schleifen werden für Konvergenz der Exploration verwendet, und Harnesses werden zum Fixieren von Zielen und Verantwortung verwendet. Die beiden sind nicht austauschbar.
Naia möchte den Arbeitsbereich auf der Benutzerseite halten
Naia lehnt das Flaggschiff-Modell nicht ab. Wir planen, das Cloud-Flaggschiff in der Entwicklung gründlich zu nutzen. Gute Modelle sollten genutzt werden.
Aber wir haben nicht die Absicht, alle Arbeitsbereiche und Daten an Big Tech-Plattformen zu übergeben. Die Struktur, die Naia anstrebt, ist das Zusammenverwenden von lokalen, P2P-, Open-Weight-, kleinen Modellen, deterministischen Validatoren und expliziten Berechtigungsharnesses. Teure Flaggschiffe sollten für notwendige Urteile verwendet werden, aber der grundlegende Arbeitsbereich sollte in den Händen der Benutzer bleiben.
Aus dieser Perspektive ist die Entwicklung von Open-Weight-Modellen wie DeepSeek, Qwen, Kimi und GLM wichtig. Es wird möglich, Modelle je nach Zweck zu kombinieren, Daten lokal zu schützen und nur bei Bedarf geschlossene Flaggschiffe aufzurufen. In Korea haben auch die eigenen Modellstrategien von Upstage und Naver in diesem Flow eine Bedeutung. Anstatt den Flaggschiff-Modellen von Global Big Tech zu folgen, könnte es praktischer sein, Open-Weight, eigene Modelle, spezialisierte Harnesses und inländischen Geschäftskontext gut zu verbinden.
Modelle können gemietet werden. Aber Sie müssen nicht den Arbeitsbereich und die Daten mieten.
Fazit: Was wir brauchen, ist eine technische Diskussion auf höherem Niveau als die Harnesslosheitsthese
Harnesses, die verschwinden, werden verschwinden. Es wird auch mehr Funktionen geben, die Modelle absorbieren. Es gibt keinen Grund, dies zu leugnen. Aber ich glaube nicht, dass die vom Modell aufgenommenen Funktionen, das Ausführungssystem, das die Absicht und Verantwortung der Organisation fixiert, und das Betriebssystem, das Kosten- und Datengrenzen schützt, verschwinden. Wenn der Mensch der Hauptakteur ist, der der KI eine Aufgabe gibt, und der Mensch die Verantwortung für das Ergebnis trägt, dann verschwinden Verträge, Struktur, Nachverfolgbarkeit, Validierung und Betrieb nicht.
Ich wünsche mir, dass wir solche Schlüsselwort-Debatten darüber beenden, ob das Harness tot oder lebendig ist. Ich würde gerne sehen, dass echte technisch orientierte Diskussionen voranschreiten, wie zum Beispiel: Was sollten Sie ins Modell einbauen, was sollten Sie unter der Kontrolle von Benutzern und Organisationen halten, wie validieren Sie Drift und kehren ihn zurück, und wer trägt die Token-Kosten und Datenbelastung.
Referenzen und Quellen
Meine Artikel und Bücher
- 「Harness Engineering: Re:Start from Zero AI Software Engineering」
- 「Harness Engineering umfassend erklärt — Ursprünge, Konzepte, Lücken und Zukunft auf einen Blick」
- 「Nachricht zur Veröffentlichung von Harness Engineering」
Direkter Kontext dieser Diskussion
- AI Times, "Nach Google auch OpenAI 'Harness-Harnesslosheitsthese'... Modelle werden Funktionen absorbieren"
- AI Times, "[25. Juni] 'Das Modell wird das Harness auffressen'..."
- Facebook-Diskussion und Kommentare von Professor Han Sang-ki
- Lee Dong-soo, CEO von A2Sys, "Harness-Harnesslosheitsthese? Halb richtig und halb falsch"
Originaltexte und technische Ressourcen
- OpenAI, "Learning to Reason with LLMs"
- OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
- OpenAI, "Introducing Codex"
- OpenAI, "Introducing OpenAI o3 and o4-mini"
- Google, "Gemini 2.0: our new AI model for the agentic era"
- "The Interplay of Harness Design and Post-Training in LLM Agents"
- "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
- "AutoHarness"