Pattern Recognition Fluency

I went back through hundreds of Git commits last week to analyse what I was asking Claude Code six months ago — when I was still building websites the slow way — versus what I ask now.

The evolution surprised me when I saw it.

Six months ago I was writing detailed technical specifications. Today I use recognisable patterns with verbal flourish.

I’m not writing better specifications. I’m speaking in patterns the model’s training data recognises.

A junior developer says: “Build a contact form with validation and email handling.”

A senior developer says: “Create a contact form component with name, email, message fields, client-side validation, server-side sanitisation, honeypot spam protection, success/error states, accessible ARIA labels, mobile-responsive layout, and integration with our email service.”

I say: “Add a HubSpot Lite lead pipeline.”

The third one delivers contact management, an activity timeline, deal stages, email integration, task management, conversion reporting, lead scoring, and pipeline velocity metrics.

From four words.

The model has seen HubSpot implemented thousands of times in its training data. It knows exactly what that pattern looks like. I don’t need to specify features. I need to trigger the pattern.

This isn’t better prompt engineering. It’s pattern recognition fluency - the art of situating AI so it works with you, not at you.

In This Issue

Why ‘HubSpot Lite’ Beats Detailed Specifications — Pattern recognition delivers more comprehensive solutions than functional requirements

The Don Draper Home Page That Actually Works — Cultural references trigger design patterns the AI recognises instantly

Pattern Recognition vs Prompt Engineering — The profound difference worth naming

Content Studio Lite in One Sentence — Social media management without writing the specification

Why The Flourish Unlocks The Pattern — Describing the feeling matters more than listing the features

The HubSpot Lite Discovery

Last month I needed lead tracking for the platform.

What I could have said: “Build a lead management system with contact database, custom fields, activity logging, deal stages, kanban board, email integration, task management, reminders, conversion tracking, funnel reporting, lead scoring, and pipeline analytics.”

What I actually said: “Build a HubSpot Lite lead pipeline.”

What Claude Code delivered:

• Complete contact management with custom fields
• Deal stages with a drag-and-drop kanban interface
• An activity timeline that tracks emails, calls, and meetings
• Task management with automated reminders
• Email integration following HubSpot patterns
• A conversion funnel with stage-to-stage metrics
• A lead scoring framework based on engagement
• Pipeline velocity and health monitoring

The model recognised the HubSpot pattern from thousands of implementations in its training data. It didn’t need me to specify each feature. The pattern reference unlocked the complete implementation.

The Don Draper Home Page

The same principle applies to design language.

Two weeks ago I was working on positioning for a manufacturing client.

What I said: “Give the home page Don Draper product positioning - make it feel like the confident choice for people who know quality when they see it.”

What Claude Code understood:

• Minimalist design with confident white space
• Bold, declarative headlines (not questions)
• Product-first imagery showing craft and detail
• Testimonials from recognisable brands
• Subtle social proof (years established, clients served)
• CTAs that assume the sale (“Start Your Project” not “Learn More”)
• A sophisticated colour palette that avoids bright urgency
• Copy that sells benefits through confident statements

The model has processed Mad Men discussions, advertising case studies, and classic positioning frameworks. “Don Draper positioning” triggered an entire design and messaging pattern.

I could have written a 500-word design brief. Or I could reference a pattern the model has seen analysed thousands of times.

The flourish did the work.

Pattern Recognition vs Prompt Engineering

The dangerous myth: “If the AI doesn’t understand, add more detail.”

The reality: More detail on unfamiliar patterns creates more problems, not fewer. You’re forcing the model away from proven implementations into experimental territory where every specification introduces new uncertainty.

Example:

Prompt Engineering approach: “Create a social media management interface with post scheduling, content calendar, draft management, image upload, multi-platform posting, analytics dashboard, and engagement tracking.”

Pattern Fluency approach: “Build a Content Studio Lite for social media management.”

The second one triggers scheduling UI patterns, calendar interfaces, multi-platform posting logic, analytics dashboards, and engagement metrics - because the model has seen Content Studio implementations hundreds of times.

The difference:

Prompt engineering tries to be clearer. Pattern fluency tries to be more recognisable.

Prompt engineering adds detail. Pattern fluency adds context.

Prompt engineering explains what you want. Pattern fluency triggers what the model has seen working.

Why The Flourish Matters

Which raises the question: why does “Lite” matter? Why not just say “HubSpot”?

Because the “Lite” in “HubSpot Lite” isn’t decoration. It’s signal.

It tells the model: I want the core features, not enterprise complexity. I want proven patterns, not custom innovation. I want fast implementation, not months of development. I want familiar UX, not a learning curve.

The “Don Draper” in “Don Draper positioning” isn’t fluff. It’s context.

It triggers confident minimalism over busy urgency. Product quality over price competition. Established authority over startup energy. Sophisticated restraint over aggressive conversion.

“Build me a HubSpot” could mean enterprise sales pipeline with forecasting, territories, and complex workflows.

“Build me a HubSpot Lite” means essential CRM with proven UX patterns and rapid implementation.

That one word changed the entire implementation approach.

The Velocity Multiplier

So how does this translate to actual website development?

Here’s how I build production websites in 4 hours while agencies quote 4 weeks.

Not better technical skills. Pattern recognition fluency with boring technology.

When I was building escudero-auto.com (see Week 42’s £49 a month case study), I didn’t write component specifications. I said:

“Build the service showcase section - think Apple product pages but for industrial 3D printing. Six service cards, each highlighting technical capability with confident minimalism.”

What Claude Code delivered:

• An Astro component with proven layout patterns
• Tailwind CSS matching Apple’s restrained design language
• A responsive grid (1/2/3 columns) straight from training data
• Hover effects following established UX patterns
• Mobile-first approach (it’s seen 10,000+ examples)
• Accessible markup (ARIA patterns are well-documented)
• Performance-optimised through Astro static generation

One sentence triggered the complete implementation. Because “Apple product pages” is a pattern the model has seen analysed extensively in Astro and Tailwind contexts.

Traditional agency approach:

1. Design mockups and client revisions (1 week)
2. Write detailed component specifications (4 hours)
3. Developer implements from scratch (8-12 hours)
4. Debug responsive layout issues (4 hours)
5. Accessibility fixes (2 hours)
6. Performance optimisation (3 hours)

My approach with pattern fluency:

1. “Apple product page style service cards” (10 seconds)
2. The system applies proven Astro/Tailwind patterns (2 minutes)
3. I review and refine the content (20 minutes)

This is where the 40x velocity comes from. Astro and Tailwind do the heavy lifting. Pattern fluency just triggers the right implementation instantly.

The Critical Caveat

Before you rush off to try “HubSpot Lite” with your experimental framework…

This only works with the boring tech stack.

I covered this in detail last week - boring, proven technology unlocks the system’s development velocity because pattern recognition is the mechanism.

When I say “HubSpot Lite” using Django and PostgreSQL, the model has seen that implementation thousands of times. Proven patterns everywhere.

When you say “HubSpot Lite” using a bleeding-edge framework that was released six months ago, the model is guessing. It understands the concept, but it hasn’t seen the proven implementation patterns.

Pattern fluency requires patterns the model recognises.

What about WordPress? The model has seen millions of WordPress sites. But “HubSpot Lite” in WordPress means: which plugin? Which theme conflicts? Which version compatibility? Which hosting limitations? Pattern recognition breaks because every WordPress installation varies wildly.

With Django and PostgreSQL or Astro and Tailwind - one proven pattern works everywhere. With WordPress - every site is different.

This is where 26 years of experience matters. I’m not discovering new patterns. I’m recognising proven patterns the model has seen thousands of times, then I’m triggering them efficiently with boring, pattern-consistent technology. Each session builds on the last — stop chatting with AI and start building with it.

Try This Tomorrow

Next time you’re about to write detailed specifications for the system, stop. Ask yourself: “What proven pattern does this resemble?”

Building a contact form? Try “Create a HubSpot-style contact form.”

Creating a pricing page? Try “Build an Apple-style pricing page with confident minimalism.”

Adding a dashboard? Try “Create a Notion-style dashboard interface.”

One sentence referencing a pattern the model knows will give you more than 10 sentences of specifications.

You’ll know it worked when Claude Code delivers more than you asked for. That’s not over-engineering. That’s the model recognising the pattern and applying proven implementations you didn’t have to specify.

Next Week

The tech stack decisions that looked boring six months ago but enabled 40x velocity today. I’ll walk through why I chose Astro over Next.js, Django over microservices, and PostgreSQL over MongoDB. The unglamorous decisions that actually mattered.

Tony Cooper We Build Stores

tony.cooper@webuildstores.co.uk