Why Your AI Assistant Can't Actually Edit Your WordPress Site (And What I Did About It)
Build-in-public update from respira.press
TL;DR
Or just enjoy the story
There’s this moment that kept happening.
A client would call. Someone who’d spent fifteen years developing their practice, their approach, their language. They’d finally gotten their old WordPress website to a place that felt right.
Then they’d want to change something small. A button. Some text. Maybe update their bio across three pages. Or just create a brand new landing page for a retreat.
And they’d have three options:
Ask their tech person (me, or someone else)
Try to do it themselves in Divi or Elementor and... maybe break something
Just not do it
Most of them chose option three.
Not because they couldn’t find help. Because the friction was too high. Because by the time they’d explained what they wanted and someone had time to do it, the moment had passed.
Their websites became frozen. Not broken - frozen. Stuck at “good enough” because change felt hard.
And on my side? i wanted to help faster. To take “can you change this button” and turn it into “done” in five minutes instead of finding time, making the edit, testing it, and following up. The work itself was simple. The process around it wasn’t.
These are people whose work is about evolution. About becoming. Their online presence should be able to keep up.
Then I started vibe coding.
That’s what they call it when you use AI assistants like Cursor or Claude Code. You describe what you want in plain English. The AI writes the code. You’re not really a developer anymore - you’re a translator between intention and execution.
It changed how i work. Completely.
I could build things i couldn’t have built before. Faster. With more room to experiment. The AI handled the syntax, the structure, the technical details. i handled the vision.
But there was a gap.
The AI couldn’t talk to WordPress. Not in a way that understood page builders. Not in a way that was safe.
I could tell it “make all the Contact Us buttons green” but it didn’t know how to find those buttons in Divi. Or Elementor. Or any of the ten different ways WordPress stores content depending on what builder you’re using.
And even if it could find them, any change went straight to the live site. No undo. No review. One wrong instruction and you’re looking at a broken homepage.
This wasn’t a tool i could hand to my clients. It was a tool i couldn’t even fully trust myself.
What was actually missing wasn’t the connection between AI and WordPress. The WordPress REST API exists. The technical bridge is there.
What was missing was the safety layer.
The understanding layer.
The thing that says: “i know you want to change this, let me duplicate the page first, make the change on the copy, show you the result, and only publish it if you approve.”
The thing that speaks Divi when you’re using Divi. Speaks Elementor when you’re using Elementor. Understands that these builders store content in completely different ways and that AI needs different instructions for each one.
That’s what i built.
Respira for WordPress is the bridge I needed.
You tell your AI assistant what you want. Respira translates it into the language of your page builder. The edit happens on a duplicate. You review. You approve. Then and only then does it go live.
If you don’t like it, nothing happened. Your original page is exactly as it was.
This sounds obvious. It wasn’t obvious to build.
Page builders are a mess. Divi stores content as shortcodes in the database. Elementor uses JSON. Gutenberg is blocks. Getting AI to understand all of them meant building separate intelligence for each one.
That part took the longest. That’s also the part that makes this actually work.
There’s an official WordPress MCP now. WordPress announced it a few months ago - a standardized way for AI to talk to WordPress through the REST API.
It’s powerful. It’s built for developers who know WordPress internals. It’s the raw connection.
Respira is something else. It’s the translator and the safety net.
Different tools for different people.
Some things I’m still figuring out:
How to explain this to people who don’t know what MCP means (which is most people - and honestly, they don’t need to know)
Pricing that makes sense for a solo practitioner with one site and an agency with fifty
And what’s next:
SEO intelligence - letting AI rewrite your titles, meta descriptions, and tags based on what actually ranks
AEO (AI Engine Optimization) - optimizing for the new wave of AI search engines, not just Google. Structured data, clarity scoring, and the things that help LLMs understand and cite your content.
Internal linking - AI that reads your whole site and suggests connections you missed
Content rewrites - taking an existing article and restructuring it for readability, both human and machine
The editing layer was step one. Making your site findable is step two.
I built this because the gap between “i want to change something” and “it’s changed” was too wide for everyone involved.
For practitioners who want more autonomy over small changes.
For developers and freelancers who want to move faster on client work without the risk of breaking things mid-edit.
For agencies managing multiple sites who need efficiency without sacrificing quality control.
The work doesn’t disappear - it gets faster and safer. You can experiment, iterate, test different approaches. The AI handles the technical translation. You handle the judgment call about whether the result is right.
You can see it at respira.press. There’s a 7-day free trial. No credit card required.
If you have questions, reply to this. i read everything.
This is what build-in-public looks like. Not just the launches - the thinking behind them.
If you found this useful, share it with someone who manages WordPress sites and wishes it were easier.
Thanks,
Mihai
