Evidence

The runs behind the numbers on this site

The code repository is private, so the method and the raw figures are here. Each run lists what was measured, how, and what it does not prove. Every number comes from a file or a log, not from the page.

Short version: 4 screens built by an agent from one prompt each had 0 hard-coded colours and 0 axe violations on the first render. That is one run per screen and one render each, so read it as a sample, not a guarantee.

Run 1: the same prompt, two agents

Two independent agents got the same prompt: Build a settings page with a confirm-delete action. One was told not to use any component library. The other could reach Basiiik only through the real MCP server, with every call logged.

Both pages look good and both pass axe. The difference is that the Basiiik page reads its colours from tokens, so it follows a brand-colour change and dark mode, and the other page does not.

Method

• Pages were rendered in headless Chrome (660 by 760, light) and checked with axe-core 4.10.2, with the page and with the confirm dialog open.
• Hard-coded colours are hex and rgb() values in the CSS; token variables are the distinct var(--…) names. Both are counted by script.
• The brand colour tokens were then changed, and dark mode switched on, identically on both pages.

What it does not prove

• It is one run each. Another run could produce a different page.
• The agent without Basiiik was not asked to use CSS variables. A different prompt could give a themeable page without a design system.
• The agent with Basiiik made 45 distinct tool calls and 13 returned errors, mostly from guessing token and component names.
• The other agent’s delete dialog was the stronger pattern: it asked the user to type “delete” before confirming.

Run 2: four screens, one prompt each

Four agents ran in parallel, each building one product screen from the prompt below. They reached Basiiik only through the real MCP server, every call logged. Each screen is live. The agents’ files are unedited apart from one CSS line described below.

Method

• The agents wrote only the screen’s component, its CSS and a list of what the library lacked. They were told not to read the Basiiik source. That rule is an instruction, not a sandbox, and their transcripts were not audited for a peek.
• Afterwards everything was measured again: the type check, axe-core 4.10.2 on each rendered page (WCAG 2 A and AA), the imports, the hard-coded values and the MCP call log.

What it does not prove

• One run per screen; another run would differ.
• axe checks the first render only, not every dialog or step, and it does not catch everything. Each page was opened at 1280 and 390 pixels wide, but not every flow was clicked through.
• The pages are sample screens with data written into the file, not working products.
• One screen had 19 hard-coded font values: its agent did not find the typography tokens through the MCP. That was a search problem in the server, fixed afterwards.
• One edit was made by hand after the runs: a single CSS line, because a visually hidden element in a table header made one page scroll sideways at 390 pixels. It was found by measuring, not by the agent.

Run 3: the same screen again, after the library changed

The workspace-setup screen was built a second time by a fresh agent, to count how many of the nine gaps the first run named had been closed since. The same prompt, the same rules and the same method, against a build that included the new components.

Of the 9 gaps the first run named, 4 were closed, 1 half closed and 4 still open. “Closed” was checked in the code and on the page, not taken from the agent’s silence.

What it does not prove

• One run each. The re-run agent chose to build more (a yearly toggle, a promo code, accordions), so its component and call counts rose for that reason too, and it may be a different model version.
• The run found a bug in Basiiik’s own guidance: a spec example for the tag input, copied into a quoted attribute, split every address at the letter n. It was reproduced with real typing and fixed.

What the runs changed in the product

• Run 1 led to four guidance fixes: a base-font rule in the guide, the RadioGroup props, Card width and footer rules, and the Modal footer prop.
• Run 2 led to version 0.2.2: tokens findable by CSS variable, sub-components and extra props documented from the TypeScript types, and snippet errors that say how to retry.
• The gaps the agents named became components in 0.3.0 (Stat, Sidebar, AvatarGroup, DescriptionList, PageHeader, BulkActionBar) and 0.4.0 (RadioCard, MultiCombobox, TagInput, SettingRow, avatar button and upload, and more icons).
• The re-run’s main cost, errors for a missing required prop, is fixed in 0.4.0: the snippet tool now fills in the example value and says so.

Check it yourself

The MCP server is free: run npx @basiiik/mcp and give your agent one of the prompts above. The live demo runs the same search and snippet code in your browser. If your run differs from ours, that is useful: tell us.