I spent last Saturday at WordPress Day for AI in Faro, Portugal. I came back with a few interesting ideas, some things I want to experiment with, and one thought that isn’t really about AI at all.
I think we need more focused WordPress events.
I’ve attended quite a few WordCamps over the years, and I often have the same problem with them. They try to offer something for everyone, which sounds great in theory but doesn’t always work in practice.
If you’ve been working with WordPress for years, it’s hard to justify travelling to a conference where half the talks cover things you already know. Make the program more advanced, and you risk losing the beginners.
You end up with an event where almost everyone can find something interesting, but a good part of the schedule isn’t particularly relevant to them.
WordPress Day for AI took a different approach. One topic, two tracks (business and development), and a fairly clear idea of who the event was for.
I liked that.
Of course, I couldn’t experience the whole conference. Roughly half the sessions were in Portuguese, which I don’t speak, so I stuck to the English-language talks.
Some were more interesting than others, but there was plenty worth listening to.
Here’s what I took away from the presentations.
Dave Lockie – Making WooCommerce ready for AI agents
Dave’s presentation was one of the more interesting ones for me, especially because it combined AI-assisted development with something I’ve been thinking about lately: how websites should work when the visitor is an AI agent rather than a person.
He used ChilliMango, his own small hot sauce business, as a testing ground for different experiments.
One of his observations was that building things was never really the hardest part of running an agency or an online business. Getting a return on that investment was.
And now, with AI making development significantly easier, that distinction becomes even more important.
Dave showed a seven-step approach to making a WooCommerce store more accessible to AI agents. It covered everything from allowing crawlers and improving content readability to exposing product information through APIs and MCP, and eventually letting agents perform actions.
In his experiment, the store’s agent-readiness score improved from 27 to 67 out of 100.
What I found particularly interesting was that some relatively small changes made a difference. Adding content signals to robots.txt, providing Markdown versions of content, and exposing discovery information helped. Other things, including some commonly recommended optimizations, didn’t seem to change much.
He also demonstrated how three custom HTML attributes could turn a regular WooCommerce form into something an in-browser AI agent could interact with.
There’s an important distinction here, though. Improving a score in an agent-readiness assessment isn’t the same as generating traffic or sales from AI agents. And Dave was quite open about the fact that there’s very little of that happening so far.
Still, I agree with his reasoning. It’s worth experimenting with this stuff now. If agent-friendly websites become standard in a year or two, whatever advantage early adopters might gain will probably be much harder to find.
There was another interesting point in his talk: AI makes it easier to build things, but testing and understanding what you’ve actually built can become a challenge of its own.
Which leads nicely to the next two presentations.
Miguel Costa – Trust, but verify
Miguel talked about his experience using AI-assisted WordPress development over the past six months.
He’s now building more functionality himself, relying on fewer plugins, and using AI for everything from creating layouts to managing content and working with existing projects.
But his main message was about staying in control.
AI can help you work faster and do more things simultaneously. The downside is that it’s also easier to lose track of what’s happening. Context switching becomes a problem, changes pile up, and something can break without you immediately understanding why.
His practical advice was pretty straightforward: keep backups of your code and databases, separate development from production, use feature flags, watch what data you’re sending to AI tools, and don’t ignore the costs of long coding sessions.
He also recommended visual regression testing, which makes a lot of sense when you’re generating changes quickly.
I wouldn’t say there was anything particularly groundbreaking here. Most of these are good software development practices we’ve known for years.
But maybe that’s the point.
AI doesn’t make those practices obsolete. If anything, it makes them more important.
Ivelina Dimova – Getting from a prototype to a reliable product
Ivelina’s talk was probably one of the most practically useful ones, particularly for anyone building AI-powered features into WordPress products.
It’s relatively easy to get an AI prototype working. Getting it ready for production is a different story.
She went through three areas that need attention: guardrails, evaluations, and governance.
The guardrails part was particularly interesting. She showed how protection should happen at different stages: checking what goes into an AI system, controlling what actions it can perform, and validating what comes out.
And these weren’t just abstract principles. She showed how to use familiar WordPress mechanisms like permission checks, REST API hooks, and output sanitization as part of those safeguards.
She also covered evaluating AI outputs. Some things can be tested with regular code, while others require judging the quality of an answer. In those cases, using another LLM to evaluate results can make sense.
Tools like Promptfoo and Langfuse came up, along with automated testing, red teaming, monitoring, and handling situations where an AI model produces something unexpected.
One of her stories involved Claude deleting an entire database during development because it apparently decided that was a reasonable thing to do.
A good reminder that giving an AI tool access to something doesn’t necessarily mean it should be allowed to use it.
What I particularly liked was her point about defining success before you start testing.
If you don’t know what a correct result should look like, it’s difficult to evaluate whether the AI is doing a good job.
And when something goes wrong, sometimes the best solution is to fall back to a traditional, deterministic process rather than trying to fix everything with another prompt.
The broader takeaway was clear: you can probably vibe-code a prototype, but building reliable software still requires a systematic approach.
For agencies developing WordPress solutions with AI features, I think there’s plenty worth remembering here.
Her presentation slides are available online.
Samuel Silva – Not everything needs an LLM
I liked Samuel’s presentation because it approached AI from a slightly different angle.
Instead of talking about another chatbot or agent, he showed how vector embeddings can improve search in WordPress.
The idea is quite simple. Rather than relying only on traditional keyword matching, you generate embeddings for your content and use them to find results based on semantic similarity.
What’s interesting is that you don’t need to involve an LLM every time someone searches for something.
Samuel demonstrated an implementation using WordPress post metadata and similarity calculations in PHP, without requiring a separate external search service.
He also compared the potential cost and response time of a search process involving an LLM with one based on embeddings alone. In his example, the embeddings approach was dramatically cheaper and faster.
Of course, these were illustrative numbers, not a guarantee that every implementation would perform the same way. There are still questions around scale, indexing, and performance.
But I liked the general idea.
We spend so much time talking about AI agents and LLMs that it’s easy to overlook the technologies underneath them.
Sometimes you can take one part of that technology, use it directly, and build something simpler, faster, and cheaper.
It doesn’t always have to be a chatbot.
Simone Cimiluca-Radzins and Rose Hes Rozendo – Selling and creating content with AI
The two business-oriented presentations I attended were interesting in their own way, although I found them a little less relevant to what I’d come to Faro for.
Simone ran a workshop about selling authentically with AI. She introduced the PET framework (People, Emotions, Trust), discussed understanding your ideal customer, and showed how AI could help create better sales messages rather than another generic landing page.
One point I liked was that selling doesn’t have to mean manipulating people. You don’t need to put on a performance, but you do need to have a clear point of view.
Being boring certainly doesn’t help.
Rose focused on creating content that still feels human in a world increasingly filled with AI-generated material.
She talked about understanding your own strengths, developing a recognizable style, and checking AI-assisted content for authenticity, accuracy, natural language, and overall quality.
One idea I particularly liked was that we need to keep exercising our creative instincts.
If you let AI handle all the ideas, writing, and decisions, there’s a risk you’ll gradually stop developing your own judgment about what’s worth saying and how to say it.
AI should help with the process, not replace your point of view.
Both sessions had useful observations, and both included practical AI applications. But to me, they felt closer to general sales and content marketing workshops than to the WordPress-specific AI discussions I was most interested in.
I’m sure they were valuable for a different part of the audience. They just weren’t quite what I was looking for.
Jamie Marsland – Build first, learn along the way
Jamie’s presentation was probably the best illustration of how much the process of building software is changing.
He walked us through a series of experiments he’d been working on, starting with relatively simple ideas like a font-guessing game and speed-building challenges.
One project led to another. He experimented with WordPress Playground, simplified editing interfaces, tools for publishing content, and eventually using AI-generated HTML to create websites.
That led him to another problem: generating HTML is one thing, but how do you make it easy for someone to edit?
So he built tools to solve that too.
Eventually, these experiments evolved into a visual editor designed to make working with WordPress feel more like Canva while still using native WordPress blocks.
What made the story interesting wasn’t any particular tool. It was how he got there.
Build something. Discover a limitation. Try another approach. Break something. Fix it. Keep going.
At some point, even testing became part of the AI-assisted workflow, with Claude helping catch problems introduced by subsequent changes.
One of Jamie’s observations stuck with me.
Until recently, you generally had to learn how to build something before you could actually build it.
Now you can start building, discover what’s possible, run into problems, and learn along the way.
I’m not convinced this approach works equally well for every type of project. As Ivelina’s presentation showed, there’s still a big difference between experimenting and delivering reliable software.
But it certainly makes things possible for people who would never have attempted them before.
Jamie ended with three questions that I think are worth thinking about:
- When anyone can build anything, what’s the moat?
- How do we show the world what’s now possible?
- Who should we hire next: a developer, a product person, or someone new?
I find the first two particularly interesting.
If building software keeps getting easier, the ability to build something may no longer be much of a competitive advantage on its own.
Knowing what to build, getting people to discover it, and earning their trust could become even more important.
And that’s a pretty interesting challenge for both product companies and agencies.
Why I’d like to see more events like this
Coming back to the conference itself, I think WordPress Day for AI is a good example of something the WordPress community should do more often.
Not necessarily more conferences. More focused conferences.
WordPress is a huge ecosystem. Developers, designers, agency owners, ecommerce specialists, marketers, hosting companies, and people just getting started all have different needs.
Trying to cover everything at one event is difficult.
And while general WordCamps are valuable for bringing people together, meeting the community, and discovering things outside your usual area of work, I think there’s plenty of room for more specialized events.
AI is one obvious topic. But it could just as easily be WooCommerce, performance, security, enterprise WordPress, or something else.
I’d happily travel to an event where I know most of the sessions will be relevant to what I do.
That’s a much easier decision than travelling somewhere knowing in advance that I’ll probably skip half the talks.
There is one thing I would have liked to see in Faro, though.
Panel discussions.
I’ve mentioned this before after WordCamp Gdynia, and I still think panels can be among the most valuable parts of a conference.
Presentations are prepared. The speaker knows what they want to say, which examples to show, and where the story is going.
A good panel works differently.
Someone asks an unexpected question. Another person disagrees. The conversation moves into territory nobody planned to cover.
And that’s often when the most interesting things come up.
With AI changing as quickly as it is, I’d love to hear more discussions between people actually building products, running agencies, and experimenting with these technologies.
What’s working? What looked promising but turned out to be a waste of time? What have they changed their minds about?
Those are the kinds of conversations that can be hard to fit into a prepared presentation.
Final thoughts
Overall, I’m glad I made the trip to Faro.
I didn’t get to see everything, and not every presentation was equally relevant to me. But the technical sessions gave me a few ideas worth exploring, especially around agent-ready websites, AI testing, and using embeddings for search.
One thing also came up in different forms throughout the day: building things is getting easier, but making them reliable, useful, and commercially successful is still difficult.
In some ways, that part might become even more important.
But my biggest takeaway is still about the event itself.
I like the idea of smaller, more focused WordPress conferences where people know what they’re coming for and have a good chance of learning something relevant to their work.
I’d like to see more of them.
Thanks to the organizers and speakers for putting this together.
