AI is rewriting the software R&D process, and it has pushed R&D organizations to the front line of change. That is why the term "AI-native organization" has become so popular. But popularity on its own is not the reason we are speaking up now.
The practices that the Alibaba Cloud CTO product-and-R&D line has been running around its business North Star goals have already produced some local results, and have also begun to expose harder problems: once AI-native practices move into deep water, single-point efficiency gains and local optima are nowhere near enough. An R&D team is never an isolated system; it sits inside business, organization, and industry-wide collaboration. We have decided not to wait for the answers to mature, and to share real progress, real confusions, and unsolved questions while the exploration is still under way. We hope to test our thinking against other R&D organizations and to spark one another, so that "AI-native R&D organization" can grow from an eye-catching concept into a new organizational paradigm.
This article looks back briefly on the "AI-Native R&D Organization Forum" at the Apsara Conference and summarizes some of its best viewpoints and most useful practices. For reasons of space, this review follows the organizational dimension; seven implementation practices will each be developed in seven separate articles.
Tang Hong, VP of R&D, Alibaba Cloud, reviewed the technological changes of recent years, starting with the speed of those changes. He traced a timeline: at the end of 2022, ChatGPT showed everyone that a general-purpose pre-trained model could solve many problems, so there was no longer a need to build a specialized model for every field; once reasoning models appeared, models could do more than carry on a conversation — they began to think for longer and to help people solve problems; and then, with tools and memory connected, Agents began doing the work directly, taking in a goal, making a plan, executing tasks, reading tool feedback, and correcting and iterating based on the results.
He summarized today's agentic computing paradigm as "model plus Harness plus Context": the model handles understanding, judgment, and real-time decision-making; Context supplies comprehensive, unified, continuously updated context; and the Harness takes care of the agent's autonomous operation and continuous evolution. As this paradigm becomes clearer, with model capability still improving and compute getting gradually cheaper, Agents will step into each stage of production one by one. The question then becomes: how do we use Agent capability well, and turn potential productivity into actual productivity?
Over the past three months, the Alibaba Cloud CTO line launched a round of AI Native exploration aimed at the R&D organization itself. Tang Hong stressed that this exploration is not intended to solve one specific technical problem, nor to produce one particular product, but is directed at the organization: thinking about how to use AI to solve organizational and collaboration problems and to create real value.
Out of this exploration he put forward three judgments. First, Agents entering the production pipeline is the real watershed. Second, AI Native is not simply about cutting costs — "cost reduction comes first" — and what matters even more is a leap in the dimension of competition. Third, AI Native will go through three stages: first tool-native, where individuals learn to use Agent tools well; then workflow-native, where work that once required many steps is carried through by Agents as far as possible; and the long-term goal is organization-native, where the whole organization works in an AI-native way. Tang Hong also emphasized that technology is advancing very quickly and that they are still exploring themselves. They would not claim that the forum offered a standard answer; they hoped to use the occasion to compare notes, test each other's thinking, and throw out a brick in the hope of drawing out jade.
Cai Liang, Head of Organization Development, CTO Organization, Alibaba Cloud Intelligence Group, explained the starting point of this exploration from an organizational perspective. He pointed to the typing shops and data-punching workshops of an earlier age: in every period, organization and management have been responding to the technological conditions and the supply of capability available at the time. In his view, technological change alters how scarce capabilities are, and the division of labor inside an organization must adjust along with it.
In his view, AI has not made the scarcity of individual capability, collaboration, and management disappear; at the same time it has added a boundary that did not exist before: for the first time, human beings have to work together with non-human intelligent agents. As Agents begin to take on tasks, there is no ready-made answer for how the new contract should be built. It will be a continuing process of exploration and construction.
This exploration sorts the questions into two categories. One is "growth" questions: optimize to the limit within the existing framework, and keep reviewing the whole chain — requirements, product, design, development, testing, release, and operations — for any space left to improve. The other is "evolution" questions: disrupt and rebuild everything between AI capability and customer value.
The exploration proceeds through a "North Star, white space, sandbox" approach. A North Star goal is critical: it mobilizes and inspires AI-native transformation and innovation, and it also decides which kinds of innovation deserve continued investment. White space means innovation does not have to wait until the management arrangements are fully prepared, and teams are allowed to cross their original role boundaries during the trial stage. The sandbox provides a supportive environment for experiments while limiting the impact on the main production chain as much as possible. Process metrics are used for observation and comparison and do not enter performance appraisal directly; the mode being used is one of "discovering new species", precisely to reduce the distortions that come from over-optimizing locally against a metric.
The selection criteria for a model room are that it has entered a real production scenario, that it has observable business results, and that its approach has the potential to be reused.
After several months of trials, some local results have appeared. For example, one project cut its end-to-end processing time from two hours to 5 minutes; another completed dozens of requirements in two weeks, shortened the release cycle from 40 days to 2 days, and distilled more than a dozen production-grade Skills. These figures do not represent overall performance, and which of the practices in the model rooms can be reused still needs to be verified. The staged practice has brought change on two fronts: first, core assets have started to be rebuilt, shifting from the artifacts themselves to the conditions that support trustworthy regeneration; second, the platform-level needs of the next stage are converging on three directions.
The panel was moderated by Cai Liang, Head of Organization Development, CTO Organization, Alibaba Cloud Intelligence Group. The three guests were Tang Hong, Vice President of Alibaba Cloud Intelligence Group and Head of CTO Office; Han Hongyuan, Vice President of Alibaba Cloud Intelligence Group and Chief Architect of the Public Cloud Division; and Bian Sikang, Head of Product and Operations, Ant Bailing and AAIF Ambassador.
Unusually for this forum, the panel was placed ahead of the seven practice topics. The purpose was to supply context for the forum and make the audience feel more involved.
Cai Liang: For the first question I'll go to Brother Hong. You are an AI Native practitioner, and you are also part of the management of an R&D organization of more than six thousand people. How do you personally practice AI Native? What has it actually done for you, and what is its value to you?
Tang Hong: Let me say up front that we tried to rehearse this, but every attempt came out as unstable as a model output, so this time we decided to improvise. I haven't been asked this question before either. I started writing code on computers in middle school, and I have since been through the PC, internet, mobile internet, and cloud computing eras. One thing I feel very strongly today is that my enthusiasm for writing code has come back to the level it was at in middle school, at graduation, and when I first started working.
When a new technological era arrives, the first thing is still to stay humble and genuinely learn it. Technology looks as if it rises in a spiral: in each turn you can see the shadow of the past, but every rise also brings a change in quality. If you ask me what AI Native is, I feel I have to use it myself first — first try to change how I handle problems, and then change how the people around me solve problems. Only by getting into these problems for real will you know what it actually is.
Cai Liang: Brother Hong has jumped in first. Old Han, tell us about yourself too.
Han Hongyuan: I may be the only person here who does not write code. I have never done coding as a full-time job, but I am the person who takes what code produces and finally delivers it to the customer.
There are at least three words connected with code: Coding, Programming, and Software Development. In the end they may all come down to Coding, but the differences between them are large. Having written code does not mean you have Software; at best you may only have a program that runs.
Real software has a great many functional and non-functional requirements. Many tools today are called Coding Agents because Coding is where the volume of work actually gets done; but inside Software there are far too many things that Coding cannot resolve directly. Whether a piece of code can be turned into software that is genuinely deliverable, sellable, and able to run sustainably — there is a great deal still to be discussed in that space.
Cai Liang: Brother Hong said he had to jump in himself; what Old Han is really asking is whether you are laying bricks or building a cathedral. Sikang, what about you?
Bian Sikang: Laying bricks can build a cathedral, and it can also build a market.
This year there is a kind of anxiety aimed at programmers: people who never wrote or understood software suddenly show up and say that the code you create is worthless. But code has always been only part of the software service as a whole; it is closer to a raw material. Turning code into good software, and then turning software into good service, involves a very long industrial chain.
So I remain bullish on SaaS in the long run. Customers' specific needs will not disappear just because code has become cheaper. I have not met the customers Old Han has met, so I cannot claim to understand that customer — that would be arrogant. What may really change is the way software is delivered.
I quite like one formulation: SaaS is still SaaS — which can also be read as "Service as Software". The cost of coding has come down, while the other requirements for release readiness and evaluation may well go up. The raw material looks the same, but the architecture, the fit-out, and the whole industrial chain will all change, and the demand for professional capability will not go down.
Cai Liang: We were just talking about laying stones or building a cathedral. But cathedrals come in many kinds too: Alibaba Cloud builds PaaS, kernels, and foundational software, while other teams may be building application software. Will different kinds of R&D organizations be hit by AI in different ways? Old Han, you go first.
Han Hongyuan: The last word to be modified by "native" was cloud native. Back then there were long arguments too, but at least there were criteria of the kind in the Twelve-Factor App. Now that we talk about AI Native, it seems we have not found comparable criteria yet.
If I have to give one direction, I think it is this: let AI do everything in the organization that AI can do, but once that is done, the North Star metrics must not go down.
Much of the difference between software and a program comes from running it, checking it, and re-verifying it. Requirements and tests never cover all the problems that exist in production, and AI probably cannot do that today either. So some programs can be throwaway, but I do not believe real software will be throwaway. Software has to go through a complete lifecycle from design and production through to inspection, and it has to survive enough real running, before it can become mature.
This is especially true of lower-layer infrastructure software, where the non-functional requirements, architectural governance, and the ability to keep evolving matter far more than getting the code written. Those things still have to be hammered out over a long time.
Cai Liang: If most of the cost of developing software used to come from the development team, and code generation has become ever cheaper, do you think the scarcity of capabilities and the capability requirements have changed within the Alibaba Cloud CTO line?
Tang Hong: They have certainly changed. It is precisely because code generation has become cheaper that other problems have been laid bare.
The traditional waterfall software process took it as given that labor was the most expensive cost, so the aim was to avoid rework at almost any price, with design review after design review and spec review after spec review. Now software iterates faster and faster; if the process stays heavy, the earlier stages become the new bottleneck.
A great many things used to rely on the division of labor inside the organization, on human gatekeeping, and on handoff through people. But a handoff between people is usually slower than one between machines. Product managers have started doing engineering work and engineers have started doing product work, because as soon as there are two different entities involved, their views may differ, and coordination has a cost.
Let me give a real example. In the past the front-end repository and the back-end repository were separate: the back end would release a version first, and the front end would understand the semantics and then integrate. When change was slow, that was fine. Today both sides are iterating quickly; the back end may have moved far ahead, and the front end may not be able to connect at all. So the best approach may actually be to put the code in one repository and change it together.
Going further, even what software is may need to be redefined. From punch cards to assembly language to high-level languages, software has consistently acted as the bridge between human intent and machine execution. In the future there may be a form of expression that is more reliable than natural language yet different from a traditional programming language, one that lets Agents complete tasks more accurately.
So the definition of software, software engineering, and the role of people within it may all change comprehensively. Many questions have no answer today, but I am quite optimistic: where there are problems, there are opportunities.
Cai Liang: What we build is not code — what we want is software. And what we want is not only software but service, and even the customer's smile.
Bian Sikang: At the start of every technological cycle, something gets reorganized. Before big data arrived, there were no data analysts or Data Scientists in today's sense. These new roles come from new technology, but the problems they have to solve have not essentially changed: customers still need to know how to run their business better and how to handle supply and demand.
You cannot get giddy because an opportunity has arrived and think that Vibe Coding will let you build an enterprise-grade system directly. Good performance engineers and good security engineers are still professionals formed by years of training. Workloads will change in the future, REST APIs may become Tokens, and the way systems are designed will change too, but professional problems such as structure, security, and performance will not disappear.
What will really change is delivery on the customer side, and customers' imagination of new things. Customers sometimes cannot articulate what they want; you need creative people to build a new work first, so that everyone realizes "so it can be done this way too". Age is not necessarily the most important thing; what matters more is staying open, and using scientific methods to keep discovering new things.
Cai Liang: We keep saying "let the professionals do the professional work", yet the boundaries of professionalism seem to be blurring. We used to have technical committees, professional domains, and role standards, but these standards are increasingly hard to define now. Customer needs are changing, and tools are changing too — so is professionalism still valuable, and where exactly does it still apply?
Tang Hong: People used to ask which kinds of intelligence AI could master and which were abilities reserved for humans. Later someone used the sea and small islands as a metaphor: human expertise is like the islands, and the scope AI can cover is like the sea level. As the sea level keeps rising, fewer and fewer "expert islands" stay above water.
Today AI is still not good enough at product design, interaction, and complex non-functional design, but it is clearly improving. Some system problems that were formerly very hard can also be solved jointly through language, tools, and an engineering system. AI does not solve everything out of thin air, but given the right tools it can enter more and more professional domains.
This means experts will not simply disappear, but the bar for being an expert keeps rising.
Even so, I think there is one thing that remains rather unique to humans: if the product is ultimately used by people, then whether it is pleasant and comfortable to use involves taste and product sense. That may be an ability that is very hard to retire completely.
Cai Liang: Let's "wait and see" on that conclusion for now. By your own logic just now, it may only be a question of when.
Cai Liang: Old Han, from the customer's point of view, is everyone actually at the same stage right now? People all say they are exploring, but the real progress is completely different.
Han Hongyuan: The benefit of some changes is already visible. Product people are entering the development domain and developers are entering the product domain, and this overlap helps collaboration. A lot of the friction in software R&D used to come from poor handoffs between stages; if you never step into the other side's territory at all, the handoff cannot truly be smooth.
But there is another problem: models are changing fast, and everyone says models may swallow the capabilities at the edges. Software used to love determinism and fear uncertainty; now the model brings uncertainty directly into the system.
I have long held one view: if you wrote an AI application, and after a new generation of models is released that application cannot make any use of the model's enhanced capability, then you should reflect on whether you are really using AI at all. Your system should not lock the model to an old version.
But conversely, you also cannot take the fact that code-writing has become stronger and directly infer that AI can already replace people from end to end. Take MySQL: it has complete documentation, clear interfaces, and plenty of well-known problems. Has anyone today used AI to rewrite a better MySQL and actually replace it? Not yet.
A compiler can finish in one run; a database has to run continuously. For infrastructure-class software, whether AI can write it in one pass and have it run reliably over the long term has not been adequately validated. So on this matter I lean conservative.
Cai Liang: The more others depend on you, the more stability matters; and while we depend on the systems below us, the users above us depend on us.
Han Hongyuan: Exactly. The complexity a great many pieces of software appears to have is far below the complexity they actually have.
Bian Sikang: Han Hongyuan and I had not compared notes, but what he said about MySQL reminds me of a conversation. I said MySQL is infrastructure, and a former leader of mine said: "Stop — MySQL is not infrastructure, MySQL is an application." Because what he worked on was containers and the operating system.
That carries a message: the infrastructure we live on today did not exist before a certain era; and below it there is always its own infrastructure. So we may well be at a very untamed stage right now.
The state a model is in already carries instability. You give a model a prompt, it returns a strange result, and sometimes that is not a bug but its most fundamental characteristic. It is like a brick that is not quite regular — it is even more like cement. It brings problems that have to be solved, but for many people it is also an opportunity to rediscover, create, and build.
The Harness is the same way. Once the simple problems are solved, the problems of the next stage will require more testing, and testing itself has to face uncertainty.
Software is deterministic, but the human world is not. In the past we used software to converge part of the uncertainty into deterministic processes; now we are using a non-deterministic model to meet customers' non-deterministic needs, so the layer in between has to be redesigned.
The "Service as Software" as I understand it still holds: abstract the deterministic parts into Building Blocks, then stack them together with the model and Context to meet customers' uncertain needs. It may be more a change of perspective than a complete overturning of everything. Engineers still have the opportunity to re-adjust and re-adapt, and I do not think this is just a question of "who gets eliminated".
Cai Liang: One last question. If you are heading toward AI Native, and you could add exactly one mechanism, or remove exactly one, which would you choose?
Tang Hong: I cannot answer this question quite as it is posed, because the mechanisms in an organization are interlocked: if you change only one piece, it may not fit back into the puzzle at all.
If I have to name the most important change, I think you first have to believe it is coming. Everything could be broken, could be changed. Any rule may change; only, you cannot tear up all the rules and leave the whole road completely cut off. You have to find a path of evolution: break one thing here, change one thing there, but keep at least one route that still gets through.
For example, today software boundaries have to be defined very clearly: inputs, outputs, parameters, versions, forward compatibility, backward compatibility. But in the Agent era, some people are researching whether APIs can negotiate: I first ask what you can do, then search and choose, and services talk to each other the way people do.
Not all software has to be like that. Where the abstraction is very definite, for RPC or MySQL, it may not be necessary. But once uncertainty goes up, some boundaries may change.
So when you believe that future will certainly arrive, and you see it clashing with an existing rule, you should first examine whether that existing rule can be broken.
Cai Liang: That is, stay open. When something new clashes with past experience, don't let the knee-jerk reflex come first and try to prove that it shouldn't be happening.
Han Hongyuan: I will say two things. First, what an R&D organization most needs to change is breaking down functional boundaries. There has to be more overlap; AI can help you enter territory that was previously outside your scope of responsibility. Only with more overlap can communication become smoother.
Second, software has to go through enough running and inspection, and its maturity must come from there. If the code, the interfaces, and the contracts offered outward are all unstable, there is no way to verify repeatedly; and if you cannot verify repeatedly, every run may reintroduce risk. Many non-functional problems only surface once you are in production and have been validated across enough customer environments.
Cai Liang: That sounds like two opposite positions: one side wants to break boundaries, the other wants stable contracts.
Han Hongyuan: During development, break the functional boundaries between people; once you actually enter system-level runtime, the contract can only be adjusted step by step. You cannot write a Windows end to end today — Windows still has to be built in layers.
Cai Liang: Understood. So boundaries should not keep being tied to people, but where the boundaries move to, and what carries them instead, is something we won't have time to open up today.
Bian Sikang: I am not sure this counts as a mechanism. If the question is what to do less of, I would say: ask less often "why doesn't this thing exist yet", and ask less often "is this my job".
The characteristic of chaotic eras is that some things simply do not exist, and that is that. Then you can write it, you can create it. Organizational boundaries evolve over the long run, and in between there is always a transitional state. Rather than repeatedly debating whether this one falls to me, it is better to ask first: the business's and the customer's problem has not been solved — can I do a bit more?
If the question is what to do more of, I would choose "tools". Right now we are short of new tools, and short of new "atomic capabilities" — in quotation marks.
When an Agent sends an email, it will probably call Gmail or Alibaba Mail; it will not usually rebuild a mail system from IMAP. A tool wrapper that is good to use can be regarded, roughly, as a kind of atomic capability. The middleware of the future may well come from reconstructing these atomic capabilities.
Too little of this is being done today. In the past engineers were not necessarily encouraged to do this kind of thing, because it looked too small; but today it may in fact be harder and more important, because many capabilities need to be abstracted again.
Cai Liang: Let's leave this topic hovering here for today.
The forum covered seven dimensions — product design, code review, code repair, R&D collaboration, operations evaluation, cross-functional collaboration, and product operations — and for each one set out what work Agents took on at different stages of production, what people remained responsible for, and what new problems appeared after implementation. For reasons of space, the seven implementation practices below are not covered in detail; seven separate articles will be published later.
Zhong Yaorong, Director of Product Management, Alibaba Cloud Intelligence Group
In practice we have felt ever more clearly that producing product design documents is no longer the bottleneck; what is genuinely scarce is product judgment and understanding of the customer. So we did not just build a PRD generation tool. We re-mapped the complete value chain of product design, and underneath it we built a knowledge system that runs through the whole chain.
Today, about two thirds of requirements no longer need to be examined one by one by a person, and the accuracy of value judgments exceeds 90%; requirement response time has fallen by 45%, and backlog handling efficiency has improved by more than 50%. About 80% of PRDs are now generated by AI, and the time to produce one end-to-end product experience review has also gone from 4 hours to 30 minutes.
Zhou Yuanhang, Technical Expert, Alibaba Cloud Intelligence Group
The relevant data has already given us a warning: total CVE reports across the software industry grew by 394% and high-severity vulnerabilities by 811%; the code bug rate rose by 9%, the average PR size grew by 154%, and review time increased by 91%. In the OpenAnolis community, the monthly PR merge volume of the two main kernel distributions grew 8.9 times over two years. So AI Native R&D cannot stop at using AI to write code; it also requires an Agentic CI that spans code production, verification, and delivery, and code review is precisely the first quality gate in it. Once we really entered large open-source projects, we found that AI can understand a piece of code but does not necessarily understand a project. It does not know the domain knowledge, development conventions, and routing rules a project has formed over a long time, and it does not know in which cases it should alert a person and in which cases it should hold back.
Around these problems we built Kitta in three steps: first distilling review principles, typical defect patterns, and project conventions from the real history in GitHub, LKML, and project repositories; then using a two-wheel design — "the process definition decides where to look, the knowledge decides how to look" — to adapt to the development context of different projects; and finally calibrating continuously through offline evaluation and real online behavior.
So far Kitta has achieved a 17%–30% improvement in review quality across six major domains, and it already serves the ANCK kernel distribution in the OpenAnolis community. It has reviewed more than 70,000 patches in total, with a gate accuracy of 97% and a code merge rate of 62%.
Sheng Taotao, Senior R&D Engineer, Alibaba Cloud Intelligence Group
I once handled a bug where only two lines of code were actually changed, but reading logs, watching monitoring, and analyzing the problem took a whole day. To reproduce the issue I could only squeeze debugging into the gaps between meetings, and it took close to a week to finish, after which I still had to add test cases and follow up on code review. If AI only helped me write those two lines, it would not save very much time at all. What we wanted to hand over to it was the whole process, from alert to delivering the fix.
To that end, we use existing APIs and CLIs so that the Agent can query monitoring, logs, and instance topology on its own. For legacy platforms that have no ready-made tools, the Agent refers to existing implementations, analyzes the web requests and the authentication method, and wraps the functions it needs into a CLI. For run verification, we re-implemented a JDB CLI suited to Agent invocation on top of the Java debugging interface, supporting structured returns, session management, and breakpoints on a specified thread; at the same time we turned the analysis of large Heap Dumps into a service, and we provide two kinds of reproduction environment: PolarDB-X Zero second-level temporary instances and full K8s clusters.
This pipeline now runs continuously in the cloud, and 100% of alerts go through a first round of analysis and handling by an Agent. Over the past half year we identified and recorded more than 200 defects out of tens of thousands of alerts, over 70% of which reproduce stably and, after the Agent completes the repair, go on to review. These practices gave us three engineering lessons: R&D systems must be callable, R&D processes must be verifiable, and tasks must also be able to run 7×24 in the cloud.
Zhao Bin, Senior R&D Engineer, Alibaba Cloud Intelligence Group
In traditional R&D, coding is only one link among requirements, solution, testing, release, and acceptance. When coding speed rises sharply but the links before and after it are still stitched together by people, work simply piles up faster at the next manual node. So we moved the goal from single-point coding efficiency to end-to-end delivery. The first thing to solve was how Agents collaborate with one another.
This automated delivery pipeline, driven by digital avatars in the cloud, runs 7×24 and now covers four business lines: domestic SMS, intelligent voice, intelligent scheduling, and international SMS. A single avatar can handle 3–4 requirements in parallel, and among the simple requirements that pass the gate, about two thirds can be closed end to end by themselves. After each delivery we audit the process, the artifacts, and how the Agent behaved, and write effective experience back into the knowledge base. Along the way we also took some wrong turns: rushing to adopt a model, underestimating the complexity of domain jargon and historical knowledge, and being misled in our judgment by context hallucinations.
Lou Haibin, Technical Expert, Alibaba Cloud Intelligence Group
We hold that one complete piece of operations evaluation data should contain the execution trace, the accompanying conditions, and the basis for verification at the same time, and should achieve environment binding, time binding, and a complete causal chain. STAROps uses four Agents with a division of labor: ScenarioAgent selects the topic, EnvironmentAgent builds the environment, BuildAgent injects the fault and extracts the evidence, and SupervisorAgent performs the quality check-up; people are responsible for setting the goal, defining the acceptance criteria, and doing the final review. Real incidents that have happened in production can also be re-constructed into evaluation sets through mechanism restoration, equivalent replay, and signal alignment. We examine every single data item along five dimensions: quality, coverage, discrimination, volume, and freshness.
The platform has accumulated more than 1,400 evaluation data items. The root-cause evaluation set grew to more than ten times its size within half a year, from 58 entries in March to 838 in September, covering more than 100 categories of root-cause faults. Fault injection is only one step in the whole process; what is genuinely hard is making sure every data item is verifiable, can be accumulated, and keeps running. Only when this is done well does improving intelligent operations capability have a credible basis for measurement.
Ren Yi, Senior Staff Security Engineer, Alibaba Cloud Intelligence Group
As more and more improvements are made autonomously by Agents, people have to set boundaries in advance in four areas: goal, quality, permissions, and stopping conditions. After the technical loop was working, we also began to adjust the organization: product, R&D, and security were merged into the same team, each requirement is carried by one Owner from defining the goal through to accepting the result, and product experience, engineering delivery, and security outcomes advance in parallel under one and the same set of standards. The roughly 51-day schedule of the traditional serial approach was shortened to about 14 days. Role boundaries have also begun to extend forward and backward around the result, but this does not mean everyone has to do everything. Tasks that are clearly defined, evaluable, and reversible are executed by Agents and approved by people; tasks that cross domains but carry controllable risk are closed out by the Owner with the help of Agents; high-risk, highly ambiguous, or irreversible tasks are still led by specialists. In the staged data, the average requirement cycle fell from 50.9 days to 13.8 days, throughput within the window rose from 63.9% to 98.9%, and ARR grew by more than 100%.
What we have learned is that re-engineering the technology alone is not enough. Once Agents are already operating around the final result, the organization also has to rebuild, around that same result, a shared goal, unified acceptance, continuous accountability, and a division of risk.
Wang Xizheng, Senior Technical Operations Expert, Alibaba Cloud Intelligence Group
Our judgment is that product launch and growth have also entered the Agentic era. Surveys by Gartner and Salesforce indicate that the share of marketing work carried by AI will grow from 16% today to 36% by 2028. The use of AI is rising in content production, GEO optimization, and lead generation, but new problems come with it — for instance traffic attribution has become harder, and content updates often cannot keep pace with product iteration.
Our response is to move from process-driven work to Agent collaboration. In the past, one complete marketing Campaign took months to prepare; now the whole thing can be run through within a week. How people spend their energy has changed accordingly: formerly the bulk went into producing materials, and now about 20% goes to production collaboration and 80% to judgment and decision-making. We formed an Agent digital workforce for marketing growth, made up of 2 natural people, 1 Leader Agent, and 6 Worker Agents. The 6 Worker Agents are responsible for content topic selection, content creation, opportunity management, business analysis, product knowledge, and traffic optimization respectively, and together they run four main pipelines: the full product launch process, new feature release, opportunity management, and data analysis. They collaborate with more than 100 roles across product, R&D, architects, and operations, delivering roughly 10 times the efficiency.
The seven model rooms took different paths. Cloud Communications tied some responsibility to an employee's digital avatar; Agentic SOC tried to have a single Owner run through what used to be functional boundaries; Kitta and STAROps paid more attention to evidence, gates, and repeatable evaluation; and the product and operations teams were adjusting work rhythm and division of labor.
Every one of these cases involves how processes and responsibilities are adjusted in step once Agents enter production. Each team is still defining goals, permissions, acceptance, and accountability separately, and there is no unified approach yet. Looking at the cases so far, teams are putting more of their effort into problem definition, context quality, result acceptance, and the division of responsibility, and are also trying to turn individual experience into Context, Skill, Eval, Harness, or platform capability. Whether these practices can be reused across teams still needs more production data to verify.
One forum is not enough to draw conclusions. The seven follow-up articles will each return to one model room and cover the background of the problem, the process changes, how the gates were set, how failures were handled, and the boundaries as they stand today.
Alibaba Cloud SLS Unveils a Major Upgrade to Build the Intelligent Data Engine for the Agent Era
803 posts | 61 followers
FollowAlibaba Cloud Native - September 4, 2024
Alibaba Clouder - April 2, 2020
Alibaba Cloud Native Community - June 23, 2026
Alibaba Clouder - December 31, 2020
Alibaba Cloud Native Community - December 6, 2022
Alibaba Cloud Community - March 8, 2022
803 posts | 61 followers
Follow
AgentCore
AgentCore unifies agent construction, governance, and execution capabilities so enterprises can deploy diverse agents with confidence.
Learn More
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Token Plan
Build more, spend less. One plan, every modality.
Learn More
Cloud-Native Applications Management Solution
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn MoreMore Posts by Alibaba Cloud Native Community
