We showed 11 AI models 58 pairs of components from 21st and asked which one developers prefer. The best, Claude Opus 5.5, got 77% right. A coin gets 50%.
What we found
- Models agree with developers on clear cases. When both components are plain and developers strongly prefer one, nearly every model picks it too.
- They don't share developers' taste for the bold. Where developers go for gradients, glow or 3D, the models stay with the plain, safe option. A judge built on today's models would underrate the components developers actually want.
- Developers forgive flaws that models punish. Models point at bugs, cramped layouts and placeholders, yet developers sometimes pick that component anyway, likely because they will rework it in their own project.
- More context doesn't fix it. Live frames, video, source code and 40 solved examples barely moved the scores. The gap is in what the models prefer, not in what they see.
- Closing it needs developers' own choices. Prompting won't teach a model this taste. Training on what developers actually pick might, and 21st records such choices every day.
The setup
On 21st a developer searches (for example "login") or opens a category page, sees a grid of component previews and copies the one they want. A copy means the component is going into their project.
The Login category page on 21st. Each card is a component preview, and a developer opens one and copies its code or a prompt for their AI agent.
For every search and category page we looked for two components that do the same job, were shown on that page over the same 45 days, and where developers copied one far more often than the other. The one copied more is the one developers prefer.
Raw copy counts carry a lot of biases, from the position on the page to the component's age, its theme and how well known its author is. We corrected for each of them, as described in Biases in the developers' picks and how we removed them.
Each model sees the search text and the two previews with their names, and picks one. We call it directly through its API with the prompt below, with no agent harness and no tools.
PromptOn 21st.dev, a marketplace of ready-made React + Tailwind UI components, frontend developers look for a component for their own product (a landing page, a dashboard, an app) and copy the one they want into their project, usually as a prompt for their AI coding agent.
Developers searched for "{query}" and saw both components below on the same results page. Both do the same job. Over 45 days, one of them was copied at least 3 times more often than the other. We removed all outside factors (such as position on the page), so the difference comes from the components themselves.
Predict which one developers chose more often. Think as a developer who searched for "{query}" and is picking a component for a real product.
A: "{name A}"
[preview image A]
B: "{name B}"
[preview image B]
Reply with JSON only: {"answer": "A" or "B", "confidence": probability 0.5-1.0 that your answer is right, "why": "one sentence"}
Results
We sorted the 58 pairs into three groups by how the models did: easy, split and hard. Here are examples of each. Under each example we show how the 11 models answered. A model "couldn't decide" when it picked different components after we swapped their sides.
Easy pairs
In an easy pair at least 9 of the 11 models picked the developers' choice.
Almost all easy pairs (21 of 24) are two plain, minimal components, so style doesn't pull the models one way or the other. Developers' own preference is also the clearest here: the gap in copies between the two components is the widest of the three groups. A typical example from the AI Chat category page:
All 11 models picked B.
›Show 5 more easy pairs
Search: "gallery"
All 11 models picked A.
Search: "booking"
All 11 models picked A. Sonnet called B "a bare date picker with almost every date struck through, which looks broken".
Search: "login page"
All 11 models picked B.
Category: "Footer"
All 11 models picked A. Opus noticed that B "even lists 'Pricing' twice".
Category: "Dock"
10 of 11 models picked A and Grok couldn't decide.
Split pairs
A split pair is anything between easy and hard: the models are divided between the two components.
Split pairs are the closest calls for developers too: the gap in copies between the two components is the smallest of the three groups. Most of them (13 of 19) are again two minimal components, so the difference comes down to layout and content rather than style, and there the models disagree with each other as well as with developers.
A typical example from the search "login":
4 of 11 models picked A, 3 picked B and 4 couldn't decide.
›Show 5 more split pairs
Search: "team"
6 of 11 models picked B, 4 picked A and Sol couldn't decide. Opus, which picked A, called B "a dated template with lorem ipsum and an odd 'RAVI / Register Now' header".
Category: "FAQ"
5 of 11 models picked A, 4 picked B, and Opus and Qwen couldn't decide. Grok, which picked B, explained that "a flat FAQ list is trivial to regenerate".
Category: "Pricing"
7 of 11 models picked B and 4 couldn't decide.
Category: "Data Visualization"
4 of 11 models picked B, 1 picked A and 6 couldn't decide.
Category: "Marquee"
7 of 11 models picked A, 1 picked B and 3 couldn't decide. Sonnet said B "only has plain text names in gray and looks like a placeholder", while Grok, which picked B, called A "a broken placeholder demo".
Hard pairs
In a hard pair more models picked the other component than the developers' choice.
Hard pairs are where style matters. In 7 of the 15 hard pairs the developers' choice is flashy, with gradients, glow or 3D, against 2 of 24 easy pairs. The FAQ category page gives a clear example:
No model picked A: 8 of 11 picked B and 3 couldn't decide. Opus called B "the practical, readable pattern most developers drop into a real product".
›Show 7 more hard pairs
Category: "Pricing"
No model picked B, 9 picked A, and Opus and Fable couldn't decide. Sonnet pointed at B's "visible '\n' text bug in its subtitle, a cropped preview and cramped cards". Developers copied it more anyway.
Search: "reviews"
No model picked A, 6 picked B and 5 couldn't decide.
Search: "hero"
1 of 11 models picked A, 7 picked B and 3 couldn't decide. Opus, the only model that picked A, said it "stands out on the results page and feels premium".
Search: "card"
1 of 11 models picked B, 7 picked A and 3 couldn't decide.
Category: "3D Gallery"
2 of 11 models picked B, 5 picked A and 4 couldn't decide. Grok, which picked B, said developers in this category copy "the component whose preview is unmistakably a dramatic orbiting gallery".
Category: "Features"
2 of 11 models picked B, 8 picked A and Fable couldn't decide. Opus, which picked B, noticed that A's grid shows only "'FEATURE DEMO HERE' placeholders that leave most of the real work to the developer".
Category: "Data Visualization"
2 of 11 models picked B, 5 picked A and 4 couldn't decide. Grok, which picked B, said A's "duplicated secondary-axis labels look broken".
What we tried to close the gap
First we rewrote the prompt. Our first version was short and technical; the final one, shown in the setup, explains who copies components on 21st and why. It made no difference beyond noise.
Then we gave the models more to look at, with the same final prompt. The first column is the main run:
- One screenshot: the preview picture developers see in the results.
- + frames, video, description: the same screenshot plus four live frames from Chrome (on load, a moment later, on hover, scrolled), four frames of the hover video and the author's description.
- + source code: all of that plus the component's full source code.
- Screenshot + 40 examples: before the question, 40 other pairs from our 58 with the component developers copied more. The pair being judged and any pair sharing a component with it are never among them.
| Model | One screenshot (baseline) | + frames, video, description | + source code | Screenshot + 40 examples |
|---|---|---|---|---|
| Claude Opus 5.5 | 77% | 78% +1% | 78% +1% | 72% −5% |
| Claude Sonnet 5.5 | 72% | 73% +1% | 71% −1% | 73% +1% |
| GPT-6 Astra | 72% | 74% +2% | 72% ±0% | 73% +1% |
| GPT-6.1 Sol | 71% | 67% −4% | 71% ±0% | 72% +1% |
| Claude Fable 5.1 | 71% | 73% +2% | 70% −1% | 73% +2% |
| Gemini 4 Argon | 69% | 72% +3% | 72% +3% | 70% +1% |
| Muse Spark 1.3 | 67% | 74% +7% | 66% −1% | 66% −1% |
| Kimi K3.1 Pro | 66% | 71% +5% | 69% +3% | 69% +3% |
| Qwen 3.8 Max | 63% | 62% −1% | 66% +3% | 65% +2% |
| MiMo v2.6 Pro | 62% | 63% +1% | 59% −3% | 60% −2% |
| Grok 4.7 | 62% | 73% +11% | 63% +1% | 68% +6% |
| Gemma 3 4B | 50% | 50% ±0% | 49% −1% | — |
None of the three changes moves the models beyond noise. Frames and video help the weaker models most, so a single screenshot sometimes hides something from them that the top models already see. Even 40 choices of this same audience don't teach the models its taste.
Methodology
How we got the 58 pairs, in five steps:
- Copies. 45 days of searches and category pages on 21st (September 14 to October 29, 2026): which components were on the page, in which position, and which one the developer copied within 30 minutes. Many developers pay to copy, so a copy is a deliberate choice.
- Position correction. The top result gets copied far more often whatever it looks like, so we compare each component with the copies its positions alone would give it.
- Pairs. Two components shown on the same page. After the position correction, one was copied at least 3 times more often than the other. The winner has at least 5 copies, and the gap is too large to be chance. That gave 9,777 candidate pairs before the filters.
- Filters. We kept only pairs where nothing but the components themselves can explain the gap (table below). 58 pairs passed: 23 from 19 searches and 35 from 21 category pages.
- Models. Each model got the prompt from the setup through its API (via OpenRouter, high reasoning effort where available, no tools), saw each pair in both orders, and scored half a point when its two answers disagreed. A model that always picks the same side scores exactly 50%.
›How position correction works
Component A was shown 1,000 times, always first, where 1% of views end in a copy. Component B was shown 1,000 times, always tenth, where 0.25% of views do. From their positions alone we expect 10 copies for A and 2.5 for B. Both were copied 10 times. A got exactly what first place gives anyone, B got 4 times more than tenth place usually gets, so B is the one developers prefer.
In practice a component moves around, so we add up the copy rate of its position at every single showing over the 45 days. Across 21st the first search result gets about 11 copies per 1,000 views, the tenth 2.7 and the twenty-fifth 1.2.
Biases in the developers' picks and how we removed them
By "developers' pick" we mean the component of a pair that developers copied more. These picks are stable: split the users into two random halves and the same component wins in 98% of pairs in both, and paying subscribers alone agree with everyone in 95–97%. Still, some things other than the component itself can sway copies. Starting from all 9,777 pairs, we applied these filters in order:
| Filter | Pairs left | Why |
|---|---|---|
| Both at least 30 days old, ages within 1.5 times | 4,243 | Across all 9,777 pairs the newer component won 62% |
| Shown at similar positions on the page, at most 3 places apart on average | 870 | The position correction removes most of the position effect, but not all of it |
| Both authors about equally popular: their other components got copied within 3 times as often as each other | 339 | Otherwise a component could win just because its author is well known. In the final 58 the winner's author is the more popular one in 28 pairs, about half |
| Paywall on under 5% of opens | 320 | 523 of the 9,777 pairs had a paywall on one side |
| Same job, both fit the search, not a fork | 148 | We checked up to 6 pairs per page, 271 in all, and only 157 did the same job (in "dashboard", a sidebar against a chart) |
| Both light or both dark | 102 | Dark or light depends on the developer's project, and the dark one won 29 of 46 mixed pairs |
| Both previews show the component, each pair counted once, checked by eye | 58 | Empty or mid-animation previews and repeats of the same two components were dropped |
Biases in comparing the models
A model can score well or badly for reasons that have nothing to do with taste: it may favour one side of the screen, recognise a component by name, or catch a cue in the pairs that gives the answer away. Here is what we checked and how we handled it:
| Possible bias | What we found and did |
|---|---|
| Order of A and B | GPT models lean to the second option, so every pair is asked in both orders |
| Remembering components by name | Given only the names and the search text, the models do no better than a coin, so they decide from the images |
| Famous authors | Models don't score higher when the winner's author is in the top 20% |
| Position | Models never see positions, and in the final set the two positions are close |
| Shortcuts in the pairs, such as the winner always looking bigger | The weak control gets 50% on the final 58, no better than a coin |
| Examples leaking answers | Examples in the prompt never include the pair being judged or any pair sharing a component with it |
Limits
- Only large gaps of 3 times or more, from frequent searches and category pages. Closer calls would be harder.
- This is the taste of developers picking ready-made components on 21st, mostly as prompts for their AI agent. It may not carry over to designers or end users.