Leila Byron

What if I ask Claude to design a WordPress page for me? At Automattic, I tried that approach three times to build a public-facing showcase of our design work with AI, and each attempt taught us that the real unlock isn’t giving Claude more tools or more autonomy, but giving it something far simpler: a concrete reference page to match.

The project

Our design team is doing remarkable work exploring AI in practice, from using AI coding assistants to ship UI changes to building new design-and-engineering workflows. But none of that work was visible to the outside world. We wanted to build a public gallery on our design blog (Automattic.design) to showcase our tools, workflows, experiments, and learning programs. We called it Field Notes (WIP): a curated space that shows how we think about designing with AI, and gives future candidates a window into our process.

The page needed four sections: a toolkit showing which AI tools we use, a workflow section with step-by-step processes from the team, an experiments gallery pulling from recent blog posts, and a learning section featuring our design meetups and enablement programs. Plus a hero statement, stats bar, quote section, and a footer inviting contributions. It had to feel native to our design blog, not bolted on.

Attempt 1: “Just build it” — browser automation

The first approach was the most optimistic. I opened a Cowork session, gave Claude the brief, and essentially said: build me a WordPress page. I pointed it at a development domain and let it take over my browser. Claude did visualize the structure. The sections were there. But the output was raw HTML with custom styling that had nothing to do with our brand identity. It looked like a generic landing page, not something that belonged on our design blog.

What I learned: Giving Claude full autonomy over the browser with a broad goal produces a reasonable first draft, but it has no design context. It doesn’t know your theme, your brand system, or your block patterns. The output is a starting point for conversation, not a deliverable.

Attempt 2: Starting with context — the WordPress MCP

For the second attempt, we took a different approach: instead of starting with the big goal, we started by setting context and asking Claude to look before building. The opening prompt was deliberately narrow: Can you use the WordPress MCP to connect to our design blog and inspect this draft page?

This was the key shift. Rather than asking Claude to build, we asked him to understand. Claude could query the site’s backend directly, not through browser automation, but through structured API calls. It pulled the theme configuration (Design Blog 2025 theme), discovered the full color palette (Vibrant Blue, Medium Blue, Soft Blue), the typography stack (Source Serif 4, Inter, Knockout), the spacing scale, and the available custom blocks. It found the AI Tools blog category and could pull existing posts into a Query Loop.

The output was better. It used real WordPress Gutenberg block markup instead of raw HTML, and it understood the theme’s color tokens and typography. But the design still felt generic. It was using the right ingredients but not the right recipes. The layout didn’t feel like it belonged on our site; it was just … correct, but not native.

What I learned: Connecting Claude to the backend via the MCP is a massive step up from browser automation. It provides structured access to the exact things that matter: theme configuration, block types, and post data. But knowing the tokens isn’t the same as knowing the patterns.

Attempt 3: The breakthrough — reverse-engineering what works

The real unlock came when I asked Claude to stop building from scratch and start looking at what already worked: Can you inspect the About Us page and design Field Notes in the same blocks and style?

Claude fetched the About Us page through the MCP and reverse-engineered its block structure. This is where it got interesting. The theme doesn’t just use generic WordPress blocks, it has semantic CSS classes that carry custom styling rules:

• designblog-stats — the stats grid with oversized Knockout numbers
• designblog-hiring and designblog-hiring__step — the numbered step pattern (NO.1, NO.2, etc.)
• designblog-blog__button — the right-aligned button style in section headers
• A two-column section header pattern: left column has the heading and subtitle in a specific color, right column has body text or a button, bottom-aligned

These patterns aren’t documented anywhere. They live in the theme’s CSS and only become visible when you examine the actual block markup of a finished page. Once Claude understood these patterns, it could compose new sections that felt native to the site.

Four rounds of iteration

From there, we moved into rapid iteration:

• First pass: Applied the About Us patterns to all four sections. Better, but the Toolkit section used numbered steps when it should have been a 4-column card grid like the “Our Blog” section.
• Second pass: Redesigned the Toolkit as a 4-column grid with the proper header pattern (label + subtitle left, button right). Much closer to what we needed.
• Third pass: Redesigned Workflows & Recipes to use curated recipe cards instead of a Query Loop, moved the blog posts to the Experiments section, and added the stats bar to the top. Three structural changes, one round.
• Fourth pass: Completely redesigned Workflows & Recipes. Each recipe now has a title, numbered steps, a dark PROMPT code block showing the exact prompt used, and a light REFLECTION callout with the key takeaway — a structure that came from a reference screenshot.

The speed of iteration was notable. The fastest feedback loops happened when we pasted the block markup into the WordPress code editor, rendered it, and reviewed what actually worked. Screenshots of problematic sections were more useful than descriptions.

What I learned: The real unlock wasn’t more tools or more autonomy, it was a reference. “Match this existing page” is far more effective than “build something that fits the brand.” Claude excels at pattern recognition and structural replication. Once it could see the actual block markup of a well-designed page, it could compose new content in the same language.

The permission lesson

One thing we learned the hard way: it’s tempting to give AI assistants broad permissions to ship work directly. We thought we had configured Claude to keep the Field Notes page in draft status only, without permission to publish or modify other pages. We were wrong. What we thought was a contained draft actually became a template edit that affected existing pages on the site. The realization came too late, and required our platform team to revert the changes (yikes!).

It’s a reminder that autonomy needs careful boundaries. Even when working with AI, human review before publishing is non-negotiable.

What this taught us

• Start with examples, not abstractions. V1 failed because we started with “build me a page.” V3 succeeded because we started with “make this look like this page.” Abstraction (“fits the brand”) is harder for AI to execute than pattern matching (“matches this reference”).
• Structured API access beats visual UI automation. For content work like WordPress block editing, API access gives Claude exactly what it needs — theme config, block types, post data — without the overhead of navigating a visual interface.
• AI is a collaborator, not a contractor. The best results came from rapid back-and-forth: Claude proposes a structure, we evaluate visually, we provide specific feedback (“make this section like that section”), and Claude adapts. The page improved because of iteration, not despite it.
• Review before publishing. Even with careful permission scoping, AI can take actions you didn’t intend. Always maintain a human approval gate before going live.

What’s next

The Field Notes page is currently being curated. We’re using what we learned, pattern matching, API-first workflows, and iterative feedback loops as we build other pages. The deeper realization is that designing with AI doesn’t require more automation or more autonomy. It requires better reference frames and tighter feedback cycles.