Building Landing Pages with AI

We had a special month at Automattic that ended last Friday. For a full month, we could form groups of two people and work on whatever we liked, as long as we are in a pair.

I chose 4 projects and ended up working on 3 of them, discarding the 4th – couldn’t get to it. First was the new Writing Prompts, which was relatively low-tech (on the surface) but pretty cool. Seeing people respond to blogging prompts that were my idea is melting my soul.

The second project was around building a way to assemble good looking landing pages with AI quickly.

A landing page on WordPress.com is a page that tells a story, highlights a feature, or shows something so it’s discoverable. For example, a colleague runs a program that gives paid plans to students. Another wants to show how WordPress.com compares to a competitor. They write content, the content is then designed, and then the design is turned to an actual page by an engineer.

Landing pages

My team is sometimes responsible for the implementation of these. I didn’t like this type of front-end work and avoided it. A few months ago, we were in a situation in which the demand for new landing pages was high, and the resources for implementing them low, so I was “shoot, if I have to make these, let’s at least offload as much possible to AI”. The first round resulted into something like a vibe-coding flow, the benefit of which was that the work moved from the WordPress editor to Claude Code. But it was still too technical, and required a design (usually in the shape of a Figma document).

My colleague Jordan Hiller came up with the idea to give sense to Claude Code by providing it with a library of pre-designed, ready to use, empty sections that can be filled with text and images, depending on the needs. The technology behind it is Gutenberg Block Patterns. They’ve been around for awhile and can also be used from the editor or the wp cli. However, we expect the usage through a Claude skill to be the primary way to use this work because it doesn’t require expertise when making more advanced tweaks.

It’s an internal tool project. Something to make our lives easier, replace an annoying process with a faster one. The faster process lets you maintain the pages better, update more frequently, apply best practices sooner. Essentially, do more and stay on top of the change requests or avoid them altogether by letting the person who requests the change do it on their own.

Is that going to result into anything you’ll notice? Probably not. But if we’ve done our job well, the new landing pages will be built and updated faster, will load faster, and the colleagues who come up with the content will take the control from engineering.

Opus

Claude Opus is my current most favorite model. I had a few blissful months of using it. Generated some good PRs, got stuck in debug loops not as many times as with previous models. I ended up extending the spend limit multiple times.

Opus Cocktail Bar, Sofia

After burning through far too many tokens, I had to stop and think. Is my usage really appropriate? Is it worth thinking how much tokens each prompt consumes? Is it because of the MCPs? Why does it make all these API calls to my dev server? How much does all of that even cost? It’s not clear from the dashboard at all.

While I’m rethinking my life’s choices, I switched to Codex and GPT 5.2. I feel like between the 4 AI editors that I have, I may have enough agent time available to last until the end of the billing period.

Being stuck with one option is not ideal. The situation is not like I have to write code without agents but my overuse of Opus is giving me a glimpse into a future where these models may start costing as much as people.