Startseite / Artikel / Vercels AGENTS.md-Fähigkeit lehrt KI-Assistenten 70 React-Best Practices.

React Next.js AGENTS.md AI coding assistants Developer Tools Performance

Vercels AGENTS.md-Fähigkeit lehrt KI-Assistenten 70 React-Best Practices.

Ein praktischer Überblick über Vercels react-best-practices Agent-Fähigkeit, der zeigt, wie 70 in der Produktion getestete React-Regeln direkt in von KI generierten Code eingebettet werden.

1477 Wörter

Ein Kollege vom Plattformteam teilte in einem internen Slack-Kanal einen Link ohne jegliche Erklärung – nur die reine URL und ein Schulterzucken-Emoji. Der Link führte zum Repository vercel-labs/agent-skills, genauer gesagt zur Fähigkeit react-best-practices. Man ging davon aus, es handele sich um einen weiteren, neu aufbereiteten Artikel mit „React-Performance-Tipps“, der für die KI-Zeit aufgemotzt wurde. Doch das war nicht der Fall. Stattdessen handelt es sich um ein Regelwerk mit 70 Regeln in 8 Kategorien, das Vercel als Zusammenfassung aus mehr als einem Jahrzehnt Erfahrungen beschreibt, in denen Produktiv-React- und Next.js-Anwendungen auf wiederkehrende Weise fehlerhaft funktionierten. Entscheidend ist, dass es ursprünglich dafür konzipiert wurde, zunächst von einem KI-Programmierassistenten genutzt zu werden und erst in zweiter Linie von menschlichen Entwicklern.

Diese Strukturierung ist tatsächlich der Kern dessen, was dieses Projekt bemerkenswert macht, und es lohnt sich, kurz darauf einzugehen, bevor man sich mit dem eigentlichen Regelinhalt beschäftigt.

Was befindet sich tatsächlich im Repository?

Die Installation der Fähigkeit erfordert nur einen Befehl:

npx skills add vercel-labs/agent-skills

Hinter den Kulissen wird dies in eine AGENTS.md-Datei kompiliert – ein Konvention, das immer mehr an Bedeutung gewinnt, um strukturierten Projektkontext an Programmieragenten bereitzustellen (Tools wie Claude Code, Cursor, Codex und OpenCode suchen alle nach dieser Datei). Sobald sie vorhanden ist, verfügt der Agent über ein Regelbuch, auf das er sich beim Schreiben oder Überprüfen von Code beziehen kann, anstatt ausschließlich auf die verschiedenen React-Tutorials zu vertrauen, die zufällig in seine Trainingsdaten aufgenommen wurden.

Die 70 Regeln sind in acht Kategorien unterteilt, wobei jede Kategorie eine Prioritätsbezeichnung von CRITICAL bis LOW erhält. Die beiden mit CRITICAL markierten Kategorien sind, wie erwartet, jene, auf die das Vercel-Team hinweist als größte Ursachen für Probleme in der Praxis: sequenzielle asynchrone Operationen, die „Wasserfalleffekte“ verursachen, sowie unkontrolliertes Wachstum der Bundle-Größe. Eine typische Regel aus der Kategorie „Wasserfalleffekte“ drückt diese Idee wie folgt aus:

// Flagged: sequential awaits create a waterfall
async function getThreadPage(threadId) {
  const thread = await getThread(threadId)
  const author = await getAuthor(thread.authorId)
  const replies = await getReplies(threadId)
  return { thread, author, replies }
}

// Preferred: parallelize independent fetches
async function getThreadPage(threadId) {
  const [thread, replies] = await Promise.all([
    getThread(threadId),
    getReplies(threadId),
  ])
  const author = await getAuthor(thread.authorId)
  return { thread, author, replies }
}

Das ist alles nichts Neues, wenn man bereits Erfahrung mit der Entwicklung unter React hat. Interessant ist eigentlich nicht der Inhalt der Regeln selbst – sondern die Tatsache, dass diese nun in einer Form vorliegen, die von Maschinen verarbeitet und einheitlich auf der gesamten Codebasis angewendet werden kann, auch um 2 Uhr morgens bei einem Pull Request, der nicht genau überprüft wurde – ohne die Ermüdung oder Abkürzungen, die bei näher rückenden Fristen entstehen.

Warum das sich von einem Linter unterscheidet

Die erste Reaktion ist die Frage, ob es sich dabei nur um ESLint in einem anderen Gewand handelt. In gewisser Weise ja – doch der Mechanismus ist es, der es unterscheidet. Ein Linter weist auf ein Problem hin, nachdem der Code bereits existiert. Dieser Ansatz soll den Code noch während seiner Erstellung beeinflussen und das Problem bereits vor dem Eingeben erkennen. Wenn ein KI-Assistent für 30 bis 60 Prozent des Diffs in einer Pull-Request verantwortlich ist – wobei die Schätzungen je nach Teammitglied stark variieren – dann stellt das Einfügen der Regeln direkt in den Erstellungsprozess eine grundlegend andere Art der Einflussnahme dar als das Nachträgliche Finden von Fehlern.

Es gibt auch eine Art von Anleitung, die ein Linter einfach nicht gut darstellen kann: architektonische Entscheidungen. Eine Regel wie „Vermeiden Sie die Erstellung eines Wasserfallmodells“ lässt sich zumindest grob durch einen Linter unter Berücksichtigung ausreichender benutzerdefinierter Einstellungen und Toleranz für Falschpositiven annähern. Doch etwas wie „Dieser Komponente sollte vermutlich zu einer Serverkomponente werden, da sie kein interaktives Verhalten aufweist und die um sie gezogene Client-Grenze willkürlich erscheint“ erfordert tatsächliches Nachdenken über Absicht und Struktur – genau die Art von Entscheidung, bei der man einen Agenten zur Beurteilung einbeziehen möchte, anstatt sie durch Mustererkennung durchzusetzen.

Wo der Skeptizismus Einzug hält

Es lohnt sich, den unangenehmen Aspekt direkt zu nennen. Eine Satzung, die von derselben Firma erstellt wird, die das Framework entwickelt und deren Hosting-Plattform zufällig bestimmte Leistungsprofile belohnt, ist von vornherein kein neutrales Dokument. Einige der Anleitungen auf CRITICAL-Ebene bezüglich der Größe der Pakete stimmen etwas zu genau mit den Mustern überein, die auch dazu führen, dass Vercels eigene Analyse-Dashboards und Edge-Caching-Einrichtungen hervorragend aussehen. Diese Überschneidung macht die Ratschläge jedoch nicht automatisch schlecht. Sich von asynchronen Abläufen fernzuhalten, ist eine solide ingenieurtechnische Vorgehensweise – egal wer Ihre Anwendung bereitstellt. Dennoch ist es angemessen, im Hinterkopf zu behalten, dass von Anbietern zusammengestellte „Best Practices“ niemals rein technische Erzeugnisse sind – es steckt stets ein leichter Marketingaspekt neben den ingenieurtechnischen Ratschlägen mit drin.

Die zweite Sorge ist struktureller Natur: Was passiert, wenn aus 70 Regeln plötzlich 200 werden oder wenn Fähigkeiten von konkurrierenden Anbietern in derselben AGENTS.md-Datei landen und sich gegenseitig widersprechen? Im Moment, mit einem einzigen Repository und einem völlig neuen Konzept, wirkt alles übersichtlich und leicht verständlich. Wenn man jedoch achtzehn Monate vorausschaut, ist es leicht vorstellbar, dass jedes Framework, jeder Hosting-Anbieter und jedes Design-System seine eigenen Fähigkeiten installieren möchte. Zu diesem Zeitpunkt könnte der Agent mit einer Reihe von Regelbüchern voller widersprüchlicher Anweisungen konfrontiert sein, und es gäbe möglicherweise keine klare Möglichkeit zu erkennen, welche Anweisung Vorrang haben sollte.

Ausprobieren an einer echten Codebasis

Aus Neugierde eher als aus Erwartung wurde die Funktion auf ein mittelgroßes internes Dashboard angewendet, um zu sehen, was tatsächlich zum Vorschein kommen würde. Die als CRITICAL und HIGH eingestuften Probleme erwiesen sich als ziemlich alltäglich: einige aufeinanderfolgende await-Aufrufe, die parallel ausgeführt werden hätten können, ein paar Client-Komponenten, die keinen wirklichen Grund hatten, als solche zu fungieren, sowie ein leicht peinlicher Fall, in dem eine ganze Bibliothek zum Umgang mit Datumsformaten herangezogen wurde, nur um einen einzigen Wert zu formatieren. All das würde niemanden überraschen, der bereits eine gründliche Leistungsanalyse einer React-Codebasis durchgeführt hat. Auffällig war hingegen die Geschwindigkeit – der Agent benötigte etwa vier Minuten, um alles zu finden und zu markieren, im Vergleich dazu, wie lange ein menschlicher Prüfer brauchen würde, um dieselben Probleme in einem großen Pull Request auszumachen.

Dieser Geschwindigkeitsunterschied ist tatsächlich der Kernvorteil hier. Die Regeln an sich sind nicht bahnbrechend – die meisten erfahrenen Ingenieure verfügen bereits instinktiv über dieses Wissen. Was sich ändert, ist, dass die Regeln nun mit einer Konstanz und Geschwindigkeit angewandt werden, die ein menschlicher Prüfer, insbesondere einer, der bereits in seiner dritten Prüfung des Tages ist, einfach nicht aufrechterhalten kann.

Ein unterschätzter Vorteil: Lehren statt nur Durchsetzen

Was die Analyse tatsächlich veränderte, waren nicht die Leistungsüberprüfungen an sich – sondern der Beobachtungsmoment, wie ein neues Teammitglied das Tool nutzte. Diese Person war erst seit wenigen Monaten im Team und lernte noch die Codebasis kennen. Bevor sie einen Pull Request öffnete, bat sie ihren Ansprechpartner, diesen zunächst zu überprüfen. Der Ansprechpartner erkannte ein „Wasserfall-Muster“ und erklärte statt dessen in einfachen Worten – direkt im Zusammenhang mit der konkreten Regel –, warum das Parallelausführen dieser Aufrufe in diesem speziellen Kontext tatsächlich wichtig war. Das ist eine völlig andere Erfahrung als bei einem Linter, der lediglich einen Regel-ID sowie eine knappe Nachricht ausgibt, die man anschließend separat nachschlagen muss. Es fühlte sich eher an wie ein Kommentar eines erfahrenen Ingenieurs, der wirklich hilfreiche Anmerkungen hinterließ – nur kam die Rückmeldung bereits, bevor der PR überhaupt aus dem Entwurfsstatus herauskam.

Das könnte hier der überzeugendere Anwendungsfall sein – mehr als „die KI schreibt saubereren Code“. Es kommt eher dem Prinzip nahe, „dass die KI bessere Gewohnheiten vermittelt“, kontinuierlich und ohne dass jemand Zeit für Mentoring aufwenden oder Einarbeitungsdokumentationen erstellen muss, die bereits nach sechs Monaten veraltet sind. Ob dieser Vorteil auch dann noch besteht, wenn ein Team fünfzig überschneidende Skill-Dateien hat – jede mit ihren eigenen Ansichten, von denen einige unweigerlich mit anderen kollidieren –, bleibt eine offene Frage. Für ein kleines Team, das aus einem erfahrenen Ingenieur und einigen Personen besteht, die sich noch zurechtfinden müssen, scheint es jedoch bereits jetzt ein echter Leistungsmultiplikator zu sein.

Was bleibt davon übrig

Diese Fähigkeit wurde schließlich in der gemeinsamen Teamkonfiguration installiert, hauptsächlich weil die Nachteile minimal sind und der Vorteil – ein Agent, der das Schreiben von „Wasserfall-Code“ vermeidet – ein angemessener Tausch ist. Ob dieses Muster zur Standardmethode wird, mit der Frameworks ihre Konzepte an KI-Agenten weitergeben, oder ob es einfach zu einer weiteren Konfigurationsdatei wird, die still vor sich hin verfällt, sobald die Neuheit nachlässt und niemand sich die Mühe macht, sie zu aktualisieren, ist noch unklar. Das ist eine Frage, die man in sechs Monaten erneut betrachten sollte, anstatt sie jetzt zu beantworten.