Julia Roberts once talked about Chinese Mahjong in an interview and said something brilliant: “To create order out of chaos based on random drawing of tiles.”

You start with a messy hand, cannot see anyone else’s tiles, and can only draw one and discard one each turn. Under extreme information asymmetry, you gradually shape your hand toward a target pattern. You cannot control what you draw, but you can decide what to wait for, when to change strategy, and when to abandon a flush and go for a basic win.

This is almost exactly what it feels like to write code with AI today.

A Stable Boy Is Not a Horse Tamer

AI is like a wild stallion. Immensely capable, but not always obedient, and it occasionally runs you into a ditch. So many engineers naturally fall into a pattern: tuning prompts, adjusting parameters, handling hallucinations, formatting output – day after day, tending to this horse.

This reminds me of the Monkey King in Journey to the West. The Jade Emperor gave him a job managing the imperial stables – feeding, shoveling, watching the horses. He was furious about the lowly title and wrecked Heaven in protest.

But the problem was not that tending horses is without value. The problem was that the stable boy’s job description had no “destination” in it.

A stable boy serves the horse. A horse tamer serves the destination. One is How, the other is What. If you spend your days crafting more elegant prompts and figuring out how to make AI err less, you are tending horses. If you know what behavior the system must ultimately exhibit, what constraints it must satisfy, and how it should fail gracefully – that is taming.

The Jade Emperor assigning the Monkey King to stable duty was fundamentally a failure of defining the What – putting an immensely capable resource into an extremely narrow role. Of course the output was terrible.

This is the situation many engineers face today: their capability has not changed, but their role definition has. If you still see yourself as “the person who writes code,” then yes, AI is taking your job. But if you are “the person who defines system behavior,” AI becomes your best steed.

What Caps How

This can be stated more precisely: the upper bound of output quality is not determined by how strong the How is, but by how precisely the What is defined.

AI is already powerful as a How – give it clear specs and it generates decent code. But it will not proactively consider edge cases, failure modes, performance constraints, or security requirements. Those need to be defined by a human.

In other words, AI has amplified the leverage ratio between What and How. Previously, a vague What was fine because engineers filled in the details while writing code. Now, a vague What gets faithfully amplified into a pile of correct but useless code.

The people who can decompose fuzzy requirements into precise specs are the scarcest people of the AI era.

Four Shifts in Focus

If What is the core, how does an engineer’s day-to-day change? I see four directions:

From Implementer to Definer

The deliverable is shifting from “code” to “verifiable behavioral specs.” Code is just one means of implementing a spec – AI-generated or configured, either works. The ability to define What is more valuable than the ability to implement How.

From Writing Code to Designing Feedback Loops

How do you know the system is working as expected? How do you auto-correct when it drifts? Using STATUS.md to track context drift, static analysis to catch problems automatically, observability to measure real behavior – designing these feedback loops matters far more than the code itself.

Back to the Mahjong metaphor: the gap between experts and novices is not drawing better tiles. Every tile discarded is an act of information gathering – observing others’ reactions to dynamically adjust your own strategy. That is a feedback loop.

From Individual Contributor to System Orchestrator

This does not mean you stop writing code – it means writing code becomes a much smaller fraction of your work. More time goes to: defining collaboration protocols between agents, designing guardrails, reviewing the correctness of AI output. It is a bit like going from IC to tech lead of a human-machine hybrid team.

From Deterministic Thinking to Probabilistic Thinking

Traditional software engineering pursues determinism – given an input, the output is fixed. But AI systems are inherently probabilistic. Engineers need to learn to design amid uncertainty: how to set an acceptable error rate, how to do graceful degradation, how to ensure overall system reliability when AI output is unpredictable.

Mahjong players have been practicing this from day one: you never know what tile comes next, but you can make optimal decisions amid uncertainty.

Creating Order from Chaos

The word “harness” is well-chosen. It means both “to tame” and “the gear on the horse.” The point is not how wild the horse is, but where you want to go and whether you can direct its power in that direction.

An engineer’s value is not in knowing how to tend a horse, but in knowing the road.

The hardest to replace are those who can create order from chaos. This has always been the essence of engineering. The only difference now is that the source of “chaos” has expanded from complex business requirements to the unpredictable behavior of AI.

So next time someone asks what you do, do not say “I write code.”

Say “I am a horse tamer.”