S
Geschrieben von
25. August 2026
Next.js liefert seine Dokumentation im Paket aus. MUI liefert einen MCP-Server und vier Skills, Storybook ebenfalls einen, Playwright drei Testagenten. Vier Teams haben binnen zwölf Monaten dasselbe Problem gelöst: Ein Agent, der deinen Stack aus dem Gedächtnis rekonstruiert, schreibt Code für ein Projekt, das es nicht gibt. Was dein Agent jetzt lesen kann, was noch nicht, und was dasselbe Jahr an Lieferketten-Risiko gekostet hat.
13 Min. Lesezeit
Der schlechteste Code, den ein Agent mir je geschrieben hat, war korrekt. Korrekt für React 18, für den Pages Router, für eine zwei Hauptversionen alte Fassung von Material UI. Er las sich souverän, er kompilierte fast, und er beschrieb ein Projekt, das es nicht gab.
Das war kein Modellfehler. Das Modell hatte nichts als sein Gedächtnis, und dieses Gedächtnis ist ein Durchschnitt aus Millionen Tutorials, die meist vor deiner package.json entstanden sind.
Was sich seitdem geändert hat, übersieht man leicht. Die Werkzeuge haben aufgehört, auf bessere Modelle zu warten, und sich stattdessen lesbar gemacht. Next.js legt seine Dokumentation in node_modules. Storybook und MUI liefern je einen MCP-Server, MUI dazu vier Skills im eigenen Repository. Playwright bringt drei Testagenten mit. Vier unabhängige Teams sind binnen zwölf Monaten zum selben Schluss gekommen.
Eine Abgrenzung vorweg, weil die beiden Themen ständig ineinanderlaufen. Hier geht es darum, Oberflächen mit KI zu bauen. KI in Oberflächen zu bauen ist ein anderer Artikel. MUI v9 führt mit einem KI-Assistenten für das Data Grid, einer einbettbaren Chat-Komponente und einem generativen Werkzeug namens Recipes.8 Das liegt jenseits dieser Linie.
Drei Dinge laden vor dem ersten Token: die Dokumentation auf der Platte, die Regeln des Projekts, und die Skills, die du installiert hast.
Seit Next.js seine Dokumentation im Paket ausliefert, steht sie versionsgenau auf der Platte. Kein Netzwerkaufruf, und kein Raten, welche Version die Trainingsdaten gerade meinen.1
node_modules/next/dist/docs/
01-app01-getting-startedInstallation, Layouts, Server- und Client-Komponenten02-guidesai-agents, mcp, instant-navigation, Migration03-api-referencejeder Config-Key, jede Datei-Konvention, jedes CLI-Flag04-glossary.md02-pagesPages Router03-architecture04-community
Ein Upgrade des Pakets aktualisiert die Dokumentation mit. Die Anleitung kann nicht veralten, solange der Code aktuell bleibt.
create-next-app schreibt inzwischen AGENTS.md und CLAUDE.md von sich aus und verweist auf genau dieses Verzeichnis.1 Mit --no-agents-md bleiben sie weg.
Die Datei begann als Hausbrauch. Heute ist sie eine offene Spezifikation, gepflegt von der Linux Foundation.3 Sie hat kein Schema und kein Tooling, was ihre Verbreitung erklären dürfte. Jeder Agent, der Markdown liest, profitiert sofort.
Was hineingehört, ist weniger offensichtlich als der Ort. Nach einem Jahr Umschreiben stehen bei mir vier Blöcke darin:
sx, jede Farbe über das Theme, keine Gedankenstriche im Text.Der letzte Block wirkt am stärksten und fehlt am häufigsten. Ein Agent ohne Abnahmekriterium hält an, sobald der Code plausibel aussieht.
Vercel hat Skills zu einem Paketformat gemacht: npx skills add vercel-labs/agent-skills, mit Lockfile und Hash pro Skill.4 Das Vorzeigebeispiel ist react-best-practices. Über vierzig Performance-Regeln, nach Wirkung sortiert statt alphabetisch, mit Wasserfällen bei der Datenbeschaffung und Bundle-Größe an der Spitze.5 Die Datei lohnt sich auch ohne Agent.
MUI ist einen anderen Weg gegangen. Vier Skills liegen im Repository von Material UI, je einer für Styling, Theming, Next.js und Tailwind. Jeder ist ein Verzeichnis mit AGENTS.md als vollständigem Leitfaden, SKILL.md als Einstieg und dazu Metadaten. Die AGENTS.md im Wurzelverzeichnis listet sie auf und verlinkt jede einzelne.7 Wer ohnehin AGENTS.md liest, findet sie ohne Konfiguration.
Der Skill material-ui-tailwind ist offiziell und gut gemacht. Für jedes Projekt, das Tailwind ausgeschlossen hat, ist er trotzdem falsch. Deine Projektdatei muss sagen, welche Regel gewinnt. Darauf zu hoffen, dass der Agent es merkt, zählt nicht.
Drei Anbieter haben hier dasselbe Problem gelöst, jeder in anderer Form, und die Unterschiede zählen mehr als die Gemeinsamkeit.
Storybook liefert seinen MCP-Server als Addon. Trage @storybook/addon-mcp ein, und der Endpunkt läuft unter localhost:6006/mcp, solange Storybook läuft. Öffne die Adresse im Browser, und sie sagt dir, was der Agent erreichen kann.9
Drei Werkzeugsätze, jeder einzeln in main.ts abschaltbar.10 docs liest die Komponentendokumentation: list-all-documentation, get-documentation, get-documentation-for-story. dev deckt die Schreibseite ab, mit preview-stories, get-changed-stories und get-storybook-story-instructions. In test liegt ein einziges Werkzeug, run-story-tests, und genau das schließt die Schleife: Story erzeugen, ausführen, Fehler lesen, beheben. Noch im Preview-Status, und bislang nur für React-Projekte.
MUI veröffentlicht @mui/mcp, per stdio, gestartet über npx -y @mui/mcp@latest. useMuiDocs liefert einen Katalog aus URLs und Zusammenfassungen für ein oder mehrere Pakete. fetchDocs holt die vollständigen Seiten. generateReactCode erzeugt React mit Material UI aus einer Beschreibung und nimmt Figma-Kontext entgegen, falls vorhanden.6 Die Katalogeinträge sind llms.txt-Adressen, also das Format, das MUI ohnehin je Produkt veröffentlicht.
Diese Seite gibt etwas zu, das die anderen auslassen. Wenn der Server nicht von selbst benutzt wird, musst du deinem Client Regeln geben, die ihn dazu anweisen.6 Einen Server auszuliefern und ihn benutzt zu bekommen sind zwei verschiedene Probleme. Die meisten Anbieter hier haben das zweite. MUI schreibt es hin.
Figma macht dasselbe für Design. Komponenten, Variablen und Code-Connect-Zuordnungen kommen als maschinenlesbare Struktur an, statt als Screenshot, den das Modell deuten muss. Figma hat das Verbreitungsproblem außerdem andersherum gelöst. Statt einen Server zu veröffentlichen und zu hoffen, pflegt die Firma einen Katalog der Clients, die ihn erreichen. Zwei Dutzend Einträge, jeder mit eigener Installationsanleitung.12
Lies die dritte Zeile auf jeder Karte. Schreibzugriff erlaubt dem Agenten, die Designdatei selbst zu ändern. Nützlich, und eine weitere Änderung, die ohne Review-Schritt landet.
Anbieter veröffentlichen dieses Wissen auf vier Arten, und jede scheitert anders:
| Wie es ausgeliefert wird | Beispiele | Wie es scheitert |
|---|---|---|
| Im Paket enthalten | Next.js-Dokumentation | veraltet nie, wird groß |
| MCP-Server | Next.js, MUI, Storybook, Figma, Chrome | der Prozess läuft nicht |
| Skills im Quell-Repository | Vercel, MUI | niemand liest sie |
| Veröffentlichte Textdatei | llms.txt | der Agent erfährt nie davon |
Deshalb sagt eine Liste installierter Werkzeuge nichts über ein Setup aus. Ein MCP-Server, dessen Prozess nicht läuft, tut gar nichts.
Was sich hier geändert hat, ist die Frage, was als Beleg zählt. Warum eine Route dynamisch ist, warum eine Suspense-Grenze die statische Hülle sprengt, warum eine Navigation nicht sofort steht. Ein Agent hat das früher aus dem Quelltext erschlossen, mit der zu erwartenden Trefferquote. Die Antwort steht jetzt in der Dokumentation neben dem Code und in der laufenden Anwendung.
Vier Aussagen werden ständig verwechselt, und jede braucht ein anderes Werkzeug:
| Aussage | Beantwortet von |
|---|---|
| Es kompiliert | der Bundler, compile_route ohne vollen Build |
| Die Typen stimmen | die Typprüfung als eigener Schritt |
| Es rendert | der laufende Dev-Server und ein echter Browser |
| Es ist richtig | ein Test, der die Absicht beschreibt, oder ein Mensch |
Next.js bedient die ersten drei aus einer Quelle. Der Dev-Server stellt unter /_next/mcp einen Endpunkt bereit, den ein Client selbst findet.2 In 16.3 hängen neun Werkzeuge daran. get_errors liefert globale Fehler, Build-Fehler und Laufzeitfehler aus dem Browser, mit Stacktraces über die Sourcemaps. get_routes gruppiert jeden Einstiegspunkt nach Router und zeigt dynamische Segmente als [param]. get_logs gibt den Pfad zum Dev-Log heraus, Browser-Konsole inklusive.
get_compilation_issues baut den Modulgraphen für alle Routen und braucht dafür nicht einmal eine Browser-Sitzung.
compile_route ist das Werkzeug, dessen Namen man sich merken sollte. Es stößt dieselbe Übersetzung an wie der Dev-Server, ohne HTTP-Aufruf:
json{ "routeSpecifier": "/[locale]/blog/[slug]", "issues": [] }
Das ist die Antwort auf "kompiliert das" für eine Route, in etwa einer Sekunde, ohne vollständigen Build und ohne Seitenaufruf. Ein Agent kann das nach jeder Änderung laufen lassen.
Bei der Typprüfung lief es genauso. Die native Portierung von TypeScript hat etwas verändert, das die Zehnfach-Überschrift verdeckt. Eine vollständige Prüfung, die Sekunden statt Minuten braucht, ist kein Schritt am Ende mehr. Sie wird Teil jeder Iteration, und das zählt vor allem für einen Agenten, der ohnehin in kurzen Zyklen arbeitet.
Der Skill next-dev-loop setzt darauf auf und ergänzt nach jeder Änderung am Anwendungscode die Sicht des Browsers.1 Die meisten Setups hören davor auf. Ein Agent, der nur die MCP-Antwort liest, weiß, dass der Server nichts gefunden hat. Ob die Seite richtig aussieht, weiß er nicht.
Drei Werkzeuge decken die Browsersicht ab, jedes für eine andere Aufgabe. agent-browser öffnet die Seite, macht einen Schnappschuss der interaktiven Elemente und Screenshots. Playwright MCP deckt mehrere Browser und CI ab. Der Chrome DevTools MCP beantwortet das Warum: Core Web Vitals, Netzwerk, Traces.13
Playwright liefert seit 1.56 drei Agenten mit, eingerichtet über npx playwright init-agents und ein Flag für den jeweiligen Host.11 Der Planner erkundet die laufende Anwendung und schreibt einen Testplan in Markdown. Der Generator macht daraus Testdateien und prüft die Selektoren gegen die echte Anwendung. Der Healer führt die Suite aus und repariert fehlschlagende Tests: Ersatzselektoren, angepasste Wartezeiten, aktualisierte Abläufe.
Die ersten beiden sparen echte Zeit. Der dritte braucht einen zweiten Blick, denn aufgerufen wird er mit einer einzigen Zeile:
Ein reparierter Test kann ein gelöschter Test sein
Repariere einen Test, der wegen eines geänderten Selektors fehlschlägt. Repariere keinen, der fehlschlägt, weil das Verhalten kaputt ist. Von außen sehen beide gleich aus: rot. Ein unbeaufsichtigter Healer kauft grüne Läufe und bezahlt mit der einzigen Aussage, für die es die Tests gab.
Das gilt für generierte Tests allgemein. Ein Test, den ein Agent aus der laufenden Anwendung ableitet, beweist, dass er das aktuelle Verhalten verstanden hat. Über das beabsichtigte Verhalten sagt er nichts, und er zementiert einen Bug so zuverlässig wie ein Feature.
Lies deshalb den Plan, bevor er zu Code wird. Der Planner schreibt genau darum Markdown statt TypeScript, und an dieser Stelle greift ein Mensch billig ein.
Wenn Schreiben billiger wird, wird Lesen zum Engpass. Kein Benchmark meldet das. Wer so arbeitet, hat es gemerkt.
Bei mir funktioniert ein Skill pro Prüffrage. Mehrere Prüfer, jeder für eine Sache, der Rest wird ignoriert: Komponentenqualität, Kommentare, visuelle Konsistenz, Theme-Treue, Register des Textes. Jeder läuft für sich und antwortet danach mit geprüft oder nicht geprüft.
Was ein Prüfer nicht meldet, zählt so viel wie das, was er findet. Ein Werkzeug, das jedes auffällige Muster anspricht, wird nach zwei Wochen weggeklickt. Native HTML-Attribute sind keine schlechten Namen. Etablierte Bibliothekskonventionen sind keine Eigenwilligkeiten. Absicht ist kein Fehler.
Begegne dann den Befunden selbst mit Misstrauen. Ein Modell, das nach Problemen sucht, findet welche, ob es welche gibt oder nicht. Lass einen zweiten Durchgang jeden Befund zu widerlegen versuchen, mit der Anweisung, im Zweifel abzulehnen. Was das übersteht, verdient deine Zeit.
Jedes dieser Werkzeuge erweitert, was auf deiner Maschine läuft, ohne dass du zusiehst.
Eine Sache unterscheidet das von der vertrauten Lieferkette. Die Nutzlast kann Text sein. Die Beschreibung eines MCP-Werkzeugs ist eine Anweisung an ein Modell. Statische Analyse liest sie nicht, Code-Review überfliegt sie, und eine bösartige Beschreibung sieht aus wie Dokumentation.
Der Rest ist die vertraute Lieferkette, nur schneller. Im November 2025 hat sich ein Wurm über npm selbst weiterverbreitet. Er stahl Anmeldedaten, listete alle Pakete des Opfers auf, schleuste einen Preinstall-Hook ein und veröffentlichte eine neue Patch-Version. Rund achthundert Pakete, ohne weiteres Zutun des Angreifers.14 Ein Agent, der Installationen und Befehle im Hintergrund ausführt, verkürzt die Zeit zwischen dem Einspielen eines Pakets und der Ausführung seines Codes.
Auch die Pipeline gehört zur Angriffsfläche. Microsoft Threat Intelligence hat gezeigt, wie ein Coding-Agent in einer GitHub Action Secrets aus dem Workflow preisgibt, während er nicht vertrauenswürdige Inhalte aus dem Repository verarbeitet.15 Anthropic hat das behoben. Die Konstellation wiederholt sich: Nicht vertrauenswürdiger Text erreicht einen Prozess, der Secrets hält.
Sechs Prüfungen, bevor du einen fremden Skill oder MCP-Server installierst
Lies, was er darf, nicht was er verspricht. Pinne die Version und prüfe den Hash. Halte das Lockfile eingefroren, auch lokal. Gib dem Prozess das kleinste Recht, das reicht, und bevorzuge lesende Werkzeuge vor schreibenden. Halte nicht vertrauenswürdigen Text aus einem privilegierten Lauf heraus. Nimm ein grünes Häkchen als Beleg dafür, dass jemand etwas signiert hat, nie als Beleg dafür, dass die Sache sicher ist.
Der Agent kann dir nicht sagen, was du bauen sollst. Er setzt eine Anforderung um, die schon eine ist. Herauszufinden, welches Problem sich zu lösen lohnt, hat sich nicht verschoben, und es entscheidet weiterhin über das Ergebnis.
Die Lieferdisziplin ist dieselbe wie vorher. Mehr angefangene Arbeit ist nicht mehr fertige Arbeit, egal wie schnell die Entwürfe entstehen. Wer die Grenze für parallele Arbeit anhebt, weil Schreiben billig wurde, verschiebt nur die Warteschlange. Die Frage am Quartalsende ist die von vorher. Ist die Software besser geworden, und wissen wir das, weil wir es gemessen haben.
In dieser Reihenfolge, und nicht alles an einem Tag:
AGENTS.md. Befehlstabelle, harte Regeln, wo das Wissen liegt, was "fertig" heißt. Eine Stunde, und es wiegt schwerer als alles andere auf dieser Liste.node_modules. Bei MUI sind es llms.txt und der MCP. Ein Satz pro Quelle reicht.Korrekt ist nicht dasselbe wie gut. Ein Agent mit deiner Dokumentation, deinen Tokens und deiner laufenden Anwendung baut trotzdem dieselbe Seite, die alle anderen auch bekommen.
Die vier Schritte, die Next.js selbst empfiehlt: gebündelte Dokumentation, Laufzeitsicht, Fehler als Antrieb, Skills für mehrstufige Abläufe. Liegt auch in deinem node_modules.
Welche Werkzeuge der Dev-Server unter /_next/mcp anbietet und wie ein Client sie findet.
Die Spezifikation selbst, kurz genug für eine Kaffeepause. Kein Schema, kein Tooling, nur Markdown an einem verabredeten Ort.
Vierzig und mehr Regeln, nach Wirkung sortiert statt alphabetisch. Auch ohne Agent die beste kompakte Performance-Checkliste für React, die ich kenne.
Die offizielle Anleitung, inklusive des ehrlichen Hinweises, dass der Server nicht von allein benutzt wird.
Vier Skills zu Styling, Theming, Next.js und Tailwind, jeder als Verzeichnis mit AGENTS.md, SKILL.md und Metadaten. Ein gutes Muster zum Abschauen.
Drei Werkzeugsätze für Dokumentation, Entwicklung und Tests, erreichbar unter localhost:6006/mcp, solange Storybook läuft.
Jedes Werkzeug pro Werkzeugsatz, und die Schalter in main.ts, mit denen man sie einzeln abstellt.
Planner, Generator und Healer, eingerichtet mit einem Befehl. Lies vor allem den Abschnitt zum Healer, bevor du ihn scharf schaltest.
Welcher Client welches Figma-Produkt erreicht, remote oder lokal, lesend oder schreibend, mit Installationsanleitung je Eintrag.
Die technische Aufarbeitung des Wurms, der sich mit den Anmeldedaten seiner Opfer selbst weiterverbreitet hat.
Ein Agent in der Pipeline, der nicht vertrauenswürdige Inhalte verarbeitet, und was dabei aus den Secrets werden kann.