Building technical confidence for content designers in the AI era

Opening a codebase can feel wildly disproportionate to the thing you're actually trying to do.

You might want to change one sentence. Instead, VS Code shows you hundreds of files and folders, unfamiliar syntax, component names you don't recognize, and terminology that makes you feel completely out of your depth — things like const, hooks, useEffect.

You don't know where your sentence lives. You don't know which bits matter. And, perhaps more importantly, you don't know whether touching the wrong thing is going to break something.

AI changes the starting point. You no longer have to understand the codebase to get into it; you can start from a content problem you already understand and follow it in.

Ask the codebase questions about itself

Imagine an error message in the product: "Your payment was declined." In a design file, you'd ask:

• When does this appear?
• What happened before it?
• Are there other states?
• Is the wording consistent with similar errors?

Those are ordinary content design questions, but the design file won't always have the answers.

For this, I use an AI coding assistant connected to the codebase — for me, that’s Claude in VS Code. Once the assistant has access to the repo, you can start by asking it questions in plain language. For example, "I'm trying to find the text 'Your payment was declined.' Where does it come from? Are there other versions of this message? Does it change depending on the payment state?"

That's where I find AI most useful. It removes the translation work between the question in your head and the codebase in front of you.

Follow one problem, not the whole system

Once you find the string, the goal isn't to learn how the whole application works. It's to follow that one problem. Ask AI to explain the surrounding logic in plain English. Find out whether the same pattern exists elsewhere, or whether the message you thought lived in one place is actually assembled across several.

That changes the conversation with engineering. Instead of "can we change this sentence?", you can say: "This message is being used for three different decline states — do we have enough information here to make the guidance specific to each one?"

A day of doing exactly this

Last month, our content design team took part in a product design hackathon for the first time. The goal was deliberately small: every content designer would edit live code and open a pull request independently.

The problem we picked was empty states in our data-visualization library. Page-level guidance existed, but nothing covered the empty states built into the charts themselves. And this wasn’t a gap you could spot in a design file, because the states had never been designed at all.

Working in the code produced a content decision we hadn't made before. "No data available" and "Could not retrieve data" are not the same message. One is a successful query that returned nothing. The other is a failure that the merchant might be able to retry. And if you collapse them into a single string, you lose the reload button, because there's nothing to reload.

That's a content design judgment, and it only came up because we were looking at what the component actually did.

It's also where the AI got it wrong. Its first pass merged the two states into one, and invented a third — a "measured zero" — that didn't exist in the data. Catching it wasn't a technical skill; it was knowing what the states meant.

Two of our content designers shipped their own pull requests that day, having never used that repo before. Most of the afternoon went on expired credentials, re-authentication, and a Figma integration that refused to connect for one of them. Worth saying plainly: the code was the easy part, and getting set up was the hardest bit.

Sometimes the content isn't the problem

I saw this again recently, reviewing an internal AI content design tool that wasn't behaving as expected. My instinct was to fix the guidance — rewrite the instructions that tell the tool how to work, make it more explicit.

Looking at what the tool was receiving told a different story. A single design frame was sending roughly 39,000 tokens (the chunks of text an AI model reads), and under 3% of it was copy. The rest was layout and geometry the tool couldn't use. The input was the bottleneck. If I'd stayed at the surface, I'd have spent hours rewriting guidance for a problem the guidance didn't cause.

This is still content design

These are the same questions we already ask in design files: when does this appear, what happened before it, is this consistent, where else does this pattern show up?

Looking at the implementation just lets us ask those questions about what actually shipped rather than what was intended. A design file tells you what someone meant to build. Code tells you what the product is actually doing.

None of that means accepting whatever the AI tells you, or making changes you don't understand. The valuable part is still judgment: knowing what to question, when something looks inconsistent, and whether a content problem is actually a content problem.

The goal is to investigate far enough to know what you're looking at, what's safe to change, and when you need someone with deeper technical expertise. Knowing when to ask an engineer is part of technical confidence, too.

Start smaller than feels useful

If opening a codebase still feels intimidating, don't start by trying to understand the codebase. Start with one piece of content you already know. Find it. Ask where it comes from. Ask what makes it appear.

Then do it again. Eventually, the same folders keep showing up, components stop looking unfamiliar, and pull requests make sense because you've seen one attached to something you care about.

Technical confidence isn't knowing how an entire codebase works. It's being able to follow a content question into the code, understand enough to make sense of what you find, and know what to ask next.