I was watching the Jensen Huang interview from my office in Hong Kong two days ago, nursing a lukewarm coffee at 11 PM, when he dropped that line: *"AI isn't causing layoffs. Unimaginative executives are."*
I paused the video. I wanted to applaud.
He's technically correct. If you give a team a 10x productivity tool, a creative leader expands output by 10x, not fires 90% of the team. But Huang was standing on a stage in Santa Clara, looking at the world through the lens of a visionary who creates demand out of thin air. For those of us in the trenches—running company, managing product teams, paying rent in Tokyo and Hong Kong—his advice felt like telling a drowning person to swim harder without acknowledging that the pool is draining.
Here's the uncomfortable truth that explains why so many brilliant people are currently updating their LinkedIn to "Open to Work": Let alone the Bullshit job. Most jobs aren't actually jobs. They're translation services.
And translation is exactly what AI just learned to do for free.
The Three Layers of Actually Useful
If you strip away the titles and the LinkedIn theater, there are only three types of work that create value:
Layer 1: Creating the Demand
This is the Steve Jobs moment—holding up a glass rectangle in 2007 and convincing people they want it before they know it exists. This requires a terrifying combination of intuition and risk tolerance. You're not solving a stated problem; you're inventing the category. Maybe 0.1% of people can do this consistently without destroying themselves.
Layer 2: Defining the Requirement
This is where the real money lives right now. Once someone wants the iPhone, you have to define: What does it actually do? What's the battery spec? Which features are in V1 versus V2? How do we measure success?
This is the Architect layer. You're not executing the blueprint—you're drawing it. You're looking at ambiguity (customer pain, market gaps, technical constraints) and crystallizing it into specific, solvable problems.
Layer 3: Fulfilling the Requirement
This is where 85% of us spent our careers. The "Translator" layer.
The software engineer who takes the Jira ticket ("Build login page") and translates it into React components. The lawyer who takes the dispute ("Client wants to sue for breach") and translates it into legal briefs. The marketing manager who takes the directive ("Increase Q3 leads") and translates it into campaign mechanics.
If your job requires waiting for someone to hand you a well-defined requirement, then using your specialized skill to convert that requirement into output—you're a translator. And GPT-4 is a translator that doesn't sleep, doesn't negotiate salary, and doesn't need health insurance.
How to Stop Being a Translator (And Become Useful)
I didn't understand this distinction until I almost became obsolete myself. Three years ago, Mercury was essentially a sophistiaed translation service. Clients came to us with defined problems: "Build us a website." "Migrate our CMS." "Fix our SEO."
We were skilled translators—taking their requirements and converting them into clean code and deliverables. We charged by the hour, which is the perfect business model for translation work. More hours = more value, supposedly.
Then in late 2023, I use ChatGPT to write the Python script that we'd normally charge them forty hours to build. It wasn't perfect code. It was messy, buggy, insecure. But it was *directionally correct*, and it took the AI thirty seconds.
That's when I realized: Being good at execution is no longer a moat.
So over the last three years, I forced myself—and my company—to migrate up the stack. Here's what that actually looked like:
1. Learning to Tolerate Ambiguity
Translators hate ambiguity. They need clear inputs to produce clear outputs. Architects live in ambiguity.
I started forcing myself to sit in meetings where the client didn't know what they wanted. Not just uncomfortable—existentially uncertain. A hospitality client would say, "We need to be more digital." That's it. No specs. No KPIs.
Old James would have pushed for a requirements doc. New James had to learn to say: "I think your real problem is that your loyalty program is leaking high-value guests to OTAs because your current CRM treats a $5,000 guest the same as a $50 guest. Here's how we redefine the segmentation logic..."
I wasn't fulfilling a requirement anymore. I was defining one that they didn't know they had.
2. Making Decisions With Incomplete Data
AI is great at execution because execution requires complete information. You need all the variables to write the function.
But defining problems happens in the fog. You have 40% of the data, a gut feeling, and a deadline.
Three years ago, I made the terrifying decision to pivot Mercury from "digital transformation agency" to "AI infrastructure architect" before we had a single AI client. The data said the old model was dying, but the new model didn't exist yet. I had to build agent architectures before anyone would pay for them. I spent six months burning cash with no proof it would work.
That's Architect work. You're placing bets before the track is built.
3. Cross-Domain Pattern Matching
Translators operate within one domain. The React developer stays in React. The SEO specialist stays in SEO.
Architects steal patterns from everywhere.
When we built the autonomous agent pipeline that migrated 18,000 articles (the 11-agent system I wrote about recently), I wasn't just "doing a CMS migration." I was applying concepts from distributed systems architecture, organizational design theory, and even military command structures (the "special forces" model) to a content problem.
The value wasn't in the code. The value was in recognizing that migration isn't a technical problem—it's an organizational coordination problem, and agents are better coordinators than humans for certain types of repetitive cognition.
4. Owning the Outcome, Not the Task
This was the hardest mental shift. As a translator, you get to say: "I built the feature you asked for. If it doesn't work in the market, that's your problem."
As an Architect, you say: "You need to increase customer retention by 15%. I will define the problem space, identify the intervention points, and deploy the solution. If it doesn't hit 15%, I don't get fully paid."
We moved from billing hours (translation units) to billing outcomes (architectural results). Some months we make less money because we bet wrong. Some months we make 3x because we bet right. But we're no longer interchangeable with software.
What I Actually Did for Three Years
Let me get specific about the last 36 months, because "become an architect" is abstract advice until you see the scars.
Year One (2023): The Panic
I was still selling product/ solution. But I started noticing that clients were using AI to write their own copy, generate their own code snippets, design their own logos. My translation services were being commoditized in real-time.
I started spending my nights reading about RAG architectures, agent orchestration, and knowledge graphs—not because I wanted to become an engineer again, but because I needed to understand where the ambiguity was moving. The execution was becoming automated. The architecture of *what to execute* was becoming valuable.
Year Two (2024): The Brutal Pivot
I fired half my team. Not because they were bad—because they were excellent translators in a world that no longer needed translation.
I kept the people who argued with me about strategy. The ones who said, "I don't think this client needs a new website. I think they need to stop existing." (We lost that client, but gained three who actually needed to exist.)
We stopped taking projects with detailed RFPs. If a client knew exactly what they wanted down to the feature list, they were going to buy a template and an AI subscription. We started targeting clients who said, "Something is broken. We don't know what. Fix it."
Year Three (2025-2026): The New Model
Now we deploy autonomous agents that handle the translation work. The 11-agent migration system I described recently? That's the new model. The agents are the translators. My human team are the Architects who define the problem space, set the constraints, and verify that the outcomes match the business goal.
I spend my days on things that sound vague and unbillable: "defining the ontology of a client's knowledge graph," "negotiating the political implications of a data migration with their C-suite," "deciding whether a problem is worth solving given their budget constraints."
None of this work can be prompted into an LLM because the inputs are too messy, too human, too political. I'm not writing code anymore. I'm defining the problem space such that code *can* be written.
The Hard Truth
Jensen Huang makes it sound like a failure of imagination. It's not. It's a failure of courage.
Walking away from the herd of translators is terrifying. Three years ago, my peers were making steady money building websites and running Google Ads campaigns. I was bleeding cash, learning about vector databases, and wondering if I'd destroyed my company.
The programmers who stayed in the herd—who kept translating Jira tickets into clean code—are currently being optimized out of existence by GitHub Copilot and Cursor. The marketers who kept translating "brand guidelines" into Instagram posts are being replaced by generative tools.
The ones who survived are the ones who stepped into the fog and started drawing maps.
How to Start Today
If you're reading this and recognizing yourself in the "Translator" category, here's the concrete shift:
Stop asking: "How do I execute this requirement better/faster/cheaper?"
Start asking: "Who defined this requirement? What problem are they actually trying to solve? Would I bet my salary that this is the right problem to solve?"
If the answer to that last question is "no," you have two choices: become the person who redefines the problem, or become obsolete.
The pool is draining. Swim upward.
*— James Huang, Mercury Technology Solutions, April 2026*
