how learnthevibe.com is built

This site builds itself and logs as it goes. What you are reading is the raw material of the learnthevibe-hub build: every agent run, every number, every failure. The recipe is in-progress: the deploy is still ahead, and the numbers finalize when the build ships.

The cost is $0: the whole thing ran on a Claude Code Max plan, no direct API charge. What we can measure is tokens and time, so that is what we report.

the spec

Two docs drove it. No human touched the code:

• PRD.md (v1.1), what and why: the flywheel (BUILD → SHOW → SELL → LOOP), the zero-human-contact rule, the bilingual-hub decision.
• DESIGN.md (v1.1 at the time), how it looks: the "terminal proof" aesthetic, mono display (JetBrains Mono), terminal-green accent (#3FB950), 21 anti-patterns. That doc has since been rewritten three times, up to v2.1 — the full turn gets its own chapter below, because it is a lesson in itself.

The DESIGN.md research: 4 parallel exa searches + a live CSS scrape with curl against the real tokens of Linear, Vercel and Raycast + a firecrawl branding scrape (structured JSON plus full-page screenshots). The competitors' real CSS beat the trend articles: the token values are measured data, not guesses.

The two files double as the agent instruction set: the token frontmatter compiled into globals.css, and the anti-pattern list became the verify gate.

the workflow

Three workflows assembled the hub. Each is a parallel agent run, orchestrated by Claude Code.

learnthevibe-foundation: 6 agents, 9.2 minutes. The base: i18n (next-intl, HU at /, EN at /en), the design tokens compiled into globals.css (DESIGN.md frontmatter → Tailwind v4 @theme), the CLAUDE.md, the BUILD-LOG.md, and the MDX pipeline (gray-matter parse, content/{type}/{slug}.{locale}.mdx convention, locale fallback).

learnthevibe-components-pages: 10 agents, 18 minutes. The surface: 10 proof and layout components (TypedHeadline, ProofStat, CostBadge, BuildMeta, TerminalBlock, RecipeTimeline, AgentTag, GridLines, StatusBadge + layout), 6 pages in HU and EN, the full copy, and one verify pass. The verify ran 17 routes at runtime against the 21-point anti-pattern list in DESIGN.md: 0 violations.

learnthevibe-finish-quality: in progress. Resend newsletter, the AX layer (llms.txt, agent-readiness), and the final quality gate. The deploy comes after.

Components first, pages on top of them: that parallelizes better than going vertical one page at a time.

the numbers

workflow                      agents   tool calls   time      tokens
─────────────────────────────────────────────────────────────────────
learnthevibe-foundation               6        103        9.2m     344,044
learnthevibe-components-pages        10        381         18m    1,165,581
learnthevibe-finish-quality           –          –          –     in progress
─────────────────────────────────────────────────────────────────────
measured total (2 UI runs)      16        484         27m    1,509,625

human time (steering)         ~4.5h
hand-written code                 0 lines
direct cost                      $0  (Max plan)

The five commits in git log are the whole of Phase 0: scaffold → deps → foundation → ui → fix. The detailed log lives in BUILD-LOG.md in the repo.

the design turn (v1.1 → v2.1)

The design was not one decision but four rounds. In each, the human decided, the agent built and measured:

• v1.2 — "too puritan." The strict bans of v1.1 produced a flat, empty page. Lesson: atmosphere (glow, grain, grid lines) is not decoration; it became a mandatory layer in the doc.
• v1.3 — the AI-slop audit. A dedicated audit round found 5 saturated AI patterns on our own page (numbered section scaffolding, eyebrow spam, stat grids). Lesson: a pattern copied from Linear can still be AI grammar if it carries no meaning. The anti-pattern list grew from 21 to 25.
• v2.0 — the death of the green. The founder called it: the green terminal aesthetic is "not best in class." After three visual variants the decision landed on Vercel-DNA monochrome — no brand color, the white↔black contrast is the brand, and the character comes from the Bricolage Grotesque display. Deleting #3FB950 everywhere became anti-pattern #26.
• v2.1 — best-in-class audit + product register. We found our own rules violated in our own code: the hero headline used a hardcoded clamp() instead of the token, so editing the doc changed nothing on screen. Fixed: a clean two-line headline, a tracking floor, a 96px display ceiling. New layer: rules for the learning UI (monochrome-luminance code scheme, the light rail, AgentTranscript). Measured result: Lighthouse performance 97, accessibility 100, CLS 0.

By the numbers: half of the 30-item anti-pattern list was born from our own mistakes, not from foresight. That is what makes it a rulebook instead of a taste document.

what broke

Honestly, because that is what makes it a recipe and not marketing:

• pnpm build approval rounds. The build asked for several manual approvals before it ran green; the harness permissions were not set up ahead of time. Time went to the interruptions.
• React 19 FormEvent deprecation. The newsletter form used the old typed FormEvent handler that React 19 no longer likes. A separate fix commit (d2e2fd8) swapped it for an inferred inline handler.
• The sips crop problem in the design research. Cropping competitor screenshots with sips did not return the expected region; firecrawl's full-page captures solved it, not the manual crop.
• A hardcoded value at the strictest spot. The hero headline ignored the design token and carried its own baked-in clamp() — editing the token did nothing on screen, and only a screenshot comparison exposed it. Our own anti-pattern rule (#19), broken by our own code.
• A header baked to dark. The sticky header background was a hardcoded rgba(10,10,11,0.72): unreadable nav in light mode. Nobody looked at light mode until the v2.1 audit. Fix: a --header-bg token in both modes.

lessons

• Design the design doc for machines to read. The DESIGN.md token frontmatter compiled straight into CSS variables. It paid off.
• Run the verify agent separately, with its own anti-pattern list. That caught drift, not the hope of "review it at the end".
• Set permissions up front. The pnpm build approval rounds were avoidable.
• Measure tokens and time, do not promise speed. The $0 cost is real, but so are the 27 minutes of machine time and the ~4.5 hours of human steering.
• Make the agent look at what it built: screenshot after every visual change, and actually read the screenshot. Both the token bug and the light-mode header were caught by pixels, not by reading code.
• The design doc's version history is course material: the road from v1.1 to v2.1 (what got overruled, when, and why) teaches more than the final state.

the extracted assets

The byproducts that later go into an asset pack:

• DESIGN.md as an agent-readable design-system format (tokens in frontmatter, taste in prose, prohibitions in the anti-patterns section)
• CLAUDE.md project-instruction template (doc hierarchy + skill protocol + anti-pattern gate)
• the skill-loading protocol: a work-type → required-skills matrix
• the competitor CSS-scrape method: curl for real tokens + firecrawl branding format + full-page screenshots
• the recipe-format template (these seven sections, themselves)

reproduction

If you want the same:

1. Write a PRD.md (what and why) and a DESIGN.md (how it looks). Put the DESIGN.md tokens in machine-readable frontmatter and the prohibitions in an anti-pattern list.
2. Scaffold: Next.js 16 + TypeScript strict + Tailwind v4 + pnpm + shadcn.
3. Foundation workflow: i18n + the DESIGN.md tokens into globals.css + the MDX pipeline. Parallel agents.
4. Components-then-pages workflow: proof components first, pages second, then a separate verify agent with the anti-pattern list.
5. Log after every run into BUILD-LOG.md: agent count, tokens, time, what broke. That becomes the next recipe.