Kategorie: Erklärer

Ein hochbegabter Mitarbeiter hat brillante Ideen, aber keinen Schreibtisch, keine Werkzeuge, keine klaren Anweisungen. Er scheitert an seiner Arbeitsumgebung, nicht an seiner Intelligenz. Diese Erkenntnis treibt einen Forschungszweig: Harness Engineering. Es geht nicht mehr nur um ein schlaues Modell, sondern um die Bühne, auf der es seine Fähigkeiten entfaltet.

Das Prinzip ist alltäglich. Jedes komplexe System braucht eine Hülle. Ein Betriebssystem verwaltet Hardware, eine IDE hilft beim Codieren, gutes Projektmanagement verhindert Chaos. In der KI heißt diese Hülle Harness – das Gerüst, das Modellen erlaubt zu planen, Werkzeuge zu nutzen, sich zu erinnern, Ergebnisse zu prüfen. Ohne dieses Gerüst bleibt selbst das beste Modell ein Denker ohne Hände.

Die Wiederentdeckung einer alten Idee

Die Vision einer sich selbst verbessernden Maschine ist nicht neu. Bereits 1965 skizzierte I. J. Good die ultraintelligente Maschine. Eliezer Yudkowsky prägte 2008 den Begriff der rekursiven Selbstverbesserung (RSI). Lange dachte man, RSI geschehe durch Umschreiben der eigenen Gewichte. Die aktuelle Forschung zeigt einen pragmatischeren Weg: Ein Modell verbessert seine Trainingspipeline und die Einsatzumgebung – also den Harness. Die Schnelligkeit, mit der KI-Labore wie Anthropic oder OpenAI Durchbrüche erzielen, spricht dafür: Die Optimierung des Gesamtsystems ist mindestens so wichtig wie rohe Rechenleistung.

Drei architektonische Muster für den idealen Harness

Die erste Lektion aus der Praxis: Ein Harness muss einfach und generisch sein. Ein Betriebssystem verbirgt Hardware hinter einer Schnittstelle – das soll auch ein Harness leisten. Drei Muster haben sich herauskristallisiert.

1. Automatisierung des Arbeitsablaufs. Der Kern jedes agentischen Systems ist ein Kreislauf: Modell plant eine Aktion, führt sie aus, beobachtet das Ergebnis, bewertet es, iteriert. André Karpathys öffentliches Repository „autoresearch“ zeigt einen eleganten Loop. Das Modell startet mit einer Aufgabe, generiert einen Plan, führt Experimente durch, analysiert Fehler und wiederholt den Prozess – ohne menschlichen Eingriff. Der Workflow steckt nicht in einer statischen Prompt-Vorlage, sondern existiert als dynamische Laufzeitumgebung, die das Modell selbst steuert.

2. Das Dateisystem als persistentes Gedächtnis. Ein Problem bei längeren Agenten-Einsätzen: Der Kontext wächst schnell über das Fenster hinaus, das das Modell verarbeiten kann. Die Lösung: Der Harness speichert Zustände in Dateien, auf die das Modell mit Bash-Befehlen wie grep oder cat zugreift. Das klingt banal, nutzt aber die Stärke moderner Sprachmodelle, die mit Dateisystemen umgehen können. Statt alles in den Kontext zu stopfen, managt der Harness Informationen wie ein Betriebssystem: auslagern, bei Bedarf laden, in überschaubaren Portionen präsentieren.

3. Sub-Agenten und Hintergrund-Jobs. Manchmal muss ein Hauptagent mehrere Hypothesen gleichzeitig prüfen. Ein guter Harness erlaubt, Tochteragenten zu starten, ihnen isolierte Aufgaben zu geben und Ergebnisse später einzusammeln. Die parallelen Arbeiten verschwinden nicht im Chat-Kontext, sondern bleiben als Dateien, Logs und Statusberichte persistent. So kann der Hauptagent auch nach einem Crash seinen Fortschritt rekonstruieren – eine Eigenschaft, die man von jedem soliden Betriebssystem erwartet.

Der Coding-Agent als Blaupause

Die konkreteste Anwendung dieser Muster sind Coding Agents wie Claude Code, Codex oder OpenCode. Sie arbeiten in einer Schleife: Sie lesen und bearbeiten Dateien, führen Bash-Befehle aus, verwenden Git und durchsuchen bei Bedarf das Web. Die Werkzeuge ähneln denen eines menschlichen Entwicklers: Editor, Terminal, Debugger, Patch-Erstellung. Der Harness stellt sie konsistent und kontrolliert bereit. Interessant ist die Standardisierung der Schnittstellen in den letzten Monaten. Die Toolgruppen sind fast überall gleich: Dateisystem-Operationen, Shell-Kommandos, Sprachserver-Funktionen, Git-Tools, Webzugriff und ein Mechanismus zum Starten und Verwalten von Sub-Agenten. Diese Standardisierung erlaubt, die Harness-Architektur unabhängig vom konkreten Modell zu verbessern – ähnlich wie Betriebssysteme von der Hardware abstrahieren.

Die Optimierung des Optimierers: Context Engineering

Je intelligenter die Modelle werden, desto wichtiger wird die Kunst, den Kontext zu gestalten. Einfach alle bisherigen Interaktionen aneinanderzureihen, funktioniert nur bis zu einer bestimmten Länge. Forscher sprechen von Context Engineering – dem gezielten Aufbereiten des Kontexts als ein sich entwickelndes Handbuch, nicht als endloses Prompt-Scrollen. Ein vielversprechender Ansatz heißt Agentic Context Engineering (ACE), entwickelt von Zhang und Kollegen 2025. ACE zerlegt die Aufgabe in drei Rollen: Ein Generator produziert Handlungsstränge, ein Reflector destilliert Erkenntnisse aus Erfolgen und Misserfolgen, und ein Curator aktualisiert den Kontext in strukturierten, nummerierten Bullet Points – schrittweise, dedupliziert, priorisiert. Das verhindert, dass das Modell den Faden verliert. ACE ist ein erster Schritt Richtung selbstverwaltendes Gedächtnis, aber die Update-Regeln sind noch von Menschen vorgegeben.

Der nächste Schritt heißt Meta Context Engineering (MCE), vorgestellt von Ye und Kollegen 2026. Hier wird nicht nur der konkrete Kontext optimiert, sondern die Methode, wie dieser Kontext erzeugt wird. Ein MCE-System lernt Skills – kleine Programme, die festlegen, welche statischen Komponenten und dynamischen Operatoren verwendet werden. In einer zweistufigen Optimierung sucht die innere Schleife den besten Kontext für eine Aufgabe, die äußere den besten Skill für eine ganze Aufgabenklasse. Das Ergebnis ist keine starre Regel, sondern eine sich selbst verbessernde Kontextfabrik – ein Schritt zur rekursiven Selbstverbesserung.

Die Meta-Ebene: Wenn der Harness sich selbst optimiert

Der radikalste Ansatz kommt von Lee und Kollegen 2026 mit dem Meta-Harness. Hier wird der gesamte Code des Harness zum Optimierungsziel. Ein Meta-Harness ist ein Werkzeug, das bessere Werkzeuge baut. Ein Coding-Agent bekommt die Aufgabe, einen neuen, besseren Harness für eine bestimmte Aufgabe zu entwickeln. Er startet Experimente, analysiert die Ergebnisse und generiert Code für neue Harness-Kandidaten. Die Ausführungshistorie bleibt im Dateisystem zugänglich, sodass der Agent mit Grep und Cat darauf zugreifen kann. Die Ausgabe ist eine Pareto-Front von Harness-Kandidaten mit unterschiedlichen Kompromissen zwischen Effizienz, Skalierbarkeit und Genauigkeit. Das zeigt eine klare Entwicklungslinie: Zuerst optimierten wir die Prompts, dann den Workflow, dann den Harness, dann den Optimierer. Mit jeder Ebene wird das System flexibler und passt sich an neue Anforderungen an, ohne dass ein Mensch jede Schraube neu justieren muss.

Was bedeutet das für die Zukunft?

Der Autor des Artikels zeichnet ein nüchternes Bild: Harness Engineering wird den Pfad zur rekursiven Selbstverbesserung in den nächsten Jahren wahrscheinlich stärker prägen als direkte Änderungen am Modell selbst. Das Modell, das seine eigenen Gewichte umschreibt, bleibt eine Vision. Der praktische Weg führt über die Optimierung der Umgebung: bessere Schleifen, schlauere Kontextverwaltung, selbstlernende Werkzeuge. Vorsicht vor Übertreibungen. Viele der heutigen Harness-Kniffe werden mit der Zeit in das Kernverhalten der Modelle einfließen – so wie frühere Prompt-Tricks durch verbessertes Instruction Tuning überflüssig wurden. Der Bedarf an einer Schnittstelle zur Außenwelt und an einem strukturierten Gedächtnis bleibt jedoch bestehen. Harness Engineering ist eine Brücke. Sie erlaubt, die wachsende Intelligenz der Modelle in geordnete Bahnen zu lenken, sie zu prüfen, zu korrigieren und zu skalieren – ohne den Überblick zu verlieren. Das ist handfeste Ingenieursarbeit, die gerade jetzt in den Laboren Gestalt annimmt.

Für Anwender: Die Werkzeuge von morgen sind heute als Entwürfe sichtbar. Wer versteht, wie ein Coding-Agent seinen Harness nutzt, versteht auch, warum manche KI-Ergebnisse brillant sind und andere scheitern. Nicht allein die Intelligenz des Modells zählt, sondern die Umgebung, in der es arbeitet. Diese Umgebung können wir gestalten.

Quelle: lilianweng.github.io

Ein KI-Modell bekommt eine knifflige Matheaufgabe. Es denkt nach, schreibt „Moment, lass mich nochmal nachdenken“ – und wiederholt diesen Satz. Und noch einmal. Bis der gesamte Textplatz mit dieser Zeile gefüllt ist. Forscher nennen das einen „Doom Loop“. Das Phänomen tritt vor allem bei kleineren Reasoning-Modellen auf, wenn sie an schwierigen Problemen arbeiten. Bisher halfen nur einfache Wiederholungsstrafen im Hintergrund. Das Team um Sam Paech von Liquid AI entwickelte eine präzisere Methode: Antidoom. Sie kombiniert eine Erkennung der Problemstelle mit einem speziell angepassten Training, das nur einen einzigen Token im Wörterbuch korrigiert. Die Schleifen werden drastisch reduziert, die Leistung verbessert sich.

Doom Loops entstehen durch drei ineinandergreifende Mechanismen. Erstens: Die ungleiche Verteilung von Wahrscheinlichkeiten im Vokabular. Manche Wörter – „overtrained tokens“ – sind durch das Training mit synthetischen Daten besonders wahrscheinlich geworden. Bei Reasoning-Modellen sind das oft Diskursmarker wie „Wait“ oder „Alternatively“. Sie sind nützlich, um Strategiewechsel anzuzeigen. Wenn das Modell unsicher ist, werden diese Tokens zu Ausweichrouten. Sie starten immer wieder dasselbe Denkmuster neu.

Zweitens: Eine sich selbst verstärkende Rückkopplung. Sobald ein Token wie „Wait“ auftaucht, steigt die Wahrscheinlichkeit für genau dieses Token weiter. Jede Wiederholung treibt die Wahrscheinlichkeit in Richtung 1. Forscher um Zenghao Duan zeigten, dass dabei ein V-förmiges Aufmerksamkeitsmuster entsteht: Die semantische Wiederholung – das Feststecken auf einer Idee – geht der textuellen Wiederholung voraus. Drittens: Greedy-Sampling. Reasoning-Modelle laufen oft bei sehr niedrigen Temperaturen, um stabile Ergebnisse zu liefern. Bei Temperatur 0 wird immer der wahrscheinlichste Token gewählt. Hat sich eine Schleife erst etabliert, gibt es keinen Ausweg. Selbst bei höheren Temperaturen bleibt die Wahrscheinlichkeit für den Schleifen-Token so dominant, dass Sampling kaum hilft. Die Forscher fanden signifikante Schleifen selbst bei Temperatur 0,67.

Das Antidoom-Team ging das Problem systematisch an. Sie generierten eine große Menge von Antworten auf einen speziell entwickelten Mix aus anspruchsvollen Prompt-Aufgaben (LiquidAI/antidoom-mix-v1.0) bei niedriger Temperatur. Dann suchten sie nach Mustern, die mindestens viermal hintereinander über 60 Zeichen wiederholt wurden. Diese Kriterien vermeiden falsche Alarme und übersehene Fälle. Für jede gefundene Schleife identifizierten sie den ersten Token der ersten Wiederholung. An dieser Position griffen sie auf die Log-Wahrscheinlichkeiten des Basis-Modells zu, sammelten die Top-Alternativen und filterten kurze oder nicht-alphanumerische Rauscher heraus. Übrig blieben bis zu 20 plausible Ersatztoken, die als „chosen tokens“ in das Training einflossen. Jeder Trainingsdatensatz bestand aus einem Prompt-Präfix, einem abgelehnten Token (dem Beginn der Schleife) und einem oder mehreren gewählten Alternativ-Token.

Die Forscher regularisierten die Verteilungen vor dem Training. Einige häufige Schleifen-Übeltäter wie „Wait“, „So“ oder „the“ würden sonst übermäßig unterdrückt und die Reasoning-Fähigkeiten beschädigen. Die Trainingsmethode heißt „Final Token Preference Optimization“ (FTPO), eine Weiterentwicklung von Direct Preference Optimization (DPO). FTPO nimmt nur gezielte Veränderungen an wenigen Token der Verteilung vor. Es unterscheidet sich von DPO in vier Punkten: Erstens wird nur der letzte Token einer Sequenz trainiert, die sich mitten in der Generierung befindet. Zweitens erlaubt es mehrere gewählte Token pro Probe, sodass die Wahrscheinlichkeit auf eine Gruppe von Alternativen verteilt wird. Drittens verwendet es einen KL-ähnlichen Verlust, der direkt im Logit-Raum arbeitet und Gradientendruck auf nicht betroffene Token vermeidet. Viertens gibt es eine zweiteilige Regularisierung: Die Logits der trainierten Token dürfen sich stärker vom Referenzmodell entfernen, während der Rest des Vokabulars stärker eingeschränkt bleibt. Das verbessert die Lernbarkeit, ohne die Gesamtverteilung zu stören.

In der Praxis wird Antidoom in der Regel für eine Epoche mit LoRA trainiert – das passt nur wenige zusätzliche Parameter an. Hohe LoRA-Ränge (128 bis 256) liefern die besten Ergebnisse: mehr Lernfähigkeit bei weniger Verschlechterung. Die Forscher trainierten auf allen Aufmerksamkeits- und MLP-Projektionen sowie auf dem Sprachkopf. Die optimalen Lernraten lagen zwischen 4e-6 und 2e-5. Übermäßiges Training schadet. Daher brachen sie das Training frühzeitig ab, sobald ein bestimmtes Maß erreicht war (chosen_win=0,35). Die Doom-Loop-Rate sank von 20–30 % auf 1–2 % bei minimalen Nebenwirkungen. Längeres Training riskierte neue Schleifen an anderen Stellen im Vokabular.

Die Ergebnisse: Bei einem frühen Checkpoint von LFM2.5-2.6B – einem Reasoning-Modell mit 2,6 Milliarden Parametern – fiel die Doom-Loop-Rate von 10,2 % auf 1,4 %. Die Bewertungsergebnisse in Mathematik und Programmierung verbesserten sich durchweg, allein durch die Beseitigung der Schleifen. Das Modell lernte nichts Neues über die Aufgaben; es konnte endlich abrufen, was es schon wusste. Bei Qwen3.5-4B (4 Milliarden Parameter) sank die Doom-Loop-Rate von 22,9 % auf 1 % unter Greedy-Sampling, auch hier stiegen die Evaluierungswerte. Ein Nebeneffekt: Nach dem Antidoom-Training schnitten die Modelle bei niedrigen Temperaturen besser ab, während die Leistung bei Temperatur 1 leicht abfiel. Das widerlegt die Annahme, dass höhere Temperaturen für Reasoning-Modelle grundsätzlich besser seien. Vermutlich hatten die Doom Loops bei niedrigen Temperaturen die Ergebnisse verfälscht.

In der Praxis kann Antidoom in mehreren Runden angewendet werden. Nach der ersten Runde sinkt die Zahl der Schleifen drastisch, aber es können neue Problemstellen auftauchen. Eine zweite Runde zielt auf diese neuen Fehler. Die Forscher räumen ein, dass Overfitting eine Gefahr ist und das Training sorgfältig überwacht werden muss. Die Methode ist effizient: Die Erstellung des Trainingsdatensatzes für ein Modell wie LFM2.5-2.6B dauert etwa eine Stunde auf 8 GPUs, das eigentliche Training eine bis zwei Stunden auf einer einzigen GPU. Der gesamte Code ist auf GitHub verfügbar.

Wenn du ein Reasoning-Modell genutzt hast, das sich in sinnlosen Wiederholungen verfing, weißt du, wie das ist. Antidoom ist kein Allheilmittel, aber es zeigt, dass man mit einem präzisen Skalpell arbeiten kann. Statt die gesamte Wahrscheinlichkeitsverteilung zu bestrafen, greift es genau an der Stelle ein, die das Problem verursacht. Das verbessert die Effizienz von KI-Modellen, ohne ihre Kreativität zu ersticken. Ob diese Methode auf andere Degenerationsformen übertragbar ist oder den Anfang einer Familie von Reparaturverfahren darstellt, bleibt abzuwarten.

Quelle: liquid.ai

Du hast ein Kommandozeilen-Tool entwickelt, das die tägliche Arbeit erleichtert. Jemand schlägt vor, die Eingabe für KI-Agenten zu optimieren – alles in einen einzigen --json-Block packen, weil Maschinen strukturierte Daten lieben. Klingt plausibel. Waldek Mastykarz, Principal Developer Advocate bei Microsoft, hat diese Annahme getestet. Er wollte wissen, ob der Wechsel von klassischen Argumenten zu JSON wirklich Vorteile bringt. Das Messergebnis ist eindeutig – und überrascht viele.

Der Ansatz hinter JSON

Die Argumentation der Befürworter ist nachvollziehbar: KI-Agenten denken in hierarchischen Strukturen. JSON bildet tiefe Verschachtelungen natürlich ab, während flache Argumente mit mehrfach auftretenden Flags wie --service-name schnell mehrdeutig werden. Der Agent muss mühsam lernen, welcher Wert zu welchem Block gehört. Ein einzelner JSON-Payload verspricht klare Hierarchien: Jedes Service-Objekt steht für sich, Ressourcen sind logisch gruppiert – kein Ratespiel. So elegant die Theorie klingt, die Praxis zeigt etwas anderes.

Waldek Mastykarz hat ein Experiment entworfen, um die Behauptung zu prüfen. Er baute ein synthetisches CLI namens podctl, das ein komplexes Multi-Service-Deployment erzeugt – mit zwei Diensten, drei Verschachtelungsebenen, Arrays, gemischten Typen und Querverweisen. Insgesamt über 30 Einzelwerte. Eine Version des CLIs akzeptiert nur traditionelle Argumente (Flags), die andere nur einen --json-Payload. Beide nutzen denselben Validierungs-Backend und normalisieren zur gleichen kanonischen Struktur. Der Agent kennt das Tool nicht und muss es über die Hilfe entdecken. Fünf gängige Modelle wurden jeweils fünfmal pro Eingabemodus getestet – von Claude Haiku 4.5 bis GPT-5.3-Codex, mit GitHub Copilot Chat als Rahmen.

Die Ergebnisse: Args gewinnen durchgehend

Jedes Modell erreichte mit den klassischen Argumenten eine perfekte Korrektheit in allen fünf Läufen. Selbst das kleinste Modell, Claude Haiku 4.5, erzeugte zuverlässig korrekte Deployments. Bei der JSON-Variante sah es anders aus: Die drei stärksten Modelle hielten mit 5/5 mit, aber die beiden kleineren Modelle fielen ab. Haiku 4.5 schaffte nur 2 von 5 korrekten Aufgaben, MAI-Code-1-Flash immerhin 3 von 5. Argumente begrenzen den Eingaberaum so stark, dass auch schwächere Modelle konsistent korrekte Ausgaben liefern. JSON zwingt das Modell, seine eigene Struktur zu verwalten – eine Fähigkeit, die nicht jedes Modell beherrscht. Der Unterschied liegt in den Randbedingungen beim Generieren.

Noch deutlicher fällt der Kostenvergleich aus. Entwickler bezahlen für Token, nicht für Versuche. Waldek Mastykarz hat den Token-Verbrauch pro Aufgabe detailliert aufgeschlüsselt – Input, gecachte und Output-Token – und mit den Preisen der GitHub-Modelle multipliziert. Das Ergebnis: JSON-Modus kostete 4- bis 11-mal mehr pro Aufgabe als der Args-Modus – je nach Modell. Der rohe Token-Abstand war noch größer (4- bis 14-mal), aber Caching mildert die Wirkung etwas. Caching hilft nicht bei den Output-Token. Bei JSON führt das zu vielen Neuversuchen. Liest das CLI die JSON-Struktur nicht, analysiert der Agent den Fehler, baut einen neuen Payload und startet einen neuen Versuch. Diese Versuche werden kreativ: Piping durch Variablen, Schreiben in temporäre Dateien, verschiedene Escaping-Strategien. All das sind Output-Token – die teuerste Kategorie.

Das Problem mit Shell-Escaping

Die reinen Tokenkosten sind nicht alles. Ein oft übersehener Faktor beim JSON-Umstieg ist das Shell-Escaping. Wenn der Agent einen JSON-Payload auf der Kommandozeile übergibt, muss er die Anführungszeichen für die Shell maskieren. Verschiedene Shells haben unterschiedliche Regeln für verschachtelte Strings, keine ist trivial. Die Modelle produzierten regelmäßig valides JSON, das dann an der Shell scheiterte: doppelte Anführungszeichen in einfachen Anführungszeichen, Escaping, das die Shell anders interpretierte als beabsichtigt. Die Fehler von Haiku 4.5 bei JSON zeigen das Problem besonders deutlich: Drei von fünf Aufrufen erreichten nie eine erfolgreiche Ausführung. Der Agent erzeugte korrekte JSON-Inhalte, kam aber nicht durch die Shell. Er versuchte Base64-Kodierung, Piping, Here-Strings, cmd.exe-Durchleitung – alles vergebens. Die Token wurden verbrannt, ohne dass je ein gültiger Befehl zustande kam.

Um den Einfluss der Shell zu prüfen, führte Waldek Mastykarz denselben Test mit Claude Sonnet 4.6 auf macOS durch, wo standardmäßig Bash läuft. Auf PowerShell betrug der Kostenunterschied zwischen Args und JSON das 9-Fache. Auf Bash schrumpfte er auf das 1,5-Fache. Gleiches Modell, gleicher Payload, gleiche Korrektheit. Der Unterschied lag allein in der Art, wie jede Shell mit zitierten JSON-Strings umgeht. Args verhielten sich stabil über beide Shells hinweg: 0,05 $ auf PowerShell vs. 0,07 $ auf Bash. JSON führt eine Abhängigkeit vom Shell-Zitierverhalten ein, die je nach Umgebung stark variiert. Argumente tun das nicht.

Warum Einschränkungen dem Agenten helfen

Die Daten zeigen einen kognitiven Effekt von Einschränkungen. Bei Args legt der Hilfetext fest, welche Eingaben gültig sind. Jede Option hat einen Namen und einen Typ, manchmal eine Aufzählung erlaubter Werte. Das Modell muss von der Aufgabenbeschreibung auf konkrete Optionsnamen und Werte abbilden. Bei JSON erhält das Modell ein Schema (oder leitet es aus der Hilfe ab) und muss ein freies Objekt konstruieren, das diesem Schema genügt. Die Syntax muss gültig sein, die Verschachtelung korrekt, die Feldnamen und Typen müssen passen – und das Ganze muss das Shell-Escaping überleben. Jeder Punkt ist eine Fehlerquelle. Args vermeiden diese Fehlerquellen von vornherein. Stärkere Modelle lösen die JSON-Aufgabe irgendwann, aber mit Aufwand: Sie leisten sich Shell-Fehler, die sie dann reparieren müssen. Diese Reparatur kostet 4- bis 11-mal mehr als der Args-Pfad, selbst wenn die endgültige Korrektheit identisch ist. Kleinere Modelle scheitern an denselben Hürden und können sie nicht überwinden – dort sinkt die Korrektheit drastisch.

Die Einschränkung des gültigen Eingaberaums gleicht Modellschwächen aus. Das Modell muss kein korrekt verschachteltes JSON erzeugen, weil es gar kein JSON gibt. Es muss keine Shell-Zitierung beherrschen, weil die Argumente ohne Zitierung auskommen. Der kognitive Aufwand sinkt auf das Wesentliche: die Zuordnung von Werten zu Parametern. Selbst die kleinsten getesteten Modelle lösen das zuverlässig.

Was das für dein CLI bedeutet

Wenn du ein CLI baust, das auch von KI-Agenten verwendet werden soll, weisen die Daten in eine klare Richtung: Ersetze deine Argumente nicht durch einen --json-Payload. Behalte die klassischen Args. Sie funktionieren über das gesamte Modellspektrum hinweg, haben keine umgebungsabhängigen Fehlermodi und kosten weniger Token – und damit weniger Geld. Du darfst zusätzlich eine --json-Option anbieten, etwa für programmatische Batch-Aufrufe oder manuelle Nutzung. Aber entferne die Args nicht zugunsten von JSON, und erwarte nicht, dass JSON die Agentenerfahrung verbessert. In diesem Experiment hat JSON die Korrektheit nie erhöht und die Kosten immer gesteigert.

Die intuitive Annahme, dass JSON die Arbeit von Agenten erleichtert, ist auf dem Papier nachvollziehbar. In der Realität – mit tatsächlichen Modellen, die in tatsächlichen Shells auf tatsächlichen Betriebssystemen laufen – hält sie nicht stand. Args sind eingeschränkt und vorhersagbar über Shells hinweg. JSON ist ausdrucksstark, aber zerbrechlich. Für den agentengesteuerten CLI-Einsatz gewinnt das Eingeschränkte.

Waldek Mastykarz gibt eine praktische Empfehlung: Bevor du eine solche Änderung vornimmst, miss nach. Wähle ein Szenario, definiere Bewertungskriterien, wähle das für deine Zielgruppe relevante Modell und Betriebssystem, und führe ein paar Durchläufe mit beiden Ansätzen durch. Nach einem Tag hast du eine Antwort, ohne etwas umschreiben zu müssen, das du gar nicht umschreiben musstest. Die Lektion: Plausible Annahmen und gemessene Ergebnisse sind zwei verschiedene Dinge. Wenn sie auseinanderklaffen, haben die Ergebnisse recht.

Du musst dein bewährtes CLI nicht für Agenten umkrempeln. Es ist gut genug. Wenn du Zweifel hast, mach den Test. Die Antwort wird dich beruhigen – und dein Budget freut sich auch.

Quelle: developer.microsoft.com

Du sitzt vor deinem Terminal, tippst claude code „refactoriere diese Funktion“, und die KI schreibt Codeblöcke um, generiert Testfälle und comittet die Änderung. Für Zehntausende von Microsoft-Entwicklern war das Anfang 2026 Alltag. Die Firma rollte zwei kommandozeilenbasierte KI-Agenten aus: Anthropic’s Claude Code und GitHub Copilot CLI. Eine auf arXiv veröffentlichte Studie von Emerson Murphy-Hill, Jenna Butler und Alexandra Savelieva untersuchte, wer diese Werkzeuge nutzt, wer dabeibleibt und was sie bringen. Die Ergebnisse sind nüchtern – und deshalb nützlich.

Stell dir eine gut sortierte Werkstatt vor. Ein neues, teures Werkzeug liegt auf der Werkbank. Es verstaubt, wenn niemand weiß, wie es funktioniert oder ob es sich lohnt. Die ersten, die es anfassen, sind nicht die erfahrensten Mechaniker, sondern die, die sehen, wie ein Kollege damit ein Problem löst. Die Studie zeigt: Die erste Nutzung von Claude Code und Copilot CLI verbreitete sich über soziale Netzwerke. Nicht über E-Mails der Geschäftsführung oder verpflichtende Schulungen, sondern weil Entwickler sahen, wie ein Teammitglied das Tool effektiv einsetzte. Die Forscher nennen es „sichtbare Peer-Nutzung“ – das stärkste Signal für Adoption. Wer zusah, wie ein Kollege einen komplexen Refactoring-Auftrag in Minuten erledigte, wollte es selbst ausprobieren.

Die Studie begleitete die Einführung über vier Monate und wertete Daten von mehreren zehntausend Ingenieuren aus. Ein zentrales Ergebnis: Die Retention – ob jemand das Tool nach den ersten Versuchen weiterhin nutzt – hing nicht von Berufserfahrung, Teamgröße oder Seniorität ab. Sondern von der individuellen Codeaktivität. Wer viel programmiert, integrierte die KI-Agenten nachhaltiger. Es geht nicht um eine spezielle „KI-Affinität“, sondern um den natürlichen Bedarf nach Effizienzsteigerung bei hohem Arbeitspensum. Die Tools verstärken bestehende Verhaltensweisen, sie erschaffen keine neuen.

Zum vielleicht spannendsten Punkt: dem Impact. Die Forscher maßen Produktivität anhand gemergter Pull Requests – Code, der in den Hauptzweig eingeflossen ist. Sie verglichen die Leistung von Adoptern vor und nach der Einführung und stellten einen Anstieg von etwa 24 Prozent fest. Aber die Autoren warnen: Ein gemergter Pull Request ist nicht gleich Wert. Er kann eine kleine Formatierungsänderung sein oder eine große Architekturveränderung. Die reine Stückzahl sagt nichts über Qualität oder Geschäftswert aus. Außerdem korrigierten die Forscher für andere Einflüsse – etwa, dass produktivere Entwickler tendenziell früher zu solchen Tools greifen. Der bereinigte Effekt bleibt über vier Monate stabil. Es ist kein kurzer Hype-Effekt, sondern ein anhaltender Produktivitätsschub.

Ein Detail, das viele überraschen dürfte: die Kosten. Der Token-Verbrauch bei einer Organisation dieser Größenordnung kann schnell in die Millionen Dollar pro Jahr gehen. CLI-basierte KI-Agenten sind keine günstige Spielerei. Die Tools sind tief in den Arbeitsfluss integriert – sie analysieren Code, generieren Vorschläge, führen Tests aus – und sammeln Tokens an. Die Studie gibt keine genauen Dollarzahlen, aber macht klar: Ein Rollout ohne Verständnis von Adoption, Bindung und Produktivitätswirkung kann teuer werden. Fehlinvestitionen entstehen, wenn man die Werkzeuge allen zur Verfügung stellt, aber niemand sie richtig nutzt.

Die Studie unterscheidet sich von vielen Hype-getriebenen Veröffentlichungen. Statt zu behaupten, KI-Coding-Agenten würden die Softwareentwicklung revolutionieren, zeigt sie ein differenziertes Bild: Die Adoption gleicht der jedes anderen neuen Werkzeugs in einem sozialen System. Die produktivsten Entwickler ziehen den größten Nutzen, und der Output steigt messbar, aber nicht dramatisch. Die Autoren empfehlen Unternehmen, ihre Rollout-Strategie nicht allein auf Top-down-Kommunikation zu stützen, sondern auf sichtbare Peer-Beispiele. Das bedeutet, in jedem Team ein oder zwei Early Adopter gezielt zu unterstützen, ihnen zu zeigen, wie sie die Tools am besten einsetzen, und sie dann die Begeisterung weitertragen zu lassen.

Die Studie stammt von Microsoft Research und wirkt selbstkritisch. Die Autoren erwähnen die Gefahr, dass gemergte Pull Requests keine perfekte Metrik für Wert sind. Sie räumen ein, dass die Ergebnisse aus einem einzigen Unternehmen stammen. Dennoch liefert sie eine Blaupause für andere Organisationen, die vor der Entscheidung stehen, CLI-basierte KI-Agenten einzuführen.

Was bedeutet das konkret? Erstens: Die Tools sind keine Wunderwaffe, aber sie können deinen Workflow beschleunigen, wenn du viel Code schreibst. Zweitens: Schau, was deine Kollegen machen. Wenn du jemanden siehst, der mit einem KI-Agenten arbeitet, frag ihn nach seinen Erfahrungen. Die beste Werbung ist ein funktionierendes Beispiel. Drittens: Sei skeptisch gegenüber reinen Output-Steigerungen. Ein Pull Request mehr ist nicht automatisch ein Feature mehr. Qualität muss stimmen, Code-Reviews sind wichtiger denn je, wenn KI-generierte Änderungen in den Main-Zweig fließen. Viertens: Wenn du in einer Führungsrolle bist, investiere lieber in soziale Dynamiken als in teure Lizenzen, die kaum jemand nutzt.

Die Studie von Murphy-Hill und Kollegen erdet die Diskussion um KI-Coding-Agenten. Ja, sie bringen etwas. Aber sie sind kein Selbstläufer. Wer sie nur hinstellt und auf Produktivitätsexplosion wartet, wird enttäuscht. Wer versteht, dass die Einführung eines Werkzeugs immer auch eine kulturelle und soziale Frage ist, kann echte, nachhaltige Verbesserungen erzielen. Die 24 Prozent mehr Pull Requests sind ein starkes Signal – aber die Kunst liegt darin, das Signal nicht mit dem Rauschen zu verwechseln.

Quelle: arxiv.org

Du kaufst ein neues Smartphone. Es ist leichter, hat einen schnelleren Prozessor – und kostet weniger als das Vorgängermodell. Du freust dich. Nach einer Woche merkst du: Der Akku hält nur halb so lang, die Kamera produziert unscharfe Fotos, und die Apps stürzen ab. Was wie ein Upgrade aussah, ist ein Rückschritt. Genau das passiert gerade in vielen Unternehmen mit KI-Modellen.

Waldek Mastykarz, Principal Developer Advocate bei Microsoft, hat das mit seinem Team untersucht. In einem Experiment verglichen sie zwei Modelle: Claude Sonnet 4.6, das ältere, und Claude Sonnet 5, das neuere. Die offiziellen Benchmarks des neuen Modells sind besser, der Preis pro Token ist niedriger – doch die Realität sieht anders aus. Die Ergebnisse: Ein Modell-Update garantiert keine besseren Ergebnisse. Oft ist es das Gegenteil.

Der Kern des Problems liegt in den Token-Kosten. Ein Token ist eine Einheit, die ein KI-Modell bei der Verarbeitung von Text liest oder schreibt – grob gesagt ein Wort oder ein Zeichen. Die Preisliste von Sonnet 5 wirkt auf den ersten Blick günstig: Der Input ist ein Drittel billiger als bei Sonnet 4.6, der Output ebenfalls. Aber die Rechnung geht nur auf, wenn die Anzahl der verbrauchten Tokens gleich bleibt. Und genau das tut sie nicht.

In den Tests – 150 Agentenaufgaben in 15 Szenarien – zeigte sich ein deutlicher Unterschied. Bei Architekturaufgaben verbrauchte Sonnet 5 im Median zwölfmal mehr Tokens als Sonnet 4.6. In einem Einzelfall sogar das 47-fache. Bei Code-Upgrades lag der Faktor bei zehn. Steigt die Token-Menge so stark, nützt der günstigere Preis pro Token nichts. Die Gesamtkosten pro Aufgabe explodieren. Bei Code-Upgrades kostete eine Ausführung mit dem neuen Modell durchschnittlich 2,01 Dollar, mit dem alten nur 0,55 Dollar. Das ist fast das Vierfache.

Auch die Qualität sinkt. In den Architekturszenarien – Aufgaben wie das Entwerfen einer IoT-Analytics-Architektur – erreichte Sonnet 4.6 in 90 Prozent der Fälle die geforderte Qualität im Sinne etablierter Patterns und Konventionen. Sonnet 5 schaffte nur 78 Prozent. Bei neun von zwölf Szenarien war das alte Modell besser oder gleich gut. Die Ergebnisse: Mehr Tokens, schlechtere Ausgabe. Kein Upgrade, sondern ein Downgrade.

Es gibt eine Ausnahme. Bei Code-Upgrade-Aufgaben – etwa der Migration eines SharePoint-Framework-Projekts – drehte sich das Blatt. Hier erfüllte Sonnet 5 die Aufgabe in 100 Prozent der Fälle, während Sonnet 4.6 nur bei 60 Prozent erfolgreich war. Das neue Modell folgte präzise den Anweisungen und suchte tiefer in der Dokumentation. In einem Lauf fraß es sogar 69 Millionen Tokens und entdeckte dabei undokumentierte Migrationsschritte. Aber solche Tiefe ist selten: Nur einer von fünf Läufen zeigte dieses Verhalten. Die Leistung ist real, aber nicht reproduzierbar.

Beide Modelle stoßen an eine gemeinsame Grenze: die Qualität des Inhalts, auf den sie zugreifen können. Bei Code-Upgrades lag die Konfigurationskorrektheit bei null Prozent – für beide Modelle. Keine der KI fand die versteckten Schritte für strukturelle Änderungen wie den Wechsel von gulp zu Heft oder von Legacy-ESLint zu Flat-Config. Die benötigten Informationen waren nirgendwo vollständig dokumentiert. Ein neues Modell kann keine Wunder wirken, wenn die Datenbasis Löcher hat. Eine Erkenntnis: Bevor du über ein Modell-Update nachdenkst, prüfe, ob deine Dokumentation vollständig ist.

Hinzu kommt ein weiteres Problem: die Varianz. Die Token-Kosten schwanken beim neuen Modell dramatisch. Bei einer einfachen Architekturaufgabe verbrauchte ein Lauf 16.000 Tokens, ein anderer 6,6 Millionen – bei exakt dem gleichen Prompt. Solche Ausreißer können das Budget eines ganzen Monats sprengen. Das alte Modell hingegen zeigte enge Cluster: Die meisten Läufe lagen zwischen 14.000 und 45.000 Tokens. Planungssicherheit bietet das neue Modell nicht.

Mastykarz‘ Studie zeigt: Ein Modell-Update ist eine Hypothese, die du für deine spezifische Aufgabe testen musst. Ethan Mollick spricht von der „zerklüfteten Grenze“ der KI-Fähigkeiten: Was auf den ersten Blick ähnlich schwer erscheint, kann auf unterschiedlichen Seiten der Grenze liegen. So auch bei Modell-Updates. Auf Code-Upgrades steigt die Erfolgsrate von 60 auf 100 Prozent, auf Architekturaufgaben sinkt die Qualität von 90 auf 78 Prozent. Du weißt nicht, auf welcher Seite deine Workloads landen, bis du sie misst.

Für Entscheider in Tech-Teams: Wenn du ein neues Modell empfiehlst oder bereitstellst, fang mit deinem Workload an. Für routinemäßige Architektur- und Designaufgaben mit gut dokumentierten Domänen liefert das ältere Modell oft gleich gute oder bessere Ergebnisse zu vergleichbaren Kosten. Für Aufgaben, die präzise Anweisungsbefolgung erfordern, hat das neue Modell einen Vorteil. Der Mix deiner Aufgaben bestimmt, welches Modell das bessere Standardmodell ist.

Wenn du im großen Maßstab arbeitest, spielt auch die Token-Varianz eine Rolle. Die engen Cluster des alten Modells machen die Budgetplanung berechenbar. Das neue Modell kann vom einen zum anderen Lauf um den Faktor 400 schwanken – ein Risiko.

Doch bevor du Zeit in die Evaluation verschiedener Modelle investierst, prüfe zuerst, ob dein Agent die Informationen hat, die er braucht. Mastykarz‘ Team beobachtete: Erweiterungen des Agenten (Extensions) erzeugen mehr Hebelwirkung pro Dollar als ein Modell-Upgrade, weil sie die Wissenslücke schließen, die beide Modelle gleichermaßen betrifft. Wenn deine Dokumentation Lücken hat, schließt sie kein Modell-Wechsel.

Miss zuerst, upgrade dann. Lass dich nicht von niedrigeren Preisen pro Token blenden. Die tatsächlichen Kosten und die Qualität hängen von deiner spezifischen Aufgabe ab. Ein neues Modell ist nicht per se ein Upgrade – es kann ein teurer Rückschritt sein. Nimm dir die Zeit, deine Workloads zu messen, bevor du den Wechsel vollziehst. Das schont Budget und Produktivität.

Quelle: developer.microsoft.com