Across the teams we work and talk with, we keep seeing the same shift.
Two years ago, content designers wrote and edited nearly all of the copy that shipped. Today, almost every teammate does: designers, PMs and engineers draft copy themselves, often with an AI agent wired directly into the same tools they build with.
Those agents read the design system, the components, the codebase, so they can build and change screens largely on their own. That solves something real: an agent that understands how a product is structured works faster and breaks less than one working from a screenshot and a guess.
However, nothing got easier. The number of arguments about copy went up, not down. The number of near-identical strings went up. The number of things that read fine in English and broke in other languages went up. We removed the bottleneck and the work got harder, because the bottleneck was never the thing we thought it was.
Why the style guide does not save you
Every team we've worked with already has a system for how the interface looks: tokens, components, a component library they maintain and everyone builds from. Almost none of them have the equivalent for how the product talks.
The immediate solution is to collect that system into a style guide and paste it into the prompt. That worked when one or a few writers were drafting copy by hand. It stops working once a hundred people's AI is drafting against it at the same time, each one reading the same paragraph slightly differently, with nothing in place that ensures alignment.
A style guide can hold a product's voice. It cannot hold hundreds of live decisions at once: which of four near-identical strings already shipped, which one is in review, and which exact wording legal already signed off on last quarter. That used to be a handful of judgment calls a writer carried in their head. At this volume, it might be hundreds of them a week, and a static document was never built to carry that.
Four new roles for running the system
Before we talk about the system itself, it's worth naming the new roles that emerged for handling the entire modern content production process.
We've watched this split into four roles. Here is a question worth sitting with: if a hundred people's AI is drafting copy all day, whose job is it to keep that consistent?
What we've found is that it is not one job any more, and some of these roles barely existed as distinct jobs two years ago:
- Content system managers. They own the standards: structure the style guide and the library, and watch which rules hold in practice and which get worked around. A year or two ago this was a side responsibility on a content design lead's plate. At today's volume it is close to a full-time job on its own.
- Content writers. Content designers, UX designers, PMs, engineers, translators, and their AI tools: everyone producing first drafts against the same rules, mostly without reading the rules first. This was true a little in 2022 and is true of nearly everyone by 2026.
- Content implementers. Developers, PMs, and the agents working alongside them, pulling approved strings into a codebase instead of retyping what someone already decided. This role used to be occupied by developers only, but today it's basically everyone who ships software, and the copy as part of it.
- Content reviewers. Legal, marketing, PMs, a client, a translator: reviewing the words in the actual design or the live interface. That role is kept as is from the traditional workflow.
The main difference in this modern setup is that far more teammates write copy, the scale is higher, and quality expectations start earlier.
The system you need to build
A content system needs more than a store of approved wording. It needs the constraint and standards attached to each text, which languages it exists in, what state it is in, and the record of what was decided and why, available wherever someone is working, not pasted into a prompt and already out of date.
It has to store:
- Content. The approved wording itself — the thing the system actually learns from.
- Design. The most important context type, both for agents and humans.
- Standards. One place for the content rules, organized by products, audiences, and languages.
- Decisions. Every review, comment, and judgment call a human made along the way. This is what closes the loop and makes the rules better over time.
Also, meet writing and editing wherever it happens:
- AI tools. Claude Code, Claude Design, Cursor, Figma's own agents: wherever copy gets drafted now.
- Design tools. Figma, where the design and the copy get reviewed and reworked together.
- Dev tools and code. IDEs, GitHub, GitLab, and whatever else a team ships through, where content goes live.
Content creation and editing no longer happen in a linear process. A text can get drafted by a developer, then handed off for review by a content designer. Or drafted by a designer and reviewed by a PM. The system needs to understand how to check that string no matter where the work happens.
The loop you need to build
To address the new scale of content, having a system in place wouldn't be enough. It should be used in a loop or a flywheel that learns and adapts.
Many teams already have the middle of it: a style guide, and a content library. What's usually missing is what feeds it and what closes it, and without both ends, the rules just go stale.
1. Collect input. User research, support tickets, content audits, a redesign that touches old copy: this is where you learn a rule is wrong or missing.
2. Set the rules. Store all content rules in one place, alongside the approved content.
3. Authoring. Every surface where copy actually gets written: the design tool, the product itself, whichever AI agent teammates who write use.
4. Review. Not one review gate at the end, but something that runs as the work happens and again at the point it ships: in the design file, in the product, on the diff before it merges in the codebase.
5. Gather feedback. This is the piece most teams skip, and it's the one that matters most. What a reviewer flags, what a research session surfaces, what an audit finds: all of it has to travel back and change the rules, not just fix the one string in front of someone. Most of the teams find it hard to automate without proper tools.
Together these complete a loop that supports a much larger scale of content and writers, while keeping quality intact.
Side note on localization
Localization didn't change the way everything else did. Most teams have used machine translation for years now, then post-edited the result in a dedicated tool before anything shipped. That part of the process is already mature.
What changed is the volume. When a couple of writers produced the source copy, there was a manageable amount of it to translate and check. Now that dozens or a hundred people's AI produces the source copy too, there is far more of it, arriving far more often, in every language a product ships in.
The same system covers this. Every approved translation becomes part of it, so an agent translating a new string checks against what has already been approved instead of generating it fresh every time. Used that way, as a translation memory the whole team draws from, it gets more accurate the more it is used, and screens that should say the same thing in a given language actually do.
We're building the UX content system for product teams
Frontitude is built to be that system, across every stage of the loop above, for all four of the roles who depend on it.
- Rules, for content system managers. A proper home for the style guide and the library: one version per product and per audience, written together in real time and kept as a history you can read and roll back, not a document that goes stale the day someone edits it locally.
- Authoring, for content writers. The style guide and the library already reach Figma, the Frontitude web app, and, as of this year, AI tools directly over MCP: Claude, ChatGPT, Cursor or your own agent can read the approved wording, the constraints and the coverage attached to it, and write changes back into the same record a person would.
- Checks, for content implementers. A check that runs on the pull request itself, reading the diff and commenting on a string before a human reviewer has to, so a problem gets caught before it is in the codebase at all.
- Feedback, for content reviewers. Rewriting and auditing built into the product surfaces where the copy already lives, so a reviewer's fix is never more than one click from the problem, and travels straight back into the rules.
The direction follows directly from everything above: the system has to reach every surface, catch problems before they ship, and keep the loop closed for every role that touches copy, not just the ones who draft it.
The job is owning the system, not writing the string
When generating text is free, the value shifts to making sure it’s right. That means managing approved wording, rules, translations, and version history, and keeping them up to date as hundreds of AI agents create content at once.
That is a bigger job than the one content designers were hired for, not a smaller one. The people who used to be the bottleneck become the people who set the rules that everyone else's AI works inside. One person can shape what a hundred agents produce, which is a leverage no amount of writing ever gave them. The title of the job may not change. The deliverable does.
It stops being copy and starts being the system that makes everyone else's copy correct, at whatever volume AI decides to produce it. The teams that come out ahead here won't be the ones whose AI writes the most copy. They'll be the ones who can say, at any moment, which version of it is actually resonating with their users.
If your team is already producing more copy with AI than anyone is keeping track of, get in touch and we'll be happy to show you how the Frontitude UX Content System works. Request a demo here
