The AI Native Org Shift: What Alibaba's Engineers Are Actually Worried About

An Alibaba Tech engineer just published one of the most honest pieces I’ve read on what happens to people when an R&D org goes AI-native. Not the productivity numbers. Not the architecture slides. The actual human cost.

Here’s the translation and what it reveals.

The Setup: What They’re Actually Seeing

The article opens with an internal survey of engineers who are heavy AI users. The results are striking:

Time writing code: 30% → 5%
Time talking to agents: 5% → 60%
Query time: down over 50%
Pure coding efficiency: 10x improvement
End-to-end feature delivery speed: only 2–3x improvement

That gap — 10x coding efficiency but only 2–3x delivery speed — tells you where the real bottleneck is. It’s not the code. It’s everything around it.

One engineer described shipping a new feature at 10 AM, running an A/B test by noon, pulling it at 3 PM based on data, and shipping a better version at 5 PM. Same day. That used to take six weeks.

The Conceptual Shift: From Org Chart to Execution Graph

The article draws on Ken Huang’s framing: once AI becomes truly agentic, a company can no longer be accurately described by an org chart. It becomes an execution graph — a live network where people, agents, data, permissions, tools, and approval relationships are equal nodes.

The old question was ownership: who owns this?
The new question is routing + governance: where does intent enter the system? How does it become action? What constraints make that action safe?

This matters practically. Traditional orgs have a minimum unit of “person + long-term relationship network” — high friction, high switching cost, 6–12 month reorg cycles. Execution graphs have a minimum unit of “task + context + permissions + tools” — machine-readable, low switching cost. Reorg cycles compress from quarters to weeks.

The Two-Layer Architecture

Observing genuinely AI-native teams (Anthropic, CREAO, internal Alibaba pioneer groups), the author identifies a consistent two-layer structure:

Bottom layer — Harness: Code, tests, pipelines, documentation, world models. Everything structured for AI consumption. The more structured, the better. AI leads here.

Top layer — Hive Mind: Conversation, experimentation, idea emergence. The looser, the better. Humans lead here.

These aren’t alternatives. They stack. The structured layer exists to release unstructured collaboration — not to control it.

Management Collapse (Not Disappearance)

Traditional managers do roughly ten things: strategy propagation, information aggregation, resource coordination, daily decisions, major decisions, conflict resolution, motivation, coaching, hiring/firing, culture building.

In an AI-native context, these split dramatically:

Automatable: Strategy propagation, information aggregation, resource coordination, daily decisions
Changing form: Major decisions (pushed down to DRIs closest to the customer), conflict resolution (volume drops as teams shrink)
Non-automatable: Motivation, coaching, hiring/firing, culture — must stay human
New, barely addressed: Intent coaching, identity rebuilding, combating meaninglessness — didn’t exist before, nobody’s doing it yet

The conclusion: management collapses, it doesn’t disappear. It’s selecting new positions.

The most critical new role is the Architect — the person who designs how AI works. Not writing code. Not shipping features. Designing the execution graph: defining system capability boundaries, writing SOPs, building test infrastructure, defining “what good looks like.”

And critically: this work requires the most experienced people. Good tests require someone who knows the business. Good SOPs require someone who’s done the thing. Good judgment requires someone with taste. This is senior engineering work — and one Architect’s output gets multiplied across N agents, multiple domain teams, multiple projects.

The Real Bottleneck: Information Shape

Here’s where it gets uncomfortable.

The article cites a large internal survey of employees who are already heavy AI users and want to go deeper. Across every dimension they were asked about, one thing dominated their requests — not model capability, not response speed — but system integration and data access.

Their specific pain: AI can process anything they give it. But it can’t reach the systems where their actual work lives — project management tools, data platforms, engineering systems, email, approval flows.

The result: employees become human middleware. They manually export data from each system, paste it into AI, then manually carry AI output back to the business system. They’re doing the integration work a machine should do.

The information shape of traditional systems was designed for humans — not for AI. All the implicit conventions, undocumented constraints, oral traditions that senior engineers quietly fill in every day… AI can’t guess. AI needs structured, queryable, executable, deterministic information.

This is the new bottleneck. Not AI capability. Not model quality. The information shape has a human bias. And the cost of that bias — previously absorbed invisibly by skilled people — is now exposed.

Section 08: What About the People?

This is the section the author says “can’t be avoided.” And it’s the most honest thing I’ve read in a tech org piece in years.

The Distillation Anxiety

Every time an engineer writes a new SOP, teaches AI a workflow, documents a process — they’re exporting their knowledge into organizational assets. It feels like collaboration. Structurally, it resembles replacement.

The author names this “distillation anxiety” — the slow realization that the more you contribute to the Harness layer, the more redundant you may become. When employees feel this, they start hoarding knowledge. The critical people who know the implicit constraints don’t share them. Harness work — which requires people to articulate hidden knowledge — becomes impossible. The best people leave first (they have the most options). What remains is a risk-averse followership. And the transformation fails.

The Training Pipeline Break

The old career path was clear: day 1, write simple code → years later, write complex code → design systems → set strategy. Each step was a direct extension of the previous one.

AI breaks this continuity. Day 1, AI is already writing the code. So what should a day-1 human do?

The most unsettling possibility: entry-level positions may simply disappear. Each company not hiring juniors is a local optimization. But if the entire industry stops hiring juniors, in three to five years the senior talent pool starts drying up. That’s an industry-level disaster.

The Feedback Loop Nobody’s Talking About

When some companies start using AI to replace rather than amplify people, competitive pressure pushes others to follow. The senior pool gets slowly consumed. The Architect reserve thins. Everyone unknowingly accelerates in the direction of “death of expertise.” In a few years, the entire industry’s judgment capacity gets hollowed out simultaneously.

What to Do About It

The author doesn’t pretend to have complete answers, but offers several directions to avoid the worst:

Be explicit about how AI productivity gains are shared. Is this expanding organizational capacity to do things you couldn’t before — or shrinking headcount? These send completely opposite signals.
Build real transition mechanisms. Architect tracks, cross-domain DRI roles, new business ownership — not just slides at an all-hands.
Classify honestly. Which roles are structurally changing? Vague reassurance causes more damage than clear honesty.
Redesign performance systems. If you say “judgment matters more than output” but your KPIs still measure output volume, nobody believes you.

“AI Native transformation isn’t about scheduling people as capability units — it’s about leaving room for what exists beyond capability.”

The “Death of Ego” Problem

The article pushes back on a fashionable phrase: “death of the ego.” It distinguishes two types:

Defensive ego: Protecting territory, hiding failure, avoiding accountability. This is what should die.
Productive ego: “This is mine to figure out.” “I don’t accept this answer.” “I can’t sleep until this is solved.” This is the engine of innovation.

Innovation requires months of sustained attention anchored by ownership. It requires willingness to look stupid publicly. It requires stubbornness during dead-end periods. It requires maintaining contrarian positions inside a consensus Hive Mind.

AI, by architecture, can’t do any of this. Transformers are stateless — they fundamentally don’t support “staying invested in a problem for months.”

Conclusion: Apply three different governance models to three types of work:

Execution work: Kill defensive ego, maximize transparency
Optimization work: Suppress ego, but preserve critical thinking
Innovation work: Protect semi-formed ideas, actively maintain productive ego, semi-private environments, no forced broadcast

Organizations that apply “death of ego” uniformly get execution efficiency + innovation death.

The Three-Pillar Platform

For the structural answer on how to organize, the article endorses Ken Huang’s three-pillar model:

Pillar 1 — Agent Platform Group: Central team. Runtime standards, permissions, logging, observability, evaluation harness, secure deployment. “Not AI research in the romantic sense — it’s production engineering plus governance.” This is the organizational form of the Architect role.

Pillar 2 — Domain Teams: Business units. Own outcomes, not models. 3–5 person vertical functional teams.

Pillar 3 — Risk and Oversight: Governance layer. Defined explicitly as “an immune system rather than a bureaucratic brake.” When governance is done well, it doesn’t slow the Hive Mind — it keeps it alive. The article is unusually direct here: “Assuming nothing will go wrong is not optimism. It’s negligence in a world where mistakes can propagate quickly.”

Open Questions (With No Good Answers Yet)

The article ends honestly:

AI trust gap in high-risk decisions: Code review and defect analysis — AI output still needs human sign-off, but humans can’t keep up. Neither path works.
Performance system failure: Old evaluation relied on manager observation. New evaluation needs artifact visibility + proactive recognition. That infrastructure doesn’t exist yet.
Are 3–5 person teams a permanent state or a temporary anomaly? Three conditions might be making them work right now that won’t hold: explorer effect, transitional human requirements, editorial review value.
AI knowledge asset inheritance. When an engineer leaves after months of building and training agents, what happens? No company has a complete answer.

The Key Judgments

Worth keeping:

Harness work is unglamorous but it’s the compound interest on your organization’s future speed. Early vs. late isn’t linear — it’s exponential.
Don’t treat AI-native transformation as another reorg. The real value is making painful reorgs unnecessary forever.
Solve the Architect incentive problem. Convert “threatened senior engineers” into “empowered Architects” — give them identity, authority, resources.
Start an agent roster. You cannot govern what you cannot name.

Original article: 《AI Native 时代 —— 研发组织何去何从》by 许晓斌, Alibaba Tech. Published May 2026.