In een eerdere post deden we een bewering en gaven we toe dat we die niet hadden getest: dat onze front-end agent-skills zwakkere, goedkopere modellen meer zouden moeten helpen dan een frontier-model. De logica was gezond — aangereikte kennis is minder waard voor een model dat het al weet — maar logica is geen bewijs. Dus hebben we het experiment uitgevoerd. Dit is wat de cijfers zeggen.
De opzet
We voerden dezelfde bouwtaken opnieuw uit met twee zwakkere uitvoerders — Haiku 4.5 en Sonnet 4.6 — met de skills en zonder, en beoordeelden ze met dezelfde instrumenten die we op het frontier-model (Opus 4.8) gebruikten. Het getal dat ertoe doet is de lift: hoeveel de skill de output verbetert, gemeten op elk modelniveau.
Twee tests: de zeven kennis-skills (beoordeeld op objectieve correctheid) en de proces-skill "visual polish" (blind beoordeeld op kwaliteit).
Resultaat 1: hoe zwakker het model, hoe groter de lift
Op correctheid is het patroon helder en monotoon:
| Model | Zonder skills | Met skills | Lift |
|---|---|---|---|
| Opus 4.8 (frontier) | 95,8% | 100% | +4,2 pt |
| Sonnet 4.6 | 91,7% | 100% | +8,3 pt |
| Haiku 4.5 (kleinste) | 87,5% | 100% | +12,5 pt |
De skill trekt elk niveau op naar 100% — maar hoe zwakker het model, hoe groter het gat dat het dicht. De lift verdrievoudigt ruwweg van het frontier-model naar het kleinste. De niet-ondersteunde zwakke modellen bleven precies de conventies laten vallen die de skills coderen (een consistente sizing-strategie, toegankelijkheidsvriendelijke breakpoints, mobiele-nav-status, prestatiesignalen); de skill herstelde ze telkens. Hypothese bevestigd.
Resultaat 2: smaak wordt doorgegeven — verificatie niet
De kwaliteits-skill was interessanter. Blind beoordeeld won de output mét skill 3 van de 4 directe duels op de zwakkere modellen (het frontier-model, dat de volledige render-lus draaide, had beide van zijn duels gewonnen). De beoordelaar bestempelde de niet-ondersteunde versies opnieuw als de generieke AI-standaard en de versies mét skill als "op maat ontworpen".
"De winnende ontwerpen kiezen voor zelfverzekerde kleurenpaletten en redactionele typografie; de verliezende leunen op de generieke standaardinstellingen — paars/indigo-verlopen, verloop in kopteksten, uniforme gecentreerde kaarten."
Maar het ene verlies is het nuttigste resultaat van de hele studie. Het kleinste model verloor, zelfs mét de skill, één duel — niet omdat het er generiek uitzag, maar omdat het een call-to-action met kapot contrast opleverde (witte tekst op een witte achtergrond). Dat is precies het soort uitvoeringsdefect dat de render-en-verfijn-lus van de skill is ontworpen om op te vangen door naar de gerenderde pagina te kijken — en een zwakker, browserloos model kon die lus niet betrouwbaar uitvoeren.
De twee helften van de skill gedragen zich dus verschillend naarmate modellen zwakker worden: de meegeleverde smaak (een gecontroleerd designsysteem, vangrails tegen anti-patronen) wordt naar lagere niveaus doorgegeven en houdt de output ervan af er generiek uit te zien. De verificatie (renderen, kritiek leveren, corrigeren) niet — die vereist zowel een browser als voldoende capaciteit om een screenshot te beoordelen.
Wat we hebben veranderd
De bevindingen hebben een duidelijke oplossing: als een zwak model de kijk-en-verfijn-lus niet kan uitvoeren, geef het dan een verificatie-ondergrens die niet afhangt van het oordeel van het model. Dus voegden we aan de polish-skill toe:
- Een afhankelijkheidsvrije geautomatiseerde kwaliteitspoort — een script dat de deterministische defecten markeert (ontbrekende focus-states, geen reduced-motion-bescherming, ontbrekende viewport-tag, content verborgen tot JS, het generieke AI-palet, platte schaduwen, duidelijke contrastfouten) en dat moet slagen voordat er wordt geleverd. Bij het testen liet het de generieke baselines correct falen en liet het de referentiepagina slagen.
- Een scenariomatrix — welke verificatie uit te voeren voor elke combinatie van modelsterkte en browserbeschikbaarheid, met de geautomatiseerde poort als de constante die in elk geval standhoudt.
De poort is een heuristiek, geen renderer — het kan het werkelijke pixelcontrast niet zien — dus wanneer een browser beschikbaar is, draait de volledige rendercontrole nog steeds. Maar het verandert "ik denk dat het goed is" in een gecontroleerd resultaat, ongeacht hoe capabel het model is.
Wat dit betekent voor teams
- Kennis-skills zijn een grotere winst op goedkopere modellen — misschien wel hun beste use case. Als u een klein of budgetmodel in productie draait, is een groot deel van uw kwaliteit afkomstig van goed gebouwde skills.
- Verwacht niet hetzelfde op een frontier-model — dat kent de conventies al, dus een correctheids-skill beweegt het nauwelijks.
- Meegeleverde smaak reist mee; zelfverificatie niet. Een designsysteem tilt de output van elk model op; de kijk-en-corrigeer-lus vereist capaciteit en een browser.
- Geef elk niveau een geautomatiseerde poort. Zo voorkomt u dat een goedkoop model de bug levert die het zelf niet kan zien.
Hoe SplatDev dit toepast
We bouwen AI-versterkte ontwikkelsystemen die zijn afgestemd op het model dat u daadwerkelijk draait — frontier of budget — met de skills, vangrails en geautomatiseerde poorten die de output betrouwbaar maken op dat niveau. En we meten het: waar de winst zit, waar niet, en wat toe te voegen om het gat te dichten.
Draait u een kostengevoelig model en wilt u er meer kwaliteit uit halen?
Neem contact op met SplatDev — Bouw beter met AI
Of mail ons op [email protected]