Vi byggde samma landningssida med och utan en färdighet

Färdighetsbänken, del 1 av 4. Samma modell, samma prompt, en färdighet installerad eller inte. Detta inlägg: en landningssida. Även i serien: en Telegram-bot, felsökning av ett ormspel och granskning av ett Google zx-skript.

Varje färdighetsrecension på denna webbplats slutar med samma olösta fråga: får denna färdighet Claude att utföra bättre arbete, eller får den bara Claude att utföra mer arbete? Dessa är inte samma sak, och de flesta testuppsättningar kan inte skilja dem åt eftersom körningarna inte är tillräckligt kontrollerade för att isolera den enda variabeln som spelar roll.

Så vi utförde ett experiment. Två körningar, samma modell, samma brief, ner till interpunktionen. Den enda skillnaden mellan dem är en instruktion: "läs och följ denna installerade färdighet." Körning ett, modellen bygger utan hjälp. Körning två, vi pekar den mot den faktiska frontend-design-färdigheten, den som ligger på 9.6 av 10 i vår katalog, och låter den läsa den verkliga SKILL.md innan den rör någon kod. Sedan jämför vi de två landningssidorna rad för rad och räknar antalet tokens varje körning kostade.

Detta är den första av fyra sådana jämförelser. Vi valde en landningssida att börja med eftersom visuell design är det område där "bättre" är lättast att argumentera om och svårast att förfalska. En gradient-tung hero ser antingen ut som alla andra AI-byggda sidor eller inte, och du behöver ingen benchmark för att se vilken.

Upplägget

Briefen var densamma för båda körningarna, en landningssida i en enda fil för "Nimbus", ett fiktivt väder-API, skriven till en Stripe-kaliberstandard: hero-sektion, tre funktionsblock, en pristabell med Free-, $29- och $199-nivåer, ett kodexempelblock och en sidfot. Inga ramverk, inget byggsteg, en HTML-fil med inbäddad CSS.

Körning ett fick den briefen och inget annat. Körning två fick den identiska briefen plus en pekare till den installerade frontend-design-färdigheten, som modellen sedan läste i sin helhet innan den började.

En viktig förbehåll, tydligt uttalat snarare än begravt: detta är N=1. En körning per arm, en modell, en brief. Vi hävdar inte att dessa siffror är statistiskt stabila över hundra försök, och om du kör detta själv kommer du att få olika specifika siffror. Vad vi hävdar är snävare och, vi tror, mer användbart: detta är vad som hände, i detalj, under en verklig körning, med verklig telemetri, och det är ett mönster vi har sett tillräckligt ofta i mindre kontrollerade tester för att lita på dess form även innan vi kör omgång två och tre.

Vad baslinjen byggde

Överlåten åt sig själv producerade Claude en sida som de flesta som har sett mycket AI-output skulle känna igen omedelbart. 890 rader, ett ljust färgschema byggt kring pappers- och bärnstenstoner, och det är värt att vara rättvis här: koden var ren, texten var rimlig, layouten fungerade, inget var trasigt.

Tecknen fanns alla i detaljerna. Elva separata gradienter över sidan, i hero-bakgrunden, i knapptillstånd, i kortramar, på platser där en gradient lade till visuellt brus snarare än att utföra en funktion. Två rubriker använde background-clip: text för att måla själva texten i en gradient, den enskilt mest igenkännbara AI-designsignaturen som finns just nu. Statistiknummer flöt i sina egna kort ovanför vecket, fristående från all layoutlogik, den typ av element som ser ut att ha lagts till för att en mall någonstans har en, inte för att just denna sida behövde det.

Inget av detta är inkompetent. Det är outputen från en modell som är bra på webbdesign i allmänhet och inte har någon specifik synpunkt om just detta varumärke, så den tar till samma knep som dyker upp när samma fråga ställs utan mer begränsning. En körning på 63 329 tokens köpte en levererbar sida. Den köpte inte en sida någon skulle minnas, och det är samma sida vi skulle förvänta oss från de flesta färdigheterna i vår sammanställning av de bästa designfärdigheterna om du tar bort designfärdigheten.

Vad färdighetsarmen byggde annorlunda

Den färdighetsstyrda körningen läste den faktiska anthropics/skills frontend-design SKILL.md innan den skrev något, och den resulterande sidan ser ut som om den kom från en helt annan designbrief. Mörk marinblå bakgrund (--bg: #0B1119) parad med en mässingsaccent (--brass: #D2A25C), en kombination som inte dyker upp någonstans i baslinjens sökutrymme och framstår som ett medvetet val snarare än en standard. 985 rader, fyra gradienter istället för elva, och noll instanser av gradient-text. Inte färre, noll. Typsystemet var disciplinerat på ett sätt som baslinjens inte var: konsekvent skala, konsekvent viktlogik, rubriker som ser valda ut snarare än anpassade i storlek.

Inget med den här sidan skriker "premium" på samma sätt som ett stockfoto av ett handslag skriker "företag". Det är tystare än så. Paletten är ovanlig nog att den inte framstår som en mall, och återhållsamheten med gradienter innebär att de som finns kvar faktiskt bär vikt istället för att dekorera allt de rör. Om du lämnade över båda sidorna till en klient och frågade vilken en designmedveten grundare skulle skicka, är detta inget svårt val.

Siffrorna

	Baslinje (ingen färdighet)	Färdighetsarm (frontend-design)	Delta
Använda tokens	63,329	125,165	+98%
Verktygsanrop	6	57	+51
Outputlängd	890 rader	985 rader	+95 rader
Gradienter	11	4	-7
Gradient-text instanser	2	0	-2
Palett	Ljus, papper + bärnsten	Mörk marinblå + mässing	—

Token-antalet är rubriken och det är inte subtilt: färdighetskörningen kostade nästan dubbelt så mycket. Det är inget avrundningsfel du kan tillskriva brus, och det är siffran varje annan påstående i denna text måste läsas mot.

Varför färdigheten kostar mer

Token-gapet handlar egentligen inte om färdighetens filstorlek. SKILL.md-filer är typiskt några tusen tokens, inte tillräckligt i sig för att fördubbla en körning på 63k tokens. Vad som faktiskt hände är synligt i antalet verktygsanrop: 6 mot 57. Baslinjekörningen skrev sidan och var klar. Färdighetskörningen läste färdigheten, itererade sedan mot den, kontrollerade sin egen output mot en checklista som färdigheten anger, justerade avstånd, omprövade färgval, ifrågasatte ett layoutbeslut den redan hade fattat en gång.

Det är mekanismen, och det är värt att nämna eftersom det betyder att token-kostnaden inte är "att läsa ett längre dokument." Det är "att göra jobbet mer än en gång." En färdighet som beskriver hur bra design ser ut förvandlar en engångsgenereringsuppgift till något närmare en självgranskningsloop, och självgranskningsloopar är till sin natur dyra i tokens, oavsett om en människa eller en modell kör dem.

När +98% tokens är ett fynd, och när det inte är det

Om leveransen är designen är detta inget svårt beslut. En landningssida som en klient kommer att titta på, ett portfolioprojekt, allt där "ser detta ut som om det gjordes av någon med smak" är en del av arbetsbeskrivningen: token-kostnaden här är närmare ett avrundningsfel än en budgetpost. Ingen ifrågasätter att betala en designer för ett andra utkast. Att betala en modell i tokens för motsvarande iteration är samma affär till ett mycket lägre pris, även till dubbla baslinjekostnaden.

Om leveransen är ett internt verktyg, en prototyp som ingen utanför teamet kommer att se, eller en sida som existerar för att bevisa att en API-endpoint fungerar snarare än att representera ett varumärke, hoppa över det. Baslinjens pappers- och bärnstensfärgade sida med sina spridda gradienter gör jobbet. Ingen som utvärderar en intern adminpanel kommer att märka att rubriken använde background-clip: text, och att betala dubbelt så många tokens för att fixa en brist som ingen kommer att se är inte ett kvalitetsköp, det är bara en större räkning.

Hur du reproducerar detta själv

Du behöver inte vår exakta brief för att köra denna jämförelse på ditt eget arbete. Upplägget är tillräckligt enkelt för att göra om på en eftermiddag.

Skriv en brief med konkreta begränsningar: ett produktnamn, en specifik uppsättning sektioner, en specifik prisstruktur, "inga ramverk" om det är viktigt för dig. Vaga briefer producerar vaga deltan, eftersom det finns mindre för en designfärdighet att arbeta mot.

Kör det en gång med en ren modell och inga färdigheter installerade. Spara outputen och notera token-antalet från din harness-telemetri, inte en uppskattning.

Installera frontend-design (eller vilken designfärdighet du än utvärderar), starta om din session så att färdighetens beskrivning laddas om, och kör den identiska briefen igen, ändrad av inget annat än en rad som säger åt modellen att läsa och följa färdigheten.

Jämför de två outputerna för de specifika tecken vi fann här: antal gradienter, användning av background-clip: text, om paletten ser vald eller standard ut, om typskalan är konsekvent. Läs vårt testprotokoll för den fullständiga versionen av denna process, inklusive den trigger-batteri vi kör före varje output-jämförelse.

Jämför token-antal sist, efter att du har bildat dig en uppfattning om outputen. Om du tittar på räkningen först, påverkar det hur generös du är med den visuella jämförelsen, och den ordningen spelar större roll än det låter som den borde.

FAQ

Fördubblar frontend-design-färdigheten alltid token-användningen? Inte nödvändigtvis, och vi hävdar ingen fast multiplikator. Denna körning visade +98% på en brief med en modell. Mekanismen bakom ökningen, fler verktygsanrop eftersom modellen kontrollerar sin output mot färdighetens egen vägledning, bör generaliseras, men den exakta procentandelen kommer att variera med briefens komplexitet och hur mycket fram-och-tillbaka modellen bestämmer sig för att den behöver.

Är en körning per arm tillräckligt för att lita på dessa siffror? Tillräckligt för att lita på mönstret, inte tillräckligt för att lita på den exakta procentandelen. Vi kallar detta N=1 medvetet så att ingen misstar det för en kontrollerad studie. Vad vi kan säga med större säkerhet är riktningen: färdighetsstyrd iteration kostar mer och producerar ett synligt mer genomtänkt resultat, ett mönster som visar sig i varje designfärdighetsjämförelse vi har kört mindre formellt i normal testning.

Varför inte bara instruera Claude att "undvika gradient-text och generisk AI-design"? Det kan du, och det kommer att hjälpa en del. Men en enradsinstruktion bär inte med sig resonemanget som en fullständig färdighet gör, den specifika palettlogiken, typskalsreglerna, checklistan som modellen itererar mot. Vårt fullständiga testprotokoll täcker varför instruktioner på promptnivå och på färdighetsnivå tenderar att producera olika djup av resultat även när de pekar mot samma mål.

Hur jämförs detta med Claudes output för andra typer av uppgifter? Designuppgifter är fallet där en färdighet har mest uppenbart utrymme att hjälpa, eftersom "ser detta distinkt ut" är läsbart även utan ett poängkort. Våra andra inlägg i Färdighetsbänken testar färdigheter mot en Telegram-bot-byggnation, en felsökningssession och en skriptgranskning, tre områden där vinsten, om det finns någon, ser annorlunda ut än en snyggare palett. Se den fullständiga metodiken för hur vi poängsätter över alla fyra.

Vi valde denna brief eftersom en landningssida talar för en designfärdighet utan att någon tolkning krävs. Titta på de två sidorna sida vid sida och paletten, antalet gradienter och typdisciplinen berättar allt som token-tabellen inte kan. Nästa inlägg i denna serie byter ut den visuella klarheten mot något svårare att bedöma med ögat: en fungerande bot, där "bättre" måste bedömas utifrån om saken fungerar.