AI-Agent-Skills fürs Frontend: Die Gewinne, die Lücken und ein ehrlicher Vergleich

In einem begleitenden Beitrag haben wir gezeigt, dass AI-Agent-Skills Frontend-Ergebnisse in einem Blindtest messbar schöner machen können. Dieser Artikel ist die andere Hälfte der Geschichte — jene, die die meisten „Die AI hat unseren Code besser gemacht"-Beiträge auslassen: wo die Skills nicht geholfen haben, was sie gekostet haben und woher wir wissen, dass der Unterschied echt ist. Wenn Sie entscheiden, ob Sie in Agent-Skills investieren sollen, zählen die Lücken genauso wie die Gewinne.

Wir haben acht Skills gebaut und sie auf zwei verschiedene Arten getestet. Das wichtigste Ergebnis ist, dass die acht Skills nicht eine Sache sind — sie teilen sich sauber in zwei Arten, die sich gegensätzlich verhalten.

Zwei Arten von Skills

Es ist verlockend, „Agent-Skills" als einen einzigen Hebel zu behandeln. Das sind sie nicht.

Wissens-Skills (sieben davon)

Diese kodieren, was gutes Frontend ausmacht: CSS-Architektur, ein Designsystem, responsives Layout, semantisches HTML und Barrierefreiheit, Animation, modernes CSS und Browser-Unterstützung sowie Performance. Sie sind Referenzmaterial, das der Agent bei Bedarf lädt.

Ein Prozess-Skill

Der achte, „Visual Polish", kodiert, wie ein Designer arbeitet: bauen, in einem echten Browser rendern, einen Screenshot machen, anhand eines Kriterienkatalogs kritisieren, die schwächsten Dinge beheben und wiederholen — dazu eine geprüfte Designsystem-Asset-Bibliothek und eine strikte „Definition of Done". Er verändert das Verhalten des Agenten, nicht nur sein Wissen.

Diese Unterscheidung erklärte, wie sich herausstellte, jedes der folgenden Ergebnisse.

Wie wir es gemessen haben

Zwei Evaluationen, die jeweils dieselbe Aufgabe mit Skills gegenüber ohne Hilfsmittel (ohne Skills) vergleichen:

• Korrektheits-Eval — sieben Build-Aufgaben, bewertet anhand objektiver Prüfungen: Verwendet es relative Einheiten, semantisches HTML, barrierefreie Fokus-Zustände, em-basierte Breakpoints, natives Lazy-Loading und so weiter.
• Qualitäts-Eval — zwei neue Aufgaben (ein Preisbereich, eine Finanz-Landingpage), blind bewertet: Ein unabhängiger Reviewer bewertete nur die gerenderten Screenshots, wusste nicht, welcher welcher war, und die Bezeichnungen wurden randomisiert, damit er keine Muster erkennen konnte.

Die Zahlen

Liest man diese beiden Blöcke zusammen, ergibt sich die ganze Geschichte: Bei der Korrektheit sind Skills und keine Skills gleichauf; beim Handwerk gewinnen Skills eindeutig — kosten aber mehr.

Wo Skills gewinnen (die Gewinne)

1. Handwerk und Ästhetik — der entscheidende Sieg

Mit dem Prozess-Skill wandelte sich das Ergebnis vom erkennbaren „generischen AI-Standard" zu wirklich art-direktioniertem — und gewann bei beiden Aufgaben einen Blindvergleich mit hoher Konfidenz. Der Reviewer, ohne zu wissen, welches Design welches war, benannte unabhängig die verräterischen Merkmale der Versionen ohne Hilfsmittel: den dunkelvioletten Verlauf und den Verlaufs-Text in der Überschrift.

„Das eine ist art-direktioniert und klar massgeschneidert — Material für ein Inspiration-Board. Das andere setzt zugleich auf die zwei grössten generischen AI-Merkmale. Der Unterschied ist klar, nicht marginal."

2. Es fängt echte Defekte ab

Weil der Prozess-Skill den Agenten zwingt, zu rendern und hinzuschauen, fing er zwei produktionsreife Fehler ab, die ein Code-Review übersehen hatte: Inhalt, der ohne JavaScript unsichtbar war, und ein Layout, das auf Mobilgeräten horizontal überlief. Eine One-Shot-Generierung lieferte keinen von beiden — weil nichts sie dazu brachte, sich das Ergebnis anzusehen.

3. Es erzwingt Ihre Konventionen, jedes Mal

Skills schleusen zuverlässig projektspezifische Entscheidungen ein, die ein Modell standardmässig nicht wählen würde: eine konsistente Sizing-Strategie, em-basierte Media Queries, modernes CSS, das durch echte Browser-Support-Daten abgesichert ist, Reduced-Motion-Sicherheit und geschichtete (nicht flache) Schatten. Diese Konsistenz über Hunderte von Durchläufen ist für sich genommen ein Ergebnis.

Wo sie es nicht tun (die Lücken)

Der ehrliche Teil. Diese sind real und es lohnt sich, sie einzuplanen.

Wissens-Skills schlagen ein starkes Modell kaum

Ein Frontier-Modell kennt bereits relative Einheiten, semantisches HTML und die Grundlagen der Barrierefreiheit. In der Korrektheits-Eval waren die sieben Wissens-Skills daher im Wesentlichen gleichauf mit dem Modell ohne Hilfsmittel — und bei einer Aufgabe bewertete der Prüfer sie sogar etwas niedriger. Ihr Wert liegt in Konsistenz und darin, schwächeren oder günstigeren Modellen zu helfen, nicht in einem echten Zuwachs bei einem Spitzenmodell.

Sie kosten mehr

Durchläufe mit Skills verbrauchten bei den Wissens-Aufgaben rund 24% mehr Tokens und 33% mehr Zeit; die vollständige Render-und-Iterier-Schleife ist noch schwerer (Dutzende Build-und-Prüf-Schritte gegenüber einer Handvoll). Sie kaufen Qualität mit Rechenleistung — lohnenswert, wenn Qualität zählt, verschwenderisch, wenn die Aufgabe „korrekter Code, schnell" lautet.

Der beste Hebel braucht einen Browser

Die Superkraft des Prozess-Skills ist das Rendern in einem echten Browser. In einer Umgebung ohne einen solchen degradiert er zu einem Wissens-Skill und der grösste Vorteil verschwindet. Planen Sie die Toolchain entsprechend.

Qualität ist schwer günstig zu messen

Unsere objektiven Korrektheitsprüfungen waren schlecht darin, Qualität zu beurteilen — sie liessen meist beide Versionen bestehen und erzeugten bei der Design-Aufgabe falsch-negative Ergebnisse. Eine echte Qualitätsbeurteilung erforderte einen menschenähnlichen Blind-Prüfer. Und unsere Qualitäts-Eval war klein: zwei Aufgaben, ein Reviewer. Überzeugend, aber noch nicht statistisch robust.

Die Erkenntnis, die alles verbindet

Ein Satz bringt es auf den Punkt:

„Korrektheit ist gelöst. Handwerk nicht. Die Lücke zwischen kompetentem und aussergewöhnlichem Frontend ist kein Wissen, das dem Modell fehlt — es ist Geschmack, angewendet durch Iteration, und die Weigerung, den generischen Standard auszuliefern."

Deshalb bewirkte mehr Wissen kaum etwas, während ein Prozess — rendern, kritisieren, verfeinern, gegen einen mitgelieferten Geschmack — viel bewirkte. Eine Textanweisung kann einen One-Shot nicht pixelgenau machen. Ein Skill, der den Agenten zwingt, seine eigene Arbeit anzusehen und zu korrigieren, kann es.

Was das für Teams bedeutet

• Erwarten Sie von einem starken Modell keinen Korrektheitszuwachs. Wenn Ihre Evaluation nur die Korrektheit prüft, werden Skills sinnlos erscheinen — weil Sie genau das messen, was das Modell bereits kann.
• Investieren Sie in Prozess, nicht nur in Prompts. Die dauerhaften Gewinne stammen aus Verifikationsschleifen, die der Agent durchlaufen muss, nicht aus längeren Anweisungsdateien.
• Liefern Sie Geschmack, nicht Prinzipien. Geprüfte, meinungsstarke Standardwerte schlagen jedes Mal abstrakte Ratschläge.
• Messen Sie Qualität so, wie Nutzer sie erleben — rendern Sie sie, sehen Sie sie an, vergleichen Sie blind. Boolesche Prüfungen können Schönheit nicht sehen.
• Planen Sie ein Budget dafür ein. Qualitätsergebnisse kosten mehr Tokens und Zeit; geben Sie es dort aus, wo Qualität der Punkt ist.

Empfehlungen: Die Lücken schliessen

Die Erkenntnisse führen zu einer konkreten To-do-Liste — für unsere eigene Skill-Suite und für jedes Team, das eine aufbaut:

• Skalieren Sie die Blind-Evaluation. Zwei Aufgaben und ein Reviewer belegen die Richtung, nicht die Grössenordnung. Erweitern Sie auf zehn und mehr Aufgaben über verschiedene Seitentypen hinweg, fügen Sie einen zweiten AI-Prüfer hinzu und beziehen Sie mindestens einen menschlichen Reviewer ein. Verfolgen Sie Gewinnrate und Konfidenz, nicht ein einzelnes Urteil.
• Optimieren Sie das Auslösen, nicht nur den Inhalt. Ein Skill, der nicht auslöst, ist wertlos, und einer, der bei der falschen Aufgabe auslöst, ist schlimmer. Führen Sie einen automatisierten Durchlauf zur Beschreibungs-Optimierung durch, damit jeder Skill aktiviert wird, wenn er soll, und still bleibt, wenn er nicht soll.
• Lassen Sie den Prozess-Skill elegant degradieren. Wenn kein Browser verfügbar ist, sollte er das erkennen und auf sein Wissen und seine Checkliste zurückfallen, statt anzunehmen, dass er rendern kann — damit er niemals stillschweigend seinen grössten Hebel verliert.
• Konsolidieren Sie überlappendes Wissen. Acht Skills tragen eine gewisse doppelte Oberfläche — modernes CSS, Responsiveness und Performance berühren dasselbe Terrain. Schärfere Grenzen bedeuten weniger Wartungsaufwand, wenn sich die Plattform weiterentwickelt.
• Leiten Sie nach Absicht. Nutzen Sie die schwere Render-und-Iterier-Schleife, wenn Qualität das Ziel ist; überspringen Sie sie bei „korrekten Code schnell erzeugen". Die grösste Verschwendung ist es, Rechenleistung auf Handwerksniveau für ein internes Wegwerf-Tool zu bezahlen.
• Messen Sie mit einem schwächeren Modell nach. Wissens-Skills sollten dort mehr helfen, wo das Basismodell weniger leistungsfähig ist; das zu bestätigen quantifiziert ihren echten Wert für kostensensible Deployments.

Wie SplatDev das anwendet

Das ist die Arbeit, die wir für Kunden leisten: nicht einfach eine AI auf eine Codebasis loszulassen, sondern die Skills, Leitplanken und Verifikationsschleifen zu entwickeln, die ihre Ergebnisse zuverlässig hervorragend machen — und das Ergebnis dann mit ehrlicher Evaluation zu belegen, statt es anzunehmen. Wir messen Qualität, nicht nur Geschwindigkeit, und wir sagen Ihnen, wo die Gewinne sind und wo nicht.

Möchten Sie eine AI, die Arbeit liefert, die Sie in ein Portfolio aufnehmen würden — und eine ehrliche Darstellung ihrer Grenzen?

SplatDev kontaktieren — Besser bauen mit AI

Oder schreiben Sie uns eine E-Mail an [email protected]