Over the past month, I was deep in Radical Speed Month at Automattic, building Opa.blog with Marjorie R. Asturias. We were designing a Substack-style writing experience built entirely on WordPress, and one of the features I built with Claude Code was a preview modal that lets writers see how their post will look without leaving the editor.
No new tab. No context switch. Just a clean layer over the writing surface with desktop, tablet, and mobile views.
The more I used it, the more obvious the question became: why doesn’t Gutenberg have this?
So I built it there too. I shipped a PR to WordPress/gutenberg, not as a core developer and not as someone who has spent years inside the Gutenberg codebase. I shipped it as a Technical Account Manager who writes prose for a living and uses AI coding agents to build things I could not build alone.
How I contributed code without being a JavaScript engineer
I am not a JavaScript engineer. My PhD is in Rhetoric and Professional Communication. I build WordPress blocks and plugins, but I do it with AI tools. That is not a caveat or a disclaimer. It is the whole point.
I used OpenAI Codex for the Gutenberg implementation. I had already spent real time training Codex on WordPress developer documentation and the official WordPress agent skills, so it was not approaching the platform cold. When I asked for a new Gutenberg component that uses the existing Modal, renders an iframe at multiple viewport sizes, and fits into the editor header actions, the agent understood the patterns because I had taught it the ecosystem.
Before this, my version of contribution would have been sharing an idea in an issue and hoping a developer had time to pick it up. This time I could show up with working code.
What the PR changes
The feature is straightforward. When you click Preview in the post or page editor, the preview opens inside the editor instead of sending you to a new browser tab. You can switch between desktop, tablet, and mobile views. The preview renders in an iframe using the same preview URL WordPress already generates. Escape closes the modal. Focus stays inside the modal. Long content scrolls inside the preview, not behind it.
In the PR, I included screenshots of the three preview states because the point is easier to understand when you can see the experience in place. The desktop view keeps the full page visible inside the editor, but still gives it enough room to feel like a real preview.
Desktop preview in the editor modal.
The tablet and mobile views are where the modal starts to feel more useful. Instead of opening a new tab, resizing the browser, or guessing what the post will look like, the writer can stay in the editor and move through the common contexts.
Tablet preview in the same modal.
Mobile preview without leaving the writing surface.
It is a small change, which is exactly why I wanted it as my first Gutenberg PR. The annoyance is easy to understand. The improvement is easy to feel. If it lands, the default preview flow gets calmer for every writer using the editor.
How someone else can do this too
The part worth sharing is not that an AI coding agent can write code. Everyone reading this already knows that. The useful part is the workflow around the agent.
I started from a product idea I had already tested in Opa. I found the closest Gutenberg patterns. I asked Codex to work inside those patterns, not invent a new preview system. I used Docker for the first time because Gutenberg’s local environment needed it. I leaned on the agent to tell me how to do the unfamiliar parts properly, from setup to implementation details to the shape of the PR.
That is the shift for me. AI does not just type faster than I do. It gives me enough scaffolding to make decisions I could not make on my own. I still have to know what experience I want for users. I still have to decide what belongs in v1 and what should wait. But when I hit the edge of my technical fluency, I am not stuck there anymore.
Why this matters beyond me
WordPress powers a staggering share of the web, and Gutenberg is the editor that shapes how millions of people create content. Anyone can contribute to WordPress. I just made the WordPress 7.0 contributors list as a tester, and testing, docs, triage, design feedback, and issue reports all matter.
This felt different because it moved me into direct code contribution through a PR. That path has always been narrower. You need React. You need PHP. You need the Gutenberg component architecture. You need enough local tooling knowledge to get the project running, and sometimes that means learning Docker because the work demands it.
AI coding agents are changing that constraint by helping more people clear the bar. The PR still has to pass review. It still has to meet Gutenberg’s standards for accessibility, testing, and architecture. I hope the review centers on what should matter most: whether the feature is useful, whether the code is correct, and whether the contribution is maintainable.
That opens a door for product people, power users, designers, writers, and support folks who understand the experience deeply. Instead of stopping at “someone should build this,” we can start asking, “what would it take for me to build the first version?”
What comes next
The PR is open and ready for review. The admin bar suppression work is queued as a follow-up. And the preview modal concept connects back to a broader idea: once you have an in-editor preview layer, you can start imagining preview modes for email, like Jetpack Newsletter does, social cards, RSS, print, paid versus public views, and plugin-provided contexts.
That is a longer conversation, and it starts with getting the foundation merged.
If you are building on WordPress with AI coding agents, the next step may not be another private prototype. It might be a patch. It might be a Gutenberg PR. It might be the first time you stop waiting for someone else to build the product idea you already understand.
What is the small WordPress improvement you understand well enough to try building?
