AI-Native R&D Organizations: Alibaba Cloud's Early Lessons & Open Questions

Alibaba Cloud's CTO line shares early practices and unresolved challenges in transforming a 6,000-person R&D organization to AI-native, revealing three-stage evolution, seven production pilots with concrete metrics, and the critical need for new human-AI contracts and platform capabilities.

Alibaba Cloud Infrastructure
Alibaba Cloud Infrastructure
Alibaba Cloud Infrastructure
AI-Native R&D Organizations: Alibaba Cloud's Early Lessons & Open Questions

This article recaps the Yunqi Conference "AI Native R&D Organization Forum" hosted by Alibaba Cloud's CTO line. The organization, comprising over 6,000 engineers, has been running a months-long exploration aimed at using AI to solve organizational and collaboration problems—not just point efficiency gains—and openly shares progress, puzzles, and unsolved questions to co-evolve a new organizational paradigm.

1. A Large R&D Organization's Phase Observations in AI-Native Practice

Alibaba Cloud R&D VP Tang Hong reviewed the technology trajectory: late 2022 ChatGPT showed general pre-trained models can solve many problems without per-domain fine-tuning; reasoning models added long-horizon thinking; tool and memory integration enabled Agents that receive goals, plan, execute, read tool feedback, and iterate. He summarizes today's agentic computing paradigm as Model + Harness + Context : Model handles understanding, judgment, and real-time decisions; Context provides comprehensive, unified, continuously updated context; Harness manages autonomous agent execution and continuous evolution.

Three judgments emerged from the exploration:

Agents entering the production pipeline is the true watershed. Only when Agents participate in end-to-end production does potential productivity become real.

AI-Native is not only about cost reduction ("cost reduction is priority one"), but more importantly a leap in competitive dimension.

Three evolutionary stages: Tool-native (individuals use Agent tools well) → Workflow-native (Agents stitch multi-step processes) → Org-native (entire organization works in AI-Native mode).

Cai Liang, CTO-line Organization Development Lead, framed the starting point historically: each era's organization and management respond to that era's technology conditions and capability supply. AI hasn't eliminated scarcity of individual capability, collaboration, or management, but adds a new boundary: humans must now work alongside non-human agents. When Agents take on tasks, new contracts must be built—a continuous exploration process.

The exploration splits problems into two types: "Growth" problems (extreme optimization within existing framework across requirements, product, design, dev, test, release, ops) and "Evolution" problems (disrupt and reconstruct everything between AI capability and customer value).

Execution follows a "North Star, Blank Space, Sandbox" approach:

North Star goal mobilizes and directs innovation, decides where to double down.

Blank Space lets teams cross role boundaries during experimentation without waiting for full management scaffolding.

Sandbox provides a supported trial environment while shielding the main production line.

Observation metrics are for discovery and comparison, not performance appraisal, to avoid over-optimization distortions. Sample-room entry criteria: must run in production scenes, show observable business outcomes, and be reusable.

Early local results (not representative of whole org):

One project cut end-to-end processing time from 2 hours to 5 minutes .

Another delivered dozens of requirements in two weeks , shrinking release cycle from 40 days to 2 days , and produced 10+ production-grade Skills . Two shifts observed: (1) Core assets reconstructing—from artifacts themselves toward conditions enabling trusted regeneration; (2) Next-stage platform needs converging on three directions:

Reliable task execution: Around Harness and "spec-as-code", close gaps in execution constraints, runtime governance, multi-agent orchestration, auto verification/acceptance with hard acceptance gates.

Continuous experience accumulation: Assetize tools, Skills, and MCP; close the loop of experience extraction, evaluation, and versioned evolution; explore capability self-evolution.

Collaboration into the organization: Around multi-agent orchestration and "Agent into org", handle role up-leveling and team blending, Agent identity/permissions, Human+Agent collaboration, end-to-end observability and efficiency analysis, and rational Agent scenario selection.

2. Panel: The New Contract Between Humans and AI

Moderated by Cai Liang with Tang Hong, Han Hongyuan (VP, Public Cloud Solutions GM), and Bian Sikai (Ant Bailing Product & Ops Lead, AAIF Ambassador).

Personal Practice

Tang Hong: "Stay humble, truly learn the new tech. I must use it first, change how I solve problems, then change how peers solve problems. Only by entering the problems do you know what AI-Native really is." Han Hongyuan (non-coder, delivers code to customers): Distinguishes Coding, Programming, Software Development . Coding Agents address the implementation volume, but real software has vast functional and non-functional requirements. Turning code into deliverable, sellable, sustainably operable software leaves huge discussion space. Bian Sikai: "Laying bricks can build a cathedral or a bazaar." Code is raw material in the software service chain. SaaS remains promising—customer needs don't vanish because code gets cheaper. Delivery mode of software will change; coding cost drops but readiness/evaluation requirements may rise. Professional capability demand won't decrease.

What Remains Scarce When Code Gets Cheap?

Han: Cloud-native had Twelve-Factor criteria; AI-Native lacks similar principles. Direction: let AI do everything it can in the org, but North Star metrics must not decline. Software vs program difference lies in run, verify, repeat-verify. Requirements and tests never cover all production issues; AI today can't either. Some programs can be "daily disposable" but real software won't be. Infra software's non-functional requirements, architecture governance, continuous evolution matter far more than writing code—still need long-term tempering. Tang Hong: Scarcity shifts. Cheap code generation exposes other bottlenecks. Traditional waterfall assumed labor most expensive, so heavy upfront design reviews to avoid rework. Now iteration accelerates; heavy process becomes the new bottleneck. Handoffs between roles (PM↔Dev) are slower than machine handoffs. Example: frontend/backend libs used to be separate; slow change was fine. Today both iterate fast—backend moves ahead, frontend can't catch up. Better to put code in same repo and change together. Further out, software definition may need redefinition: from punch cards to assembly to high-level languages, software bridges human intent and machine execution. Future may have a representation more reliable than natural language yet different from traditional programming languages. Bian: Each tech cycle reorganizes roles. Big data created data analysts/scientists—new roles from new tech, but core problem unchanged: customers still need to run business better. Don't drift into thinking Vibe Coding builds enterprise systems. Performance/security engineers remain multi-year trained pros. Workloads shift (REST→Token), system design changes, but structural, security, performance problems persist. Real change is customer-side delivery and customer imagination of new things. Age matters less than openness and scientific discovery.

Professional Boundaries Blurring

Cai: "Professionals do professional work" but boundaries blur. Tech committees, domain standards, role standards getting harder to define. Tang Hong uses sea-level/island metaphor: human expert capabilities are islands; AI coverage is rising sea level. Islands above water shrink. AI still weak in product design, interaction, complex non-functional design, but visibly improving. Hard system problems can be solved jointly via language, tools, engineering systems. AI doesn't solve everything out of thin air; give it proper tools and it enters more domains. Experts won't vanish, but the bar rises. One uniquely human trait: if product is for humans, taste and product sense (good/bad, comfortable/uncomfortable) may be hard to fully automate. Cai: "We'll watch—by your logic that may just be a matter of time."

Deterministic Software vs Probabilistic Models

Han: Some benefits visible—product/dev overlap aids collaboration. Past blockers were handoff friction; without entering each other's domain, handoffs can't be smooth. But models change fast, injecting non-determinism into systems that crave determinism. If your AI app can't leverage a new model's enhanced capabilities, reflect on whether you're truly using AI. Don't lock model to old version. Conversely, stronger code gen ≠ AI replaces humans end-to-end. Example: MySQL has full docs, clear interfaces, known issues. Has anyone used AI to rewrite a better MySQL and actually replace it? No. Compiler runs once; database runs continuously. For infra software, AI writing it once and running reliably long-term is unproven. Han leans conservative. Bian: MySQL is infra to some, application to others (container/OS layer). Today's infra didn't exist in prior eras; there's always deeper infra. We're in a very early, wild-west stage. Model state is inherently unstable—weird outputs may be features, not bugs. It's an irregular brick, more like cement. Brings problems to solve, but also opportunity to rediscover, create, build. Harness same: simple problems solved, next stage needs more testing facing non-determinism. Software is deterministic; human world is not. We used software to converge partial uncertainty into deterministic flows; now using uncertain models for uncertain customer needs requires redesigning the middle layer. "Service as Software" still holds: abstract deterministic parts as Building Blocks, stack with Model+Context to handle uncertain needs. More perspective shift than total upheaval. Engineers can readjust, adapt—not just a "who gets eliminated" question.

What Should R&D Org Change First?

Cai: If you could add one mechanism or remove one, what would it be? Tang Hong: Can't answer piecewise—mechanisms interlock. Most important change: believe the future is coming. Everything could be broken, could be changed. Find an evolution path: break here, adjust there, but keep a viable path. Example: today software boundaries must be precise (I/O, params, versions, compat). Agent era explores API negotiation: ask what you can do, search/select, services converse like humans. Not all software needs this (RPC, MySQL may not). But where uncertainty rises, boundaries may shift. When you believe that future, examine whether current rules can be broken when they conflict. Cai: Stay open. Don't knee-jerk reject new things conflicting with past experience. Han: Two things. (1) Break functional boundaries in dev—more overlap, AI helps enter previously out-of-scope areas. Overlap more, communicate smoother. (2) Software maturity comes from sufficient runs and verification. If code, interfaces, contracts unstable, no repeat verification; each run reintroduces risk. Many non-functional issues only surface in production after extensive customer env validation. Cai: Sounds contradictory—break boundaries yet stabilize contracts. Han: Break human functional boundaries during dev; at system runtime, contracts adjust gradually. You can't write Windows end-to-end today; Windows still needs layered construction. Cai: Boundaries shouldn't stay tied to people, but where they move and what carries them is still unfolding. Bian: If less: stop asking "why doesn't this exist yet" and "is this my job". In chaotic times, missing things are just missing—go write, create. Org boundaries evolve through transition states. Instead of debating ownership, ask: business/customer problem unsolved, can I do more? If more: choose "tools". Lack new tools and new "atomic capabilities". Agent mailing uses Gmail/AliMail, not re-implement IMAP. A good tool encapsulation ≈ atomic capability. Future middleware may come from recomposing these atomic capabilities. Today this is underdone. Engineers weren't encouraged to build such small things; now they may be harder and more important because many capabilities need re-abstraction.

3. Seven Sample Rooms: Practices & Problems in Production Scenes

Seven pilots from product design, code review, code fix, R&D collaboration, ops evaluation, cross-functional collaboration, product ops. Each shows what Agents do, what humans retain, and new issues. Detailed articles to follow.

Product Design Evolution: Human-Led → Human-AI Full-Chain Collaboration

Zhong Yaorong, Product Management Director. Bottleneck shifted from PRD production to product judgment and customer understanding. Built full-chain knowledge system, not just PRD generator. Results: ~2/3 needs no longer need human per-item review; value judgment accuracy >90%; requirement response time -45%; backlog handling efficiency +50%+; ~80% PRDs AI-generated; end-to-end product experience eval from 4 hours to 30 minutes.

Code Review Evolution: General Review → Domain Expert (Kitta)

Zhou Yuanhang, Technical Expert. Data: industry CVE reports +394%, critical vulns +811%; code bug rate +9%, avg PR size +154%, review time +91%. Anolis community two main kernel distros monthly PR merges 8.9× in two years. AI-Native R&D can't stop at AI writing code; need Agentic CI across production, verification, delivery. Code review is first quality gate. In large open-source projects, AI reads code but not the project—lacks domain knowledge, dev conventions, flow rules, when to alert vs stay quiet. Kitta built in three steps: (1) extract review principles, defect patterns, project conventions from GitHub/LKML/repo history; (2) dual-wheel customization—"process defines where to look, knowledge decides how to look"; (3) continuous calibration via offline eval and online behavior. Now: 17-30% review quality lift across six domains; serving Anolis ANCK kernel, 70k+ patches reviewed, gate accuracy 97%, merge rate 62%.

Code Fix Evolution: Alert → Auto Fix (PolarDB-X Loop)

Sheng Taotao, Senior R&D Engineer. Personal anecdote: two-line fix took a whole day log/monitor analysis, near a week to reproduce across meeting gaps, then test cases, code review. AI writing two lines saves little; want Agent to own alert-to-fix-delivery loop. Exposed existing APIs/CLI for Agent to query monitoring, logs, instance topology. For legacy platforms lacking tools, Agent references existing impl, analyzes web requests/auth, wraps needed functions as CLI. For run verification: re-implemented JDB CLI on Java Debug Interface for structured returns, session management, thread-specific breakpoints; servitized large heap dump analysis; provided PolarDB-X Zero second-level temp instances and full K8s clusters for repro. Now running continuously in cloud: 100% alerts get Agent first-pass analysis/handling; half year, 200+ defects identified from 10k+ alerts, >70% stably reproducible, Agent fixes enter review. Three engineering heuristics: R&D systems must be callable, R&D processes verifiable, tasks runnable 7×24 in cloud.

R&D Collaboration Evolution: Coding Efficiency → End-to-End Delivery (Cloud Communication)

Zhao Bin, Senior R&D Engineer. Traditional: coding is one link between requirements, design, test, release, acceptance. When coding accelerates but up/downstream still human-handoff, work piles up at next manual node. Goal shifted to end-to-end delivery. First solve: how Agents collaborate. Cloud digital-twin-driven automated delivery pipeline runs 7×24, covers domestic SMS, intelligent voice, intelligent scheduling, international SMS. Single twin handles 3-4 requirements in parallel; ~2/3 of gated simple requirements achieve end-to-end auto-closure. Post-delivery audit of process, artifacts, Agent execution; effective experience written back to knowledge base. Detours: rushed models, underestimated domain jargon/historical knowledge complexity, context hallucinations affected judgment.

Full-Domain Ops Evolution: Manual Fault Injection → Scalable Benchmarking (STAROps)

Lou Haibin, Technical Expert. Complete ops eval data = execution trajectory + supporting conditions + verification basis, with env-binding, time-binding, full causal chain. Four Agents collaborate: ScenarioAgent (topic selection), EnvironmentAgent (env build), BuildAgent (fault injection + evidence extraction), SupervisorAgent (quality check); humans set targets, acceptance criteria, final review. Real online issues can be reconstructed via mechanism restoration, equivalent replay, signal alignment into eval sets. Five quality dimensions: quality, coverage, discrimination, scale, freshness. Platform accumulated 1,400+ eval records; root-cause eval set grew 10× in half year (58 in Mar → 838 in Sep), covering 100+ root-cause fault types. Fault injection is just one step; real difficulty: every record verifiable, sedimentable, continuously runnable. Only after this is solid does intelligent ops capability improvement have a trustworthy measurement foundation.

Org Evolution: Agentic SOC Security Product Self-Evolution Behind Org Restructure

Ren Yi, Senior Security Expert. As more improvements done by Agents, humans must pre-set four boundary types: goals, quality, permissions, stop conditions. After tech loop closed, org adjusted: integrated product, R&D, security into one team; each requirement owned by one Owner from goal definition to result acceptance; product experience, engineering delivery, security effectiveness advanced in parallel under same standards. Traditional serial ~51 days scheduling → ~14 days. Role boundaries stretch forward/backward around outcomes—not everyone does everything. Standardized, evaluable, rollbackable tasks: Agent executes, human approves. Cross-domain but risk-contained: Owner + Agent closes loop. High-risk, high-ambiguity, irreversible: pros lead. Phase data: avg requirement cycle 50.9→13.8 days; window throughput 63.9%→98.9%; ARR growth >100%. Lesson: restructuring tech alone insufficient. When Agents run around final outcomes, org must also rally around same outcome—shared goals, unified acceptance, end-to-end accountability, risk division.

Product Ops Evolution: Process-Driven → Agent Digital Human Team Growth

Wang Xizheng, Senior Product Ops Expert. Product launch/growth entering Agentic era. Gartner/Salesforce: AI share of marketing work 16%→36% by 2028. Content production, GEO optimization, acquisition AI adoption rising; new problems: attribution harder, content updates lag product iterations. Response: shift from process-driven to Agent collaboration. Full marketing campaign used to take months; now one week. Human effort reallocation: was mostly asset production; now ~20% production collaboration, ~80% judgment/decision. Built marketing growth Agent digital employee team: 2 humans + 1 Leader Agent + 6 Worker Agents (topic selection, content creation, opportunity management, business analysis, product knowledge, traffic optimization). Four main pipelines: full product launch, new feature release, opportunity management, data analysis. Coordinating 100+ roles across product, R&D, architects, ops. ~10× efficiency gain.

4. Still Early Stage

Seven sample rooms took different paths. Cloud Communication binds partial responsibility to employee digital twins; Agentic SOC tries single Owner spanning original functional boundaries; Kitta and STAROps focus on evidence, gates, repeatable eval; Product and Ops teams adjust rhythm and division of labor. All involve how process and responsibility sync when Agents enter production. Teams still separately defining goals, permissions, acceptance, accountability—no unified practice yet. From cases, teams invest more in problem definition, context quality, result acceptance, responsibility division; also trying to codify personal experience into Context, Skill, Eval, Harness, or platform capabilities. Cross-team reusability needs more production data validation. One forum yields no conclusions. Next seven deep-dives will return to each sample room: problem background, process adjustment, gate setup, failure handling, current boundaries.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

platform engineeringsoftware engineeringAgentAlibaba CloudAI-nativeorganizational transformationhuman-AI collaborationR&D organization
Alibaba Cloud Infrastructure
Written by

Alibaba Cloud Infrastructure

For uninterrupted computing services

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.