In einem früheren Beitrag haben wir eine Behauptung aufgestellt und zugegeben, dass wir sie nicht getestet hatten: dass unsere Front-End-Agenten-Skills schwächeren, günstigeren Modellen mehr helfen sollten als einem Spitzenmodell. Die Logik war stimmig – vorgegebenes Wissen ist für ein Modell, das es bereits kennt, weniger wert –, aber Logik ist kein Beweis. Also haben wir das Experiment durchgeführt. Das sagen die Zahlen.
Der Aufbau
Wir haben dieselben Build-Aufgaben mit zwei schwächeren Ausführern – Haiku 4.5 und Sonnet 4.6 – erneut ausgeführt, mit und ohne die Skills, und mit den identischen Instrumenten bewertet, die wir beim Spitzenmodell (Opus 4.8) verwendet haben. Die entscheidende Zahl ist der Zuwachs: wie stark der Skill die Ausgabe verbessert, gemessen auf jeder Modellstufe.
Zwei Tests: die sieben Wissens-Skills (bewertet nach objektiver Korrektheit) und der Prozess-Skill "visueller Feinschliff" (blind nach Qualität beurteilt).
Ergebnis 1: Je schwächer das Modell, desto grösser der Zuwachs
Bei der Korrektheit ist das Muster klar und monoton:
| Modell | Ohne Skills | Mit Skills | Zuwachs |
|---|---|---|---|
| Opus 4.8 (Spitzenmodell) | 95.8% | 100% | +4.2 Pkt. |
| Sonnet 4.6 | 91.7% | 100% | +8.3 Pkt. |
| Haiku 4.5 (kleinstes) | 87.5% | 100% | +12.5 Pkt. |
Der Skill hebt jede Stufe auf 100 % – aber je schwächer das Modell, desto grösser die Lücke, die geschlossen wird. Der Zuwachs verdreifacht sich grob vom Spitzenmodell bis zum kleinsten Modell. Die schwachen Modelle liessen ohne Unterstützung immer wieder genau jene Konventionen weg, die die Skills kodieren (eine konsistente Grössenstrategie, barrierefreie Breakpoints, den Zustand der mobilen Navigation, Performance-Signale); der Skill stellte sie jedes Mal wieder her. Hypothese bestätigt.
Ergebnis 2: Geschmack überträgt sich nach unten – Verifikation nicht
Der Qualitäts-Skill war interessanter. Blind beurteilt gewann die Ausgabe mit Skill bei den schwächeren Modellen 3 von 4 direkten Vergleichen (das Spitzenmodell, das die vollständige Render-Schleife durchlief, hatte beide seiner Vergleiche gewonnen). Der Gutachter kennzeichnete die Versionen ohne Unterstützung erneut als generischen AI-Standard und die mit Skill als "massgeschneidert".
"Die Gewinner-Designs setzen auf selbstbewusste Farbpaletten und redaktionelle Typografie; die Verlierer stützen sich auf die generischen Standards – violett-indigofarbene Verläufe, Verlaufstext in Überschriften, einheitliche zentrierte Karten."
Doch die eine Niederlage ist das nützlichste Ergebnis der gesamten Studie. Das kleinste Modell verlor selbst mit dem Skill einen Vergleich – nicht weil es generisch aussah, sondern weil es einen Call-to-Action mit fehlerhaftem Kontrast auslieferte (weisser Text auf weissem Hintergrund). Genau diese Art von Ausführungsfehler soll die Render-und-Verfeinerungs-Schleife des Skills abfangen, indem sie die gerenderte Seite betrachtet – und ein schwächeres Modell ohne Browser konnte diese Schleife nicht zuverlässig ausführen.
Die beiden Hälften des Skills verhalten sich also unterschiedlich, wenn Modelle schwächer werden: Der mitgelieferte Geschmack (ein geprüftes Designsystem, Leitplanken gegen Anti-Patterns) überträgt sich auf niedrigere Stufen und verhindert, dass die Ausgabe generisch wirkt. Die Verifikation (rendern, kritisieren, korrigieren) hingegen nicht – sie braucht sowohl einen Browser als auch genügend Fähigkeit, um einen Screenshot zu beurteilen.
Was wir geändert haben
Die Erkenntnisse haben eine klare Lösung: Wenn ein schwaches Modell die Betrachtungs- und Verfeinerungs-Schleife nicht ausführen kann, geben Sie ihm eine Verifikations-Basis, die nicht vom Urteil des Modells abhängt. Deshalb haben wir den Feinschliff-Skill ergänzt um:
- Ein abhängigkeitsfreies automatisiertes Qualitäts-Gate – ein Skript, das die deterministischen Mängel kennzeichnet (fehlende Fokus-Zustände, keine Reduced-Motion-Absicherung, fehlendes Viewport-Tag, bis zum Ausführen von JS verborgene Inhalte, die generische AI-Farbpalette, flache Schatten, offensichtliche Kontrastfehler) und vor der Auslieferung bestanden werden muss. Im Test liess es die generischen Baselines korrekt durchfallen und liess die Referenzseite passieren.
- Eine Szenariomatrix – welche Verifikation für jede Kombination aus Modellstärke und Browser-Verfügbarkeit auszuführen ist, mit dem automatisierten Gate als Konstante, die in jedem Fall gilt.
Das Gate ist eine Heuristik, kein Renderer – es kann den tatsächlichen Pixelkontrast nicht sehen –, daher wird bei verfügbarem Browser weiterhin die vollständige Render-Prüfung ausgeführt. Aber es macht aus "ich glaube, das passt" ein überprüftes Ergebnis, unabhängig davon, wie leistungsfähig das Modell ist.
Was das für Teams bedeutet
- Wissens-Skills bringen bei günstigeren Modellen einen grösseren Gewinn – wohl ihr bester Anwendungsfall. Wenn Sie ein kleines oder günstiges Modell in der Produktion einsetzen, stammt ein Grossteil Ihrer Qualität von gut gebauten Skills.
- Erwarten Sie dasselbe nicht bei einem Spitzenmodell – es kennt die Konventionen bereits, sodass ein Korrektheits-Skill es kaum verändert.
- Mitgelieferter Geschmack überträgt sich; Selbstverifikation nicht. Ein Designsystem hebt die Ausgabe jedes Modells; die Betrachtungs- und Korrektur-Schleife braucht Leistungsfähigkeit und einen Browser.
- Geben Sie jeder Stufe ein automatisiertes Gate. So verhindern Sie, dass ein günstiges Modell den Fehler ausliefert, den es selbst nicht sehen kann.
Wie SplatDev das anwendet
Wir bauen AI-gestützte Entwicklungssysteme, die auf das Modell abgestimmt sind, das Sie tatsächlich einsetzen – Spitzenmodell oder günstig –, mit den Skills, Leitplanken und automatisierten Gates, die die Ausgabe auf dieser Stufe zuverlässig machen. Und wir messen es: wo die Gewinne liegen, wo nicht und was hinzuzufügen ist, um die Lücke zu schliessen.
Setzen Sie ein kostensensibles Modell ein und möchten mehr Qualität daraus herausholen?
SplatDev kontaktieren – Besser bauen mit AI
Oder schreiben Sie uns eine E-Mail an [email protected]