Don’t Hide Behind Job Titles: Why AI Doesn’t Rank Danger by Profession — Lessons from Yao Shunyu’s Framework

Why AI Will Eat Programmers Before Product Managers

If you’re still judging AI risk by job titles, stop for a moment.

In an interview, Yao Shunyu offered a counterintuitive insight: AI transforms fastest not the jobs humans perceive as simple, but the jobs with the clearest feedback signals.

Applied to professions, the most striking example is programmers.

Many once believed AI would first replace repetitive, low-barrier, standardized work — customer service, simple copywriting, data entry. Those sound far more automatable than programming.

Programming requires high cognitive ability and involves complex systems. By that intuition, it shouldn’t be at the front of the line.

Yet the first profession to have its work reshaped by AI tools is precisely the code world. Cursor, Claude Code, Copilot, and various coding agents made many people realize for the first time that AI isn’t just chat — it’s actually starting to take over chunks of work.

But Yao precisely identified AI coding as one of the first explosive native AI scenarios. The reason isn’t that coding is low-skill, nor that product management is more advanced; the key is that the code world has tests, compilation, runtime results, logs, and version history.

After a model completes its work, the environment tells it where it went wrong.

AI doesn’t queue up by occupational prestige. It enters those tasks that can be clearly defined, rapidly verified, and cost-effectively corrected.

Programmers are just the first row. What AI is targeting is the verifiable execution layer within every profession — tasks that can be broken down into inputs, outputs, standards, and feedback.

Job Replacement Rankings Are Too Coarse

In recent years, discussions about “who AI will replace first” have easily devolved into league tables.

Where do programmers rank? Product managers? Designers, operations, consultants, lawyers, accountants? This game is fun because it’s simple — like watching a stock chart. Everyone wants to know if their own profession has already broken down, and whether the adjacent profession is falling first.

But job titles are far too coarse.

Take “programmer.” Some programmers receive well-defined requirements, modify a local function, run tests, and submit code. Others must understand business goals, decompose system boundaries, decide which dependencies cannot be touched, and ultimately be responsible for the entire system’s outcome.

Take “product manager.” Some PMs write PRDs from templates, compile meeting minutes and competitor screenshots. Others must determine where users are stuck, define metrics, coordinate resources, and own feature trade-offs.

These two groups are covered by the same job title. Asking “will programmers be replaced” or “will product managers be replaced” is like asking “will cars break down?” Trucks, race cars, taxis, and bicycles are all crammed into one word — the answer is inevitably muddy.

This is where Yao’s insight becomes useful. It shifts the question from job title to task structure:

• After a task is done, can the environment tell the model whether it did it correctly?
• Can that signal be repeatedly collected, trained on, and corrected?
• If it fails, can you retry at low cost?

You can call this task evaluability. The clearer the success/failure signal, the easier for AI to learn. The noisier, slower, and more subjective the feedback, the harder for the model to improve stably.

So AI doesn’t know your job title. It doesn’t care whether you’re called an engineer, product manager, operations analyst, or strategy analyst in your company’s system.

It only cares whether the task can be defined, executed, verified, and iterated upon after failure.

The Code World Is Like a Pre-Built Training Ground

Writing code is hard for humans, but friendly for training systems.

This might sound odd. We’re used to equating “hard for humans” with “hard for machines.” But a model’s learning difficulty and human occupational prestige don’t share the same coordinate system.

For a model, the difficulty isn’t just the task’s complexity; it’s also whether the environment can push back error signals promptly.

The code world is remarkably generous in this regard. After you write a piece of code, signals abound: does it compile? Do tests pass? Type check errors? Does the runtime output match expectations? Are there log anomalies? Performance regression? Which files changed in version history?

Many of these aren’t human subjective evaluations — they are direct feedback from the toolchain.

If a coding agent modifies a function and a test fails, it at least knows where the failure is. If a command doesn’t run, it sees the error. If dependencies are misaligned, it can read the dependency configuration. If the change breaks another module, version control and tests expose the impact.

Of course, this process still requires human review. But it’s already much closer to a “do a step, see feedback, fix a step” loop than many knowledge work tasks.

Beyond that, GitHub and the open source ecosystem provide the code world with a massive corpus of tasks, contexts, and modification histories. A model doesn’t just see final answers — it sees how others filed issues, fixed bugs, conducted code reviews, and iterated around a repository.

A repository itself acts like a state machine: files, commits, tests, discussions, and documentation capture the full context.

Good code still has subjective aspects — architecture elegance, naming conventions, abstraction levels — these can’t be fully auto-judged. But compared to many product decisions, code still forms a more repeatable quality standard.

Does it run? Does it pass tests? Does it introduce obvious regressions? Does it meet interface constraints? These signals allow models to practice repeatedly.

So programmers standing in the front row isn’t because the job is low-end. Quite the opposite: software engineering is complex enough to provide AI with abundant learnable signals.

The code world is like a pre-built training ground: problems, context, tools, error prompts, rollbacks, and retrospectives all readily available.

This also explains why the experience of coding agents feels so rapid. The key isn’t just that the model “can write code” — it’s that it’s placed in an environment where it can continuously correct itself.

Write wrong → see it → fix it → run again.

Product Manager Isn’t Safe; It Just Has Messier Feedback

Does that mean product managers are safe?

No.

This is a common misunderstanding: programmers are in danger, product managers are safe for now. That take is too cheap and doesn’t match Yao’s original point.

Within product management work, there are plenty of structured subtasks that will be transformed by AI:

• Writing PRDs
• Organizing user interviews
• Summarizing meetings
• Generating competitive analysis
• Doing initial data screening
• Breaking down requirements lists
• Creating tracking plan specifications
• Generating prototype descriptions

These tasks already have templates, inputs, outputs, and delivery formats. They won’t remain purely manual for long.

There’s a cruel dividing line here:

Are you writing documentation, or are you defining the problem? Are you organizing what someone else has already clarified, or are you turning something unclear into judgment criteria?

The former increasingly looks like an execution task. The latter is closer to the responsibility of a product manager.

But what Yao calls difficult is complete product judgment. In his interview, he repeatedly pointed to one problem: the reward signal for good products is unclear.

In plain English: after you make a product decision, it’s very hard to know immediately whether it was right.

When a feature ships, will users adopt it? Why won’t they? Is the entry point too deep? The copy unclear? The need invalid? Or is the market timing off?

When a retention metric changes, is it due to the feature, or is it mixed up with channel activity, seasonality, competitor moves, pricing, or brand?

When a product direction seems to fail, was the judgment wrong, or did resources fall short, or did organizational execution distort it?

Product feedback is often late, noisy, and subjective. Late because it takes time to manifest. Noisy because too many variables are mixed in. Subjective because user psychology, aesthetics, organizational goals, and business trade-offs all enter the judgment.

You only know if it’s good after it’s out, and often not at a glance.

So the product manager’s moat isn’t writing documents or running meetings. Documents will be generated, meetings summarized, competitors organized, data pre-screened.

The part of a PM that’s hard to fully train is turning ambiguous goals into verifiable problems, criteria, and trade-offs.

The distinction between programmers and product managers is not “who will be replaced, who won’t.” A more accurate view: the code world earlier exposed how all knowledge work will be restructured. The core judgment work in product is harder to train, but its peripheral execution layer will be restructured just the same.

After AI Efficiency Gains, Work Doesn’t Necessarily Decrease

Many assume that once AI writes code, programmers will have an easier time.

That expectation is natural. A feature that used to take two days can now be done in half a day. The remaining time should be yours — you can leave early, think more about architecture, or finally write that overdue documentation.

Sounds great.

But when Yao talks about AI coding, the feeling he describes is closer to another outcome: when ideas become implementable faster, people run more experiments, try more approaches, and make more decisions.

What AI efficiency first changes is the cost of trying. When the cost of trying falls, a high-competition environment rarely gives you the saved time — it fills the same day with more attempts.

If one approach took two days, a team might try only one. Now you can try three in an afternoon. Naturally, leaders, colleagues, and you yourself will ask: why not try more?

If fixing a bug used to be laborious, everyone might tolerate it. Now that the model can locate and fix it quickly, more edge-case issues get added to the backlog.

If nobody dared to launch many experiments because each required human effort, now with lower cost, the judgment burden rises.

Work doesn’t disappear; it shifts from “manual implementation” to “defining tasks, organizing context, reviewing results, comparing approaches, and accepting verification responsibility.”

Your hands type less, but your brain opens more windows. It’s like running many threads in a system — each thread is fast, but you’re responsible for scheduling, preemption, rollback, and priority decisions.

This won’t happen only to programmers. Any profession that can break execution into small loops will be pushed faster by the same force.

Operations can generate campaign plans faster. Researchers can organize literature faster. PMs can write requirements and prototypes faster. Creators can generate multiple headlines and versions faster.

When every step speeds up, the result isn’t necessarily more leisure — it’s higher work density.

AI may not make people unemployed first. It may first make the same job denser.

This is a shift many already feel but haven’t articulated. The better the AI tools, the less work seems to disappear and the more it seems to compress. Where you once ran one version per day, now you review three. Where you once just delivered a result, you now also explain why you chose this result, why not the other two, and where iteration could continue.

The Real Danger Is the Verifiable Execution Layer

The question isn’t whether programmers will disappear. That question is too large and too contentious.

Some will cite top engineers — they certainly aren’t replaceable. Others will cite junior positions — many local implementations have already been taken over by models.

Both sides can find examples, and the argument over job titles continues.

A more useful question: within a profession, which parts are simply performing localized execution under well-defined standards?

People who only take local tasks, write local implementations, cannot define requirements, cannot review cross-file impact, and cannot own system verification — their value will be compressed.

This isn’t necessarily because they aren’t hardworking. It’s because their work increasingly resembles tasks that can be sliced, dispatched, and reclaimed.

As long as a model can get enough context and receive feedback through tests, compilation, logs, and code review, it will keep approaching this execution layer.

The same risk exists in product roles.

People who only write PRDs from templates, organize materials, do shallow competitive analysis, or package others’ words into pages will also be compressed. These tasks can be broken into inputs, outputs, and format requirements, can be quickly verified, and can be redone at low cost.

Yao’s insight translates directly into occupational risk: AI prioritizes not a job title, but the verifiable, decomposable, low-cost-to-correct execution layer within a job.

Taking it one level deeper, three indicators emerge:

1. Verification speed: How quickly do you know if you’re right or wrong after finishing?
2. Correction cost: Can you quickly redo if wrong?
3. Responsibility position: Are you executing standards or defining standards?

The higher the first two, and the lower the third, the closer the risk.

If your work can be broken into inputs, outputs, standards, and feedback, it starts to look like code.

This is more precise than “programmers are in danger” and harder to dodge, because it pulls all professions into the picture.

Operations has parts that look like code. Research has parts that look like code. Consulting has parts that look like code. Design has parts that look like code. Product has parts that look like code.

What “looks like code” means isn’t about the output being code — it’s about the task structure: clear inputs, clear outputs, clear verification, low redo cost.

Whenever this structure appears, AI has a training ground.

Job titles give a false sense of security. You think you stand behind an industry, a role, a title.

But AI sees a different map: where are the clear tasks, the feedback signals, the failure-correctable paths, the structured contexts?

Human Value Shifts Toward Feedback Responsibility

What gets compressed is pure execution, not everyone’s value.

The question is: have you started migrating from the execution layer to the feedback layer?

Human value moves both upstream and downstream. Upstream: defining tasks, organizing context, setting boundaries. Downstream: reviewing results, designing verification, owning trade-offs.

The middle — pure execution — will be increasingly taken over by AI workers.

By AI worker, I mean an AI entity you can dispatch to do specific tasks. It could be a coding agent, an assistant that organizes information, a tool that runs analysis, a model that generates proposals.

It’s not a traditional employee, but it will occupy more and more execution positions.

The migration path for programmers is clear. Their value used to lie heavily in manual implementation: understanding requirements, researching context, designing solutions, writing code, debugging, delivering.

With AI, this chain reshuffles. Humans must become better at defining task boundaries, providing sufficient context to the model, knowing which files cannot be touched, knowing how to verify results, understanding whether a local change might affect the rest of the system.

This doesn’t mean writing code is unimportant. If you can’t read code, you can’t review what the model writes. If you don’t understand the system, you can’t tell when the model is hallucinating.

But writing code is no longer the sole center. What’s more scarce is the ability to organize a team of AI workers to do things and then take responsibility for the outcome.

The migration path for product managers is similar. A PM’s value isn’t in expanding a single requirement into three pages of documentation. It’s in turning ambiguous goals into verifiable problems, metrics, experiments, and retrospectives.

Can you determine what “the user wants” actually means underneath? Can you break a direction into several low-cost validation steps? Can you define success criteria? Can you judge, when data looks bad, whether the direction is wrong, the execution is wrong, or the feedback isn’t yet sufficient?

An unwinnable verification task is the highest-priority problem (P0) in AI collaboration.

If a task has no success/failure standard, it’s hard to hand to AI for stable execution. If you tell a model “make it better,” it can only guess.

If you tell it “modify this interface to pass tests and not change existing callers,” it has boundaries.

If you tell it “write a better product proposal,” it can only rely on common sense.

If you tell it “propose three hypotheses for the decline in new user day-1 retention, each with metrics, experiments, and failure criteria, and each verifiable within two weeks,” then real collaboration becomes possible.

The next scarce resource is no longer just people who can write code or understand products. It’s people who can manage AI workers.

And management here is not about meetings, giving orders, or traditional management roles.

Management means: define goals, allocate tasks, provide context, identify failures, update standards, and ultimately take responsibility for the outcome.

You are not safe because you stand above AI. You are safe because you are responsible for what AI cannot yet stably handle: goals, standards, trade-offs, and verification.

Don’t Start by Asking: Should I Learn AI Coding or Product?

So don’t start by asking whether learning AI coding is safer, or learning product is safer.

That question still stops at job titles.

It’s like asking “should I buy tech stocks or consumer stocks” without looking at cash flow, valuation, industry cycle, or management quality. Job titles are just stock tickers; the underlying asset determines the risk.

Instead, ask yourself five questions.

First: Can your result be automatically verified? Code can run tests, spreadsheets can be reconciled, data can be validated, formats can be checked, deliverables can be scored clearly. Tasks like these are easier for AI to practice.

Second: Can the task be broken into small loops? If a big goal can be decomposed into many small tasks, each with input, output, and completion criteria, it becomes easier to parallelize across AI workers.

Third: Is the context structured? Documentation, code, data, history, interfaces, constraints — if they are clear, AI can take over more easily.

If the context is all in one person’s head, the model can’t work stably. But that doesn’t mean safety; it just means the organization hasn’t extracted the context yet.

Fourth: Can failure be corrected at low cost? If failure can be followed by retry, rollback, retrospect, and retry again, AI will improve faster.

If failure costs are high and feedback is slow, risk will be exposed later.

Fifth: Do you own the standard-setting and trade-off responsibility?

If the first four answers are “yes” and the last answer is “no,” the part of your job is likely in the front row.

Conversely, if you can define problems, organize context, set verification criteria, and own trade-offs, AI entering the picture will actually amplify you.

You can turn one model into ten execution threads. Turn fuzzy problems into verifiable tasks. Turn failures into the next round of feedback.

People like that won’t disappear because AI can write code or write documents — at least not in the same simple compression.

Job rankings will continue to be popular. The reason is simple: they compress complex task risk into identity fate, easy to share, easy to take sides, and easy to give momentary relief.

But the real AI transformation doesn’t follow that logic. It doesn’t first ask your job title. It asks whether your work can be evaluated, replayed, and redone.

What Yao’s insight leaves us isn’t an occupational ranking. It’s a more sober framework:

Don’t treat your job title as a shield. Don’t treat any tool as a disaster itself.

AI’s order of job reshaping is like searching for the clearest feedback signals.

Where a task can be defined, where the process can be observed, where the result can be verified, where failure can be corrected cheaply — that’s where it will accelerate first.

Programmers are just the first row. The question is: is your work being reshaped into the shape AI likes?

References

This article draws heavily on the long interview Zhang Xiaojun conducted with Yao Shunyu. The understanding of AI coding, product judgment, feedback signals, and work restructuring comes from that public interview. I am responsible for translating those insights into a framework for occupational risk and personal work methods.

• Zhang Xiaojun / Yao Shunyu interview: Let Me Go a Little Crazy! Training Models at Anthropic & Gemini
• Cursor official documentation: Cursor Docs
• Anthropic official documentation: Claude Code Docs
• GitHub official documentation: GitHub Copilot; GitHub Docs on repositories, issues, pull requests, reviewing proposed changes
• Productboard: Product Requirements Document glossary
• Atlassian: Understanding incident severity levels