Die Coding-Leistung von 15 LLMs wurde verbessert – geändert wurde nur das Harness

 (blog.can.ac)
35 Punkte von GN⁺ 2026-02-13 | 3 Kommentare | Auf WhatsApp teilen
  • Tests mehrerer LLMs unter identischen Bedingungen zeigen, dass sich die Leistung bereits durch den Austausch des Code-Editierwerkzeugs deutlich verbessern lässt
  • Statt der bisherigen Patch- und Replace-Methoden wurde das „Hashline“-Format eingesetzt, das jeder Codezeile einen Hash-Tag zuweist und so die Bearbeitungsgenauigkeit erhöht
  • Hashline erzielte bei 14 von 16 Modellen eine höhere Genauigkeit als die bisherigen Verfahren; zudem wurde eine durchschnittliche Token-Ersparnis von 20–30 % bestätigt
  • Besonders beim Modell Grok Code Fast 1 sprang die Erfolgsquote von 6,7 % auf 68,3 % – eine Verzehnfachung allein durch eine einfache Änderung des Harness
  • Die Studie zeigt, dass eher das „Harness“ als das Modell selbst der Flaschenhals der tatsächlichen Leistung ist, und betont die Notwendigkeit von Zusammenarbeit im Open-Source-Ökosystem

Überblick über den Benchmark für Code-Editing

  • Das Experiment verglich drei Editierformate: Patch, Replace und Hashline
    • 16 Modelle bearbeiteten dieselbe Aufgabe zur Korrektur von Code
    • Jedes Modell wurde getestet, indem es Bugs in zufällig ausgewählten Dateien einer React-Codebasis beheben musste
  • Das Hashline-Format lieferte bei 14 Modellen bessere Ergebnisse als Patch und sparte im Schnitt 20–30 % Tokens
    • Die größte Verbesserung zeigte Grok Code Fast 1: Die Erfolgsquote stieg von 6,7 % auf 68,3 % (+61,6 Prozentpunkte)
    • Gemini 3 Flash verbesserte sich um 5,0 Prozentpunkte, Claude Sonnet 4.5 um 1,6 Prozentpunkte

Das Harness-Problem

  • Die aktuelle Diskussion konzentriert sich meist auf die Frage, „welches Modell am besten programmieren kann“, doch der eigentliche Flaschenhals ist nicht das Modell, sondern das Harness
    • Das Harness ist die zentrale Schnittstelle, die Eingabetokens verwaltet und die Modellausgabe mit Änderungen im Workspace verbindet
    • Die meisten Fehlschläge entstehen nicht durch das Modell, sondern durch strukturelle Grenzen des Harness
  • Der Autor versuchte Verbesserungen in einem persönlichen Projekt namens oh-my-pi, einem Fork des Open-Source-Coding-Agenten Pi, und führte dabei rund 1.300 Commits aus
    • Diese Umgebung ist modellunabhängig und erlaubt Experimente, bei denen nur das Harness als Variable verändert wird

Grenzen bestehender Editierwerkzeuge

  • Die apply_patch-Methode von Codex nutzt ein OpenAI-spezifisches Diff-Format, was bei anderen Modellen zu hohen Fehlerraten führt
    • Beispiel: Patch-Fehlerrate bei Grok 4 von 50,7 %, bei GLM-4.7 von 46,2 %
  • Die str_replace-Methode von Claude Code erfordert eine perfekte Zeichenkettenübereinstimmung, wodurch schon Unterschiede bei Leerzeichen oder Einrückung Fehler auslösen
    • Der Fehler „String to replace not found in file“ wurde vielfach auf GitHub gemeldet
  • Cursor trainiert ein separates 70B-Modell für das Mergen, doch bei Dateien mit weniger als 400 Zeilen liefert ein vollständiges Neuschreiben (full rewrite) bessere Ergebnisse
  • Auch in JetBrains' Studien Diff-XYZ und EDIT-Bench wurde bestätigt, dass die Leistung stark vom Editierformat abhängt

Prinzip des Hashline-Ansatzes

  • Jede Codezeile erhält einen 2–3 Zeichen langen Content-Hash, damit das Modell das Ziel einer Änderung eindeutig angeben kann
    • Beispiel: 22:f1| return "world";
    • Das Modell fordert Änderungen dann hashbasiert an, etwa mit „replace line 2:f1“
  • Wenn sich eine Datei verändert und der Hash nicht mehr übereinstimmt, wird die Änderung abgelehnt, um Beschädigungen zu verhindern
  • Da das Modell bestehende Inhalte nicht rekonstruieren muss, reduziert dieser Ansatz Fehler bei Leerzeichen und Einrückung und ermöglicht stabilere Änderungen

Benchmark-Ergebnisse

  • Der Test bestand aus 180 Aufgaben zur Bugbehebung, drei Wiederholungen und vier Werkzeugen (read, edit, write etc.)
  • Im Ergebnis war das Patch-Format bei fast allen Modellen am schwächsten, während Hashline Replace ebenbürtig oder überlegen war
    • Je schwächer das Modell, desto größer die Verbesserung
    • Bei Grok 4 Fast sanken die Ausgabetokens um 61 %, MiniMax verbesserte sich um mehr als das Doppelte
  • Geminis Erfolgsquote von +8 % entspricht einer Verbesserung, die größer ist als bei typischen Modell-Upgrades, und wurde ohne zusätzliches Training erreicht

Anbieterpolitik und Open-Source-Ökosystem

  • Anthropic blockierte den Zugang von Claude Code für den Open-Source-Coding-Agenten OpenCode
    • Als Grund wurde „Reverse Engineering einer nicht öffentlichen API“ genannt, de facto wurde dies jedoch als Signal verstanden, „nur das eigene Harness zu verwenden“
  • Google sperrte den Account des Autors und kappte damit den Zugang zu Gemini
    • Dies geschah unmittelbar nach einem Benchmark, in dem sich Gemini 3 Flash mit Hashline auf 78,3 % verbesserte
  • Der Autor kritisiert solche Maßnahmen als rückschrittliche Eingriffe, die Chancen zur Modellverbesserung blockieren
    • Harness-Optimierung sei keine modellbezogene Sondermaßnahme, sondern öffentliche Forschung, die die Qualität aller Modelle erhöhen könne
    • Mit der Formulierung „Modelle sind der Burggraben, das Harness ist die Brücke“ betont er, dass ein geschlossener Ansatz die Entwicklung des Ökosystems behindert

Fazit

  • Das Harness-Problem wurde als messbarer Faktor mit direktem Einfluss auf die tatsächliche Leistung bestätigt
  • Schon eine einfache Formatänderung kann Verbesserungen bringen, die einem Modell-Upgrade nahekommen
  • Die künftige Entwicklung sollte nicht in geschlossenen Verbesserungen einzelner Unternehmen, sondern in offener, gemeinschaftsgetriebener Zusammenarbeit liegen
  • Sämtlicher Code, alle Benchmarks und Ausführungsergebnisse sind im GitHub-Repository oh-my-pi veröffentlicht

Verwandte Beiträge

3 Kommentare

 
github88 2026-02-15

Mit dem Modell stimmt etwas nicht – warum schon wieder Prompt Engineering..
 
cosine20 27 일 전

Harness und Prompt Engineering sind zwei völlig unterschiedliche Dinge.
 
GN⁺ 2026-02-13
Hacker-News-Kommentare

  • Ich fand diesen Artikel wirklich sehr interessant. Ich denke, der Autor hat genau den Kern getroffen.
    Selbst die heute existierenden Modelle könnten, je nachdem wie wir den Agent-Harness gestalten, noch deutlich effizienter werden.
    Ich denke, man sollte „AI“ nicht einfach nur als das LLM selbst betrachten, sondern als das gesamte kybernetische System, in dem LLM und Harness über eine Feedback-Schleife verbunden sind.
    Modell und Harness verstärken sich gegenseitig und entwickeln sich gemeinsam weiter, daher sind beide gleichermaßen wichtig.
    Diese Sichtweise führt nicht nur zu Leistungsverbesserungen, sondern erlaubt es auch, generative AI als ein neurosymbolisches Projekt neu zu interpretieren.

    • Meiner Meinung nach kann man auch jetzt schon mit GPT-4 sehr viel bauen.
      Ich habe tatsächlich mit der 2023er-Version von GPT-4 einen Coding-Agenten gebaut.
      Wenn man mit älteren Modellen arbeitet, muss man die Dinge einfach halten, und genau das führt oft dazu, dass man Probleme anders betrachtet.
      In Python ist zum Beispiel eine einfache semantic compression wie grep -r def . unverzichtbar.
      Wenn man bei Tools wie Claude Code solche simplen Hooks ergänzt, kann man die Codestruktur sofort erfassen, ohne Tokens zu verschwenden.
    • Ich entwickle ein CLI namens Peen. Es hilft lokalen Ollama-Modellen dabei, Tools effizient aufzurufen.
      Schon mit nur ein paar Stunden Prompt-Tuning und Code zur Antwortverarbeitung verbessert sich die Ausgabequalität kleiner lokaler Modelle erstaunlich stark.
      GitHub-Link
    • Auch die Harnesses von Claude Code und OpenAI Codex entwickeln sich selbst weiter.
      OpenAI hat mit einer frühen Version von GPT-5.3-Codex den eigenen Trainingsprozess debuggt und das Deployment verwaltet.
      Claude Code reicht pro Tag mehr als 20 PRs ein, und zwar vollständig durch selbst erzeugten Code.
    • Nur zur Info: Mein Schreibstil verwendet oft Strukturen wie „It’s not just X, it’s Y“, aber das liegt daran, dass ich müde bin, nicht daran, dass es von einem LLM geschrieben wurde.
    • Wenn man sich die SWE-bench-Dokumentation anschaut, wird dort fast schon willkürliches Context Engineering verwendet.
      Tatsächlich wissen wir nicht einmal genau, welche Modelle besonders empfindlich auf gutes Context Engineering reagieren.
      Aber ich stimme definitiv zu, dass es hier noch viele low hanging fruits gibt.

  • Diese Technik ist interessant, wirkt aber überschätzt.
    Der Autor sieht bei einem einfachen selbstgebauten Find/Replace-Benchmark eine Verbesserung von 5 % und spricht dann so, als wäre die Gesamtleistung um 14 Punkte gestiegen.
    Tatsächlich liegt die Verbesserung bei der gesamten Token-Effizienz wahrscheinlich unter 1 %.
    Außerdem mindern der übertriebene Tonfall und der typische ChatGPT-Stil die Glaubwürdigkeit.

    • Bei einem Format wie „replace line 2:f1…“ könnte die tatsächliche Effizienz vielleicht deutlich höher als 20 % sein.
    • Im Benchmark heißt es zwar, der Token-Verbrauch sei um 25–50 % gesunken, aber ob das in realen Nutzungsszenarien genauso wirkt, ist fraglich.

  • Dieser Beitrag zeigt gut, wie viel Verbesserungspotenzial es auf Harness-Ebene gibt.
    Agenten verschwenden viele Tokens beim Editieren, in Sandboxes und bei der Datenübergabe zwischen Tool-Aufrufen.
    Die Kombination aus inhaltsbasierter Adressierung + Zeilennummerierung ist praktisch und elegant.

    • Der größte verschwenderische Faktor könnte sein, MCP überall zu verwenden.
      Das macht die anfängliche Entwicklung zwar leichter, führt aber ineffizient dazu, dass unnötig riesige Modelle aufgerufen werden.
    • Ich habe das Plugin ClaudeCode Superpowers ausprobiert; die Funktionen sind gut, aber es ist teuer.
      In CC kann man mit dem Befehl /cost die Kosten pro Sitzung prüfen, und solche Kennzahlen eignen sich gut, um die Effizienz von Plugins zu bewerten.
    • Umgekehrt kann man auch mehr Tokens einsetzen, um komplexe Probleme zu lösen, indem man sie in kleine Teilprobleme zerlegt.

  • Die Bedeutung des Harness ist viel größer, als die meisten denken.
    Zum Beispiel hat sich der CORE-Benchmark-Score von Opus fast verdoppelt, als man vom eigenen Harness zu Claude Code gewechselt ist.
    Relevanter Link

    • Auch im Blogbeitrag von Mario, dem Entwickler des Pi-Terminal-Agenten, wird erklärt, dass der beste TerminalBench-Score dem Terminus-2-Harness zu verdanken war.
    • Deshalb sollten wir Harnesses frei austauschen oder selbst bauen können.
      Wegen eines 20-Dollar-Abos an ein bestimmtes Harness gebunden zu sein, ist unvernünftig.

  • Ich habe ein Tool namens tilth gebaut, das einen hashbasierten Lese-/Editieransatz umsetzt.
    Es kann über npm und cargo installiert werden und lässt sich mit Editoren wie Claude Code oder Cursor integrieren.
    GitHub-Link
    Das Ziel ist, dass LLMs Tools effizienter nutzen und weniger Tokens verschwenden.

    • Das ließe sich vermutlich auch auf Markdown anwenden. Wenn man adressierbare Abschnitte ergänzt, steigt die Stabilität über verschiedene Versionen hinweg.
    • Auch ein Benchmark-Vergleich mit grep wäre interessant.

  • Ich bin unabhängig auf eine ähnliche Methode gekommen, habe sie aber wegen der Abhängigkeit von Abstraktionen aufgegeben.
    Stattdessen berechne ich mit der Damerau-Levenshtein-Distanz die Ähnlichkeit von Edits und lasse Änderungen ab einem bestimmten Schwellenwert zu.
    Dadurch muss das Modell die zu ersetzenden Source-Tokens explizit ausgeben, was die Genauigkeit erhöht.
    Codebeispiel
    Entscheidend ist, dass Fehlermeldungen konkret sein müssen — Fehlerbehandlung mit Wiederherstellungshinweisen wie „Content mismatch. Reread the file“ ist wichtig.
    Dieser Ansatz funktioniert auch mit 4B-Modellen gut, und bei Modellen ohne Tool-Call-Unterstützung wird mit einem Hack per System-Prompt-Injektion nachgeholfen.
    Relevanter Code

  • Auch mit älteren Modellen konnte man ziemlich präzise Ergebnisse erzielen.
    Entscheidend war, das Modell „richtig zu behandeln“.
    Der Beitrag deutet an, dass noch größere Fortschritte möglich wären, wenn Modelle nicht einfach nur Text, sondern direkt strukturelle Repräsentationen von Source Code (AST) verarbeiten könnten.
    OpenRewrite verwendet zum Beispiel einen Lossless Semantic Tree, der Typen, Formatierung und Abhängigkeitsinformationen des Codes vollständig enthält.
    Wenn Modelle solche Strukturen nutzen könnten, wären sehr präzise Änderungen ohne unnötigen Token-Verbrauch möglich.
    Letztlich ist das dieselbe Antwort wie beim Streit „Vim vs Emacs“, bei dem die Antwort „IntelliJ“ lautet — strukturelle Informationen sind eine mächtige Waffe.
    Wenn ein Modell gemeinsam mit Code, Dokumentation und Syntax-/Semantikbäumen trainiert würde, wäre das ein echtes neurosymbolisches Coding-Modell.

  • Beim Experimentieren mit LLMs über gptel in Emacs habe ich festgestellt, dass LLMs schlecht darin sind, Code mit dem Unix-Patch-Tool zu ändern.
    Deshalb habe ich mit tree-sitter in Emacs selbst ein Tool für gptel gebaut.
    Mit Befehlen wie tree_sitter_list_nodes und tree_sitter_update_nodes, die AST-Knoten direkt bearbeiten, hat es perfekt funktioniert.

    • Klingt spannend, ich würde gern wissen, ob du den Code teilen kannst.

  • Das apply_patch von Codex verwendet tatsächlich ein Schema mit eingeschränktem Sampling.
    Relevanter Code
    Der Autor kannte das offenbar nicht und hat deshalb einen zu simplen Vergleich gemacht; ein realistischeres Benchmarking müsste dieses Schema aktiviert lassen.

  • Unter den Zitaten in diesem Artikel gab es einen Teil, der mich besonders beeindruckt hat.
    „Das Modell versteht das Problem nicht falsch, die Repräsentation ist instabil. Gib nicht dem Piloten die Schuld für ein Problem mit dem Fahrwerk.“
    „Das Modell ist der Burggraben (moat), der Harness ist die Brücke (bridge).“
    „Der Unterschied zwischen einer großartigen Demo und einem zuverlässigen Tool ist keine Magie, sondern langweilige, aber präzise Engineering-Arbeit.“

    • Dem stimme ich voll zu. Das ist nicht nur ein einfacher Ratschlag, sondern wirkt wie ein technisches Kunstwerk, das die Denkweise des Autors lebendig zeigt.
    • Mein Lieblingssatz ist: „Das ist keine Bedrohung. Es ist kostenlose F&E.“