The AI superpower: We get five shots. Let’s see what the market actually needs.

For decades, localization lived inside a constraint that shaped everything: the translator makes a choice, then that choice gets baked into the TMS and shipped to 50 languages. Revising means rework. Changing your mind means cost. So you commit to one semantic framing and hope it was the right one.

AI changes this completely. When the cost of generating an alternative drops from “hire another translator” to “press Enter,” you can afford to do something revolutionary: generate multiple competing approaches, compare them openly, and choose based on what your market actually needs rather than what you guessed was right the first time.

This is the Best-of-N pattern. And it’s not just about speed. It’s about how localization should work at the semantic layer.

Part 1: Why Best-of-N Breaks the TMS Model

The Problem with “One True Translation”

A Translation Management System was built on an assumption: one source string → one translation → managed in perpetuity.

This made sense in 1999. A translator researched, committed, and the TMS enshrined that decision. Changing it later meant rework. So TMS culture became “get it right the first time.”

But “right” was always a guess. You’re guessing which semantic framing will resonate in Japanese. You’re guessing whether the UI term should be formal or conversational in Spanish. You’re guessing whether the metaphor that works in English will land in German.

The TMS doesn’t help you resolve that guess, it just locks it in.

The AI Advantage: Egoless, and Fast

Here’s what changes with AI:

Speed. Generating five versions of a 500-word marketing passage takes Claude about 30 seconds.

Egolessness. An AI agent doesn’t care. Ask it to try again from scratch, and it generates something completely different without friction.

Creativity under constraint. Each iteration can explore radically different approaches. Version 1 stays close to source structure (useful for brand consistency). Version 2 follows target-market semantics (useful for native fluency). Version 3 invents from first principles (useful for discovering what you didn’t know you wanted).

The Semantic Governance Insight

Best-of-N only works if you have criteria for choosing.

Traditional localization chose by “gut feel” or “this sounds natural.” That works for small teams with aligned judgment. It breaks at scale: 50 markets, multiple LLM providers, different use cases, stakeholders who disagree about tone.

Best-of-N localization is really semantic governance in action.

You generate multiple versions. You evaluate them against your actual market context: the cryptotypes of your target audience, the vibe you’re trying to establish, the regulatory or brand constraints that matter. Then you choose—or combine—based on why that version is better, not just that it sounds better.

This is what a semantic governance platform does. It makes the choice criteria explicit instead of buried in someone’s intuition.

Part 2: Three Complete Claude Code Exercises

Here’s how to practice this. We’re going to build three localization scenarios using Claude Code, Git branching, and the Best-of-N pattern.

Prerequisites

• Claude Code installed (claude in terminal)

• Basic understanding of Git branches

• A text editor or IDE you’re comfortable with

• ~45 minutes

Exercise 1: Brand Voice Translation (Simple → Semantic → Native)

The Scenario

You’re localizing tagline copy for a SaaS product. The English version is:

“Unclutter your mind. Keep what matters.”

This works in English because it uses a visual metaphor (”unclutter”) + an emotional anchor (”what matters”). But these don’t translate word-for-word. Your job is to find three completely different semantic framings in Spanish that capture the same intent—and then decide which one your Madrid market actually needs.

Setup

mkdir localization-best-of-n
cd localization-best-of-n

git config user.email "localizer@example.com"
git config user.name "Localizer"

# Create a basic project structure
touch README.md
echo "# Localization Best-of-N Exercises" > README.md
git add .
git commit -m "Initial project setup"

Version 1: Literal Semantic Translation

Launch Claude Code:

claude

Copy and paste this prompt:

I'm running a localization exercise to practice the Best-of-N pattern. 
I have an English tagline for a note-taking/productivity SaaS:

ENGLISH SOURCE:
"Unclutter your mind. Keep what matters."

VERSION 1 REQUIREMENT:
Translate this into Spanish by staying close to the semantic structure 
and the visual metaphor. Don't try to be clever—translate the *meaning* 
literally. This is the baseline version.

Git workflow:
- Create a new branch called "tagline-v1-literal"
- Create a file called "localization-versions.md"
- Add the translation with a brief note (2-3 sentences) explaining 
  your approach and what trade-offs you made
- Commit when done

Format your entry like this:

## Version 1: Literal Semantic Translation
Spanish: [translation here]
Approach: [2-3 sentences explaining your strategy]
Trade-offs: [what you gave up to stay literal]

Claude will:

1. Create the branch tagline-v1-literal

2. Translate the tagline staying close to source structure

3. Add reasoning to localization-versions.md

4. Commit the work

What to Observe

As Claude works:

• Notice the metaphor choices (¿cómo traduce “unclutter”? ¿Desorden → desorden visual o mental?)

• Notice where literal translation starts to feel awkward in Spanish

• This version should feel accurate but maybe slightly formal or English-like

Test It

Once Claude finishes:

git log --oneline
git show HEAD
cat localization-versions.md

Version 2: Semantic Equivalent (Cryptotype-Aware)

Now prompt Claude to create Version 2 from scratch:

Great! Now create VERSION 2, which should be completely different.

VERSION 2 REQUIREMENT:
Translate the same tagline, but this time think like a native Spanish 
copywriter in Madrid. Ignore the English structure. Your goal is to 
capture the same emotional intent—clarity, focus, what matters—but using 
the semantic framings that actually resonate in Spanish.

Consider:
- Spanish has different metaphors for mental clarity than English
- Spanish copy culture tends toward different emotional anchors
- The vibe should feel native, not translated

Git workflow:
- Switch back to main branch first
- Create a new branch called "tagline-v2-native"
- Add your translation to localization-versions.md (same file)
- Commit when done

Format:

## Version 2: Native Semantic Equivalent
Spanish: [translation here]
Approach: [2-3 sentences on what Spanish copywriting instinct guided you]
Trade-offs: [where you diverged from source meaning, and why]
Vibe: [how this feels different from Version 1]

What You’re Looking For

Version 2 should feel genuinely Spanish, not just translated. It might:

• Use different metaphors (maybe about clarity/focus rather than clutter)

• Have a different rhythm (Spanish copy often prefers parallelism)

• Hit different emotional buttons (e.g., focus vs. simplification)

This version should make you think: “Oh, a Spanish copywriter would never phrase it the other way.”

Version 3: Market-Specific Remix (Audience + Vibe)

Final version. New approach:

Excellent. Now VERSION 3—the most ambitious.

VERSION 3 REQUIREMENT:
You're not just translating this tagline. You're adapting it for a 
specific Madrid-based user who is: 
- A freelance designer, age 32, high creative standards
- Frustrated by tool clutter and distraction
- Wants to feel sophisticated and in control
- Responds to clean, confident language (not overly friendly)

This isn't translation anymore—it's *copywriting from first principles* 
using the same core idea. Generate something that would make *that specific 
person* in Madrid feel: "Yes, this is for me."

Git workflow:
- Switch back to main
- Create branch "tagline-v3-audience"
- Add to localization-versions.md
- Commit

Format:

## Version 3: Audience-Specific Remix
Spanish: [translation/adaptation here]
Approach: [2-3 sentences on the copywriting strategy for this audience]
Persona reasoning: [why this specific framing works for the Madrid designer]
Vibe: [tone, confidence level, sophistication]

What You’re Looking For

Version 3 might be quite different from the English. It’s not a translation—it’s a localized rewrite. It should:

• Feel like it was written for the Madrid market, not translated into it

• Hit emotional notes that matter to that specific persona

• Use language that audience actually uses

• Potentially drop the English metaphor entirely if something else works better

Compare All Three

Now switch between branches and compare:

git checkout tagline-v1-literal
cat localization-versions.md

git checkout tagline-v2-native
cat localization-versions.md

git checkout tagline-v3-audience
cat localization-versions.md

Reflection Questions

Which version do you actually want to ship? Why?

• Does your market prefer Version 1 (trustworthy, accurate)?

• Does it prefer Version 2 (native-sounding)?

• Does it prefer Version 3 (audience-targeted)?

The answer isn’t universal. It depends on your product positioning, your market maturity, and the specific use case. The Best-of-N pattern is how you make that decision visible and defensible.

Exercise 2: UI Microcopy (Technical → Conversational → Local Idiom)

The Scenario

You’re localizing error messages and button labels for a financial app. The source is:

Button: "Confirm Transaction"
Error: "Insufficient funds in account"
Success: "Transaction processed successfully"

These are clear and technical. But they need to work across three completely different contexts: a conservative Spanish bank user, a fintech-savvy millennial, and a casual mobile user.

Can the same strings work for all three? Should they? Let’s explore three versions.

Read more

Let me back up.

I left Spain with a translation degree, and the growing realization that nobody was going to pay me decently for knowing how to carry meaning between languages. So I did what any sensible person does: I moved to the coldest, most socially encrypted country I could find. I learned Danish. Kind of. I made friends, real ones. And still, with my vocabulary growing week by week, I was lonelier than I had ever been in my life.

That’s when it hit me, and no dictionary had warned me: communication has almost nothing to do with language, and almost everything to do with an invisible architecture of social and cultural rules that nobody writes down, precisely because everyone already knows them. Everyone except you, the foreigner, standing at the party with perfect grammar and no idea what is actually going on.

So I did what lonely linguists do. I went back to school, a master’s in comparative linguistics and literature, and there, in a course with a name only academia could love, I found the thing that would quietly reorganize my brain: critical discourse analysis. The idea: every communicative act is shaping reality in a very concrete way. Not describing reality. Shaping it.

Subscribe now

A discipline born suspicious

Critical discourse analysis — its practitioners now say Critical Discourse Studies, because academics can never leave a name alone — was never a neutral science, and to its credit, it never pretended to be. It emerged in the 1980s from three suspicious traditions: Halliday’s functional grammar, which insists that every grammatical choice is a meaning choice; Foucault’s conviction that discourse doesn’t reflect power, it builds it; and the Frankfurt School’s refusal to analyze injustice politely. Fairclough gave it its engine: discourse shapes society, society shapes discourse, round and round, no beginning. Van Dijk added the mind: the mental models through which repeated framings become “common sense.” Wodak added history, because no text arrives alone.

And what does the analyst actually do? Something almost embarrassingly concrete. She notices that “protesters clashed with police” and “police beat protesters” describe the same afternoon and build two different worlds. She notices the nominalization that makes agents evaporate — the closure of the plant, as if plants closed themselves out of personal conviction. She notices the presupposition that smuggles a claim past your defenses, the modality that dresses opinion up as inevitability, the small lexical decision between migrant and expat that assigns a person their place in the moral order before a single fact has been stated. None of these choices is innocent. Repeated a few million times across front pages and feeds, they harden into what a society is willing to call reality.

The field has its critics, and it’s better for them. Widdowson famously accused CDA of finding exactly what it went looking for, one conveniently outrageous headline at a time. Fair hit. The answer came from corpus linguistics: run the analysis across millions of words, and the ideology stops being a cherry-picked anecdote and becomes a slow statistical drumbeat you can no longer politely ignore.

Then the machines arrived, speaking perfectly

And then, the machines began to write.

Here is the thing about large language models: they don’t know things, they continue patterns. What they produce is discourse in its purest laboratory form, detached from any obligation to be true. They mimic the style of authority flawlessly. Which is exactly the trick CDA spent forty years teaching people to see through.

A model trained on the world’s text inherits the world’s framings, and then does something newspapers never could: it generates them on demand, personalized, fluent, at planetary scale. The research is starting to say plainly what discourse analysts suspected from the first paragraph: these systems don’t merely reflect entrenched ideologies, they participate in shaping them. They privilege the statistical mainstream and quietly sand away the minority framing, the dialect, the inconvenient register. The bias of a model is a discourse to be read.

Which is why the bookish little discipline from my Salamanca classroom has become, without changing a single method, urgently practical. In a world where anyone can generate fluent text, fluency is worthless as a signal. The scarce skill (maybe the scarcest) is knowing what fluent text is doing: who it grants agency and who it erases, what it presupposes, whom it legitimates, which world it is quietly building while pretending only to describe one. If you’re trained in CDA, you read a model’s output the way you read a front page: not asking is this well written? but what work is this writing performing, and for whom? Prompts, evals, system cards, AI policy documents… same instruments, new corpus. You become, in effect, an auditor of meaning in an economy that has just made meaning its main industrial product.

I think often of that winter in Denmark, when I spoke the language and understood nothing, and how the loneliness sent me looking for the rules beneath the words. I didn’t know I was training for this exact moment: a world full of machines that speak every language and inhabit none of them as culturally weightless, as I was at that Danish party. Someone has to notice what they’re building with all those innocent-looking words.

The words were never innocent. Neither, thankfully, are we.

Subscribe now

Where translation memory actually earns its keep

There are contexts where a well-maintained TM is genuinely valuable: legal contracts that follow a rigid structure, regulatory documentation that barely moves between releases, clients who send the same categories of content in the same format, release after release. In those worlds, high TM leverage is a real efficiency gain, and the maintenance overhead is manageable because the content universe is small and predictable.

That is not most software companies. It is not most product teams scaling into new markets. And it is definitely not any environment where content changes every sprint.

What happens when content refuses to sit still

A translation memory is, by design, a record of the past. Every segment carries the context, the product understanding, and the terminology decisions of the moment it was created — and all three of those drift. Products evolve. Tone shifts. Features get renamed. New concepts arrive and quietly change the meaning of language you thought was settled.

The TM doesn’t know any of this. It just keeps producing matches.

And here’s the trap: the more leverage a TM produces, the more invisible the drift becomes. A 100% match gets accepted. The linguist — often on a fast-turnaround job, often with zero visual context — sees a green checkmark and moves on. Nobody is wrong to do this. The entire economic logic of TM leverage rests on the assumption that a 100% match is correct. That assumption breaks the moment the content around a segment has changed, even slightly.

Context mismatches are one of the most common root causes of localization defects I’ve seen in production. A segment that was translated perfectly in a settings screen reappears as a 100% match in an onboarding flow, where it lands completely wrong. Same string. Different meaning. Full leverage credit.

The scale problem nobody staffs for

Run a TMS across five languages with a dedicated linguist team that has native-level oversight of every market, and you can probably keep the memory clean. Run it across thirty-plus languages — not unusual for a mid-size tech company — and the real question surfaces: who is actually maintaining these assets?

Terminology updates need to cascade across every language. Bad segments need to be found, retired, replaced. Outdated glossary entries need flagging. Duplicates with inconsistent translations need resolving. This isn’t a one-time cleanup project — it’s continuous, linguistically skilled work that also requires understanding the technical structure of the assets themselves.

Almost nobody has thirty native-speaker linguistic asset managers on staff. Most teams have one or two people juggling vendor relationships, running reviews, coordinating projects, and trying to keep the TM clean somewhere in the margins of all that.

So the maintenance doesn’t happen. Not fully, not consistently. The TM grows. The errors compound. The technical debt accumulates quietly, one accepted match at a time.

The problem with pretending translation is sequential

There’s a structural issue in how TMS workflows get discussed that matters enormously in any high-velocity environment.

The classic argument for TM leverage assumes a sequential process: translate file A, close it, commit it, leverage it for file B. In reality, when a release has a deadline and there are forty files to translate, they go out in parallel and come back in parallel, committed in whatever order finishes first. A TM cannot leverage across files being translated simultaneously — and if multiple translators are working the same project without real-time TM sharing, you get exactly the inconsistencies the TM was supposed to prevent.

Worse, concordance search doesn’t fix this — it launders it. Once an inconsistency lands in the memory, concordance makes it easier to find and reuse, propagating it into future projects until someone actively hunts it down and kills it.

The concordance argument — that TMs enforce consistency — assumes a model of translation work that high-velocity product localization almost never resembles.

Read more

Here’s the distinction that actually matters, in the order these structures tend to get built.

Taxonomy: what’s a type of what

A taxonomy is a hierarchy of categories. Parent, child, sibling. “Running shoes” is a type of “footwear” is a type of “apparel.” It answers exactly one question — is this a subtype of that?. Taxonomies are easy for humans to navigate, and they’re the backbone of most e-commerce nav menus and content tagging systems.

What they can’t do is tell you why two things are related if the relationship isn’t parent-child. A taxonomy has no vocabulary for “competes with,” “is a component of,” or “is regulated by.” Everything has to be forced into an is-a tree, and real domains are rarely that obedient.

Ontology: what’s true about the concepts, and how they relate

An ontology is what you get when you take a taxonomy and give it a richer set of relationship types, plus formal rules about what’s allowed. It doesn’t just say a running shoe is a type of footwear — it can say a running shoe requires a size attribute, is compatible with certain sock materials, is manufactured by a brand entity, and cannot simultaneously belong to two mutually exclusive categories.

The defining feature of an ontology is that it encodes meaning independent of any single dataset or language. It’s a model of the domain itself — the concepts, their properties, and the constraints between them — built so that both humans and machines can reason over it consistently. This is the layer where semantic governance actually lives: define the concept once, define what’s true about it, and every downstream system inherits that truth instead of reinventing it.

Knowledge Graph: the ontology, populated

A knowledge graph is an ontology (or several) filled in with actual instances. The ontology says “a Product has a Manufacturer”; the knowledge graph says “this running shoe, SKU 4471, has manufacturer Brooks.” It’s the difference between a schema and a database — except the schema here is semantic, not just structural, so the graph preserves the relationships and constraints, not just the rows.

Knowledge graphs are what let a system answer questions no one explicitly programmed it to answer, by traversing relationships: everything manufactured by Brooks, compatible with trail conditions, currently unavailable in the EU. That traversal is only as good as the ontology underneath it.

Semantic Layer: the translation between the graph and the tools that use it

A semantic layer sits between the knowledge graph (or any underlying data model) and the applications that consume it. Its job is to expose consistent business definitions (”revenue” always means the same calculation everywhere) so that different tools querying the same underlying data don’t quietly disagree with each other.

Where an ontology defines what’s true about the domain, a semantic layer defines how that truth gets surfaced to a specific consumer, in that consumer’s terms. It’s an interface, not a source of truth, but a bad one is exactly how two dashboards end up showing two different numbers for the same metric.

Context Graph: what’s relevant right now

A context graph is the newest and least standardized of the five, and it’s the one most specific to AI systems. It’s not a static model of the domain — it’s a dynamic, situational slice of relevant entities, relationships, and state assembled for a particular task, user, or moment. Think of it as what an agent actually holds in working memory to complete this action, for this user, in this session — pulled from the knowledge graph, the semantic layer, recent interactions, and live data, then discarded or rebuilt for the next task.

If the ontology and knowledge graph are the long-term memory, the context graph is closer to attention: a temporary, task-scoped assembly of exactly what’s relevant, nothing more.

Putting them in order

• Taxonomy — categorize

• Ontology — define meaning and relationships

• Knowledge graph — populate the ontology with real instances

• Semantic layer — expose consistent definitions to consuming tools

• Context graph — assemble what’s relevant for a specific task, right now

Each layer depends on the one before it being solid. A context graph built on a shaky ontology will confidently assemble the wrong thing, fast.

Subscribe now

The multi-market complication

All of this gets harder (and more interesting) the moment you’re not operating in one market. In a multi-market ontology, a single concept doesn’t just need a term per language; it needs a term per market, because the same product can be legally unavailable, culturally repositioned, or attribute-different from one locale to the next. “Running shoe” in the US ontology might carry a widths attribute that doesn’t exist in the EU instance, because EU sizing doesn’t expose it the same way. A supplement that’s a wellness product in one market is a regulated pharmaceutical in another, which isn’t a translation problem at all — it’s a different node with different constraints, different availability, and a different compliance path, that happens to share a parent concept with its US counterpart. Get this layer wrong and no amount of downstream semantic layer or context graph sophistication will save you, because you’ll be serving confidently wrong answers in every market at once, just in the local language.

That risk is mostly gone now. Give a pipeline the right infrastructure: an i18n scanner, a real multilingual knowledge graph, market definitions that actually encode what’s shared and what isn’t, terminology governance instead of a spreadsheet, and translating a batch of new strings stops being a project. It’s minutes. It doesn’t need to leave the repo. I mean this literally, not as anything rethorical: the bottleneck I used to manage for a living has essentially disappeared.

Which is exactly the problem, because most companies haven’t noticed. They’re still pointing all their resources at the part that got solved, and none of it at the part that didn’t.

Subscribe now

The part that didn’t get solved

If I think about it, localization was never really about strings. It was about whether a Japanese user, a German user, a Brazilian user, opens the product and feels like it was made with them in mind, or feels like it was made for someone else and hastily relabeled. That feeling doesn’t come from correct grammar. It comes from an entire chain of small decisions holding together end to end. And that chain is exactly what QA is supposed to verify. It’s also what’s being undertested.

I keep seeing the same five gaps, across companies that are otherwise sophisticated about everything upstream of QA:

Testing on a costume, not a market. An en-US account with the language switched in settings is not a German user. It doesn’t have German payment methods, German address formats, German regulatory prompts, German default expectations about what a checkout flow should ask for and in what order. The account is part of the locale. Testing without it is testing a costume.

Automated visual QA without a native. Screenshot diffing will catch a truncated button and an overflowing modal. It will not catch a phrase that’s technically correct and reads as cold, or pushy, or slightly childish, in a way only a native living in the target market could understand. It’s a judgement only a native speaker can make, and not amount of pixel comparison substitutes for it.

Testing the screen instead of the journey. Website, purchase, install, auth, first run. Every handoff between those touchpoints is a seam, and locale drops silently at seams: a payment processor that reverts to English mid-checkout, a confirmation email in the wrong date format, and install wizard that forgets what language you started in. One broken seam undoes everything that was done right upstream of it. And most test plans are built screen by screen, so the seams never get checked at all.

No test cases tied to what actually changed. “We ran the regression suite” is not the same claim as “we covered the new strings.” Without a direct line from newly added or changed strings to specific test cases, coverage is a story someone tells to themselves, not a measurement.

FAIL without a cause. Something fails, it gets logged, and it goes in a bucket labeled ‘localization is buggy’. But why it failed determined who fixes it and how: was it i18n (the code cannot properly support the locale?), L10N (the translation is wrong, and if it is wrong, why?), design (the string doesn’t fit the layout), or linguistic-cultural (the translation is correct and still wrong for the audience)? Skip that classification and you can’t route the fix, and you definitely can’t spot the pattern the third or fourth time it happens.

I think this is an infrastructure problem

None of this is an argument for going back to manual, everything by-hand testing. It’s an argument for pointing automation and human eyes to the right layers, instead of using automation as an excuse to remove human judgement from the layer that still needs it.

Automate the mechanical layer as hard as you can: visual regression, string coverage tracing, build verification across locales, the parts that are pattern-matching. That’s the same instinct that made the translation pipeline fast in the first place: don’t spend a human’s attention on something a system can check reliably.

But the experience layer: does this feel right, does this journey hold together, would a real person in this market trust what they are looking at? That’s not a coverage percentage. It’s a human call, and it requires eyes that actually belong to the market: someone who can feel when something’s off, not just confirm that nothing’s technically broken.

So what’s my point

Localization is solved. I’ll keep saying that, because I mean it structurally, not as a hot take: with the right language infrastructure in place, the translation step is no longer where the risk lives. What deserves the time and the budget, the headcount, the attention, is the international user experience. Whether the whole thing, watched end to end by someone who lives in that market, actually holds together.

That’s a much harder thing to build a dashboard for. It’s also the only thing left worth testing.

We ask, “did a person write this, or a machine?”, as though writing were a single act, done by a single agent, that could be assigned to one side of a line or the other. But writing was never one act. It only felt that way because, until recently, one skull happened to contain all the agents involved.

Consider what actually has to happen for a post like this to exist:

Something has to know things: has read the papers, built the pipeline, argued in a meeting, noticed a pattern nobody named yet.

Something has to want to say them: has decided this particular knowledge, out of everything known, is worth someone else’s ten minutes.

Something has to organize them: decide what comes first, what can wait, what’s a detour.

Something has to phrase them: choose this word over that one, this rhythm over that one.

Something has to judge the result: read it back and decide whether it’s actually any good.

For most of history these five agents lived in the same head, so we never had to ask which one deserved the credit. We just said “the writer wrote it” and moved on. But the agents were always separable in principle — a ghostwriter has always split knowing/wanting from phrasing; an editor has always been an outsourced version of judging. Nothing about a mind requires that all its parts live in the same body. That was always an accident of biology, not a law of thought.

In my own case, the split is simply more visible than usual. I supply the first two agents entirely: the knowing and the wanting. Claude and I share the third — organizing — in a long conversation where I offer sources and it offers others, where we sometimes build the very thing the post will later describe: a script, a pipeline, a terminology system, some small object that didn’t exist an hour before. The fourth agent, phrasing, I hand over almost completely: I don’t experience much loss in this, because for me the phrasing was never where the meaning lived. And the fifth, judging, comes back to me: I read what it wrote, and I keep only what survives the reading.

Fiction is different, and worth noting exactly why: there, the phrasing agent and the knowing agent are the same agent, doing the same job at the same moment — you can’t know what a sentence means, in fiction, until you’ve found its exact words. That’s not true of an explanation. An explanation can survive a thousand different phrasings and still be the same explanation. So I keep fiction’s phrasing agent as myself, and I subcontract this one’s, freely, without feeling that anything essential has left the building.

None of this should be surprising to anyone who has thought carefully about what a mind even is: a mind was never a single thing to begin with. It was always a society of smaller processes, cooperating, sometimes badly, to produce something that only looks unified from the outside. I’ve simply let one member of that society live outside my skull. The society still works. The ideas are still mine: mine in the sense that matters, which is that I chose them, wanted them said, and would stand behind every one. Whether the sentence that carries an idea was assembled by a neuron or a network was never, on reflection, the interesting question.

The interesting question was always just: is the idea any good?

I think it stopped making sense a while ago, and most of us kept using it anyway because replacing infrastructure is expensive and the old infrastructure still technically works. But “technically works” is a low bar when the unit of localization work has changed. A translation memory answers the question “have we translated something like this before?” It has nothing to say about why a term is approved, what a market’s tone should be, or whether a placeholder needs to move to a different position in the sentence because Spanish resolves it differently than English does. That knowledge has always lived in people’s heads, in style guides nobody reads end to end, in Slack threads that get lost. A TMS was never built to hold it, because when TMS architecture was designed, it didn’t need to — a human translator was always in the loop to supply it from memory.

Take that human out of the loop — which is what’s actually happening, whether we’ve formally decided it should or not — and you notice the gap immediately. An LLM can produce fluent Spanish in about a second. Fluent isn’t the problem anymore. Correct, on-brand, and governed is the problem. And that’s not a translation problem, it’s an infrastructure problem: you need somewhere for the terminology decisions, the market definitions, and the governance rules to live as structured, queryable knowledge — not as a PDF style guide that an LLM half-remembers from training data.

That’s the rebuild I’ve been working on. Not a better translation step. A different pipeline entirely:

Read more

Terminal looks like it was built for people who already know what they’re doing. But the truth is almost the opposite: the terminal only feels like the deep end because nobody showed you where the shallow end is. You don’t need to memorize hundreds of commands. You need a small, fixed set, and you can learn all of it in one sitting.

Part 1: Finding out where you are

pwd — “print working directory.” Every terminal session drops you somewhere on your computer, and you can’t always tell where just by looking. Typing pwd prints your exact location, e.g. /Users/yourname. That’s your home folder — where nearly every session begins.

ls — lists everything in your current folder, files and subfolders together. Add the -F flag (ls -F) and it labels folders with a trailing /, so you can tell at a glance what you can move into versus what’s just a file. This one flag — a modifier tacked onto a command with a dash — is your first taste of a pattern you’ll see everywhere: command -flag.

Part 2: Moving around

cd foldername — “change directory.” cd Documents moves you into Documents; run pwd again and you’ll see your location updated. Notice your prompt itself changes too — most terminals show your current folder right there, so you rarely even need to ask pwd twice.

cd .. — two dots mean “the folder that contains this one.” It’s your reverse gear.

cd alone, or cd ~ — teleports you straight back home from anywhere, no matter how deep you’ve wandered.

One thing worth naming explicitly here: Documents in cd Documents is a relative path — relative to wherever you currently are. /Users/yourname/Documents is an absolute path — it works no matter where you’re standing, because it starts from the very top (/). Both work with cd; absolute paths are just more reliable when you’re not sure where you currently are.

Part 3: Making and organizing things

mkdir foldername — creates a new, empty folder. This is the first moment the terminal stops being read-only for you — you’re not just looking around anymore, you’re changing things.

touch filename.txt — creates a new, empty file. Handy for quickly making a file to edit later, or for testing that a command worked.

cp source destination — copies a file. cp notes.txt notes_backup.txt makes a duplicate in the same folder; cp notes.txt Documents/ copies it into another folder.

mv source destination — moves a file, and it’s also how you rename things, since “move it to a new name in the same place” and “rename it” are the same operation to a computer. mv notes.txt Documents/notes.txt moves it; mv notes.txt final_notes.txt renames it.

rm filename — deletes a file. This is the one command on this whole list that deserves real caution: there’s no Trash, no “Are you sure?”, no Undo. Deleted from the terminal means gone. Never run rm on something you haven’t double-checked with ls first, and be especially careful with rm -rf (which deletes folders and everything inside them, forcefully) — that combination is infamous for a reason. If you’re ever unsure, don’t run it.

Part 4: Looking inside things

cat filename — prints a file’s entire contents straight into your terminal. Great for quickly checking what’s inside a small file (like a .json or .txt) without opening an app.

clear — wipes your terminal screen so you’re looking at a clean slate. Doesn’t undo anything you’ve done — just clears the visual clutter.

Part 5: The habits that make everything faster

Tab completion. Start typing a file or folder name and hit the Tab key — the terminal will try to finish it for you. This alone eliminates most typos and is the single biggest quality-of-life habit to build early.

The up arrow. Pressing ↑ c

man commandname (or commandname --help) — pulls up the manual for any command, listing every flag it accepts. When you forget what ls -F does, or want to know what other flags exist, this is where you ask the terminal instead of the internet.

open filename or open . (Mac-specific) — opens a file or folder in its normal graphical app, or opens the current folder in Finder with open .. This is a nice bridge command: it lets you jump from the terminal back into the visual world you already know.

Why any of this matters for Claude Code

Claude Code lives in this exact window. When it talks about “your current directory,” references a file by path, or asks you to run something, it’s speaking in the vocabulary above — pwd, ls, cd, cp, mv, rm, absolute vs. relative paths. None of that is Claude-specific knowledge; it’s just how every terminal on every computer has worked for decades. Once these dozen or so commands are reflexes instead of a foreign language, the fear of the blank prompt disappears — and what’s left is just a fast, precise way of telling your computer exactly what you want.

The secret is that professional developers don’t have some vastly bigger toolkit running in their heads at all times either. They’ve built up this same small set of reflexes over years, one command at a time — the exact way you just did in one sitting. The blinking cursor isn’t hiding complexity from you. It’s just waiting for you to type the next thing you already know.

More on Claude Code:

[Claude Code: A super simple guide]

[Practice Makes Claude Perfect]

[Claude Code, for the pros]

That enemy is dead. Most of the industry hasn’t noticed yet.

Subscribe now

Origin story

Xerox PARC. A linguist named Martin Kay writes a paper nobody outside computational linguistics reads at the time, arguing translators shouldn’t waste their genius on the mechanical parts of the job — let the machine hold the boring half, let the human keep the art. Ahead of its time by about forty years.

The 1980s try to build it and mostly fail. Too early. The hardware isn’t there.

Early ‘90s: it works. IBM, Star, Eurolang, Trados — four systems land almost simultaneously, and suddenly a translator’s past decisions live in a database instead of a filing cabinet. Translation memory is born, and it is genuinely brilliant, because it solves the actual bottleneck of its era: human translation is the scarce resource, so stop burning it on a sentence you’ve already paid to translate once.

Everything after that is armor stacking on armor.

LISA. GALA. TMS platforms. The 2005 shockwave — SDL swallows Trados, Lionbridge swallows Bowne — and an entire generation of language service providers gets built on the logic of the vendor chain: client, LSP, subcontractor, freelancer, each layer adding coordination because the actual translation work upstream was too precious to risk. String-key extraction, so content could leave the product and land in a spreadsheet or a workbench a translator could actually work. QA gates built to catch placeholder bugs and broken variables — not because “does this feel natural” didn’t matter, but because nobody building the QA process had the AI-era luxury of asking that question at scale.

Every piece of it was the correct answer to: translation is slow and expensive, protect it.

The enemy is gone

LLMs didn’t improve translation. They deleted the bottleneck the entire industry was built around.

And once that bottleneck is gone, the whole cathedral of process stops making sense. Because it was built to defend a resource that isn’t scarce anymore.

Here’s the part I actually believe:

The moment English content lands in the repo, it should already exist in every target locale. Not “queued for translation.” Not “scheduled for the next localization sprint.” Exists. Same commit. Same CI run. English merges, and German, Japanese, Brazilian Portuguese, Spanish are already sitting there, correct, on merge.

That is not science fiction. The pieces exist right now:

• An LLM that can read the string, the surrounding UI (hello Figma MCP), the screenshot, the design tokens — and generate a first-pass translation that’s already context-aware, because it isn’t working from an isolated string in a spreadsheet the way a human translator was forced to for thirty years.

• A semantic governance layer sitting above generation — not a QA gate that catches mistakes after the fact, but a constraint the AI has to satisfy while it’s writing. This is the part the old model never had a mechanism for, because TM only ever knew how to enforce “same source string, same target string.” It had no concept of market.

• Market definitions — real, structured, computable market definitions — that tell the system: in this locale, this concept takes this term, this tone, this register, and this is the one that’s explicitly forbidden. Not a style guide a human reads once and half-remembers. A layer the AI is generating inside of, every single time.

Put those three things together and you don’t have “faster localization.” You have localization that isn’t a separate process anymore. It’s a property of the build.

What actually dies

Let’s be precise about what’s getting killed here, because it isn’t the linguist.

It’s the process. And this industry has one very reliable move: every time it hits a problem, it doesn’t remove a step, it adds one. A CMS to hold the content. A QA check to police the CMS. A vendor to manage the QA check. A product manager to manage the vendor. Extract, export, assign, translate, review, import — and now a Slack channel and a spreadsheet and a status meeting to manage all of it. Thirty years of that instinct, stacked on itself, is the “ecosystem” this industry calls normal. That’s what’s getting killed. Not the linguist. The tower of process built on top of them.

The linguist’s eyes move. The linguist doesn’t disappear.

What doesn’t survive: a linguist spending their day converting English sentences into Spanish sentences, one string at a time, in a tool that shows them a segment and nothing else.

Here’s what does: a linguist who curates the knowledge graph the model actually grounds itself in. That’s the real job now — not translating, teaching. Feeding the semantic layer the concepts, the distinctions, the “this word, not that word, in this market” judgment calls that no amount of scraped web text hands a model on its own. The linguist becomes the person who builds and maintains the thing the AI is constrained by, instead of being the thing the process grinds through.

And past that — this is the endpoint I actually want — translation as an act mostly disappears from a linguist’s day entirely. What’s left is better work: sitting with the real product, in the real market, checking whether the actual artifact — not a string in a spreadsheet, the actual screen a real user in Tokyo or São Paulo is going to tap — genuinely lands. Writing and refining the market definitions themselves, the guidelines the whole system runs on, so the semantic layer gets sharper every cycle instead of sitting there static.

That’s not de-skilling the linguist. That’s finally letting them do the part of the job that was always the real expertise, instead of the part a database lookup could do faster.

The industry didn’t get it wrong for thirty years. It got it exactly right, for thirty years, for a world where fluent translation was the scarce, expensive thing.

That world ended. The content should know it the second it hits the repo.

Good terminology work is concept-oriented, not word-oriented. You’re not building a glossary of vocabulary. You’re building a map of the ideas your organization needs to name consistently, and then attaching the right labels to them. That shift, from words to concepts, is the whole game.

The concept comes first

Here’s the discipline that separates a termbase from a word list: define the idea before you name it.

A concept is a unit of knowledge — an abstract thing your field or company cares about — that exists independently of whatever word you happen to use for it. “The rotating component that transfers torque from the motor” is a concept. Shaft, spindle, drive rod are terms that might point to it. When you lead with the concept, you can see immediately whether three words are three ideas or one idea with a naming problem. Lead with the words and you’ll never notice the difference.

This is also why quality beats quantity every time. A tight set of well-researched concepts, each clearly defined and validated, does more work than a bloated database padded with generic, redundant, or self-evident entries. Nobody needs “computer” in the termbase. They need the twelve concepts your industry argues about.

What actually belongs in a termbase

Not every word earns a spot. Target the units of knowledge where precision is mandatory and ambiguity is expensive:

• Technical terms specific to your domain, where a wrong synonym causes real errors.

• Core product names and feature names that must stay identical everywhere.

• Brand identifiers — trademarked phrases, taglines, names with legal or stylistic weight.

• Industry jargon where your usage differs from a competitor’s or the general meaning.

If a word is everyday language used in the everyday way, leave it out. It’s noise.

Selecting concepts, step by step

1. Audit existing content. Go through manuals, string files, product guides, help docs, and marketing assets and hunt for the places where terms drift — where the same thing gets three names, or one name covers three things. Those friction points are your candidate list. You’re not inventing concepts; you’re catching the ones already causing confusion.

2. Isolate high-value targets. From that list, prioritize ruthlessly: trademarked phrases, interface labels, and the recurring technical pain points that generate support tickets and translation queries. High risk plus high frequency equals high value.

3. Map relationships. A concept doesn’t live alone. Place it in a structure — what’s the broader category above it, the narrower types below it, the concepts it’s often confused with? This is what makes a termbase a knowledge system instead of a flat list, and it’s how you catch gaps and overlaps you’d otherwise miss.

4. Consult your experts. Bring in the internal subject-matter experts to confirm each concept is genuinely distinct, actually necessary, and accurately defined. They’ll tell you when two of your “concepts” are the same thing, or when the definition you wrote is subtly wrong. This validation is what earns the termbase its authority.

Does this concept actually deserve an entry?

Auditing and prioritizing hands you a pile of candidates. The next job is the one people skip: deciding which of them are real. Most candidates fail at least one of these tests, and that’s fine — the goal is a termbase you can trust, not a big one. Run each candidate through the following filters, roughly in order.

Uniqueness — is this a distinct concept, or a duplicate wearing a different coat? This is the first and most important gate. Before anything enters, check whether the concept already exists under another label. If two candidate terms point at the same unit of knowledge, you don’t have two entries — you have one concept with a synonym problem, and the fix is to record both terms under the single concept, not to create a second entry. The failure mode here is subtle: near-synonyms that feel different but denote the same idea. If you can’t articulate a real difference in meaning, there isn’t one.

Distinctiveness — can it be told apart from its neighbors? Uniqueness asks “is this a duplicate?”; distinctiveness asks “does it have a clean boundary?” A concept earns its place only if you can draw a line between it and the adjacent concepts it’s easily confused with. If every attempt to define it bleeds into the concept next door, either the boundary is real and you haven’t found it yet, or the two aren’t actually separate. This is exactly what mapping relationships surfaces — the confusable pairs jump out once concepts sit next to each other.

Necessity — does getting this wrong cost anything? A concept can be perfectly unique and still not worth an entry. Ask what breaks if it’s absent: does a translator guess, a support ticket get filed, a legal risk appear, a product string mismatch the UI? If nothing breaks, it’s a definition in search of a problem. Consistency only matters where inconsistency has a price.

Stability — is the meaning settled enough to pin down? If a concept is still being actively argued over internally, an entry freezes a fight rather than resolving it. Either wait for the meaning to settle, or record it explicitly as provisional so nobody treats a moving target as fixed.

Reusability — will this come up again? Terminology work pays off through repetition. A concept that appears once, in one document, rarely justifies a permanent entry. Recurrence across content, products, or languages is what turns a word into an asset worth governing.

A quick way to hold all of this together: a candidate belongs in the termbase when it is unique (not already there under another name), distinct (cleanly bounded against its neighbors), necessary (costly to get wrong), stable (settled enough to define), and recurring (worth the upkeep). Miss uniqueness or necessity and the entry is usually noise. Everything else can often be fixed with better definition work rather than rejection.

Writing a definition people will actually trust

A definition isn’t a dictionary gloss. Its job is to pin down exactly this concept and distinguish it from every neighbor. A few rules that hold up:

• Define the concept, not the word. Describe the idea, not the grammar of the label.

• Use the genus-and-difference shape: state the broader category it belongs to, then the feature that sets it apart from siblings in that category. “A [broader thing] that [distinguishing feature].” This single pattern prevents most bad definitions.

• Don’t be circular. A definition that reuses the term to define the term explains nothing.

• One concept, one definition. If you need “or” to hold your definition together, you probably have two concepts.

• Match the scope to your domain. Define the concept as your field uses it, not in the fullest possible abstract sense.

A good test: hand the definition to someone and see if they can tell your concept apart from the one next to it. If they can’t, tighten it.

A term approval workflow that won’t collapse

A termbase is only as trustworthy as the process that lets entries in. Keep the workflow light enough that people follow it and strict enough that it means something. A workable path from proposal to production:

1. Propose. Anyone can nominate a concept — flagging where confusion showed up and offering a draft term and definition. Low friction here keeps the pipeline fed.

2. Research. A terminologist checks whether the concept already exists under another label, gathers real usage from your content, and drafts or refines the definition and any relationships.

3. Validate. A subject-matter expert confirms the concept is distinct, necessary, and correctly defined. This is the technical gate.

4. Approve. A designated owner gives the entry its status. Until this step it’s a candidate, not a term to be used.

5. Publish. The approved entry goes live to writers, translators, and tools — with its status clearly marked so everyone knows it’s binding.

6. Review. Set a cadence to revisit entries. Products change, meanings drift, and a term that was right last year can quietly go stale.

The key idea is status, not just presence. Every entry should carry a state — proposed, under review, approved, deprecated — so people know what they’re looking at. A term in the database isn’t automatically a term you should use; only an approved one is. That single distinction is what keeps a growing termbase from rotting back into the word-dump you were trying to avoid.

Terminology management, done right, is the deliberate curation of the concepts your organization can’t afford to get wrong, defined once, agreed on by the people who know, and governed by a process everyone trusts. Start with the idea. The words follow.

I never stopped being fluent in Spanish. Fluent in everything else. The timing of dinner. The volume of a normal conversation. The correct number of kisses. The knowledge that when someone says ahora they mean sometime before nightfall, probably. For eleven months of the year I run all of this through a translation layer. Then I land, and the layer switches off, and for about forty-eight hours the relief is physical. Nobody here asks me to repeat myself. My jokes land at native latency.

This is the part of the expat return that everyone writes about, so I’ll keep it short: yes, it feels like taking off shoes that were half a size too small. You didn’t even know they were too small. That’s the trick of living abroad, the discomfort is so constant it stops registering as discomfort and starts registering as personality.

The part people write about less is day three.

Day three is when I catch myself getting annoyed at things I grew up inside of. The bureaucratic phone call that requires three transfers and ends with “you have to come in person.” The dinner that starts at ten and the opinions about my life that arrive unrequested. The noise — my God, the noise. I used to be this noise. Now some Nordic firmware I didn’t consent to installing flags it as a violation.

The annoyance isn’t really at Spain. It’s at the discovery that I’ve changed without signing off on the change. Somewhere between Copenhaguen and Cork, a committee I was never invited to rewrote parts of my defaults. I only find out which parts when I come home and they throw errors.

The verb gives it away

Volver doesn’t actually mean “to return.” Or rather, it does, but that’s not what the verb is doing underneath. Volver comes from the Latin volvere — to turn, to roll, to revolve. It’s the same root as revolver and vuelta. The English “return” pretends you can go back along the same line you left on. The Spanish verb is more honest: you come back turned. Rotated some number of degrees. Same coordinates, different orientation.

Gardel’s tango insists that twenty years is nothing. Twenty years is not nothing. Neither is eleven. The tango is beautiful precisely because it’s wrong.

So every summer vuelvo and I am slightly rotated, and Spain has rotated too, new slang I have to reverse-engineer from context, prices I gasp at like a tourist, a political conversation whose reference points I’ve half lost. We are two systems that keep drifting apart between syncs, and once a year we attempt to merge, and there are always conflicts, and some of them can’t be resolved automatically.

Where are we supposed to belong?

The standard answers to this question are all cope, and I’ve tried them all.

“You belong in both places.” No. Belonging isn’t additive. In Ireland I’m the Spanish one; in Spain I’m the one who left. Both labels are affectionate and both are a door held politely ajar rather than open.

“You belong nowhere, and that’s freedom.” This one is popular with people who’ve been abroad for two years and still find it romantic. Ask again at year ten, in February.

“Home is a feeling, not a place.” Home is very much a place. That’s the whole problem. If it were only a feeling, I could carry it through customs.

The answer, I think, is that “belonging” is not a location property at all. It’s a compatibility question, and compatibility degrades. Every year abroad, you patch yourself against a different environment. Every patch makes you run better there and slightly worse here. There’s no version of you that runs natively on both systems anymore. There hasn’t been for years. The summer visit is just the annual test that confirms it.

This sounds bleak and I don’t experience it as bleak. What I’ve stopped doing is treating the incompatibility as a bug to fix, as if with enough visits, enough effort, enough authentic reconnection with my roots, I could reconcile the branches. I can’t. The fork happened the day I left. Everything since is divergent history.

It comes out about eleven minutes in, when someone has to actually do something with the tools in front of them.

Suddenly the “Head of Global Innovation Strategy” is squinting at a prompt box like it just insulted their family. Meanwhile the person whose title is just “Localization QA, Tuesdays” is quietly shipping three iterations before lunch and has already caught two hallucinated product names.

This is the tell. Not the title.

Subscribe now

Titles describe where you sat. Fluency describes what you can move.

A title is a snapshot of a negotiation that happened in the past, what HR could approve that quarter, what budget existed, what sounded impressive in a board deck next to a stock photo of a handshake. It tells you almost nothing about whether someone can take a messy, ambiguous problem and actually push it forward today, with the tools that exist today.

AI fluency is brutally current. It can’t be inherited from a past role. It can’t be implied by seniority. You either know how to decompose a problem into something a model can chew on, or you don’t. You either understand why your output is mediocre and can fix it, or you blame the model and move on to complaining about it in a meeting.

Let’s name names. Job-shaped names, anyway.

The Senior Program Manager whose entire value proposition was translating between teams who couldn’t otherwise talk to each other. Except now the engineer can just ask the model to explain the API in plain English, and the designer can ask it to explain the constraint in design terms, and suddenly the translation layer that justified the title isn’t load-bearing anymore. The PM who survives this is the one who became a translator of judgment, not just vocabulary.

The “10 Years of Experience” Localization Manager who still reviews machine translation output the same way they reviewed it in 2014 — string by string, with the same checklist, completely unaware that the failure modes have changed entirely. Ten years of experience doing the wrong review process is not experience. It’s repetition with a tenure bonus.

The Marketing Director who insists every piece of AI-assisted copy gets “a human touch” pass, but can’t actually articulate what that means beyond “make it sound less robotic” — because they’ve never sat down and learned why AI copy sounds the way it does, what specifically to fix, or how to prompt their way around it in the first place. The human touch becomes a vague tax on the workflow instead of an actual skill.

The Engineering Lead who bans AI tools company-wide after one bad experience with a hallucinated dependency, instead of doing the much harder, much less title-flattering work of teaching the team how to verify output. Banning the tool protects the lead from ever having to admit they don’t know how to use it well themselves.

None of these are bad people. Most of them are smart, capable, hardworking. But the title was never the thing keeping the work moving, and now that the tools have changed, the gap between “what the title implies” and “what the person can actually produce, today, in front of you” has never been more visible, or more uncomfortable.

The fluency tell shows up in specific, almost embarrassing ways.

None of this shows up on a resume. All of it shows up in the first real working session, which is exactly why so many people are quietly terrified of working sessions becoming the new interview.

Smart companies have started noticing this.

A “Director” who needs forty-five minutes and three Slack messages to get a usable first draft is not actually more valuable than the person two levels below them who gets there in four minutes flat, and knows exactly why it’s good, and can explain the one part that still needs a human eye.

Impact doesn’t scale with title. It scales with how fast someone can move from “I have a vague, annoying problem” to “I have a real, working answer,” and how much judgment they apply in between. The title was supposed to be a proxy for that. It increasingly isn’t. The grandiloquence stayed; the correlation didn’t.

So what’s the actual signal?

Not “have they used AI.” Everyone’s used AI. Even your uncle who still calls it “the chatbot” and asks it to write his out-of-office message has used AI.

The signal is whether they’ve developed taste, whether they can tell good output from confident-sounding garbage, whether they’ve built an actual mental model of where these tools are strong and where they quietly fall apart, and whether they’re getting faster and better over time, or just running the same shallow prompt pattern on repeat since last March because it worked once and nobody made them improve.

That’s not a credential. It’s a practiced skill, accumulating in real time, completely indifferent to what your business card says, or how many words are on it.

The companies that figure this out first get an unfair advantage: they start promoting and hiring on demonstrated movement instead of declared seniority. The ones that don’t will keep being quietly baffled about why their “leadership” can’t move at the speed their juniors already do, and will keep mistaking the confusion for a tooling problem, instead of the org-chart problem it actually is.

I didn’t move on.

There’s a particular feeling — I don’t have a word for it in English, though Spanish gets closer with desasosiego — when data shows you something that retroactively makes every decision of the past five years look slightly absurd. Not wrong, exactly. Just built on a ground that turned out to be thinner than anyone thought.

That’s where I’ve been sitting tonight.

Share

The OS locale of a device is, in a very literal sense, the language a person chose for themselves. Not the country their IP resolves to. Not the market their purchase was attributed to. Not the region their billing address sits in. The language they picked, deliberately, when they set up their device. The language in which they read system notifications and error messages and the little tooltip that appears when they hover over a button.

It is the closest thing software has to a person saying: this is how I move through the world.

And most localization strategies have never looked at it.

So let me tell you what I found when I did.

Nearly half of devices in Latin America are running es-ES. Spain Spanish. Not es-MX, not es-419, not any of the regional variants that localization programs spend considerable energy debating. The Spain locale. Set on a device in Mexico City or Bogotá or Lima.

Sit with that for a moment.

We’ve been having very sophisticated conversations about the linguistic differences between es-ES and es-MX — the vosotros that nobody uses in Latin America, the vocabulary gaps, the register differences, the eternal debate about whether ordenador or computadora is the right call for a given market. And meanwhile, a substantial portion of the users we’re serving in those markets have a device that told our product: Spain.

The causes are not mysterious once you look for them. They’re just invisible until you do.

Android, for most of its history, shipped with a single Spanish variant in its OS settings. One Spanish. If you were a user in Colombia setting up an Android device five years ago, you didn’t choose es-ES because you felt an affinity for Castilian Spanish. You chose it because it was the only Spanish on the list. The granularity that localization teams take for granted — the careful distinction between variants — simply didn’t exist at the OS level for a large share of the Android install base.

Then there are the devices that travelled. Europe has been exporting second-hand hardware to Latin America for years — refurbished phones, repurposed corporate laptops, hand-me-down tablets sent to family. Those devices arrive pre-configured. The locale is already set. The user inherits it, and often never changes it, because changing system language settings is not an obvious action, and there is no moment in most software onboarding flows that invites them to reconsider.

And then there is simply inertia. A device set up once, in whatever locale was available or defaulted to, persists. Users don’t audit their OS settings. They live in them.

The pattern doesn’t stop at Spanish.

India is running en-US at a scale that should make every English-language localization decision uncomfortable. India has hundreds of millions of English-speaking users — English is a language of education, professional life, upward mobility — and a significant share of those devices are configured with the American locale. Not en-GB, not en-IN if it exists in their device settings at all. en-US. Because that was the default, or the most available option, or the inherited configuration of a device that passed through someone else’s hands first.

The same phenomenon appears across non-native English-speaking markets globally. Devices in Southeast Asia, in the Gulf, in parts of Africa — running en-US not because the user is American or even particularly oriented toward American cultural norms, but because the OS options were limited, the default was set, and nobody ever asked them to revisit it.

Which brings me to the mismatch that actually keeps me up at night.

When a product ships a culture ID to a device — the locale it uses to format dates, currencies, sort orders, measurement units — it typically makes that decision based on either the OS locale signal or an internal market mapping. And when those two things don’t agree, the product is making a silent choice on behalf of the user. A user whose device says es-ES but who is sitting in Guadalajara is receiving either the Spain configuration or whatever the product’s fallback logic produces. Either way, something is slightly wrong. And slightly wrong, at 8.6 million devices, is not a small problem.

So what should the fallback hierarchy actually be?

The honest answer is that there is no clean one-size answer, and the fact that most products have never interrogated this is part of the problem.

Device OS locale is the most intentional signal — the user chose it, however imperfectly that choice was constructed. It deserves weight. But it is corrupted, at scale, by the structural issues above: limited OS options, inherited device configurations, the Android single-Spanish legacy.

Product culture ID based on market/country mapping is a reasonable proxy but it assumes country of deployment equals linguistic context, which the data flatly contradicts.

IP or country code is the least reliable of the three for linguistic decisions. It tells you where the device is. It does not tell you what language that person thinks in.

The most honest solution — the one that actually respects user agency — is something most products avoid because it introduces friction: ask. An onboarding screen. A language preference step. Not buried in settings, not inferred from a signal the user never knowingly produced, but an explicit moment where the product says: you are in Mexico, your device is set to Spain Spanish — is that what you want?

That screen would surface something real. It would give users a chance to correct a configuration they may not have known was wrong. It would produce a consent-based locale signal that is worth infinitely more, as a localization input, than any downstream inference.

The reason it doesn’t happen more often is that product teams treat language preference as a known variable. The data says it isn’t. It’s an assumption that has been compounding, quietly, for years.

I’m a linguist by training. I came to engineering sideways, through localization, through a growing suspicion that the interesting problems were in the infrastructure and not just the strings. And there is something particularly strange about sitting here, at nearly midnight, reading numbers off a screen and feeling the ground shift under five years of accumulated professional certainty.

Borges wrote about maps that became so detailed they were the same size as the territory they described. We have the opposite problem. Our maps are far too small — they flatten entire linguistic realities into a single country code, treat a language as if it were a place, confuse the accident of where someone bought a product with the much more intimate fact of what language they think in.

The data was always there. The query was not complicated. We just never ran it.

If you work in localization — if you make decisions about which locales to support, which variants to maintain, which markets to prioritise — and you have never had access to OS locale data at the device level, broken down by geography: you are working without your most important instrument.

Ask for it. Demand it, if you have to. Learn enough SQL to go get it yourself if nobody will give it to you.

What you find might not be comfortable. That discomfort is information.

It is, in fact, the most important information you have.

The AI-Ready Localizer is written by a localization engineer who spends too much time in data pipelines and not enough time sleeping. If any of this resonates, the subscribe button is right there.

Subscribe now

It happens after design has finished mocking something up in Figma, and before an engineer has written a single line of implementation code. It is typically a 60-to-90-minute meeting. It involves a designer, one or two frontend engineers, maybe a product manager. It is not on most people’s radar. It is, from a localization standpoint, the most important meeting in the entire product lifecycle.

Subscribe now

This post is about why that is true, what is changing as AI reshapes the handoff itself, and why any localization leader who is not fighting for a seat in that room is leaving the hardest problems to be discovered too late, at the worst possible cost.

What the handoff actually is

To understand why the handoff matters so much for localization, you need to understand what it is trying to accomplish.

When a designer completes a screen or a component, the artefact they produce — a Figma frame, a prototype, a spec — contains decisions that are partially encoded and partially implicit. The layout is explicit. The typography is explicit. What is not explicit is the reasoning behind every constraint: why that button label is two words, why that text container is that width, why that notification string is phrased as a statement rather than a fragment.

The handoff meeting is where the designer explains the implicit decisions to the engineer. The engineer pushes back on what is technically difficult. Compromises are negotiated. The spec gets annotated. Implementation begins with shared understanding, or at least, with less misunderstanding than would otherwise exist.

The designer is encoding meaning into a format that the engineer must decode and re-encode in a different medium. Every step in that chain introduces opportunities for something to be lost.

Why the handoff is where localization debt is born

Most localization issues that surface in QA, in linguistic sign-off, or worse — post-launch — were not created at translation time. They were created at design time and survived through the handoff undetected.

Here is a non-exhaustive list of what gets hardcoded, inherited, or overlooked in the handoff that later becomes a localization problem:

String concatenation. An engineer sees a label like “Sort by: Relevance” and builds it as two variables joined at runtime. The colon and the space feel like formatting, not syntax. In many languages, they are syntax — the word order inverts, the particle changes, the connector is language-specific. Concatenation breaks translation because it assumes the grammar is in the middle.

Fixed-width containers. German is 30–40% longer than English on average. Finnish can be 50–60% longer. A button that fits “Continue” perfectly in an 80px container will truncate “Weiter” and fail to render “Jatka” entirely. When an engineer builds a fixed-width container because the design shows a fixed-width container, they are not making a mistake — they are faithfully implementing what was handed to them. The mistake was made when no one in the handoff asked: what happens when this string is twice as long?

Hardcoded dates, currencies, and units. Date formats are the most well-known localization failure mode, but they are far from the only one. Number formatting (period vs. comma as decimal separator), currency placement (symbol before or after the amount, with or without space), measurement units — all of these are frequently left as implementation details, resolved by engineers using whatever defaults their framework provides, which is usually the locale of the developer writing the code.

Directional assumptions. RTL is obvious, but it is the visible tip of a much larger iceberg. Directionality affects not just text rendering but icon semantics (a back arrow in Hebrew points right), layout mirroring logic, and animation direction. Designs that are built without RTL consideration pass through handoffs that don’t flag it because the designer assumed LTR and the engineer implemented what they saw.

Invisible string decisions. Truncation behaviour. Placeholder text. Error messages. Toast notifications. Empty states. These are often not fully specified in design. Engineers fill the gaps using whatever seems reasonable. “No results found” versus “No results” versus “Nothing here yet” is not just a copy decision — it is a translatability decision, because those three strings carry different syntactic structures that do not behave the same way across languages.

Context starvation. A string exported as “Done” could be a button label, a success state, a column header, or a tooltip. Without context, a translator working in a TMS with no rendering preview is making a probabilistic guess. Engineers and designers both know what “Done” refers to. Neither of them thinks to record it, because to them it is obvious. It stops being obvious the moment it crosses a language boundary.

These are the structural consequence of a handoff process that was designed to transfer knowledge between two disciplines — design and engineering — without any representation from the third discipline that will eventually inherit everything they decide.

The cost structure of late discovery

There is a reason the phrase “shift left” became a cliché in localization. The underlying logic is not complicated: defects are cheaper to fix the earlier they are caught.

A string that is caught as untranslatable at the handoff stage costs a conversation and a design revision. The same string caught at linguistic QA costs a re-translation, a re-export, a re-import, a re-QA cycle, and potentially a re-build if the fix requires a string key change. The same string caught post-launch costs all of that plus a patch release, plus the reputational cost of shipping broken text to a market you were supposed to be serving.

The earlier the intervention, the cheaper the remediation, by an order of magnitude at each step.

The handoff meeting is the last structural moment before a design decision becomes a code decision. Once code exists, inertia sets in. Refactoring is not free. Engineers have moved on to the next ticket. Product has signed off. The cost of changing it escalates immediately upon implementation.

The localization leader who is not in the handoff is, by definition, operating downstream of the point where most of their future problems are created.

How AI is changing the handoff

The design-to-engineering handoff was already evolving before AI entered the picture. Figma’s introduction of developer mode, auto-layout, and design tokens had already begun to blur the boundary between design artefact and implementation spec. The handoff was shifting from a meeting-centric event to a continuous, tooling-mediated process.

AI has accelerated this in ways that are simultaneously exciting and alarming from a localization standpoint.

AI-assisted design generation means that more screens are being produced, faster, with less human deliberation behind each decision. The output looks polished. The underlying assumptions are invisible. A screen generated from “create a settings page with notification preferences” will produce English-length labels, LTR layout, pixel-precise containers, and concatenated strings — because that is what the training data looks like. The designer who reviews it may not catch what was never flagged.

Vibe coding — the practice of generating frontend implementation directly from design descriptions, often bypassing the traditional handoff entirely — removes the meeting from the loop altogether. There is no room where someone could have asked the question. The question never gets asked.

AI code generation tools like GitHub Copilot and Cursor produce syntactically correct code that implements what the prompt asks for. If the prompt describes a fixed-width container, the code will have a fixed-width container. If the prompt includes a concatenated string, the code will concatenate the string. The AI has no frame of reference for what will happen when that component is handed to a translator in Oslo.

Design token automation is one of the more promising developments. When design decisions are encoded as tokens — including text container sizing, typographic scale, and spacing — there is at least a structured artefact that a localization system could, in principle, interrogate. But this potential goes mostly unrealised because the tooling that connects design tokens to localization constraints does not yet exist at scale.

LLM-generated copy introduces a new category of problem. When an LLM writes UI copy at the design stage, it produces strings that are optimised for English readability. Strings like “You’re all caught up!” or “Let’s get you started” are colloquial, idiomatic, and aggressively untranslatable. They look great in an English mockup. They are a nightmare to localise without losing either the meaning or the tone. And because they were generated quickly and approved quickly, no one stops to assess their downstream cost.

The net effect of these trends is that the handoff is becoming faster, more automated, more continuous, and more opaque. The window for intervention is narrowing. The volume of decisions passing through that window is increasing.

The localization leader’s seat at the table

In most organisations, the design-to-engineering handoff is attended by: the designer who owns the spec, the frontend engineer who will implement it, and a product manager who is there to maintain coherence with the roadmap. Sometimes a tech lead. Sometimes a QA engineer.

Localization is not in the room.

The reason is organisational gravity. Localization is downstream. It is a later-phase function. The assumption is that what happens in the handoff is a design-and-engineering conversation, and localization will deal with the output when it arrives.

This assumption is wrong, and the cost of it is borne entirely by the localization team.

For a localization leader with a strategic role, the handoff meeting is where product decisions intersect with linguistic and cultural constraints at the earliest possible moment. It is the only moment in the process where a localization perspective can influence implementation before implementation creates its own inertia.

What a localization leader brings to the handoff that no one else in the room has:

Mental model of the translation unit. A designer thinks in components. An engineer thinks in functions. A localization leader thinks in translation units — context-bearing strings that must survive extraction, delivery to a translator or AI, translation, re-import, and rendering in a different language at a different length. That mental model produces a completely different set of questions when looking at a spec.

Pattern recognition for failure modes. Having seen hundreds of localization bugs, a localization leader can look at a design spec and identify, in minutes, the places where localization will break. Concatenated strings, fixed containers, hardcoded punctuation, culturally-loaded metaphors, directional icons — these are visible, once you know how to look. No one else in the room has been trained to look.

Cross-linguistic intuition about length and structure. When a designer sees a label that reads “Save changes”, they see a label. A localization leader sees a label that will become “Änderungen speichern” in German, “Guardar cambios” in Spanish, and “変更を保存する” in Japanese, and immediately considers what each of those does to the container, the button, the layout.

Awareness of cultural and regulatory variation. Some UI decisions are not just translation problems but localisation problems in the deeper sense: date formats that must match regional legal requirements, content hierarchies that reflect different cultural assumptions about information priority, address form structures that do not generalise across postal systems.

Fluency with the downstream pipeline. A localization leader understands that what looks like a string to an engineer is actually a node in a pipeline that runs through a TMS, through a translator’s workspace, through a QA tool, and back. Decisions made at the handoff have consequences at every node. The localization leader is the only person in the room who has ever stood at each of those nodes and watched things break.

Why this seat is typically inaccessible

The handoff meeting is a small, functional meeting. It is not a steering committee. It is not a roadmap review. It operates on a different axis of organisational power than the meetings where localization leaders typically have access.

Access to it requires either a formal mandate (a role that includes localisation review as a stage-gate in the product process) or informal credibility (a track record of catching things early that saves engineers time later). The second path is harder to build but more durable: when you have sat in three handoffs and flagged five issues that would have become QA bugs, you start getting invited without having to ask.

The argument for formalising it is straightforward. If localisation is a strategic priority — and for any product operating across more than two markets, it should be — then localization review belongs at the point where decisions are still changeable. A localization leader who is only engaged at string extraction has been handed a fait accompli.

The organisations that do this well, and they are not common, treat localisation review as part of design review, not as a separate downstream phase. The localization leader, or a designated localization engineer, reviews specs before they are handed off. Flags are raised before implementation. The spec is updated. The pipeline is cleaner from the start.

This is not an exotic practice. It is just a discipline that requires a localization team with enough standing, and enough technical credibility, to participate in conversations that were not originally designed for them.

What to ask for, specifically

If you are a localization leader who has never been in a handoff meeting and wants to be: the ask is not a standing invitation to every handoff in the company. That is operationally unrealistic and would not be a good use of your time.

The ask is a seat in handoffs for new feature work and new surface areas — the moments where architectural decisions are being made for the first time, rather than incremental updates to existing patterns. These are the handoffs where localization debt is most likely to be created at scale.

Secondarily: a lightweight localization checklist as part of the designer’s pre-handoff process. Not a bureaucratic gate. A five-point reference that prompts designers to ask themselves: are there concatenated strings in this spec? Are containers flexible? Have I provided context annotations for short or ambiguous strings? This does not require your presence in every meeting. It requires that your institutional knowledge be embedded in the process.

Third: a direct line between the localization function and the design system. If your organisation uses a design system — and any organisation of meaningful scale does — that design system contains decisions about text components, container sizing, and typographic scale that directly affect localization. Localization’s input into the design system is not a nice-to-have. It is the highest-leverage intervention available, because it propagates through every product surface automatically.

The AI inflection point

The reason this argument has more urgency now than it did five years ago is not that the handoff problem is new. It is that AI is making the handoff faster, more automated, and further from human deliberation, precisely at the moment when the volume of localised product surfaces is expanding.

More markets. More languages. More AI-generated copy. More vibe-coded frontends. More design tokens automating decisions that used to be made by a person. All of it passing through a process that was designed for a world where a human designer handed off a human-reviewed spec to a human engineer in a meeting where, in principle, someone could have raised a question.

That window is closing. The localization leader who understands this and positions accordingly, who builds the relationships, the checklists, the design system integrations, and the institutional credibility to be in the room before the room disappears, is not just managing a pipeline. They are shaping what gets built.

That is the job. It always was. The handoff meeting just happens to be where you can see it most clearly.

If this saved you from a future concatenation argument at 11pm before a release, share it with someone who needs it. And if it didn't, you're probably already in the room.

We’re going to vibe-code an i18n scanner. Not a polished product. The version one person with domain knowledge can build in a weekend, and that will immediately find real problems in a real codebase.

But first, I need to make the case for something that gets skipped constantly: you cannot build this right without domain knowledge. Not the AI. You.

What is an i18n issue, actually?

Before you write a single prompt, ask yourself: do you have a dashboard at work where defects are filed under an “i18n” label? A tag in Jira, a column in your QA tracker, a category in your defect classification system?

If you do, that data is gold. That is your training set. Not some generic list from a blog post. Your organization’s own history of what breaks, how it breaks, and what it was called when someone filed it.

If you don’t have that yet, you’re about to understand why i18n logging discipline matters. But you can still build a useful scanner with what I’m about to give you.

So: what are i18n issues, and what are they called?

The field has reasonably settled terminology. These are the categories you’ll want your scanner to know about:

Issue taxonomy with real examples

Hardcoded strings User-facing text that lives in source code instead of a resource file. The classic. Surprisingly common even in mature codebases.

# Bad
button_label = "Submit Order"

# Should be
button_label = t("checkout.submit_button")

String concatenation Building sentences by joining fragments. Works in English. Fails in German (verb-final), Japanese (topic-comment), Arabic (VSO word order), and anywhere the grammar doesn’t match the assumption baked into the join.

// Bad — assumes "Welcome, " + name + "!" order works everywhere
const greeting = "Welcome, " + userName + "!";

// Should be
const greeting = t("welcome_message", { name: userName });

Plural handling Hardcoding “1 item” / “X items” as a binary. Russian has three plural forms. Arabic has six. Welsh has five. CLDR defines plural categories: zero, one, two, few, many, other. If your pluralization logic is if (n === 1), it’s wrong for most languages.

# Bad
message = f"You have {count} item" if count == 1 else f"You have {count} items"

# Should use ICU MessageFormat or equivalent
message = t("item_count", { count: count })

Date, time, and number formatting Dates hardcoded as MM/DD/YYYY. Decimal separators assumed as .. Thousands separators assumed as ,. None of these hold globally.

// Bad
const display = `${month}/${day}/${year}`;

// Should use Intl.DateTimeFormat or a locale-aware library
const display = new Intl.DateTimeFormat(locale).format(date);

Currency and measurement units Hardcoded currency symbols ($, €) without locale context. Imperial units without conversion paths. Temperatures in Fahrenheit without localization awareness.

Missing or incomplete locale configuration Language/locale codes that aren’t BCP 47 compliant. es where es-419 (Latin American Spanish) was needed. zh where zh-Hant (Traditional) or zh-Hans (Simplified) was required.

// Bad — ambiguous
{ "locale": "zh" }

// Good
{ "locale": "zh-Hant-TW" }

Untranslatable or translation-blocking patterns Content that’s genuinely impossible to translate accurately: strings with embedded HTML that will break in RTL languages, strings baked into images, strings that are keys masquerading as human-readable text.

// Bad — HTML in the middle of a translatable string
const label = `<b>Warning:</b> Your session expires in ${minutes} minutes`;

Missing translation fallback No fallback locale defined, so if a key is missing in fr-CA, the system doesn’t fall back to fr, it surfaces the key string or crashes.

Character encoding issues Files saved without UTF-8 encoding. Characters outside ASCII range hardcoded as literals rather than escaped properly.

Locale-sensitive sorting Using default sort on strings in a multilingual context. ä doesn’t sort near a in Swedish. Locale-aware collation is a separate concern from translation.

That’s your taxonomy. Not every scanner needs to catch all of these. But you need to know which ones matter for your codebase before you start building.

Step two: understand what your scanner will be reading

Before you write any prompts or code, answer these questions:

Read more

The headline isn’t a new model. It’s a stack of primitives — Skills, CLAUDE.md hierarchies, MCP, Hooks, Plugins, subagents, agent teams, parallel Claude, verification loops — that collectively answer one question:

Once the model is good enough, what’s actually left for the human to do?

The answer, as far as I can tell after this session, is context engineering. Not prompting. Not “knowing the magic words.” Engineering the information environment the model operates in — what it sees, what it doesn’t, when it sees it, who else is looking, and what gets to count as “done.”

That’s the thread I want to pull on. Here’s what I took away, organised the way I now actually think about it.

Subscribe now

1. The shift: from prompting to context engineering

The old mental model was: write a clever prompt, get a clever answer. Iterate.

The new model is closer to: design the context window. The prompt is a small part of it. The much bigger part is what Anthropic frames as four context management strategies:

• Actively manage your context — visualize it (/context), prune it (/compact), don’t let it accrete junk.

• Isolate distinct tasks by session — /clear aggressively, or spin up parallel Claudes for separate concerns.

• Shrink your search space — point Claude at exactly the files it needs (CLAUDE.md, @-mentions) instead of letting it grep the whole repo.

• Progressively disclose context — load capabilities only when needed (this is the whole Skills design philosophy).

If you internalise nothing else from this post, internalise that list. Every other primitive below is in service of one of those four moves.

For anyone working in multilingual AI, this maps onto territory I think about constantly with Black Ice: the unit of correctness isn’t the string the model produces, it’s the structured context the model was operating inside. Context engineering for code is the same discipline, with different vocabulary.

2. CLAUDE.md: instructions as a hierarchy, not a prompt

CLAUDE.md is a markdown file that lives in your repo (and ~/.claude/CLAUDE.md lives at user level). Claude reads it on startup. That’s it. That’s the feature.

What makes it interesting is the hierarchy:

• ~/.claude/CLAUDE.md — your personal preferences, your global thinking instructions

• Monorepo/CLAUDE.md — system overview, modernization strategy, team structure

• Repo/CLAUDE.md — component architecture, technical debt, migration plans

• Submodule/frontend/CLAUDE.md, Submodule/backend/CLAUDE.md, Submodule/test-cases/CLAUDE.md — local specifics

Claude assembles the right slice based on where you’re working. You stop repeating “use pnpm, not npm. Run tests with pytest. Follow PEP8” in every session, because it’s already loaded.

The mental shift: persistent instructions belong in version control, not in your prompt history. Your prompts get shorter. Your repo gets smarter.

3. Skills: progressive disclosure as a design principle

This was the moment I sat up.

A Skill is an organised folder containing a SKILL.md plus whatever else the skill needs — reference docs, executable scripts, templates, examples.

The trick is progressive disclosure:

In plain English: Claude has hundreds of latent capabilities sitting on disk. It pays a tiny token cost (~100 tokens of metadata) per Skill to know they exist. It only pays the full cost of reading the body when the skill is actually relevant to the current task. It only pays the cost of bundled assets when it specifically needs them.

This is the architecture you’d design if you took context windows seriously as a constraint and you wanted the agent’s effective competence to be unbounded. Two types of Skills they highlighted:

• General capabilities Claude isn’t good at out of the box (yet) — e.g. creating PDFs, Excel, PowerPoint files.

• Knowledge of an organisation’s workflows and best practices — e.g. Anthropic’s own brand styling, internal coding standards.

The second category is where this gets genuinely interesting for anyone working on enterprise AI. A Skill is essentially a portable unit of organisational expertise — versioned, testable, distributable. The localisation parallel is obvious: a Skill that encodes how your company handles dates, currencies, honorifics, and ICU message format across 30 locales is doing exactly the kind of work an ontology does in a knowledge-graph pipeline. Different mechanism, same job: keep the model from improvising on things it shouldn’t improvise on.

One tip, worth pinning above your monitor: be very explicit in the description of your skill. That YAML frontmatter is what Claude reads to decide whether to load the rest. Vague descriptions = skills that never fire.

4. MCP and Hooks: where Claude reaches outside its box

MCP (Model Context Protocol) is how Claude talks to external systems — Atlassian, Asana, Linear, Canva, Sentry, Cloudflare, your own internal services. You add a server with mcp add <server-name> and /mcp to manage them. Configurations live in .mcp.json.

Hooks are shell commands that fire on lifecycle events: PreToolUse, PostToolUse, Notification, UserPromptSubmit, SessionStart. Use cases the session covered:

• Auto-format on save (prettier on .ts, gofmt on .go)

• Run tests after edits

• Send notifications on completion (Slack, text, “carrier pigeon as long as there’s an API”)

• Logging

• Correcting Claude behaviour deterministically

The mental model they offered for choosing between features is actually the clearest part of the whole deck:

Read that table twice. It’s the cheat sheet.

5. Plugins: distribution, finally

The newest piece. A plugin is a single distributable that bundles MCP servers, Skills, subagents, custom slash commands, and hooks under one manifest. Installed via terminal commands.

Two things matter here:

1. Unified distribution — you ship one thing instead of asking colleagues to configure five.

2. Enterprise marketplaces — organisations can run internal and external marketplaces to distribute plugins across teams.

This is the piece that turns Claude Code from “a tool a senior engineer configures heroically” into something that scales across an org. It’s also, frankly, what makes “AI workflow design” a discipline you can actually hire for.

6. The three parallelism primitives

Here’s where the mental model expands. Anthropic distinguishes three ways of running Claude in parallel, and they are not interchangeable.

Subagents — same session, separate context windows

One Claude session spawns multiple subagents. Hub-and-spoke. Workers report summaries back. They live as markdown files in agents/ — code-reviewer.md, researcher.md, writer.md.

When to use:

• Quick, focused workers that return summaries

• Isolating noisy operations (test runs, large greps)

• When you need the cheapest token footprint

The three conditions where subagents work well, from the deck:

1. Well-defined roles — clear, specialised role with defined tool access levels and success criteria.

2. Hands-off delegation — you don’t need to inspect or interact with the subagent’s work.

3. Enhance context management — subagents are a context-management strategy in disguise.

Agent Teams — separate processes, shared task list

Multiple Claudes with a shared task list and peer messaging. Best for debate and cross-layer coordination. Higher token cost, but you can have agents disagree productively.

Patterns that work:

• Fan-out research — spawn N subagents to research modules in parallel.

• Isolate noisy ops — route verbose test/grep output to a subagent; only the summary returns.

• Chain sequential hand-off — reviewer subagent finds issues → optimiser subagent fixes them. Separation of concerns without nesting.

• Competing hypotheses — spawn 5 teammates on a hard bug; they debate to disprove each other. The surviving theory is the real root cause.

That last one — competing hypotheses — is the most genuinely new pattern I picked up. It’s the model arguing with itself on purpose, and the disagreement is the signal.

Parallel Claude (Worktrees) — true filesystem isolation

claude --worktree. Multiple Claude Code instances running simultaneously, each in its own git worktree, each on its own branch, each with its own context. True parallel implementation without file conflicts.

When to use:

• Implementing on separate branches you actually intend to merge.

• Risky refactors you want isolated.

• Auto-cleanup if no changes get made.

For cross-session awareness, they recommend TMUX.

The honest summary: subagents for context isolation, agent teams for coordination and debate, worktrees for filesystem-level parallelism. Most people reach for one when they want another. Pick deliberately.

7. Verification: the line that stuck with me

Claude is only as good as the thing that checks its work.

This is the part of the talk that has the most to say to anyone working in localisation, governance, or any domain where “sounds right” isn’t good enough.

Three verification modalities:

• Rules-based — define pass/fail rules. Claude runs the checker and reads the output.

• Visual — screenshot the output, feed it back to Claude. Best for UI work via Playwright MCP.

• LLM-as-judge — a second model evaluates output against fuzzy criteria.

And five verification patterns worth memorising:

1. Isolate test noise — “run the test suite and report only failing tests with errors.” Verbose output stays in the subagent’s context; your main session stays clean.

2. Post-implementation review — “review this diff for edge cases I missed.” Fresh context = no author bias on the code it just wrote.

3. Find → Fix chain — reviewer subagent finds perf issues, optimiser subagent fixes them.

4. Write-new-tests challenge — “write three new tests not in the existing suite. Verify they pass.” Catches what the happy-path suite won’t.

5. Autonomous loop (”Ralph”) — define pass criteria upfront → let Claude iterate write-test-fix unattended until green. Works for overnight runs.

And then the framing they put a red box around:

Test Driven Development. Write tests first → have Claude implement until they pass. Claude can’t rationalise away a failing test — the spec is the contract.

This is the move. If you’ve ever watched an LLM gaslight itself into thinking broken code is fine, you know exactly why a hard spec it cannot edit is the whole game.

The localisation parallel here is something I’ve been arguing for years: linguistic QA needs to move upstream into the spec, not get bolted on after generation. “Sounds fluent” is the LLM rationalising. A failing locale-specific test it can’t argue with is the contract.

8. The slash commands worth knowing

Three that came up repeatedly:

• /batch — orchestrates large-scale changes across a codebase in parallel. Describe the change; /batch researches, decomposes, and presents a plan. On approval it spawns one background agent per unit, each in an isolated git worktree, each runs tests and opens a PR. Example: /batch migrate src/ from Solid to React → 5–30 parallel agents, 1 PR per unit, auto-opened.

• /simplify — reviews recently changed files for code reuse, quality, and efficiency, then fixes them. Three internal agents: Code Reuse, Code Quality, Efficiency. Run after implementing a feature.

• /loop — scheduled prompts. Run prompts automatically on an interval. Examples: /loop 5m check if the deployment finished, /loop 15m scan error logs and open fix PRs, /loop remind me at 3pm to push the release. Tasks run in the background within your session. Default interval is 10 minutes. One-time natural-language reminders also supported.

/batch is the headline. The other two are the daily-use workhorses.

9. The pattern underneath all of it

If I had to compress the whole session into one diagram, it’d be this loop:

Plan → Implement → Verify → (Fail? → Read error → back to Implement) → Finish

That’s it. Every primitive above is in service of making one of those four nodes better:

• Plan — CLAUDE.md hierarchy, Skills, MCP for external context

• Implement — subagents, agent teams, parallel Claude

• Verify — rules-based / visual / LLM-as-judge, hooks

• Iterate — /loop, autonomous loops, TDD

The thing that changes when you take this seriously is your job. You stop being the person who types prompts. You become the person who designs the context in which the prompts get evaluated.

That’s the discipline. Everything else is syntax.

What I’m taking back to my own work

Two parallels I can’t stop thinking about, both light-touch but real:

Progressive disclosure is the ontology pattern. A Skill’s three-tier loading model — metadata always, body on trigger, assets on demand — is structurally identical to how a well-designed multilingual ontology behaves: the schema is always present, the concept graph loads as the domain is invoked, the locale-specific assets resolve last. If you’ve built one, you can recognise the other instantly.

The “thing that checks the work” is the unit of governance. In code: tests, types, linters, LLM-as-judge. In multilingual AI: terminology constraints, locale rules, semantic validators. The model is interchangeable; the verifier is the moat. Whoever controls verification controls quality. This has been the Black Ice argument from day one and it was strange and gratifying to hear it phrased back at me by someone from Anthropic without either of us mentioning localisation.

TL;DR for the impatient

• Context engineering is the actual skill. Prompting is a subset.

• CLAUDE.md for persistent instructions. Skills for on-demand expertise. MCP for external systems. Hooks for deterministic automation.

• Plugins bundle all of the above for distribution.

• Three parallelism primitives — subagents (context isolation), agent teams (coordination/debate), worktrees (filesystem parallelism). Not interchangeable.

• Verification is the moat. TDD with Claude works because it can’t argue with a failing test.

• Slash commands worth learning today: /batch, /simplify, /loop.

• The whole thing is a loop: Plan → Implement → Verify → Iterate.

If you take one thing away, take this:

Claude is only as good as the thing that checks its work.

Build the checker first.

If you found this useful, the rest of The AI-Ready Localizer digs into the same patterns from the multilingual side — same discipline, different vocabulary.
Like, share, subscribe!

The chart that usually accompanies this story is the Brynjolfsson et al. call-centre study. Junior reps get a 34% lift. Senior reps get almost nothing. The headline writes itself: AI is the great equaliser.

It isn’t. And if you’ve actually worked in a domain — really worked in it, the way you only do after you’ve seen the same problem mutate fifty different ways — you already know why.

What the novice gain actually measures

The 34% lift is real. It’s also a measurement of the floor, not the ceiling.

What those studies are capturing is the cost of producing a passable first draft of something. A ticket response. A code snippet. A summary. The reason novices benefit so much is that producing a passable first draft used to be the hard part of their job. AI ate that part.

What it didn’t eat is the part of the job that comes after the first draft. The part where you decide whether the draft is wrong. Whether it’s wrong in a way that matters. Whether the framing of the question was wrong to begin with. Whether the “right” answer for this customer is actually the wrong answer for this contract.

This part is invisible in productivity studies because it shows up as quality, not throughput, and quality is much harder to count. So we count throughput and call it progress.

The “passive pasting” problem

A recent review of the AI-and-jobs literature flagged something the cheerful version of the story leaves out: a lot of the novice productivity gains in controlled experiments come from what the authors call passive pasting — workers taking AI output and submitting it without modification. That’s not learning. That’s not augmentation. That’s automation with a human dressed up as the operator.

If your job consisted of producing the kind of output that AI can now generate directly, your “productivity boost” is the sound of your role being decoupled from your salary. The work still happens. You’re just no longer the necessary part of it.

This is the cohort I’d describe as people who were doing a repetitive job without ever grasping the bigger picture. They were never really doing the work. They were executing a procedure that resembled the work. AI doesn’t make them better at the work. It makes the procedure cheaper to run.

What the expert gain actually measures

Now look at the experts. The studies that get cited say experts gain little. Some say expert quality actually drops with AI.

The “drops” finding is the interesting one. It’s not that AI made the experts worse at their domain. It’s that experts who let AI do the thinking stopped doing the thinking, and the thinking is what made them experts. Outsource the muscle and the muscle atrophies. We’ve known this since the Dreyfus brothers were writing about skill acquisition in the eighties.

But this average masks the real distribution. There’s a subset of experts for whom AI is enormously generative, and it’s not the ones who hand the steering wheel over. It’s the ones who use AI as a peer they can argue with.

The pattern looks like this:

• They know the right question to ask, which is most of the work.

• They can spot a wrong answer in under a second because they’ve seen the right one a thousand times.

• They can tell when the model is being plausible versus correct — two states that look identical to anyone outside the domain.

• They use AI to handle the parts of their job they were never paid to enjoy — boilerplate, scaffolding, the seventh variation of a thing they’ve written six times — and reinvest the recovered hours into the parts that need a human brain.

This is the population that “flies solo with AI.” They don’t need a manager translating between them and the tool. They don’t need a vendor’s enablement deck. They don’t need three months of training to figure out what prompts work. They sit down, they describe what they want in the vocabulary of their own field, and the tool responds in kind because they’re giving it enough scaffolding to be useful.

The Harvard study nobody quotes correctly

Bojinov and McFowland ran a study at IG Group that’s been quietly devastating to the equaliser narrative. They had marketing specialists and software developers attempt the work of web analysts — a job adjacent to marketing, distant from software. Same AI, same task.

Marketing specialists, with adjacent domain knowledge, produced reasonable analyst-quality work with AI assistance. Software developers, further from the domain, did not. The researchers’ framing is that skills transfer with AI’s help if they’re already adjacent. They don’t transfer across a real domain gap.

What this means in plain English: AI doesn’t give you expertise. It gives you reach. If you have a foothold in the territory, you can extend further than you used to be able to. If you have no foothold, you produce something that looks like the work but isn’t.

Why this is a problem for organisations and not just for individuals

The version of this argument that focuses on individual careers is the boring version. “Build domain depth, you’ll be fine.” Sure.

The interesting version is what happens to organisations whose workforce was built around the assumption that domain expertise could be substituted with process. A great deal of the modern white-collar economy was constructed on exactly this premise: hire generalists, give them a playbook, let the playbook do the thinking. It scales beautifully. It also produces, over twenty years, a workforce that has never had to develop the kind of expertise that AI can’t replicate.

Those organisations are about to discover something painful. The people who can fly solo with AI are a much smaller fraction of their staff than they’d assumed. The “AI literacy” training programmes won’t fix it, because the bottleneck isn’t AI literacy. The bottleneck is domain literacy, which takes years and can’t be procured on a quarterly budget cycle.

The research from Wharton’s Tambe is pointing at this exact dynamic from a different angle: the firms that get the biggest market valuation lift from AI investment are the ones where algorithmic skills are broadly diffused among domain experts. Not the ones with the most data scientists. Not the ones with the most tooling. The ones where the people who understand the work also understand the tool. That combination is rare, and the market is starting to price it accordingly.

The “incompetent expert” trap

There’s a second-order risk that’s worth naming because it’s going to define the next five years.

When a novice uses AI to produce work in a domain they don’t understand, the failure mode is invisible to them. They can’t verify what they don’t understand. They submit confident-looking output, the output gets accepted because nobody downstream understands the domain either, and the organisation accumulates a quiet liability — work that looks expert and isn’t.

This is the configuration that produces catastrophic failures eighteen months later, when someone with actual domain knowledge finally looks at the output and realises the whole stack is wrong. By that point the original author has moved on, the institutional memory of how the decision got made has evaporated, and nobody can unwind it.

Verification is a domain skill. It is the deepest domain skill, in fact. Knowing what right looks like is harder than producing something that resembles right. AI has dramatically lowered the cost of producing things that resemble right, without lowering the cost of verification at all. The asymmetry is the entire problem.

So what’s the actual claim

The cheerful story says AI democratises expertise.

The honest version: AI widens the gap between people who actually understand their work and people who were performing a simulation of it. The performers get exposed because the simulation is now free. The understanders get a force multiplier because they finally have a tool that can match their cadence.

If you’ve ever wondered why some people seem to be ten times more productive with AI and others seem to be producing slightly polished sludge, this is why. It was never about prompt engineering. It was about whether there was a thinker holding the pen.

The lesson for anyone whose job is in the firing line isn’t “learn AI.” It’s the older, less marketable lesson: go deep on something. Pick a domain, stay in it long enough that you stop needing the playbook, develop the kind of taste that lets you spot a wrong answer at a glance. That is the asset. The tool is the multiplier. Multiplying zero is still zero.

Why this series exists

Localization professionals have a long tail of repetitive, judgement-heavy tasks that nobody is going to build a commercial tool for. The market is too narrow, the workflows too specific, and the people who feel the pain don’t sit close enough to the people who write code. So the work either gets done manually, gets shoved into a spreadsheet that someone maintains until they leave, or gets ignored.

Vibe-coding closes that gap. Not because it turns translators into developers. It doesn’t, and the framing is condescending in both directions. But because it lets domain experts commission small bespoke tools the way they’d commission a translation: by writing a clear brief and reviewing the output.

This series is about treating vibe-coding as a discipline rather than a vibe. Over four posts we’ll build four tools that any localization professional should find useful, and the goal isn’t really the tools, it’s the method. By the end you should be able to look at any narrow, annoying, repetitive task in your week and decide whether it’s a vibe-coding candidate, what shape the tool wants to take, and how to commission it without spending three hours fighting an AI builder that keeps adding features you didn’t ask for.

A note on register before we start. There is a lot of breathless content about AI-built tools at the moment and most of it is selling something. This series isn’t. The tools we build will be small and useful and occasionally clunky, the prompts will go through several rounds of refinement before they produce anything good, and at least one of the four projects will hit a wall that requires you to step back and rethink.

Subscribe now

What “vibe-coding” actually means

The term gets used loosely. For our purposes:

Vibe-coding is the practice of building working software by describing what you want in natural language to an AI builder, then iterating on the result. You’re not writing code. You’re writing specifications, reading output, and steering. The skill is in the steering.

It works well for tools that are small in scope, narrow in audience, and live somewhere between “spreadsheet macro” and “internal utility.” It works as a starting point for ambitious projects too, but it’s a starting point, not a finish line, and we’ll come back to that boundary at the end of the post.

The toolkit

Lovable is a full-stack app builder. You describe what you want, it generates a React frontend with a Supabase backend, deploys it, and gives you a URL. Best when the tool needs to persist data, support logins, or be shared with colleagues. The trade-off is that you’re committing to a small web app — there’s a database, there’s auth, there’s hosting. For a tool you’ll use once a week with a team, that’s fine. For a script you want to run against a folder of files, it’s overkill.

Claude Artifacts lives inside a Claude conversation. No deployment, no account, no persistence. You describe a tool, Claude builds it as a self-contained artifact, and it runs in your browser inside the chat. Best for stateless single-user utilities: a quick glossary checker that takes pasted text and returns flagged terms, a formatter, a one-shot transformation. Sometimes exactly what you want, often forgotten because it doesn’t feel like “building.”

Replit, Bolt.new and v0 are worth knowing about. Replit is a browser-based coding environment with an AI agent — strong when you want a script rather than an app, something that runs against files in a repo and returns a result. Bolt covers similar territory to Lovable and is sometimes faster for throwaway prototypes. v0 is UI-first — strong for "I need a dashboard that looks good," weaker on backend logic. We won't use any of these in this series but they're in the same family.

Claude (the chat) is not a builder. It’s the thinking partner. You use Claude to refine the specification before you touch any builder, to interrogate the generated code during, and to debug after. This is the move that separates vibe-coding from button-pushing, and we’ll spend a fair amount of the rest of this post on it.

The takeaway: builder choice follows tool shape, not preference.

The skill that actually matters: clarity and workflow architecture

The AI builders are good now. They will be better next month.

The bottleneck is knowing what you actually want, and being able to describe it as a workflow.

That sounds obvious. It isn’t. Most people, when asked what they want, describe a feature (”a tool that flags terminology issues”). What they need to be able to describe is an artifact (”a CSV with one row per flagged segment, columns for source, target, the violated term, the rule that was violated, and a confidence score, ranked so the highest-confidence violations appear first”) and a workflow (”the user uploads a bilingual XLIFF, the tool extracts segments, runs each segment against the ontology API, applies a confidence threshold, sorts the output, and returns the CSV with a summary count at the top”).

The first version — “a tool that flags terminology issues” — is a wish. The second version is a specification. The gap between them is the entire skill.

Read more

The Claude Code + NotebookLM MCP setup is the first thing I’ve used that actually solves this, and not in a clever-workaround way. It just moves the problem to the right tool.

Subscribe now

What the setup actually is

NotebookLM is Google’s tool for asking questions against a fixed corpus of sources you upload. It’s grounded — answers come with citations to the specific passages in your documents — and it’s free for individuals. The catch has always been that NotebookLM lives in a browser tab, isolated from whatever you’re actually trying to write or build.

The MCP server changes that. Claude Code can now query your NotebookLM notebooks directly, get back citation-backed answers from Gemini, and use those answers as input to whatever it’s doing in your terminal. There are several implementations on GitHub; the install is roughly install, authenticate once with Google, register the MCP server with Claude Code. Five minutes if nothing goes wrong.

The token economics

When you paste a 200-page PDF into a Claude conversation, you’re paying input tokens for that document on every single turn. Ask five questions, you’ve sent the document five times. With the NotebookLM MCP, the document lives in NotebookLM. Claude only sees the answer that comes back — usually a few hundred tokens with citations, instead of the entire corpus.

For long research sessions this is the difference between hitting your usage limit at lunch and still having room at the end of the day. It also means Claude’s context window stays clear for the work you actually want it doing: writing, analysis, code. The reading happens elsewhere.

One honest caveat: MCP servers add tools to Claude’s context, and tools cost tokens too. The popular implementation by jacob-bd ships with around 35 tools, which is enough to noticeably eat into your window if you leave it on all the time. The same repo flags this and tells you to toggle the server off when you’re not using it (@notebooklm-mcp in Claude Code). Treat it like a power tool, not a permanent fixture.

Three use cases for people working with LLMs

1. Reading a long document without paying to re-read it. You drop a 300-page report, a court ruling, a textbook chapter, a stack of meeting transcripts into a NotebookLM notebook. Then you sit in Claude Code and ask whatever you want — what does this say about X, where does the author contradict themselves, summarise chapter 4 in plain language. Each question is a cheap call. You can spend an hour on a document for a fraction of what the same conversation would cost if the document were pasted into the chat.

2. Synthesis across sources you can’t fit in one prompt. Most useful research isn’t one document, it’s twenty. Ten papers on the same topic, a folder of customer interview transcripts, every blog post a competitor has ever published. NotebookLM holds all of it. Claude queries it. You can ask things like which of these sources disagree about the mechanism, and quote the disagreement — and get back a grounded answer with citations pointing to the exact passages, instead of a hallucinated summary stitched together from the model’s training data.

3. Drafting from your own knowledge base. This is where it stops being research and becomes production. You keep a NotebookLM notebook of your own writing, your meeting notes, your existing documentation — whatever counts as your stuff. Then when you’re drafting a new piece in Claude Code, the model can pull from that notebook to stay consistent with how you’ve talked about something before. It’s not impersonating your voice (it’s still Claude generating the prose); it’s making sure Claude has the actual facts of what you’ve previously said, instead of inventing a plausible version.

What this is and isn’t

It isn’t magic. The grounding only works if the documents in your notebook are actually the right documents. Garbage in, citation-backed garbage out. NotebookLM also has its own limits on notebook size and source count, which you’ll hit eventually if you’re feeding it large corpora.

What it is, though, is one of the few MCP integrations I’ve installed where I can point at the actual benefit instead of waving at the general idea of connecting things. Reading is offloaded to the tool that’s good at reading. Generation stays with the tool that’s good at generating. The token bill goes down. The hallucination surface shrinks because answers are grounded in real passages.

For anyone whose work involves regularly thinking against a body of source material — researchers, writers, analysts, lawyers, anyone with a folder of PDFs they keep meaning to read — this is worth the five minutes.

To show how simple this can be in practice, I built a little dinosaur game for my 5-year-old using Claude Code pulling from a NotebookLM notebook of dino facts. Here's the video.

Quick housekeeping, because it matters for what follows.

Starting with this post, everything Black Ice — product updates, build-in-public notes, deep dives on semantic governance, ontology design, agentic pipeline architecture — moves to its own newsletter: The Frost Line.

The AI-Ready Localizer, the newsletter you’re reading right now, is staying exactly where it is and doing exactly what it does: localization and AI, broadly. The shifts in our industry, the tooling questions, the cultural and linguistic theory underneath the work, the unglamorous infrastructure decisions, the day-in-the-life craft of being an AI-assisted language professional. None of that is changing. If anything, it’ll get more focused now that I’m not stitching Black Ice product material into every other essay.

If Black Ice is what you’re here for, subscribe to The Frost Line. If you’re here for the broader conversation about AI and localization, you’re already in the right place.

This post is the bridge — the long version of what Black Ice actually is, why I built it, and why I think the framing most people start with is wrong.

The framing problem

Most people, when I describe Black Ice for the first time, try to slot it into the pipeline they already know. They picture the traditional localization stack: source content, TMS, translation memory, CAT tool, QA, delivery. They ask which slot Black Ice sits in. They assume the answer is somewhere upstream of the TMS.

That’s the wrong picture, and the wrongness of it is the whole point.

Black Ice isn’t a step in the old pipeline. It’s the framework that holds together a different pipeline — one that doesn’t have those slots anymore.

What is Black Ice?

Black Ice is the semantic governance framework for agentic localization pipelines. It’s the layer that defines, enforces, and audits meaning across multilingual AI workflows where content is regenerated rather than recycled, and where the seven-step waterfall of source → TM → MT → post-edit → review → QA → publish has collapsed into a fluid agentic system.

In those pipelines, governance can’t be a checkpoint. It has to be the substrate. That’s the role Black Ice plays.

Three things make it what it is:

1. A multilingual ontology — concepts, classes, market profiles, relationships, governance and availability rules — that every agent in the pipeline reads from and writes back to.

2. Pre-linguistic enforcement — checks that operate at the cryptotype and concept level, not the word level, so they survive the rewriting that LLMs do by default.

3. Agent-native integration patterns — built for pipelines where multiple AI agents handle different stages of the work, not for pipelines built around translator handoffs and segment-by-segment review.

The platform lives at black-ice.ai. It’s in active development with a small but growing group of users.

Why “the layer before the TMS” is the wrong mental model

I used to describe Black Ice that way. It sits upstream of your TMS. It feeds clean, governed source content into your localization stack.

It was a useful explanation for people who needed a familiar shape to attach the idea to. It was also wrong, and I want to be clear about why.

The teams I’m building Black Ice for are not running TMS-shaped pipelines anymore. They’ve moved past them. Not because TMS is bad — translation management systems were the right answer to the problem of coordinating human translators across thousands of segments — but because the problem has changed. When marketing copy doesn’t get translated anymore, when it gets rewritten in market, the TMS abstractions don’t fit.

Consider what a TMS is optimized for:

• Segment-level reuse. Translation memory pays off when source segments repeat. They don’t, in agentic rewrite workflows.

• Linear handoffs. Source author → TMS → MT → post-editor → reviewer → QA. Each step is a discrete job with a defined input and output. Agentic pipelines aren’t linear; they’re loops with branching, retries, and parallel paths.

• Translator-centric tooling. CAT tools, concordance search, fuzzy matches. Useful for human translators working segment by segment. Mostly irrelevant to a pipeline where an agent generates a French marketing variant from a brief and a brand profile.

• String-level QA. Catching repeated errors across similar strings. Doesn’t fire when every output is freshly generated.

None of this is wrong, for the work it was designed for. It just isn’t the work the new pipelines are doing.

What does the new pipeline actually look like?

There isn’t one shape. There are three, and Black Ice governs all of them — which is the point. The same ontology, the same market profiles, the same governance rules, applied to three very different generation modes.

Mode one: marketing campaigns generated from scratch

A trigger arrives. A piece of marketing content needs to exist in five markets. An agent reads the brief and the brand profile. Another agent retrieves relevant context — past campaigns, regulatory notes, market guidelines. A drafting agent writes the local version directly in the target market, working from the concept rather than from a source string. A market-fit agent checks tone and cultural register. A compliance agent checks regulated terminology and market-specific disclosure rules. A coherence agent reconciles any mismatches across markets. The output goes to QA already local, already governed, already coherent.

There’s no source-target alignment. There’s no segment-by-segment translation. There’s no fuzzy match. There’s no handoff to a post-editor. The “translation memory” of this pipeline isn’t a database of past segments; it’s a knowledge graph of past meanings.

Mode two: product strings translated directly from the repo

This is the mode that surprises people, because it looks closer to traditional localization on the surface. It isn’t.

A repo holds your product strings — JSON, YAML, ARB, .po, whatever your i18n framework uses. An agent pulls the source strings, respects the placeholders, respects the format, respects the length constraints (because a German label that overflows a button breaks the UI), and generates the localized strings directly into the target locale files. The previously-translated strings in the repo become the working memory of the pipeline — the repo is the TMS, in the sense that consistency, prior decisions, and stable terminology all live there as committed history rather than in a separate database.

What governs this mode isn’t fuzzy matching. It’s the ontology. When the agent encounters a string referencing a concept that’s market-restricted, governed by disclosure rules, or expressed differently in a specific market profile, the rule fires from the same ontology that governs the marketing pipeline. Same substrate, different surface.

Mode three: conversational multilingual experiences

Chatbots, voice assistants, customer support agents, in-product AI assistants. Anything where the system generates output in real time, in multiple languages, in response to live user input.

This is the mode where TMS thinking breaks down most visibly, because there’s nothing to pre-translate. The system is generating fresh language at runtime, in whatever locale the user happens to be in, often pulling from RAG retrieval that may itself be multilingual. The governance can’t be applied after the fact — the user sees the output the moment it’s generated.

What this mode needs is an ontology that the model can consult during generation: which concepts are approved for this market, which require disclosures, which are off-limits in this brand vertical, which have a specific endorsed surface form in the user’s locale. The same ontology that governs campaigns and product strings, exposed to the conversational system at inference time.

Mode four: QA on assets you already have

The fourth mode is the one most teams will adopt first, because it requires changing nothing about your existing pipeline. You point Black Ice at content that already exists — translated marketing pages, localized product strings, support articles, chatbot training data, whatever you have — and the ontology surfaces what the human eye and the standard QA tools miss.

The kinds of things that come up:

• Terminology drift. The same concept rendered three different ways across three pages in the same market, none of them flagged because they all sound fine in isolation.

• Mentions of features not available in this market. A Spanish landing page describing a payment option that’s restricted in es-ES, a German support article referencing a feature gated to en-US, a French chatbot promising functionality that requires a US-only integration.

• Style and tone drift. A market profile that calls for formal address but content that has slipped into informal, or vice versa. Mixed registers within the same asset. Brand voice that holds in one section and dissolves in the next.

• Disclosure gaps. Regulated concepts present in the copy with the disclosure language missing, abbreviated, or rewritten into a softer form that no longer satisfies the requirement.

• Cross-market inconsistency. The same campaign telling subtly different stories in different locales — not because the markets need different framings, but because each was localized in isolation without a shared concept layer to anchor against.

This mode doesn’t require an agentic pipeline at all. It’s a way to apply semantic governance to the content estate you’ve already built, find the issues that have accumulated invisibly, and decide what to fix. For a lot of teams, this is the entry point — you start by auditing what you have, then graduate to governing what you generate next.

What ties the four modes together

There’s no source-target alignment in mode one. In mode two, there is — but it isn’t the unit of governance. In mode three, there’s no source at all, just a generated turn. In mode four, there’s no generation happening at all — just inspection of what’s already been produced.

Four modes, four different relationships to “source” and to time. All four need the same thing: a shared, enforceable understanding of what every concept means in every market, accessible to whatever system is doing the generating, translating, conversing, or auditing. That’s not a glossary. That’s not a TMS module. That’s an ontology with governance teeth.

What does “semantic governance” mean in an agentic context?

Semantic governance is the practice of enforcing rules about meaning — what a concept is, where it’s allowed, how it relates to other concepts, which markets approve it, what disclosures it triggers — independently of the specific words used to express it.

In a TMS world, governance happens at the string. You approve a translation, you save it, you reuse it. The unit of control is the segment.

In an agentic world, the string is ephemeral. Every output is fresh. The unit of control has to move upstream, to the concept itself. That’s the only level at which a governance rule survives the constant rewriting.

A traditional terminology system says: translate “Buy Now, Pay Later” as “Compra ahora, paga después” in Spanish.

A semantic governance system says: the concept of deferred-payment-installment is approved in your en-US, en-GB, es-ES, de-DE, and fr-FR markets, but the governance rules around it diverge sharply. In de-DE and fr-FR, from 20 November 2026 the concept falls under CCD2 and any agent generating content involving it must include the pre-contractual creditworthiness disclosure and the right-of-withdrawal notice — regardless of how the surrounding marketing copy is rewritten. In en-GB, the concept is mid-transition under FCA regulation and requires the “credit agreement, may affect credit score” framing rather than the previously-acceptable lifestyle framing. In en-US, the concept is permitted with state-level disclosure variation. The concept is forbidden entirely in your under-18 vertical across all markets. The lexical surface is at the discretion of each market profile, but the disclosure obligations are non-negotiable and enforced at the concept layer, so an agent that paraphrases the offer into a softer phrase like “split your payment” still triggers the same governance rules.

That rule survives paraphrasing. It survives a brand voice update. It survives the agent deciding to rewrite the entire paragraph. It survives the addition of a sixth market next quarter. The rule isn’t tied to a string; it’s tied to the concept.

This is why agentic pipelines need a substrate, not a checkpoint. The agents are constantly making local decisions. Governance has to live in the layer they’re all reading from.

What QA looks like when meaning is governed upstream

This is where the pipeline shift becomes visible to people who’ve spent careers in localization, and it looks different across the four modes — but the underlying logic is the same: human reviewers stop catching the failures the ontology already prevented or already surfaced, and start spending their time on judgment.

In a traditional pipeline, QA reviews source-target pairs. The reviewer looks at the English, looks at the Spanish, decides whether the Spanish is a faithful and well-rendered version of the English. Faithfulness is the implicit standard, and a large share of the reviewer’s time goes to catching governance failures — wrong terminology, missing disclosures, restricted feature names — that a glossary couldn’t prevent.

In a Black Ice-governed pipeline, the picture changes by mode:

• Mode one (campaigns from scratch): there’s no source string for the Spanish to be faithful to. The reviewer judges the Spanish as Spanish — as local content for the local market, with the correct concepts, correct disclosures, correct register. Governance failures don’t reach this stage because the ontology fired upstream.

• Mode two (repo strings): the reviewer is still working with source and target, and format/length/placeholder fidelity still matters. What changes is what doesn’t reach them: terminology drift, feature mentions invalid for the target market, disclosure gaps. Those were caught and resolved by the time the strings landed in the locale file.

• Mode three (conversational): there’s no human in the loop at runtime, by definition. The reviewer’s job moves earlier — auditing the ontology, sampling generated turns, tightening rules. Governance is the only QA there is, because the user sees the output the moment it’s generated.

• Mode four (audit on existing assets): Black Ice itself is performing the QA. The reviewer’s job is triaging the issues it surfaces — deciding which terminology drifts to fix, which feature mentions to remove, which tone slips matter — and turning those decisions back into ontology rules so the same issues don’t recur.

Across all four modes, the shift is the same. QA stops being the place where governance failures are caught one by one. It becomes the editorial layer where humans bring judgment to material that’s already structurally sound, or to issues that are already systematically surfaced.

That’s the shift. And it’s the shift Black Ice exists to make possible.

What Black Ice is not

Worth saying explicitly, because the framing keeps coming up:

• It’s not a TMS. It doesn’t manage projects, files, or translator assignments.

• It’s not a translation memory. It doesn’t store source-target pairs. The pipelines it serves don’t need them.

• It’s not a glossary or termbase. It can read TBX-compatible termbases as input, but the ontology layer is richer than what a termbase represents.

• It’s not a downstream QA-only tool. Black Ice can audit existing content (mode four), but its job goes well beyond review: it governs generation across campaigns, product strings, and conversational systems. Bolt-on QA tools can’t do that.

• It’s not a prompt library. Prompts are stateless instructions to a stochastic system. Governance has to be enforceable and auditable in ways prompts alone aren’t.

• It’s not a model. Bring your own LLM. Bring your own agentic framework. Black Ice is the meaning layer underneath them.

If your current pipeline is working well with TMS, TM, and a good termbase, you don’t need Black Ice. The framework is built for teams whose pipelines have already shifted, or are visibly about to.

The theoretical foundation, briefly

I write about this at length elsewhere — and now, specifically, in The Frost Line — but the short version of the intellectual scaffolding:

Linguistic relativity, in its defensible form. Languages package experience differently. Two markets aren’t two word lists; they’re two conceptual carvings of the same domain. Governance has to operate at the layer where those carvings happen, not at the surface.

Whorf’s cryptotypes. The pre-linguistic structures that shape how meaning gets assembled. This is the layer Black Ice operates on, which is why governance survives paraphrasing.

Lakoff’s embodied metaphor. Concepts are organized by metaphorical mappings rooted in physical and cultural experience. Mappings differ across cultures, which is why “frictionless checkout” lands differently in different markets even when the words translate cleanly.

Hofstede’s cultural dimensions, used operationally. Not as theory, but as actual parameters in market profiles — power distance, uncertainty avoidance, individualism — that shape whether content is appropriate for a market.

ISO 30042 (TBX) compatibility. Existing terminology work flows into the ontology rather than being thrown away.

Who is this for?

If you’re running any of the following, the framing in this post probably already matches your pipeline reality:

• Agentic localization workflows where multiple AI agents handle different stages of content production.

• Multilingual AI assistants in regulated industries — finance, healthcare, legal, public sector — where concept-level governance is non-negotiable.

• LLM-powered content adaptation across many markets where TMS-style segment reuse no longer applies because the model rewrites everything.

• RAG systems serving multilingual knowledge content, where retrieved chunks need to respect per-market terminology and disclosure rules.

• Continuous, fluid pipelines where source content is in constant flux and human review can’t gate every change.

If you’re running a small site translated by one freelancer once a year, you don’t need this. Carry on.

Frequently asked questions

What is Black Ice in one sentence? The semantic governance framework for agentic localization pipelines — the layer that defines and enforces meaning across AI workflows where content is regenerated rather than recycled.

Is Black Ice a step before the TMS? No. It’s the framework for pipelines that have moved past the TMS shape entirely. In those pipelines, governance is the substrate, not a checkpoint.

Does Black Ice replace my TMS? If your team is still running TMS-shaped work — segment reuse, translator handoffs, source-target QA — keep it. Black Ice is for the pipelines that have already shifted.

What does “semantic governance” mean? Governing concepts and their market-specific rules independently of the specific words used to express them, so the rules survive paraphrasing and rewriting by LLMs and agents.

What is Black Ice used for? Four modes: generating new marketing campaigns from scratch in multiple markets; translating product strings directly from a repo while respecting placeholders, format, and length constraints; powering conversational multilingual experiences like chatbots and voice assistants; and auditing existing localized content for terminology drift, restricted feature mentions, disclosure gaps, and tone inconsistency.

Why does QA look different in this model? Because the failures QA used to catch one by one — terminology drift, missing disclosures, restricted features, register mismatches — are either prevented upstream by the ontology or surfaced systematically by Black Ice itself. Reviewers spend their time on judgment, not on hunting for governance issues.

Does Black Ice work with my existing termbase? Yes. ISO 30042 (TBX) data flows in as one input to the ontology.

Where do I read more about Black Ice specifically? The Frost Line, the dedicated newsletter as of this post, or Black Ice’s own Knowledge Base.

Where do I read about localization and AI more broadly? Right here, in The AI-Ready Localizer. That’s not changing.

Closing — and a clear last call

To make it explicit, because it matters:

From this post forward, every Black Ice deep dive lives in The Frost Line. Product notes, ontology design, agentic pipeline architecture, build-in-public material, semantic governance theory in operational form. If that’s what you came here for, that’s where to follow it.

The AI-Ready Localizer is staying. I’m still going to keep writing — here, regularly — about localization and AI. The industry shifts, the craft questions, the tools, the theory, the day-in-the-life of working in this field as it changes underneath us. None of that is moving. If anything, this newsletter gets sharper now that Black Ice has its own home.

You can subscribe to both. Most of you probably should. But you should know what each one is for.

The line that holds the whole framework together hasn’t changed:

Sounds right isn’t good enough.

In a world where every output is freshly generated, sounding right is the easy part. Meaning right is the work. That’s what Black Ice governs, and that’s what The Frost Line will be about.

— Julia