Teaching Claude Code Taste: How a Pattern Library Replaced 30 Minutes of Corrections

“Apply the energypages footer pattern.”

What came back: a four-column layout, the right typography, spacing consistent with every other site in the portfolio, business details pulled automatically from the config file. No instructions. No pixel measurements. No Tailwind class specifications.

A year ago, the same request would have produced a footer. Generic. Competent. Not wrong, exactly — just not mine. And next week it would produce a different footer, equally competent, equally not mine, with no memory that a decision had already been made.

That’s the default state of Claude Code. It builds what you ask for. Every time. From scratch. Without preference, without memory, without any sense that you’ve already decided what good looks like.

The six-word instruction only works because of what happened between October 2025 and now. This is that story.

The Problem With Fresh Every Time

Claude Code has no taste. That’s not a criticism — it’s a description. It has extraordinary capability and no aesthetic memory. Ask it to build a hero section and it’ll build something reasonable. Ask it again tomorrow and it’ll build something different, equally reasonable, with no knowledge that you’d already made a call.

For a single website, this is manageable. You correct it, it adjusts, you move on. But I’m not building single websites. I’m building a portfolio of trade sites — plumbers, roofers, electricians, landscapers — each one needing its own domain, its own branding, its own service pages, while sharing the same underlying quality. Thirty minutes from domain registration to live site. The same standard every time.

That only works if the decisions are made once and held.

The Pattern Library

In 1977, the architect Christopher Alexander published A Pattern Language. His argument: good design isn’t a set of rules. It’s a set of recurring solutions to recurring problems — patterns that can be combined and extended. Once you document the patterns, any competent designer can produce new work that belongs to the same family. The pattern language is generative. It doesn’t prescribe the outcome. It ensures the outcome feels right.

The first commit that matters: 1 November 2025. “feat: Consolidate WBS Design System + Add Tiling Experts site.” First trades template. The WBS Design System — components, colours, spacing — pulled together into one place for the first time. I wasn’t thinking about a library. I was thinking about a plumber in Telford who needed a website.

The second template came three weeks later. Landscaping Experts. I copied the components from Tiling Experts, adjusted the colours, changed the trade. It worked. It also meant I now had two copies of every component. Two footers. Two navigation bars. Two hero sections. When I improved one, the other stayed behind.

This is the trap every developer knows. Copy-paste is fast. Copy-paste is also how you end up with fourteen slightly different versions of the same thing, none of them quite right, all of them needing separate maintenance.

The Unpicking

19 January 2026. The commit that changed everything: “Restructure to npm workspaces monorepo with @wbs/patterns.”

@wbs/patterns became a proper shared package. Not a folder to copy from. A library to import from. One footer component. One navigation component. One hero section. Change it once, every site that uses it gets the change.

But — and this is the part nobody tells you — Claude Code didn’t automatically understand what this meant.

Ask it to build a new page and it would reach for a fresh component. Confident, well-structured, competent, and completely outside the pattern library. It didn’t know the library existed. It didn’t know I’d made decisions. It was doing what it always does: starting from scratch.

The enforcement is where the taste gets encoded. Not through rules. Through correction.

“That footer doesn’t use the shared pattern. Use FooterStandard from @wbs/patterns.”

“That hero won’t accept a background image. Use HeroFullWidth, not HeroSimple.”

“The navigation needs to come from the library. Don’t build a new one.”

Each correction, written back into the pattern library documentation. Each documentation update, available to the next session. The library absorbed the decisions. Claude Code stopped generating fresh because the context made clear that fresh wasn’t wanted.

How Taste Gets Encoded

Here’s the thing about aesthetic direction. You can’t specify it in advance. Not precisely.

I didn’t write a design brief that said “feature cards should have a subtle drop shadow, rounded corners at 12px, and a left border accent in the brand primary colour.” I looked at what Claude Code produced and said: “Can you make the feature cards more beautiful? I want them to feel premium.”

Claude Code interpreted that. Tried something. I reacted. “Better. But the shadow is too heavy.” Adjusted. “The spacing between the icon and the text needs more room.” Adjusted again. And then — this is the critical step — we wrote the resolution back into the pattern library.

Not the conversation. The outcome. The component itself, with the shadow, the spacing, the border. Living in @wbs/patterns as FeatureCard. Available to every site that comes after.

This is Alexander’s pattern exactly. The pattern captures the resolution of forces — what makes a feature card feel right. Once it’s in the library, the forces don’t need resolving again. The next site inherits the answer without asking the question.

The Timeline

The first site took a day. Not because I was slow — because every decision was being made for the first time. What should the footer look like? How should the navigation behave on mobile? What makes the hero section feel right for a trades business?

By Roofing Crew, those decisions were already made. The library held them. What used to take a day — domain registration, DNS configuration, site build, Netlify deployment, live — now takes thirty minutes.

Why This Only Works Here

One important thing. This isn’t possible in WordPress.

WordPress stores components in PHP files and database records. Deployments happen through a dashboard. Plugins get configured through admin panels. Every step requires a human to click something. You can’t hand that to Claude Code because Claude Code lives in the terminal — and WordPress has no terminal interface worth the name.

The pattern library works because the entire stack is addressable from the command line. Astro builds at the CLI. Tailwind compiles at the CLI. Netlify deploys at the CLI. Stripe payment links are created at the CLI. The whole thing — from registering a domain to a live site with working payments — happens in the terminal.

Claude Code operates in the terminal. The pipeline operates in the terminal. There’s no GUI wall between Claude Code and the operations.

The stack choice isn’t a preference. It’s the enabling condition. The pattern library is what sits on top of it.

The Six Words

So when I say “apply the energypages footer pattern” — Claude Code knows what that means. Not because I told it in the prompt. Because the context holds the decision. The pattern library documents the outcome. The previous sessions encoded the correction. The library absorbed the taste.

Six words sit at the intersection of four months of work. The prompt is minimal. The infrastructure makes it sufficient. That’s ingeniculture in practice.

Alexander was right. The pattern isn’t a rule. It’s a resolution. Once you’ve found it, you don’t need to find it again. You just reach for the library.

One word for the footer. The library does the rest.

Read more about the system:

• Claude Code for Web Development: 10x Faster
• Escaping WordPress for Astro
• Ingeniculture: The Word for What’s Missing
• The Magic Word

@wbs/patterns is the shared component library across all We Build Stores trade sites. Built with Astro and Tailwind. Deployed via Netlify. Everything in the terminal.