In een begeleidend artikel lieten we zien dat AI-agent-skills de front-endoutput meetbaar mooier kunnen maken in een blinde test. Dit artikel is de andere helft van het verhaal — de helft die de meeste "AI heeft onze code beter gemaakt"-posts overslaan: waar de skills niet hielpen, wat ze kostten, en hoe we weten dat het verschil echt is. Als u overweegt of u in agent skills investeert, tellen de tekortkomingen net zo zwaar als de winst.
We bouwden acht skills en testten ze op twee verschillende manieren. Het belangrijkste resultaat is dat de acht skills niet één ding zijn — ze splitsen zich netjes in twee soorten die zich op tegengestelde wijze gedragen.
Twee soorten skills
Het is verleidelijk om "agent skills" als één hefboom te behandelen. Dat zijn ze niet.
Kennis-skills (zeven ervan)
Deze coderen wat goede front-end is: CSS-architectuur, een ontwerpsysteem, responsieve lay-out, semantische HTML en toegankelijkheid, animatie, moderne CSS en browserondersteuning, en prestaties. Het is referentiemateriaal dat de agent op verzoek laadt.
Eén proces-skill
De achtste, "Visual Polish", codeert hoe een ontwerper werkt: bouwen, het in een echte browser renderen, er een screenshot van maken, het aan een rubriek toetsen, de zwakste punten verhelpen en herhalen — plus een gecontroleerde assetbibliotheek voor het ontwerpsysteem en een strikte "definition of done". Het verandert het gedrag van de agent, niet alleen zijn kennis.
Dit onderscheid bleek elk resultaat hieronder te verklaren.
Hoe we het maten
Twee evaluaties, elk waarbij dezelfde taak mét skills versus zonder hulp (geen skills) werd gebouwd:
- Correctheidsevaluatie — zeven bouwtaken, beoordeeld met objectieve controles: gebruikt het relatieve eenheden, semantische HTML, toegankelijke focus-statussen, em-gebaseerde breekpunten, native lazy loading, enzovoort.
- Kwaliteitsevaluatie — twee nieuwe taken (een prijssectie, een finance-landingspagina), blind beoordeeld: een onafhankelijke beoordelaar scoorde alleen de gerenderde screenshots, wist niet welke welke was, en de labels waren willekeurig gerangschikt zodat er geen patroonherkenning mogelijk was.
De cijfers
| Meting | Mét skills | Zonder hulp | Oordeel |
|---|---|---|---|
| Slagingspercentage correctheid | ~90% | ~95% | In feite een gelijkspel |
| Blinde kwaliteit — taak 1 | Gewonnen (hoge betrouwbaarheid) | Verloren | Onderscheidend vermogen 9 vs 3 |
| Blinde kwaliteit — taak 2 | Gewonnen (hoge betrouwbaarheid) | Verloren | Onderscheidend vermogen 8 vs 3 |
| Tijd per taak | +~33% | basislijn | Skills kosten meer |
| Tokens per taak | +~24% | basislijn | Skills kosten meer |
Lees die twee blokken samen en het hele verhaal verschijnt: op correctheid spelen skills en geen-skills gelijk; op vakmanschap winnen skills overtuigend — maar kosten meer.
Waar skills winnen (de winst)
1. Vakmanschap en esthetiek — de doorslaggevende winst
Met de proces-skill ging de output van de herkenbare "generieke AI-standaard" naar werkelijk art-directed — en won een blinde vergelijking op beide taken met hoge betrouwbaarheid. De beoordelaar, zonder enig idee welk ontwerp welk was, benoemde zelfstandig de tekenen van de versies zonder hulp: het donkerpaarse verloop en de verlopende koptekst.
"De ene is art-directed en duidelijk op maat ontworpen — materiaal voor een inspiratiebord. De andere leunt tegelijk op de twee grootste generieke-AI-tekenen. De kloof is duidelijk, niet marginaal."
2. Het vangt echte defecten op
Omdat de proces-skill de agent dwingt om te renderen en te kijken, ving het twee bugs van productiekwaliteit op die een code review had gemist: content die zonder JavaScript onzichtbaar was, en een lay-out die op mobiel horizontaal overliep. Een generatie in één keer leverde geen van beide op — omdat niets het naar het resultaat liet kijken.
3. Het handhaaft uw conventies, elke keer
Skills injecteren betrouwbaar projectspecifieke beslissingen die een model niet standaard zou kiezen: een consistente groottestrategie, em-gebaseerde media queries, moderne CSS afgeschermd door echte browserondersteuningsgegevens, reduced-motion-veiligheid, en gelaagde (niet vlakke) schaduwen. Die consistentie over honderden runs is op zichzelf al een deliverable.
Waar ze dat niet doen (de tekortkomingen)
Het eerlijke deel. Deze zijn echt en het waard om rekening mee te houden.
Kennis-skills verslaan een sterk model amper
Een geavanceerd model kent relatieve eenheden, semantische HTML en de basis van toegankelijkheid al. Dus op de correctheidsevaluatie speelden de zeven kennis-skills in wezen gelijk met het model zonder hulp — en op één taak scoorde de beoordelaar ze zelfs iets lager. Hun waarde ligt in consistentie en het helpen van zwakkere of goedkopere modellen, niet in ruwe winst op een topmodel.
Ze kosten meer
Runs mét skills gebruikten ongeveer 24% meer tokens en 33% meer tijd op de kennistaken; de volledige render-en-itereer-lus is nog zwaarder (tientallen bouw-en-controlestappen tegenover een handvol). U koopt kwaliteit met rekenkracht — de moeite waard wanneer kwaliteit ertoe doet, verspilling wanneer de klus "correcte code, snel" is.
De beste hefboom heeft een browser nodig
De superkracht van de proces-skill is renderen in een echte browser. In een omgeving zonder browser degradeert het tot een kennis-skill en verdwijnt het grootste voordeel. Plan de toolchain dienovereenkomstig.
Kwaliteit is moeilijk goedkoop te meten
Onze objectieve correctheidscontroles waren slecht in het beoordelen van kwaliteit — ze lieten beide versies grotendeels slagen, en produceerden fout-negatieven op de ontwerptaak. Een echte kwaliteitsbeoordeling had een blinde jury van menselijke stijl nodig. En onze kwaliteitsevaluatie was klein: twee taken, één beoordelaar. Overtuigend, maar nog niet statistisch robuust.
Het inzicht dat het samenbindt
Eén zin vat het samen:
"Correctheid is opgelost. Vakmanschap niet. De kloof tussen competente en uitzonderlijke front-end is geen kennis die het model mist — het is smaak die door iteratie wordt toegepast, en een weigering om de generieke standaard uit te leveren."
Daarom bewoog het toevoegen van meer kennis de naald amper, terwijl het toevoegen van een proces — renderen, bekritiseren, verfijnen, tegen meegeleverde smaak — de naald flink bewoog. Een tekstinstructie kan een generatie in één keer niet tot op de pixel perfect maken. Een skill die de agent dwingt naar zijn eigen werk te kijken en het te verhelpen wel.
Wat dit voor teams betekent
- Verwacht geen correctheidswinst van een sterk model. Als uw evaluatie alleen correctheid controleert, zullen skills zinloos lijken — omdat u meet wat het model al doet.
- Investeer in proces, niet alleen in prompts. De duurzame winst komt van verificatielussen die de agent moet uitvoeren, niet van langere instructiebestanden.
- Lever smaak, geen principes. Gecontroleerde, uitgesproken standaardinstellingen verslaan abstract advies elke keer.
- Meet kwaliteit zoals gebruikers die ervaren — render het, kijk ernaar, vergelijk blind. Booleaanse controles kunnen geen schoonheid zien.
- Begroot ervoor. Kwaliteitsoutput kost meer tokens en tijd; besteed het waar kwaliteit het punt is.
Aanbevelingen: de tekortkomingen dichten
De bevindingen wijzen op een concrete takenlijst — voor onze eigen skill-suite en voor elk team dat er een bouwt:
- Schaal de blinde evaluatie op. Twee taken en één beoordelaar bewijzen de richting, niet de omvang. Breid uit naar tien-plus taken over paginatypen heen, voeg een tweede AI-jury toe, en betrek minstens één menselijke beoordelaar. Volg winstpercentage en betrouwbaarheid, niet één enkel oordeel.
- Stem het activeren af, niet alleen de inhoud. Een skill die niet afgaat is waardeloos, en een die op de verkeerde taak afgaat is erger. Voer een geautomatiseerde beschrijvingsoptimalisatie uit zodat elke skill activeert wanneer het zou moeten en stil blijft wanneer het niet zou moeten.
- Laat de proces-skill netjes degraderen. Wanneer er geen browser beschikbaar is, moet het dat detecteren en terugvallen op zijn kennis en checklist in plaats van aan te nemen dat het kan renderen — zodat het nooit stilzwijgend zijn grootste hefboom verliest.
- Consolideer overlappende kennis. Acht skills dragen enig gedupliceerd oppervlak — moderne CSS, responsiviteit en prestaties raken dezelfde grond. Scherpere grenzen betekenen minder onderhoud naarmate het platform beweegt.
- Routeer op intentie. Gebruik de zware render-en-itereer-lus wanneer kwaliteit het doel is; sla het over voor "produceer correcte code, snel". De grootste verspilling is rekenkracht van vakmanschapsniveau betalen voor een wegwerptool voor intern gebruik.
- Meet opnieuw op een zwakker model. Kennis-skills zouden meer moeten helpen waar het basismodel minder capabel is; dat bevestigen kwantificeert hun werkelijke waarde voor kostengevoelige implementaties.
Hoe SplatDev dit toepast
Dit is het werk dat we voor klanten doen: niet zomaar een AI op een codebase richten, maar de skills, vangrails en verificatielussen engineeren die de output ervan betrouwbaar uitstekend maken — en het resultaat vervolgens bewijzen met eerlijke evaluatie in plaats van het aan te nemen. We meten kwaliteit, niet alleen snelheid, en we vertellen u waar de winst zit én waar niet.
Wilt u AI die werk oplevert dat u in een portfolio zou zetten — en een eerlijke verantwoording van de beperkingen ervan?
Neem contact op met SplatDev — Bouw beter met AI
Of mail ons op [email protected]