A content-heavy client already used AI tools for first drafts, but constantly switching between a separate AI app and the WordPress editor was slowing their team down in a way that was easy to underestimate from the outside. Every draft meant copying a prompt into one tool, copying the output back into another, and losing whatever formatting and context WordPress's block editor already understood about the piece. We built a lightweight plugin that brings AI-assisted drafting directly into the block editor, and the technical integration turned out to be the easy part of the project.
The problem wasn't the AI, it was the workflow
Before we built anything, we spent real time just watching the editorial team work, which is usually the most valuable hour on a project like this and the one that's easiest to skip under deadline pressure. What we saw wasn't a team struggling with AI-generated content quality, their prompts and review process were already solid. What we saw was a team losing focus every time they had to leave WordPress to get a draft, then losing more time re-establishing context when they came back. The AI tool they were using was good. The seam between it and their actual writing environment was the thing costing them time.
That reframing changed what we built. Instead of a more powerful AI drafting tool, we needed the same drafting capability the team already trusted, delivered without the context switch. The plugin doesn't introduce a new AI model or a new set of prompts to learn, it wraps the drafting capability the client was already using into an interface that lives inside the block editor they already work in every day.
What we built and why control mattered more than features
Keeping the human editor firmly in control, the plugin drafts suggestions inline but never publishes or overwrites content automatically, mattered more to the client than any feature we added. This wasn't a hypothetical concern raised by legal, it came directly from the editorial team itself during our early conversations: they wanted AI assistance they could accept, reject, or heavily rewrite, not a tool that could silently change what was already on the page. We built the suggestion mechanism as a genuinely separate layer, visible as a distinct block that the editor explicitly accepts into the main content, rather than an inline autocomplete that blurs the line between what the editor wrote and what the AI suggested.
- Suggestions render as a distinct, clearly marked block the editor must explicitly accept, never a silent inline change.
- The plugin never publishes or modifies existing published content on its own under any circumstance.
- Drafting prompts reuse the same underlying capability the editorial team already trusted, rather than introducing a new model to evaluate.
- Every accepted suggestion is attributed in the post's revision history, so the editorial trail stays fully auditable.
We also made every accepted AI suggestion visible in WordPress's existing revision history, attributed clearly as AI-assisted rather than blended invisibly into the editor's own authorship. That auditability wasn't a feature anyone explicitly requested, but once we mentioned it as an option during a review meeting, the editorial lead immediately confirmed it was exactly the kind of transparency they wanted, both for internal accountability and in case a piece of content was ever questioned later.
Adoption and what actually drove it
Editorial team adoption was fast specifically because it removed a context switch rather than adding a new tool to learn from scratch. Within the first two weeks, editors who had been openly skeptical of AI drafting tools in general started using the plugin regularly, not because their opinion of AI-generated content had changed, but because the friction of using it had disappeared. That's a distinction worth sitting with: the technology didn't get more persuasive, the cost of trying it dropped low enough that skepticism stopped being a sufficient reason to avoid it.
We tracked usage over the first quarter and saw a pattern we hadn't fully anticipated: editors used the AI drafting feature most heavily on the pieces they found most tedious to write from scratch, routine product updates and recurring content formats, and least on flagship pieces where the client's distinctive voice mattered most. That split matches how we'd hope a tool like this gets used, as leverage on the routine work rather than as a replacement for the writing that actually needs a human's judgment and voice.
The real lesson
The technical integration was straightforward. The real design work was making sure the tool assisted the existing editorial workflow instead of replacing or disrupting it, which is what actually determined whether the team used it. We've carried that lesson into how we scope every subsequent AI tooling project for a client: the question that predicts success isn't "can the AI do the task well," it's "does the tool fit into the shape of the work the team already does," and answering that second question honestly requires watching people work before writing a line of code.
Not every concern the editorial team raised was about control in the way the publish-and-overwrite question was. A quieter, more persistent worry was about voice: several senior writers were concerned that AI-assisted drafts, however lightly used, would gradually homogenize the publication's distinctive tone across writers who had each cultivated a genuinely different style over years. That concern didn't have a clean technical fix the way the publishing-control concern did, and we spent real time in follow-up conversations rather than trying to engineer our way past it.
What we landed on was giving each writer the ability to save their own style preferences, favored sentence rhythms, a list of phrases to avoid, examples of their own past writing the drafting feature could reference as a style anchor, so that AI-assisted suggestions for a given writer leaned toward that writer's own established voice rather than a single generic house style applied uniformly across the team. That feature took longer to build than the core drafting integration itself, and its value is harder to measure than adoption rate, but it directly addressed the specific worry that had been holding back a few of the team's most respected writers from using the tool at all.
We check in with the editorial team roughly quarterly now, specifically asking whether anyone feels the AI-assisted drafts have started to feel repetitive or formulaic across different pieces, since that's the failure mode we're most worried about long after initial adoption enthusiasm has settled into routine use. So far the per-writer style anchoring has kept that concern from materializing in a serious way, but it's the kind of gradual drift that's easy to miss without deliberately asking about it, since no single piece would ever look obviously wrong even if the aggregate body of work were slowly losing some of its original range. We've built that check-in into our standard cadence for any similar project going forward, treating "does this still sound like us" as an ongoing question rather than one answered once at launch and never revisited.
Adoption rate alone doesn't tell you whether a tool is actually saving meaningful time, since a team can use a feature regularly while it only shaves a small amount off their overall workflow. We asked a handful of editors to track, informally, how long a typical first draft took before and after adopting the plugin for the specific content types where they used it most. The reported time savings varied a fair amount by content type, routine product update posts saw the largest reduction, since those follow a predictable structure the drafting feature handles well, while more exploratory, reported-style pieces saw a much smaller time saving, since the drafting feature's suggestions were less directly usable when the piece's structure wasn't decided in advance.
That variation matched what we'd expect intuitively, but having it measured rather than assumed changed how we talked to the client about where the tool was actually delivering value. We stopped describing the plugin as a general productivity improvement and started describing it more precisely as a strong fit for structured, recurring content types and a modest fit for exploratory writing, which is a more useful and more honest way for the client's editorial leadership to think about where to actually encourage its use going forward. That distinction between structured and exploratory content has since become one of the first questions we ask on any similar project, well before we write a line of integration code.