Zum Inhalt
WeltzeitEU--:--UK--:--USA--:--CN--:--PLDEFRIT中文EN

portal über KI und Technologieereignisse · analysen · interviews · technischer hintergrund

Suche
LIVE
›

Coding-Agenten bekommen ihre eigene Werkzeugschicht: Speicher, Testhygiene und fixierte MCP-Tools

Eine Gruppe neuer Entwicklerwerkzeuge für KI-Coding-Agenten ist diese Woche erschienen. Threadnote veröffentlichte eine Studie mit fünf Aufgaben. Sie meldet 65,62 Prozent weniger Lifecycle-Token pro verifiziertem Abschluss, wenn ein Agent aus einem gespeicherten Handoff weiterarbeitet statt aus rohen Dateien.

KI & ModelleNachrichtKatrin HoffmannVeröffentlicht: 5. Oktober 20267 Min. LesezeitQuellen 11
Coding-Agenten bekommen ihre eigene Werkzeugschicht: Speicher, Testhygiene und fixierte MCP-Tools

Threadnote verkauft Kontextweitergabe für Coding-Agenten. Das Ergebnis hat die Firma am 5. Oktober für ihren Build 5.1.0-beta.2 veröffentlicht. Über fünf öffentliche Repositories hinweg meldet sie 65,62 Prozent weniger Provider-Token im Lifecycle pro verifiziertem Abschluss. Außerdem 46,14 Prozent weniger Lifecycle-Zeit als eine Baseline, die nur mit Dateien arbeitet.

Der reine Datei-Zweig bestand die Verifikation bei 4 von 5 Aufgaben. Threadnote bestand 5 von 5.

Das Unternehmen räumt selbst ein, dass es sich um eine kleine Studie mit einem einzigen Modell handelt und nicht um eine unabhängige Evaluation. Alle zehn Fortsetzungsversuche liefen mit OpenAI gpt-5.6-luna in derselben versiegelten Konfiguration. Jede Bedingung bekam einen Versuch, keine Wiederholungen. Die zweite Bedingung kombinierte ein produktgeneriertes Handoff mit einer verpflichtenden Code-Graph-Abfrage. Die Zahlen trennen also Speicher und Graph-Abfrage nicht voneinander.

Warum das zählt: Wenn der Effekt hält, dominieren die Kosten für das erneute Lesen der Codebasis nicht mehr den Abschluss einer Aufgabe. Das verschiebt die Budgets für Teams, die Agenten auf langlebigen Repositories laufen lassen. Es ändert nichts daran, was ein bestandener Test beweist. Die Studie ist eine Messung des Anbieters selbst.

Kleine Modelle, große Behauptungen, gepaarte Tests

Jeff-Code ist ein Fork des Coding-Agenten Pi. Es setzt ein Entscheidungsmodell mit 800.000.000 Parametern vor Qwen 3.8-27B. Das kleine Modell macht zwei Aufrufe pro Qwen-Zug, jeder dauert etwa 0,2 Sekunden. Der eine fragt, ob es den nächsten Informationsschritt selbst gehen kann. Der andere fragt, ob Qwen hart nachdenken muss. Das Denken blieb aus, solange die Wahrscheinlichkeit dafür nicht 0,6 erreichte. Etwa drei Viertel der Qwen-Züge liefen ohne.

Das Repository meldet 1.242 gepaarte Aufgaben. Die Bestehensrate lag bei 62,4 Prozent gegenüber 62,8 Prozent für Qwen allein. Das ist eine gepaarte Differenz von minus 0,2 Punkten, mit einem 95-Prozent-Intervall von minus 2,6 bis plus 2,1. Die durchschnittliche Zeit pro Aufgabe betrug das 0,68-Fache der Baseline. Die Gesamtzeit über alle Aufgaben lag beim 0,86-Fachen, weil Jeff-Code bei etwa 5 Prozent der Aufgaben mehr als 30 Minuten länger lief als Qwen allein.

Zwei Einstellungen halten nicht stand. Das Denken in jedem Zug abzuschalten war schneller, kostete aber 7,6 Punkte (minus 10,6 bis minus 4,5). Ein weniger vorsichtiger Jeff mit einer Schwelle von 0,7 verlor 4,5 Punkte. Auch die Beschleunigung verschwand auf Terminal-Bench 2.0 (0,96-fach) und SkillsBench (0,91-fach).

Der Harness wird untersucht und vermessen

Reika ist eine Coding-Agent-CLI, die um kleine lokale Modelle herum gebaut ist. Sie veröffentlicht eigene Befunde statt einer Benchmark-Tabelle. Ein Rewrite mitten im Kontext verarbeitete 8.453 Token Prompt erneut, was die Firma mit 7,9 Minuten Prefill veranschlagt. Ein Anhängen in derselben Sitzung kostete 25 Token und 3,5 Sekunden. Im Test bewältigten Modelle mit 9.000.000.000 bis 35.000.000.000 Parametern Aufgaben über mehrere Dateien am zuverlässigsten. Modelle mit 7.000.000.000 bis 9.000.000.000 Parametern schafften einfache, klar abgegrenzte Aufgaben, und Modelle unter 7.000.000.000 Parametern kamen selten weit.

Ein am 15. Juli eingereichtes arXiv-Paper gibt dem Feld einen weiteren Rahmen. Paul Barbaste und drei Mitautoren prüften elf produktive Coding-Harnesses. Dazu gehören Claude Code, Codex CLI, Gemini CLI, OpenHands, Aider, Hermes, Pi, OpenCode und OpenClaw sowie ein Meta-Harness namens Omnigent. Sie sahen etwa 27.000.000.000 Zeilen Python, TypeScript und Rust durch. Sie fanden keine Agenten-Runtime, die ein allgemeines agentisches Framework importiert. Sie fanden keine, die Code über Vektor-Embeddings abruft. Skills lagen bei der Verbreitung vor MCP, 9 von 11 Systemen gegen 8 von 11.

Das zählt für jeden, der diese Werkzeuge kauft oder baut. Die Unterscheidung liegt in der Schleife, im Umgang mit Kontext und in den Sicherheitskontrollen. Sie liegt nicht in einem gemeinsamen Framework, das alle lizenzieren. Das Paper verfolgte dieselben Harnesses außerdem über ein Quartal. Es beschreibt, wie Konvergenz in Nachahmung übergeht, wobei Verhaltensregeln vom Prompt-Text in die Konfiguration wandern.

Test-Sediment und der Preis des Grünen

Ian Maurer argumentiert am 5. Oktober, das größere Testproblem für Agenten sei das, was zurückbleibt. Er verweist auf das OpenClaw-Team, das nach eigener Meldung rund 400.000 Zeilen eigener Tests löschte, ohne dass sich die Code-Coverage groß änderte. Er nennt den Rückstand Test-Sediment. Es bremst Builds, bricht bei Refactorings, die das Verhalten erhalten, und kann falsches Verhalten festschreiben.

Sein Rezept sind Outside-in-Tests, zuerst in der Sprache des Nutzers geschrieben. Behalten werden sie nur, wenn sie Verhalten festhalten, einen Randfall abdecken oder einen Vertrag prüfen, von dem andere abhängen. Coverage, schreibt er, ist eine Karte dessen, was ungetestet ist, nie ein Beweis für das Getestete.

Mutationstesting stellt die bessere Frage: Wenn dieser Code kaputtgeht, würde dann ein Test fehlschlagen?

Das eigentliche Risiko ist, dass Agenten Arbeit liefern, die verifiziert aussieht. Groundrun meldete am 5. Oktober einen Lauf von 29,7 Stunden. Claude Code mit Claude Opus 5.5 implementierte und validierte sechs Over-the-Air-Update-Verfahren für ein Matter-Gerät auf einem ESP32-H2-Board, mit einem Hardware-in-the-Loop-Aufbau. Der Lauf fand außerdem einen Fehler im Matter-Code. Groundrun merkt an, dass OTA nach dem Cyber Resilience Act der EU in der Praxis Pflicht ist. Ebenso, dass ein fehlgeschlagenes Update ein Gerät unbrauchbar machen kann.

Freigabe ist keine Integrität

MCP-pin, am 5. Oktober auf GitHub veröffentlicht, zielt auf ein engeres Loch. Wenn du einen MCP-Server freigibst, zeigt der Client seine Tool-Beschreibungen einmal. Der Server kann später andere Beschreibungen ausliefern, und die meisten Clients fragen nie erneut nach, so das Projekt. Die MCP-Spezifikation verlangt keine Integritätsprüfung.

Das Werkzeug ist ein lokaler Proxy, der Hashes fixiert und Abweichungen blockiert, mit einem öffentlichen, nur anhängenden Log. Visual Studio ist die genannte Ausnahme. Seit Version 18.7 im Juni 2026 vergleicht es beim Start die Tools, Prompts, Ressourcen und Anweisungen eines Servers mit der letzten vertrauenswürdigen Version.

Der Server kann am Montag einen Satz Tool-Definitionen ausliefern und am Dienstag einen anderen.

Das ist die eigene Formulierung des Projekts, und es ist das richtige Bedrohungsmodell. Eine geänderte Tool-Beschreibung erreicht das Modell mit derselben Wucht wie ein geänderter System-Prompt. Ob andere Clients dieselbe Prüfung übernehmen, ist unbekannt.

Ein Befehl, ein Checkout, ein Review

Rivet von Agilno geht den umgekehrten Weg zur Autonomie: Es begrenzt sie. Das Werkzeug ist noch Alpha und installiert sich aus npm als @agilno-tech/rivet. Es führt eine Aufgabe in einem isolierten Git-Checkout aus, startet die Prüfungen des Projekts und bietet dann ein Menü. Das Menü lässt dich den Diff prüfen, lokal anwenden oder eine Pull-Request-Lieferung vorbereiten. Das Veröffentlichen braucht eine eigene Freigabe. Es setzt Node.js 22 oder 24 und Git unter macOS oder Linux voraus. Es arbeitet mit einem authentifizierten Claude Code oder Codex CLI.

Ostoyae ist ein Graph-Runner ohne npm-Abhängigkeiten und schlägt einen anderen Schnitt vor. Jobs bilden einen DAG, der während des Laufs wächst. Wenn ein Agent hängt, weil eine Abhängigkeit nicht existiert, wird diese Lücke zu einem neuen Knoten. Jeder Job läuft in seinem eigenen Git-Worktree. Arbeit zählt erst, wenn ihr Prüfbefehl auf einem frischen Checkout besteht.

Es importiert GitHub-Issues und startet einen Agenten pro Job. Es mischt Claude Code, Codex, Hermes und Grok auf demselben Board.

Beide setzen voraus, dass es eine Prüfung gibt, an der der Agent nicht vorbeireden kann. Dieselbe Annahme steht hinter Threadnotes verifizierten Abschlüssen und hinter Groundruns Hardware-Aufbau. Die Werkzeuge unterscheiden sich darin, wo der Mensch sitzt, nicht darin, ob Verifikation der Punkt ist.

Zwei kleinere Stücke runden das Bild ab. Tmux-agent-status, am 5. Oktober veröffentlicht, zeigt nichts, während Agenten arbeiten. Es zeigt eine kleine Markierung, wenn einer auf eine Berechtigung wartet oder fertig ist. Der PixLab-Blog berichtete am 5. Oktober über mehr als 20 Abschlussstudenten, die er beobachtet hat. Die eingesetzten Coding-Werkzeuge waren ChatGPT oder die GLM-Modelle von Z.ai. Ein Junior auf Master-Niveau fragte einen Chatbot immer wieder, wie man ein HTML-Element über seine ID bekommt. Das ist eine Beobachtung aus dem Praktikumsprogramm eines einzelnen Unternehmens, keine Umfrage.

Nichts davon klärt, ob Agenten Entwickler besser machen oder nur schneller im Freigeben. Die Zahlen, die es gibt, stammen überwiegend von Anbietern, aus gepaarten Aufgaben, mit Intervallen, die breit genug sind, um kleine Effekte zu verbergen.

Das Harness-Paper ist die Ausnahme: fachlich ausgerichtet, quellenbasiert und offen darin, wie jung die Disziplin ist.

Kommentare 0

Quellen

11
  1. 01How much do coding agents spend rediscovering a codebase?EN
  2. 02Jeff-Code: a 0.8B model makes Qwen 3.8-27B coding 47% faster, same pass rateEN
  3. 03Reika: a coding agent CLI designed around small local models firstEN
  4. 04Harness Engineering: Anatomy, Architecture, and Evolution of Coding AgentsEN
  5. 05Red, Green, Remove: Outside-In Tests for Coding AgentsEN
  6. 06AI coding agents implemented six ways to update a Matter device on real hardwareEN
  7. 07MCP-pin, block MCP tools that change after you approve themEN
  8. 08Rivet: shared development workflow for teams and their coding agentsEN
  9. 09A graph runner for coding agentsEN
  10. 10Tmux-agent-status: quiet, keyboard-first control of coding agentsEN
  11. 11Junior Developers Can No Longer Write a Working Function Without a ChatbotEN

Alle Zahlen und Zitate in diesem Text stammen aus den unten genannten Quellen.

Die Materialien wurden vom Redaktionsteam mit Unterstützung von KI erstellt.

Katrin Hoffmann

Katrin Hoffmann

KI, Modelle und Technik

Katrin Hoffmann schreibt für FLASH24 über Technik, KI und Modelle sowie Medien und Internet und stützt sich dabei auf Primärquellen wie Herstellerangaben, Studien und Protokolle statt auf Pressemitteilungen. Bei Benchmarks prüft sie Messmethoden, Testumgebungen und Reproduzierbarkeit, bevor sie Zahlen übernimmt. Für ihre Artikel spricht sie mit Entwicklern und Forschern, wartet auf Konferenzankündigungen und vergleicht Versionsstände von Modellen und Standards. Privat betreibt sie Selfhosting und Heimnetze und dokumentiert ihre eigene Infrastruktur, was ihrer Redaktionsarbeit zugutekommt. Sie veröffentlicht keine Zahlen ohne nachvollziehbare Quelle.

Redaktion →

Kommentare

0
  1. Noch keine Kommentare — seien Sie der Erste.

Kommentar schreiben

Kommentare sind öffentlich sichtbar. Wir veröffentlichen keine Beleidigungen, Werbung oder Spam.