Govern product copy like a design system, with one system spanning Figma, code, and pull requests
How to build content systems for AI product workflows with Ditto | Config 2026 · Jessica
20 min total·Actually worth watching closely: ~11 min·3 must-watch clips
- 0:12 – 5:22Listen
Framing the problem: where AI lets copy get away from you
Starts with how shipping changed: a spec was written, designs were created and refined, then handed to an engineer to build. Now copy rides along in every pull request, drafted in seconds by more people and agents. As features get easier to build, what sets a product apart is how it talks.
The question has never been whether AI can write copy, but how to keep all of it right, consistent, and on-brand at the speed and volume it's now created.
This stretch is mostly the speakers standing and making the argument, with slides that just carry the title. Nothing is lost listening to it on a commute or while doing something else.▶ Jump to 0:12Speaker · Jessica - 5:25 – 7:56Watch
The raw material is already in your production codebase
Cuts to a live demo: Scan runs over a sample finance app's codebase, extracts the strings that shipped, and after a bit of added context tags them, organizes them, and pulls out their relationships into a text component library.
All of your product language is already scattered across the live code, so the content system should grow out of what's actually shipped rather than from a fresh idealized draft.
The string counts, the automatic grouping, and the Spanish translations pulled from the code all show up on screen one item at a time; you won't catch those details from the audio.▶ Jump to 5:25Speaker · Jo - 7:56 – 12:26Skim
An inferred style guide, shaped by feedback
On top of the library, the system drafts a full style guide from the language actually used in the code, and the speaker demos re-tagging items by UI element and using feedback to gradually shape the guide into the team's own.
The guide isn't a document written once and frozen; it's a first draft inferred from real usage that the team keeps correcting with feedback.
Mostly scrolling through pages of generated guide entries and tags, fairly static text, so skimming for the structure and a few sample entries is enough.▶ Jump to 7:56Speaker · Jo - 12:26 – 13:16Watch
Place one: correcting copy while you design in Figma
The plugin is connected to both the content system and the screens themselves, so as the designer reworks the onboarding flow it checks the copy against the system line by line, surfaces the terminology inconsistency, and offers a replacement you accept in one click.
Governance has to happen where the work is actually being done, not in a review afterwards, and it only closes the loop when the change lands back in the design.
The whole case rests on that check and on the design visibly changing once the suggestion is accepted; heard as description, it sounds like just another checklist.▶ Jump to 12:26Speaker · Jo - 13:16 – 15:08Watch
Place two: embedding the rules in code for the agent
A pull command embeds the content system in the codebase, so alongside the three files defining how a design system component is built visually there's now a file defining how the copy inside it should be written. Then Claude Code is asked to add international transfers.
For an agent, more context isn't better context. Split the rules up and put them next to the component they apply to, and it only picks up the few the task at hand needs.
You need to see where the rules file sits next to the component files in the tree, and what the currency formatting and the reused components look like in the output, all of it on screen.▶ Jump to 13:16Speaker · Jo - 15:08 – 16:03Watch
Place three: the last gate before merge
As soon as the PR opens, the bot runs through all the copy it finds, checks it against the content system, and leaves comments and suggestions in the GitHub review, like using the existing "Your payment was processed successfully" instead of a slightly different rewrite.
Catch wording drift before the code is merged and shipped to production, so reviewing copy becomes part of ordinary code review.
What matters is the shape of the GitHub comments and the exact wording of the suggestions, since that decides whether it works in a real review flow; worth reading the screenshots closely.▶ Jump to 15:08Speaker · Jo - 16:03 – 18:08Watch
The feedback loop: rejections are fuel too
Back in Figma, a suggestion to use contractions is rejected with the reason written out: consent language is more serious and shouldn't use contractions. The rejection goes back into the system, and this kind of feedback from across the team keeps accumulating.
The reason you leave when rejecting a suggestion does more to keep the system close to the team's real judgment than accepting one does.
You can see the step where the reason gets typed in on rejection, and that's exactly the line between this and a static style guide, so it's worth a look at what the interaction looks like.▶ Jump to 16:03Speaker · Jo - 18:08 – 20:12Watch
Performance you can see, one edit enforced everywhere
The style guide page shows, rule by rule, how often each is attributed, used, accepted, and rejected, so you can act on it and edit rules there. Flipping the preferred term from live to active is immediately enforced across Figma, Claude Code, and pull requests. It closes on the talk's main argument.
The teams that do this well won't be the ones generating the most copy; they'll be the ones with a system underneath keeping all of it right.
One word changes and three tools follow at once, and that continuous sequence is the evidence for the talk's conclusion, far more effective seen than heard.▶ Jump to 18:08Speaker · Jo