A journey from writing copy to shipping it in code.
How It Started
Approximately 1 billion years ago (end of 2024), I was experimenting with custom GPTs. I trained a co-writer on our product content style guide, which has been the most popular GPT at Justworks pretty consistently ever since. I fed it one guideline at a time and it took forever. But I felt ahead of the game, and could brag that I was training my own AI when most people I knew had barely entered the chat. I was pretty confident that no robots were coming for my job.
The only job these robots are coming for is freaking out my cat. Photo by Eric Krull on Unsplash
Only a few months later custom chatbots were old news and the conversation turned to vibe coding. Suddenly I felt like I was being left behind. It’s easy enough now to ask a chatbot to spit out some code, but that only gets you so far. Once you have the code… where does it go? How do you run it? How does it become something real?
What Happened Next
During our annual hackathon I joined a team with another designer and two PMs and we decided to build an app that gives you a tarot-style reading based on a privacy policy or terms of service. With no engineers on our team we had to figure things out as we went. We poked around GitHub, asked a lot of dumb questions, and leaned on tools like Claude Code, Gemini, and ChatGPT. Most of the time we weren’t doing things “right.” But we kept going anyway, and it worked!
On the left: Three of us accepting a Tamagotchi after we were voted “Best Use of Vibes as a Service.” On the right: Fine Print Fortune
Up until then, code felt like something I could sort of generate, but not something I could actually do anything with. After the hackathon, the gap between “I have some code” and “this is a real, working thing” felt a whole lot smaller.
How it’s Going
We recently had some copy in our product flagged for inconsistency by a member of our CS team. Do we say “Workers’ Compensation Insurance” or “workers comp” or some other variation? Turns out we were using a variety of different capitalization styles, sometimes abbreviating, and even misplacing the apostrophe. Before AI our workflow would have taken several days and looked like this:
Inconsistent copy gets flagged to content design
Content designer tries to figure out what pages those inconsistencies live on and which teams own the pages
Content designer requests help from relevant engineers
Engineers add it to a Jira backlog
Copy gets updated eventually
We cross our fingers that we got every instance
This kind of workflow is a real pain for our team and it diverts our attention away from the more strategic aspects of our job like research, testing, aligning with stakeholders, and developing content systems.
So, what if we could update the copy directly in the code ourselves? Engineers have been asking us to simply open a pull request (PR) on GitHub for a while now, but of course we had no idea how to go about doing that. With my post-hackathon confidence, I decided to give it a try.
I cloned our main repo locally, asked Claude Code to find all instances of any variation of the phrase workers’ compensation in customer facing strings. Then I told it how to update them and sent my changes to GitHub where I opened my first real PR.
I’m making it sound easier than it was. I couldn’t get Claude Code to use the correct apostrophe (it kept defaulting to a straight quote), and it took over an hour just to update three strings. Still faster than several days (or never), but it made me think this would be a lot easier with a proper strings management tool.
So I built one.
My magnum opus. All our strings in one place.
I teamed up with a product designer who has a lot of technical knowledge and we vibe coded a strings management platform together — Justwords. We built the whole thing with Claude Code, which feels less like coding than working with the world’s most agreeable coding partner. Someone who can explain things to you in non-technical language, doesn’t mind if you ask the same question over and over, and is happy to rebuild anything from scratch when it isn’t quite right.
Here’s how it works
Our user-facing strings are stored in locale files that are basically big lists of key-value pairs. The “key” is a code-friendly label and the “value” is the actual string that shows up in the product. Change the value, and that string updates everywhere the key is used.
The files look something like this:
“Key1” : “This is the string that shows up in the UI”
“Key2” : “Another user-facing string here”
In the locale files there’s no context about where or when that string appears. Let’s say you found a string that says “No, go back.” and you want to change it to “Cancel.” Could be an ok change, but what if it was a button in a destructive action modal and the other button says “Yes, cancel.” I certainly wouldn’t want to be the person responsible for creating something like this.
I made this as an example in Figma, and I died inside a little.
With Justwords, we can select a specific instance of a string and get a natural language description of the context in which it appears. Now we’ll always know who the audience is, what they’re doing when they see a particular string, and what else is happening on the page before we edit anything.
A picture may be worth 1000 words, but sometimes the words are all we’re going to get
An extra complexity for us is that our keys always match the English language version of the string. So if we update the English, we also need to update the key. That means we’re not just updating the locale files, but also every reference to the key across hundreds of lines of code in multiple files. Finding all those instances in different files and sometimes multiple repos is a serious challenge. Justwords solves that for us by connecting to the files across multiple repos and finding all of the references to each key. It then pulls everything into one place for easy searches and editing.
When we’re done editing, there’s a checkout page that automatically checks for obvious spelling errors and violations of our house style or glossary. If everything looks right, we can click one button to create a branch in GitHub with our changes and open a PR. And if we’ve made changes across multiple repos, it can create multiple PRs all at once. A human engineer still needs to review and approve it before we merge, just like any other code change, so there’s no danger of an LLM running amok in our code.
Now our workflow for updating strings takes minutes and looks like this:
Open Justwords
Search for strings
Edit strings
Create PRs
We don’t have to wait for inconsistencies to be flagged. We can proactively find and fix issues before they become a problem. And it gives us and our engineers time back to focus on higher leverage work.
What’s Next
While I still design content in user flows, vibe coding has fundamentally changed how I approach the rest of my job. Instead of making suggestions, I’m pushing changes to production and building my own tools to solve problems for our team.
My hackathon project was just for fun, but it helped me get over the hump of not knowing how to get started. And now that I know where to start, I can’t seem to stop.
Things I’ve made so far:
Justwords
A Figjam plugin to help us choose the next host of our design team monthly retros — no more awkward silence while we wait for a volunteer!
A Figma plugin to check text in our design files against our house style and glossary.
If you’re feeling left behind by AI like I was, just start making something. Even a ridiculous project, like a tarot reading for data privacy, is enough to get you unstuck. You’ll run into a real problem soon enough, and by then you’ll have the foundation to actually solve it.
