The Discovery Shoot-out

One real garage · one interview brief · three AI builders — PageMotor Discovery AI field test, 22 July 2026

One garage. One brief. Three very different builders.

Baytree Road Garage — a real, family-run MOT garage in Weston-super-Mare, est. 1949 — was interviewed by an AI on a live PageMotor site, producing a locked Design Brief. Three LLMs then each turned that same brief into a five-page website: two through the automated Discovery pipeline, one working hands-on through the site's API. This is what actually happened, receipts included.

ContenderRouteInterviewBuild (hands-off)Pages vs briefOutcome
Kimi K3
reasoning model · Moonshot
Discovery pipeline
amber-reef
30 min — praised by the tester ~2¼ h once configured
~20 min/page + verify pass
5 / 5 + verified Stalled for hours on default settings, then — given a 64k-token rope — delivered the richest, most characterful site of the pipeline pair
Claude Sonnet 4.6
Anthropic
Discovery pipeline
golden-vale
10 min — brisk ~20 min total 3 / 5 — no MOT, no About Fastest and drama-free, with a handsome phone-first design — but it quietly shipped 60% of the brief, and it wasn't even meant to be the designer (see below)
Claude Fable
claude-fable-5 · Anthropic
Agent, hands-on via the site API
amber-reef /claude-*
— (reused K3's brief) ~40 min incl. design QA 5 / 5 Built page-by-page with screenshot self-review before publishing; a different methodology, included as a reference ceiling rather than a pipeline datapoint

The three findings that matter

1 · The "Claude arm" never fielded its intended designer. Golden-vale was configured as Sonnet-interviews / Opus-designs — but a one-line plugin bug routed page generation to the interview model on every rig. So the Claude pipeline site was designed by Sonnet 4.6, and Claude Opus 4.7 has not yet raced at all. The same bug is what starved Kimi K3 for four hours on amber (details in “How it actually went”).
2 · Reasoning models need different plumbing, not different talent. K3 kept returning empty responses — it was spending its entire 16k-token budget thinking, leaving nothing for the page. At 64k tokens and a 25-minute per-call leash it delivered every page, roughly double the size of a fast-model equivalent. Talent wasn't the blocker; the harness was.
3 · Completeness beats polish and speed beats nothing. Sonnet finished in 20 drama-free minutes but silently dropped the MOT page — the single most commercially important page for an MOT garage — and the About page carrying the 1949 family story the whole design leans on. Nothing in the pipeline flagged the shortfall. A build that reports what it skipped would have turned a hidden failure into a visible one.

Disclosure: this report was written by one of the contenders (Claude Fable). Every measurable claim comes from page source, live timestamps or server logs and is reproducible from the receipts in Scorecard and Methodology; the aesthetic observations are labelled as the author's read, and the screenshots let you judge those yourself.

Scorecard

Measured first, judged second. Everything in this section can be re-derived from the shipped page source.

Pages delivered against the brief's five

Kimi K35 / 5Claude Sonnet 4.63 / 5 MOT & About missingClaude Fable5 / 5

Hands-off build time (interview excluded)

Kimi K3135 min ~20 min a pageClaude Sonnet 4.620 minClaude Fable40 min incl. design QA

K3's figure is its clean post-fix run (five pages sequentially at ~15–25 min each plus the verify pass). Fable's includes design, local screenshot QA and publishing, and is a different methodology — see fairness notes.

Total shipped page weight

Kimi K3179 KBClaude Sonnet 4.6113 KB 3 pagesClaude Fable82 KB

Author-shipped HTML per site, summed. Weight is neither good nor bad by itself — K3's extra bytes bought texture and detail; Fable's economy bought speed — but it tracks how much stuff each model chose to make. Sonnet's total covers only three pages.

Measured checklist

CheckKimi K3Sonnet 4.6Fable
All five brief pages (incl. About & MOT)Yes — 5/5, verifiedNo — 3/5Yes — 5/5
Phone-first: tel: links across site3916 (3 pages)18
Correct phone & address on every pageYesYesYes
Brief's banned words in copy000
External scripts / trackersNoneNoneNone (one font stylesheet)
Executable JavaScript shippedNone (JSON-LD only)MinimalNone
“Website Discovery” leaking into page metadataYes — platform-injectedYes — platform-injectedYes — platform-injected
Drama during build4 h stall + ~$20 tokens before fixesNoneNone (one badge redraw in QA)

The “Website Discovery” leak is a platform bug, not a model failing — the site-name setting isn't updated on delivery, so every contender's pages inherit it in og:site_name and JSON-LD.

The author's read (judge for yourself in the Gallery)

K3 made the bravest site: a fully-committed vintage job-card world — stamps, ticket-stub dividers, ledger numbering, a hand-sketched map. It reads like a designer with a concept, and it's the only build a visitor might describe as memorable. Its looseness is real too: the header changes outfit on every page, and one “photo” is secretly the logo.

Sonnet made the most conventionally handsome pages — a big serif phone number as the hero is exactly right for this business — but a site that's missing its MOT page hasn't finished the job, however nice its typography.

Fable (the author) aimed for disciplined heritage: one consistent system, restored About page, plain-spoken copy, zero JS. Readers should discount the author's own aesthetic opinion of it accordingly — the screenshots are next door.

How it actually went

The result table hides the day's real story: the first eight hours were an incident, and the incident is where the engineering lessons live. All times Irish, 22 July 2026.

  1. 11:07 — a genuinely lovely interview. Keith (the tester, a developer posing as the garage's owner using its real details) finished a 30-minute chat with K3. It read his uploaded 1949 badge, pulled cream-and-red from it, captured his exact strapline, and locked a rich Design Brief. The holding page went live and the auto-build started.
  2. 11:07–13:30 — the silent stall. Zero pages appeared. Investigation through the site's API found the build attempting, failing and re-arming roughly every 15 minutes — with no error logged anywhere, the owner dashboard reporting “live and healthy”, and the token meter running on every attempt.
  3. ~12:50 — the smoking gun. A direct probe of the model showed K3 spending 2,045 of a 2,048-token budget on hidden reasoning and returning zero characters of content. Reasoning models think before they speak; the pipeline's budget was smaller than the thinking.
  4. ~14:45 — the one-line bug. Reading the plugin source revealed the deeper fault: page generation called the interview model instead of the configured synthesis model. This simultaneously explained K3's starvation on amber and silently re-cast golden-vale's designer from Opus to Sonnet. A config landmine was also defused on golden — its Anthropic credentials were pointed at Moonshot's API endpoint.
  5. 14:51–17:03 — K3 gets its rope. With the fix applied on amber, a 64,000-token budget and a 25-minute per-call leash, K3 generated all five pages (~15–25 minutes each, pages roughly twice the weight of a fast-model draft) and passed the pipeline's verification pass. An interim attempt with the fast k2.7 model completed in minutes but was rejected on quality.
  6. 13:20–13:53 — golden's clean run. Keith re-answered identically on golden-vale: 10-minute interview, ~20-minute build, no drama — but only three of five pages, built by Sonnet rather than the intended Opus.
  7. 15:11–15:24 — the third contender. Fable, working as an agent with the same locked brief, designed and published five pages to side-by-side URLs on amber, screenshot-checking each before it went live.

What the incident taught (the transferable bits)

Give reasoning models budgets sized for thinking plus answering, and treat empty-content-at-token-limit as “budget too small”, not “model said nothing”. Cap retries and log every failure — a $20 silent loop should be impossible. Don't couple build progress to whether a human keeps a browser tab open. Validate provider config at save time (one test call would have caught both sites' misconfigurations in seconds). And make pipelines assert the brief — a build that delivers three of five pages should say so, loudly, rather than report success.

Methodology & fairness

Kimi K3Sonnet 4.6Fable
Brief sourceKeith's 30-min interview (K3 as interviewer)Keith re-answered the same answers verbatim (Sonnet as interviewer)K3's locked brief, reused untouched
Generation routePipeline: single large generations per pagePipeline: single large generations per pageAgent: iterative authoring + local screenshot QA before publish
Special conditionsPost-fix rerun; 64k tokens, 25-min per-call timeoutStock settings; built by the interview model due to the routing bugFull tool access; also wrote this report (disclosed)
Judged fromThe exact HTML each contender shipped (retrieved via the sites' API), rendered identically offline

Honest caveats

Not yet a K3-vs-Opus verdict. The intended headline bout — K3-as-designer vs Opus-as-designer — hasn't happened, because the routing bug substituted Sonnet. Fix, rebuild, then judge.

Different ropes. K3 raced after bespoke tuning; Sonnet raced on stock (buggy) settings; Fable raced with a fundamentally different method. This report is a field study of what each route really took, not a controlled lab benchmark.

Screenshots are offline renders. Each contender's shipped HTML was rendered locally with brand images swapped for one neutral placeholder (the live sites all show the real badge). Fable's visible roundel is its own inline fallback mark — a property of that build, not special treatment.

Did any AI scrape the garage's real website? No — checked on both interview arms. Neither brief contains a site URL or analysis reference (existing_site_url empty/null on both), the logo is flagged as client-uploaded, and every fact traces to what the tester typed. Keith's question, answered with receipts.

Next: the four-tester wave

Four testers — Keith, Chris, Hasmukh and Kenn — each running fresh, independent interviews. Worth doing only once the platform reflects today's lessons; here's the readiness state, honestly.

FixStatus today
Build uses the synthesis model, not the interview model (the one-liner)Patched on amber's deployed copy only — golden and the rest of the fleet still carry the bug
Reasoning-sized token budget & per-call timeoutHand-tuned on amber (64k / 25 min); hardcoded, not a per-provider setting, not on other rigs
Golden's endpoint/config landmineFixed & verified (settings)
Retry caps, spend ceiling, failure logging, real kill switch, build cancelNot implemented — the $20 silent loop is still possible on every rig
Build survives nobody watching (server-side runner)Not in the plugin — today's success used a temporary server script
Pipeline asserts the brief (5 pages promised → 5 delivered, or say so)Not implemented — Sonnet's 3/5 shipped as “done”
Save-time provider preflight (“test connection”)Not implemented
Site name propagated on delivery (the “Website Discovery” leak)Not implemented — visible on all three builds' metadata
Recommended before the wave: roll today's amber patches plus the items above into a proper TIBAI_Discovery 1.2.1, deploy it to every rig from one source, verify each with the preflight — then run all four testers on identical, current code. Otherwise the wave measures five different bug configurations instead of four different humans.

Test-design notes: one fresh rig per tester per arm; interviews independent (no shared answers this time — the wave tests the interview too); per-rig spend ceilings before anyone presses go; and the Opus arm finally fielded, so the poster fight actually happens.