Vercels Eval-Daten legen nahe: Statischer Kontext schlägt Skill-Retrieval bei KI-Coding-Agenten

In der KI-Entwicklung gibt es ein wiederkehrendes Thema, das nie alt wird: Der „dumme“ Ansatz schlägt den raffinierten. Diesmal liefert Vercel die Belege. Am 27. Jänner 2026 veröffentlichte das Unternehmen Eval-Ergebnisse, die zwei Ansätze vergleichen, mit denen man KI-Coding-Agenten die APIs von Next.js 16 beibringt: Framework-Features wie use cache, connection() und forbidden(), die jünger sind als der Trainings-Cutoff vieler verbreiteter Modelle.

Die Ergebnisse fielen so einseitig aus, dass sich ein genauer Blick lohnt. Und falls sie sich verallgemeinern lassen, berühren sie eine Grundfrage des Agenten-Designs: Soll ein KI-Agent selbst entscheiden, wann er etwas nachschlägt, oder soll die Information einfach da sein?

Die wichtigsten Zahlen

In Vercels Tests erreichte ein komprimierter Dokumentationsindex von 8 KB, der direkt in AGENTS.md eingebettet war (einer Markdown-Datei, die als dauerhafte Anweisungen in den Kontext des Agenten eingespeist wird), eine Erfolgsquote von 100 % über alle Build-, Lint- und Test-Assertions hinweg. Ein Skill-basiertes Retrieval-System, bei dem der Agent Zugriff auf dieselbe Dokumentation hat, sich aber selbst dafür entscheiden muss, sie aufzurufen, kam selbst mit ausdrücklichen Anweisungen, die zur Nutzung ermunterten, auf höchstens 79 %. Ohne diese Anweisungen erzielte das Skill-System 53 %, genau so viel wie die Baseline ganz ohne Dokumentation.

Das Ergebnis ist bemerkenswert. Es ist außerdem eng gefasst, in der offengelegten Methodik begrenzt und möglicherweise nicht verallgemeinerbar. Beides kann zugleich stimmen.

Was Vercel tatsächlich getestet hat

Bevor man die Zahlen interpretiert, braucht es etwas methodischen Kontext. Vercels Open-Source-Eval-Repository enthält 20 Fixture-basierte Aufgaben. Jede Fixture besteht aus einem Next.js-Projektgerüst, einem Aufgaben-Prompt und einer Reihe von vitest-Assertions, die Build-, Lint- und Testergebnisse prüfen. Laut Vercels Blogbeitrag wurde die Eval-Suite „gehärtet“: Test Leakage wurde entfernt, Widersprüche wurden aufgelöst, und die Assertions prüfen nun das Verhalten. Die Konfigurationen wurden mit Wiederholungen getestet, um die Varianz des Modells zu verringern. (Wiederholungen können Erfolgsquoten scheinbar erhöhen: Eine Aufgabe, die beim ersten Versuch scheitert und bei der Wiederholung gelingt, zählt als bestanden, und die Unbeständigkeit, die die Wiederholung überhaupt nötig machte, bleibt verborgen.)

Was Vercel im Blogbeitrag nicht offenlegt: das genaue Modell oder die genauen Modelle, die Zahl der Wiederholungen pro Konfiguration, die Verteilung der Aufgabenschwierigkeit und ob der Aufwand für das Prompt-Tuning bei allen vier Konfigurationen gleich war. Das Open-Source-Eval-Repo empfiehlt runs: 10 und merkt an, dass einzelne Durchläufe nicht ausreichen, um Zuverlässigkeit zu messen, doch es bleibt unklar, ob die veröffentlichten Ergebnisse dieser Empfehlung folgen.

Der Unterschied ist wichtig: 100 % Erfolgsquote bei 20 Aufgaben mit Wiederholungen erzählt statistisch etwas anderes als, sagen wir, 100 % bei 200 Aufgaben ohne Wiederholungen. Als Richtungsanzeige ist das Ergebnis interessant: Der Abstand zwischen 100 % und 79 % ist beträchtlich, und der Abstand zwischen Skills mit Standardverhalten und Baseline (beide 53 %) ist für sich genommen ein aussagekräftiger Befund. Aber wer die 100 % als Beweis für ein allgemeines Architekturprinzip nimmt, braucht mehr Belege, als die Eval-Suite eines einzelnen Frameworks liefern kann.

Trotz dieser Einschränkungen ist der Unterschied zwischen „Doku verfügbar, aber nicht genutzt“ und „Doku immer sichtbar“ groß genug, um ein allgemeineres Zuverlässigkeitsproblem sichtbar zu machen: Die Nutzung von Tools hängt von Selbstdiagnose ab, und Modelle sind schlecht in Selbstdiagnose.

Zwei Modelle, wie Agenten an Informationen kommen, die sie nicht haben

Vercels Eval ging einer Frage nach, die im Engineering von Agenten immer wichtiger wird: Wie gibt man einem Modell Wissen, das nicht in seinen Trainingsdaten steckt?

Vercel verglich zwei Ansätze, die für unterschiedliche Punkte auf einem zunehmend anerkannten Spektrum des Context Engineering stehen, also der Praxis, bei jedem Schritt einer Inferenzaufgabe auszuwählen, welche Informationen in das Kontextfenster eines Modells gelangen.

Push-Kontext (AGENTS.md) bettet Informationen direkt in die dauerhaften Anweisungen des Agenten ein. Was in AGENTS.md steht, ist für den Agenten während der gesamten Session verfügbar. Der Agent entscheidet nie, ob er es lädt, es ist einfach da. Claude Code verwendet die entsprechende Datei CLAUDE.md. Laut der Open-Agent-Spezifikation tauchen Dateien im Stil von AGENTS.md/CLAUDE.md in mehr als 60.000 Repositories auf, und Tools wie Cursor, Devin, GitHub Copilot und Gemini CLI haben ähnliche Konventionen übernommen.

Pull-Kontext (Skills) arbeitet mit Progressive Disclosure. Der Agent sieht einen Katalog verfügbarer Skills, nur Namen und Beschreibungen, und entscheidet zur Laufzeit, welche er aktiviert. Bei der Aktivierung wird der vollständige Skill-Inhalt in den Gesprächskontext eingespeist. Wie Anthropics Dokumentation zu Claude Skills beschreibt, geschieht diese Auswahl durch „reines LLM-Reasoning“: Es gibt kein algorithmisches Routing und keine Intent-Klassifikation, nur das Urteil des Modells darüber, ob ein Skill relevant ist.

Andrej Karpathy hat Kontextfenster mit dem RAM eines Betriebssystems verglichen. Das ist eine nützliche gedankliche Abkürzung, auch wenn die Analogie Grenzen hat. Kontextfenster verhalten sich nicht wie Speicherhierarchien: Attention-Mechanismen gewichten Informationen anders als Speicheradressierung, und Modelle können nicht zu beliebigen Positionen „springen“, so wie eine CPU den RAM adressiert. Trotzdem trifft die Metapher die zentrale technische Spannung: dauerhafter Kontext (Daten, die beim Booten geladen werden) versus abgerufener Kontext (Daten, die bei Bedarf aus dem Speicher geholt werden). Der Zielkonflikt zwischen Verfügbarkeit und Fensterbudget ist real, auch wenn sich die zugrunde liegenden Mechanismen unterscheiden.

Was bei den Skills schiefging und was die Forschung dazu sagt

Vercels Daten zeigen ein Fehlermuster in drei Stufen, das sich gut mit der vorhandenen Forschung zu LLM-Kalibrierung und Tool-Nutzung deckt.

Der Agent nutzte den Skill nicht. In 56 % der Eval-Fälle mit der Standard-Skill-Konfiguration rief der Agent den Next.js-Dokumentations-Skill nie auf. Er hatte Zugriff auf die Information und entschied sich dagegen, sie zu nutzen. Das Ergebnis: 53 % Erfolgsquote, identisch mit der Baseline.

Das passt zu einem umfangreichen Forschungsstand zur LLM-Kalibrierung. Die Arbeiten reichen von allgemeiner Konfidenzschätzung über domänenspezifische Bewertung bis zu Entscheidungen über Tool-Nutzung und kommen alle zum selben Kernbefund: Modelle überschätzen durchgängig, was sie wissen.

Xiong et al. (ICLR 2024) haben den grundlegenden Befund etabliert, dass LLMs systematisch zu selbstsicher sind, wenn sie ihre Sicherheit in Worte fassen: Die Konfidenzwerte ballen sich unabhängig von der tatsächlichen Genauigkeit überwiegend im Bereich von 80 bis 100 %, ein Muster, das die Autoren darauf zurückführen, dass Modelle menschliche Ausdrucksweisen von Zuversicht nachahmen. Eine biomedizinische Kalibrierungsstudie aus dem Jahr 2025 über neun Modelle hinweg übertrug das auf domänenspezifische Aufgaben und fand Selbstüberschätzung in 84,3 % der 351 getesteten Experimentalszenarien.

Am direktesten relevant für das Problem des Skill-Aufrufs ist die Arbeit von Liu et al. (EMNLP 2024 Findings), die die Unsicherheitskalibrierung speziell bei Sprachagenten mit Tool-Nutzung untersucht hat. Sie identifizieren Prompt-Design und die Auswahl von Execution Traces als „zwei Hauptbereiche, die unter Fehlkalibrierung leiden“. Agenten schätzen also sowohl falsch ein, wann sie Tools nutzen sollen, als auch, welchen Ausführungspfaden sie trauen können.

Zusammengenommen deuten diese Ergebnisse auf ein einheitliches Fehlermuster hin: Modelle sind schlecht kalibriert, und zwar nicht nur bei ihren Antworten, sondern auch bei der Frage, wann sie Hilfe suchen sollten.

Für Skill-Systeme folgt daraus etwas Einfaches: Wenn ein Modell sein vorhandenes Wissen systematisch überschätzt, unterschätzt es auch systematisch, wie sehr es externe Dokumentation braucht. Einen Skill, den das Modell nicht zu brauchen glaubt, ruft es nicht auf.

Ausdrückliche Anweisungen halfen, waren aber fragil. Als Vercel in AGENTS.md Anweisungen ergänzte, die dem Agenten sagten, er solle den Skill nutzen, stieg die Auslöserate auf über 95 % und die Erfolgsquote auf 79 %. Das Ergebnis reagierte aber empfindlich auf die genaue Formulierung: „Explore the project first, then invoke the skill“ funktionierte deutlich besser als direktivere Formulierungen. Vercels Blog nennt keine Erfolgsquoten für die weniger wirksamen Formulierungen, die 79 % sind also vermutlich ein annähernd bestmögliches Ergebnis.

Diese Fragilität ist keine Besonderheit von Vercels Setup. Prompt-Sensitivität, bei der kleine Änderungen in der Formulierung von Anweisungen große Änderungen im Modellverhalten auslösen, gehört zu den am wenigsten verstandenen Eigenschaften LLM-basierter Systeme. Sie zeigt aber, warum es technisch etwas bringt, die Zahl der Entscheidungen zu verringern, die ein Agent treffen muss (welche Formulierung er beachtet, wann er auslöst, was er priorisiert).

Statischer Kontext beseitigte die Entscheidung ganz. Mit dem komprimierten Doku-Index in AGENTS.md erreichte der Agent eine Erfolgsquote von 100 %. Er musste nicht über einen Skill-Aufruf entscheiden und keine Reihenfolge wählen, und die Formulierung spielte keine Rolle.

Der Kompressionsansatz: Technik, keine Magie

Der Mechanismus, mit dem Vercel das Aufblähen des Kontextfensters vermied, verdient einen genaueren Blick, denn von ihm hängt ab, wie gut sich der Ansatz übertragen lässt.

Die ursprünglich eingespeiste Dokumentation umfasste etwa 40 KB. Vercel komprimierte sie auf rund 8 KB und hielt dabei die Erfolgsquote von 100 %, eine Reduktion um 80 %. Das komprimierte Format verwendet einen durch Pipes getrennten Index, der Dokumentationsabschnitte auf lokale Dateipfade abbildet:

[Next.js Docs Index]|root: ./.next-docs|IMPORTANT: Prefer retrieval-led reasoning 
over pre-training-led reasoning|01-app/01-getting-started:{01-installation.mdx,...}|...

Das ist nicht die Dokumentation selbst, sondern eine Nachschlagetabelle. Der Agent sieht den Index, erkennt, zu welchen Themen lokale Dokumentation vorliegt, und liest bestimmte Dateien, wenn er Details braucht. Damit verschiebt sich die Retrieval-Entscheidung von „Soll ich das nachschlagen?“ zu „Welche bestimmte Datei soll ich lesen?“, und das ist eine viel engere und weniger fehleranfällige Entscheidung.

Vercels Blog beschreibt nicht, ob die Kompression manuell oder algorithmisch erfolgte oder wie empfindlich die Erfolgsquote auf die Qualität der Kompression reagiert. Das durch Pipes getrennte Format selbst kann eine Rolle spielen oder auch nicht. Plausibel ist, dass jedes ausreichend strukturierte Format, das auf abrufbare Dateien verweist, ähnlich abschneiden würde, getestet wurde das aber nicht.

Eine wichtige Anweisung im Index, „Prefer retrieval-led reasoning over pre-training-led reasoning“, scheint eine bedeutende Rolle zu spielen, weil sie den Agenten ausdrücklich von seinen Trainingsdaten weglenkt. Ohne Ablationsstudien, die den Beitrag dieser Anweisung isolieren, lässt sich schwer sagen, ob die Indexstruktur oder die Meta-Anweisung mehr bewirkt.

Es gibt ein plausibles kognitives Argument dafür, warum komprimierte Nachschlagetabellen bei Transformer-Modellen besonders gut funktionieren könnten. Vollständige Dokumentation hat viele Token, aber wenig Informationsdichte pro Token: Prosa, Beispiele und Erklärungen, die ein menschlicher Leser braucht, die ein Modell aber als zusätzliche Attention-Ziele verarbeitet, die mit dem eigentlichen Signal konkurrieren. Ein durch Pipes getrennter Index kehrt dieses Verhältnis um: Er ist strukturell karg und inhaltlich dicht, und jedes Token ist für die Retrieval-Aufgabe hochrelevant.

Eine Hypothese lautet, dass das besser dazu passt, wie Attention-Mechanismen Gewicht verteilen: Ein kurzer, strukturierter Index bietet weniger Ablenkung als dieselbe Information verteilt über Seiten natürlicher Sprache. Der Preis dafür ist, dass die strukturelle Kompression semantischen Kontext verwirft, der bei neuartigen oder mehrdeutigen Anfragen helfen könnte. Das könnte erklären, warum der Ansatz bei klar umrissenen API-Lookups gut funktioniert, bei Aufgaben, die tieferes konzeptionelles Verständnis verlangen, aber anders abschneiden könnte.

Das Open-Source-Projekt olore hat dieses Muster auf andere Frameworks verallgemeinert und komprimiert 438 Prisma-Dokumentationsdateien auf etwa 4 KB. Der Befehl npx @next/codemod@canary agents-md automatisiert das Next.js-Setup: Er erkennt die Projektversion, lädt die passende Doku nach .next-docs/ herunter und speist den komprimierten Index ein. Erste Nutzer haben Bugs bei der Indexgenerierung gemeldet, was darauf hindeutet, dass die Werkzeuge noch reifen müssen.

Wo dieser Ansatz nicht funktioniert und wo Skills weiterhin taugen

Die wichtigste Einschränkung von Vercels Befund ist seine begrenzte Reichweite. Getestet wurde der Abruf von Referenzwissen: Der Agent musste API-Syntax, Funktionssignaturen und Nutzungsmuster einer bestimmten Framework-Version kennen. Das ist Faktenwissen, statisch und klein, also genau die Art von Wissen, die sich gut komprimieren lässt und von dauerhafter Verfügbarkeit profitiert.

Mehrere Bedingungen begrenzen, wie weit sich das verallgemeinern lässt.

Größe. Daniel Miesslers Projekt Personal AI Infrastructure betreibt 43 Skills mit insgesamt etwa 398 KB (rund 99.000 Token). Das alles passiv zu laden, würde ungefähr die Hälfte eines 200K-Kontextfensters verbrauchen. Bei Systemen mit großen Skill-Bibliotheken ist das Laden bei Bedarf keine Vorliebe, sondern eine Vorgabe aus der Ökonomie des Kontextfensters. Miesslers Analyse formuliert ein brauchbares Trennprinzip: „Vorgaben für ALLE Ausgaben → passiv. Fähigkeiten für BESTIMMTE Ausgaben → aktiv.“

Komplexität. Skills mit mehrstufigen prozeduralen Workflows, Codeausführung oder Multi-Agent-Orchestrierung lassen sich nicht sinnvoll in einen 8-KB-Index komprimieren. Referenzwissen und prozedurales Wissen unterscheiden sich in ihrer Informationsdichte.

Konflikte zwischen mehreren Frameworks. Ein Projekt mit Next.js, Prisma, TanStack Query und einem eigenen internen Framework bräuchte mehrere komprimierte Indizes in seiner AGENTS.md. Ab einem gewissen Punkt erzeugt die Gesamtgröße genau den Druck auf das Kontextfenster, den Skills vermeiden sollten, dazu kommt möglicherweise die gegenseitige Störung überlappender Anweisungen.

Modellkapazität. Die Analyse von HumanLayer zum Claude-Code-Harness ergab, dass der System-Prompt bereits etwa 50 einzelne Anweisungen enthält, und schätzte, dass Frontier-Thinking-Modelle insgesamt rund 150 bis 200 Anweisungen zuverlässig befolgen können. Jede Anweisung in AGENTS.md konkurriert mit allem anderen im Prompt um die Aufmerksamkeit des Modells. Kleinere Modelle haben entsprechend kleinere Anweisungsbudgets.

Wartungsaufwand. Ein komprimierter Doku-Index muss jedes Mal neu erzeugt werden, wenn sich die Dokumentation des Frameworks ändert. Bei aktiv entwickelten Projekten entsteht so eine Wartungslast, die Skill-basierte Systeme vermeiden, weil sie aktuelle Dokumentation bei Bedarf abrufen.

Kosten und Latenz. Dauerhafter Kontext verursacht bei jedem API-Aufruf Token-Kosten, ob der Agent die Information im jeweiligen Turn braucht oder nicht. Ein 8-KB-Index kostet je nach Encoding und Formatierung grob ein paar tausend Token pro Turn. Für eine einzelne Entwicklungssession ist das vernachlässigbar. Bei einer agentischen Pipeline, die täglich Hunderte Aufgaben abarbeitet, etwa einem CI-System, das über Pull Requests hinweg Code generiert, häuft sich der Overhead an. Ein paar tausend zusätzliche Input-Token pro Aufruf, bei aktuellen Frontier-Preisen in der Größenordnung von einstelligen Dollarbeträgen bis in den niedrigen zweistelligen Bereich pro Million Input-Token (je nach Modell und Tarif), über 500 Aufrufe pro Tag: Das summiert sich allmählich. Mit mehreren Framework-Indizes multipliziert wird daraus ein Kostenposten, den man im Auge behalten sollte.

Vercel räumt ein, dass sich die beiden Ansätze ergänzen. AGENTS.md biete „breite, horizontale Verbesserungen dafür, wie Agenten über alle Aufgaben hinweg mit Next.js arbeiten“, während Skills „besser für vertikale, aktionsspezifische Workflows sind, die Nutzer explizit auslösen“. Diese Einteilung (horizontales Wissen als dauerhafter Kontext, vertikale Fähigkeiten als Skills auf Abruf) wirkt schlüssig, auch wenn sie sich erst noch in anderen Domänen als Next.js bewähren muss.

Zur Veranschaulichung, wo Skills klar überlegen wären: Nehmen Sie einen Workflow „auf den App Router migrieren“, der die aktuelle Routing-Struktur des Projekts liest, einen schrittweisen Migrationsplan erzeugt, Dateien verschiebt und umschreibt und Verifikationstests laufen lässt. Eine solche prozedurale, mehrstufige Aufgabe umfasst bedingte Logik, Codeausführung und Zustandsverwaltung über mehrere Schritte, und nichts davon lässt sich sinnvoll in einen statischen Index komprimieren. Das Skill-Format kann Skripte, Referenzdateien und strukturierte Anweisungen bündeln und ist genau für diese Art von Problem gebaut. Das als dauerhaften Kontext zu kodieren, würde AGENTS.md aufblähen, ohne die Zuverlässigkeit zu erhöhen, denn der Agent braucht die Information nur dann, wenn der Nutzer ausdrücklich eine Migration verlangt.

Was das für das künftige Agenten-Design bedeutet

Mehrere sich abzeichnende Muster scheinen beobachtenswert, mit dem Vorbehalt, dass die meisten auf dünner Evidenz beruhen und sich als abhängig von der Modellgeneration erweisen könnten.

Erstens scheinen komprimierte Referenzindizes eine wirksame Form des Context Engineering für Framework-spezifisches Wissen zu sein. Der Ansatz, eine schlanke Nachschlagetabelle, die auf abrufbare lokale Dateien verweist, statt der vollständigen Dokumentation im Prompt, ist ein vernünftiger Mittelweg zwischen aufgeblähtem Kontext und unzuverlässigem Retrieval. Projekte wie olore deuten darauf hin, dass dieses Muster auch über Next.js hinaus trägt.

Zweitens könnte das Problem des Skill-Aufrufs bei Agenten ein Sonderfall eines breiteren Kalibrierungsversagens von LLMs sein. Modelle rufen keine Tools auf, die sie nicht zu brauchen glauben, und aktuelle Modelle überschätzen ihr vorhandenes Wissen systematisch. Jede Architektur, die darauf baut, dass Modelle ihre Wissenslücken selbst einschätzen, hat demnach grundsätzlichen Gegenwind. Er mag nachlassen, wenn Modelle besser mit Tools umgehen können, ist heute aber beträchtlich.

Drittens scheint die Verringerung von Entscheidungspunkten bei Agenten die Zuverlässigkeit zu verbessern, wenn eine falsche Entscheidung teuer ist. Das erinnert an ein vertrautes Prinzip der Software-Zuverlässigkeit: Die Ausfallwahrscheinlichkeit eines Systems steigt tendenziell mit der Zahl der bedingten Verzweigungen, weil jede Verzweigung zusätzliche Fehlerarten einführen kann. In klassischer Software lautet die Lösung: defensive Standardwerte und weniger Verzweigungen. In Agentensystemen besteht der entsprechende Schritt darin, die Zahl der Stellen zu verringern, an denen das Modell seinen eigenen Wissensstand beurteilen muss, ein Urteil, das es, wie die Kalibrierungsliteratur zeigt, unzuverlässig fällt.

Schließlich sind Evals, die auf Wissen außerhalb der Trainingsdaten zielen, unverzichtbar, wenn man messen will, wie gut die Anbindung der Dokumentation funktioniert. Testen Evals nur Wissen, das das Modell schon hat, wirken alle Ansätze ungefähr gleichwertig. Vercels Eval-Design macht das, bei allen Einschränkungen, richtig.

Die größere Frage

Die Spannung, die Vercels Ergebnisse sichtbar machen (passive Verfügbarkeit gegen aktiven Abruf), ist nicht auf Coding-Agenten oder Next.js beschränkt. Es ist eine Variante einer Frage, die überall dort wiederkehrt, wo KI-Systeme entscheiden müssen, was sie wissen und was sie nachschlagen: Wie sehr sollten wir dem Urteil des Modells über seine eigenen Wissensgrenzen trauen?

Die derzeitige Evidenz aus Vercels Evals und aus der breiteren Literatur zur LLM-Kalibrierung legt nahe: „weniger, als wir hoffen würden“. Das kann sich ändern, wenn Modelle besser werden. Bis dahin scheint es verlässlichere Ergebnisse zu bringen, die Zahl der Retrieval-Entscheidungen eines Agenten zu verringern (durch komprimierte Indizes, dauerhaften Kontext oder andere Formen von proaktivem Context Engineering), als dem Modell zuzutrauen, selbst nach Informationen zu suchen.

Ob dieses Muster im großen Maßstab, über Domänen und über Modellgenerationen hinweg hält, ist die offene Frage. Vercels Daten sind ein nützlicher Datenpunkt, keine abschließende Antwort.

Aus dem Englischen übersetzt: zum Originalbeitrag