When Taste Becomes Executable

A few weeks ago, I was staring at several disconnected sites in Jetpack Cloud.

The connections were dead, but the sites were still stuck in my list. The warning was clear and there was a “Fix now” link, but it only let me remove some disconnected sites. The others weren’t going anywhere.

It was pretty darn annoying.

Normally, I’d write up the problem, grab a few screenshots, and hand it to an engineer. Maybe it would make the next sprint. Maybe someone would find an existing issue. Maybe I’d learn there were six reasons the obvious fix wasn’t so obvious.

This time, I opened Codex and asked it to fix the flow.

From product issue to pull request

The agent reproduced the problem, traced the routing and site state, found an existing confirmation flow, and started changing code.

It added tests, ran checks, produced a working preview, and opened a pull request. That pull request is still open and waiting for the next review, which matters to the rest of this story.

I didn’t have to translate the experience into a perfect issue and hope all the context survived the handoff. I could point at the bug, stay in the loop, and watch the idea turn into working software.

That part still feels new.

At Automattic, I spend most of my time moving between product, design, marketing, and customer experience. I’m close to the code, but I don’t spend most days in it.

Using an agent changed that for me. It didn’t turn me into the engineer who knows every corner of the codebase. But it did let me carry the problem much farther than I could before.

That’s what I mean by executable taste.

Taste isn’t a mysterious creative gift. It’s noticing friction, explaining why it matters, and making a clear call about what should change.

Now I can turn that judgment into a branch, a test, a preview, and a pull request instead of stopping at a comment or mockup.

The first fix was too direct

The initial version solved my complaint. It made removing the disconnected site easy.

It also made removal too prominent.

A reviewer pointed out that some Jetpack connections only look broken. A security plugin might block connection checks even when the customer knows what’s happening. In those cases, troubleshooting should stay primary. Removal should be explicit, but secondary.

There was another problem. The agent had also changed a separate dashboard flow that wasn’t part of the fix. In testing, that path could log the user out.

That review changed the product.

I had optimized for my own frustration. I wanted those sites out of my list, so I had made removal the obvious answer for everyone. The reviewer was thinking about the users I’d missed.

After that, I narrowed the scope to Jetpack Cloud and asked the agent to revise the interaction. Clicking the site still led to troubleshooting. “Remove site” became a separate secondary action. The existing confirmation flow stayed in place.

The value wasn’t that I got my way faster. It was that I could put a working version in front of people who knew what I was missing.

More code ≠ better software

AI has made it much easier to turn a complaint into working code. For WordPress, that means more people can bring a proposed fix, not just a paragraph and a screenshot.

WordPress already runs on people who approach the same problems from different angles. Designers, support folks, marketers, agency owners, plugin developers, and users notice things maintainers might never encounter.

Agents can help more of those people get involved in the implementation. They can arrive with a reproducible case, a proposed fix, tests, and a preview.

But that only works if we keep respecting the work around the code.

Maintainers and reviewers still hold the context agents don’t. Tests and users tell us when a fix makes something else worse.

Without that care, faster code just creates a bigger pile of almost-right software.

As I moved into management, more of my product work happened through feedback, mockups, planning docs, and conversations. Agents let me get closer to the implementation again.

The PR is still open and waiting for another review. I think that belongs in the story.

AI helped me carry an annoying product problem into working code. It didn’t replace the context, review, and follow-through needed to ship it.

That’s the opportunity I see for WordPress. More people can help build the software, while the community keeps deciding what makes it better.

If AI has helped you contribute in a way you couldn’t before, I’d love to hear what changed.